To play devil's advocate: The hypocrisy that was pointed out in the post are post "post compile" events.
If you want to setup Play Services, that's on the onus of the user, same thing with distribution of GPLv3 applications.
The problem is that the utilizing GPLv3 code during compliation (and yes it's technically copying the APK more or less) of the operating system, means that it trips some of GPLv3's linking requirements.
Don't get me wrong, I'm all for accessibility, but coming under legal fire is a big no-no for many open source projects.
strcat•8mo ago
Including GPLv3 code within a GrapheneOS release would make GrapheneOS more restrictively licensed than the Android Open Source Project (AOSP). GrapheneOS is meant to be usable everywhere AOSP can be used. It's meant to permit making a locked down device if desired. It's not what we want for GrapheneOS ourselves, but we want organizations using it to be able to make that choice. Some organizations won't use devices which can be unlocked, so GrapheneOS would never be usable for them if it prevents having a locked device variant.
There are permissively licensed text-to-speech implementations including ones more modern than eSpeak NG. We haven't had time to properly review them, fork one and integrate it into GrapheneOS. Text-to-speech is fully usable on GrapheneOS, but the app needs to be installed. Including text-to-speech in the OS with it pre-configured and working out-of-the-box is a planned feature. It can take a long time to get planned features implementations, particularly if we need to make hard choices about what to use as we do in this case. We aren't sure which app we want to use yet. These decisions are very difficult to ever change since users have an expectation of things not changing or especially breaking their existing setups. It's not something to be taken lightly.
We don't need to include GPLv3 code in GrapheneOS to provide text-to-speech. We just can't use one of the implementations, eSpeak NG, which is also largely written in C code that's not particularly modern or battle hardened. Since this would be something enabled by default and exposed to untrusted input, we would greatly prefer something more security oriented.
Android 1.6 added SVOX Pico as a text-to-speech implementation. SVOX Pico was a dead project for ages and was replaced by a closed source Google TTS app. SVOX Pico turned out to have all kinds of memory corruption bugs and it was a major issue for our hardening features when it was still around, often crashing or having corrupted output due to memory protections. It had lots of use-after-free bugs, etc. It was eventually removed from AOSP due to being a major security issue. By then, it was also a terrible text-to-speech app compared to mainstream options. We couldn't justify keeping it around. This was also before we had a fork of TalkBack (screen reader) included in GrapheneOS. After we added TalkBack, we've looked for a text-to-speech implementation we can use but the existing options were missing Direct Boot (Before First Unlock) support and had licensing issues for their code and/or language support.
theossuary•8mo ago
Really appreciate the work you guys are doing with GrapheneOS, it's the only OS I'll run, and I don't know what I'd do without it
qmarchi•8mo ago
If you want to setup Play Services, that's on the onus of the user, same thing with distribution of GPLv3 applications.
The problem is that the utilizing GPLv3 code during compliation (and yes it's technically copying the APK more or less) of the operating system, means that it trips some of GPLv3's linking requirements.
Don't get me wrong, I'm all for accessibility, but coming under legal fire is a big no-no for many open source projects.
strcat•8mo ago
There are permissively licensed text-to-speech implementations including ones more modern than eSpeak NG. We haven't had time to properly review them, fork one and integrate it into GrapheneOS. Text-to-speech is fully usable on GrapheneOS, but the app needs to be installed. Including text-to-speech in the OS with it pre-configured and working out-of-the-box is a planned feature. It can take a long time to get planned features implementations, particularly if we need to make hard choices about what to use as we do in this case. We aren't sure which app we want to use yet. These decisions are very difficult to ever change since users have an expectation of things not changing or especially breaking their existing setups. It's not something to be taken lightly.
We don't need to include GPLv3 code in GrapheneOS to provide text-to-speech. We just can't use one of the implementations, eSpeak NG, which is also largely written in C code that's not particularly modern or battle hardened. Since this would be something enabled by default and exposed to untrusted input, we would greatly prefer something more security oriented.
Android 1.6 added SVOX Pico as a text-to-speech implementation. SVOX Pico was a dead project for ages and was replaced by a closed source Google TTS app. SVOX Pico turned out to have all kinds of memory corruption bugs and it was a major issue for our hardening features when it was still around, often crashing or having corrupted output due to memory protections. It had lots of use-after-free bugs, etc. It was eventually removed from AOSP due to being a major security issue. By then, it was also a terrible text-to-speech app compared to mainstream options. We couldn't justify keeping it around. This was also before we had a fork of TalkBack (screen reader) included in GrapheneOS. After we added TalkBack, we've looked for a text-to-speech implementation we can use but the existing options were missing Direct Boot (Before First Unlock) support and had licensing issues for their code and/or language support.
theossuary•8mo ago