Antsyboi
GrapheneOSIn order to provide better support for blind users, we maintain a fork of the open source TalkBack app fixing serious issues with it, modernizing it and making the builds reproducible. One of the goals of making our own Setup Wizard has also been integrating TalkBack support.
Google unfortunately doesn't publish the source code for each stable release of TalkBack as they do for Android itself. The open source release of the app lags significantly behind. It also has a bunch of missing and broken features. We plan to gradually improve this situation.
In order to use GrapheneOS, blind users need to successfully install the OS and set up the device to be usable with a screen reader. This is an area we've been thinking about and working on improving for a while. Our new Setup Wizard provides a better base for integrating this.
The first barrier to someone using GrapheneOS without sight is installing the OS. We've done what we can to make our web installer as accessible as possible (https://grapheneos.org/install/web). However, users need to interact with the device's firmware interface which the user can see.
Due to the inaccessible firmware user interface, it's difficult to perform the installation correctly and safety, particularly confirming unlocking and then confirming locking. Confirming the verified boot key matches after installing/locking would require OCR on another device.
The next issue is the Android Open Source Project no longer includes a text-to-speech app. Pico TTS used to be included in AOSP but was not what Google Mobile Services devices use. It was quite primitive, awful to use and AOSP removed it after security issues were found.
We've wanted to include a text-to-speech app and bundle a language pack to have it working out-of-the-box for a long time. We could then add a shortcut for enabling TalkBack in our new Setup Wizard to make things accessible from the start of the post-install setup process.
To provide what we need, the TTS app needs to be built into the OS, enabled and set up to work by default without configuration. It doesn't do any good if you need to connect to a network and download a language pack. It also needs to work Before First Unlock via Direct Boot.
Since it will be enabled by default, security is quite relevant. It shouldn't be a bunch of C++ code without a modern coding style, use of sanitizers, decent tests, etc. It needs to be actively developed and properly maintained. This is why Pico TTS had to be removed from AOSP.
GrapheneOS is intended to be a drop-in replacement for the Android Open Source Project usable by companies to make all kinds of products. Due to this, we avoid non-commercial usage licenses. Lots of the language packs for TTS implementations have non-commercial usage licenses.
We also avoid including GPLv3 code in the base OS since it would add restrictions on how it can be used. We do add new GPLv2 licensed code. This doesn't mean we have issues with using GPLv3 code or making forks of GPLv3 projects, we just don't bundle it within GrapheneOS itself.
Neither eSpeak NG or RHVoice meets our security expectations (piles of problematic C and C++ code) and both have licensing issues. Both were previously also missing Direct Boot support to function Before First Unlock, but we requested it from both and eSpeak NG implemented it.
There were previously no good options available. Things have changed and there are multiple open source text-to-speech implementations which could be turned into a suitable Android app and integrated into the OS. This involves significant work and we haven't gotten to this yet.
We have hundreds of planned features. We've been working on some features for months or even years. We try to focus on features which would provide the most overall benefit to our users with a focus on improving privacy, security, compatibility and usability. It's subjective.
For example, built-in support for network location was a feature we wanted to integrate for years. Last year, we made it a top priority, and assigned a developer to solely work on it, so it got done. This is still being worked on to add cellular fallback and full offline support.
thereisnoanderson
eladnarra@GrapheneOS I think this post exemplifies a difference in approach that's causing issues.
For disabled folks, a lack of accessibility is a bug, not a missing feature. So our position is that it should be prioritized higher, not lumped into general features and improvements.
Focusing on things that provide the most benefit to users overall leaves out disabled people and accessibility by default, because we're a minority. One has to prioritize accessibility outside that subjective calculation.
@eladnarra GrapheneOS is an open source project. Blind people are 100% capable of doing software engineering and contributing to GrapheneOS. They're the people who know best about what they need and how to approach things. One of our contributors is in fact blind and helps us work on TalkBack along with helping to test it and a bunch of other things. There is a whole lot which has to be done simply to keep what we already have working. Expanding what we have requires more contributions.
@eladnarra We have a small development team and have had major setbacks due to attacks on the project, Google largely refusing to work with us and making our job harder with the Play Integrity API and recently our lead developer being forcibly conscripted to fight in a war. We're struggling just to continue the project already and are already dealing with a huge amount of hate and harassment towards us based on fabrications about us. Now we're dealing with another source of it. That's great.
@eladnarra Not clear how more attacks on us is going to improve things for our present and future blind users. This has already disrupted development, taken resources away from the ongoing port to Android 16 without the main person who did 90% of the recent ports to new Android versions, etc. Every GrapheneOS user including our blind users will be negatively impacted by the project and team being attacked with outrageously false claims about us. What should be cut to make up for it?
@eladnarra The port to Android 16 is essential to keep providing the latest privacy and security patches. Porting all of our features to Android 16 is not mandatory. Features can be dropped if needed. We're also going to need to narrow our focus and scale back what we're working on further.
The reason we have a bunch of largely unmodified AOSP sample apps is lack of resources to make a bunch of new apps meeting our standards, or to fork existing ones. The same goes for lack of translations.
@eladnarra We're successfully providing a highly private and secure OS with broad app compatibility and good stability. We're not able to do everything though. We cannot realistically make our own TTS app so we rely on there being one that's a reasonable starting point to include. Perhaps one of them is a reasonable starting point now. eSpeak NG cannot meet our requirements. Someone attacking us for not including eSpeak NG with a bunch of false claims about us is not going to accelerate this.
@eladnarra Several people have now told us about more recently created permissively licensed TTS apps which may meet our requirements.
If people put a fraction of the effort into helping us as they do harming us, things would be dramatically better as a whole.
Responding to these posts and posting about this on our timeline would have been development time. This time could have gone towards working on TTS if someone had reached out to us interested in helping us instead of hurting us.
@GrapheneOS @eladnarra I'm sorry, was he from the Ukraine by any chance?
em@GrapheneOS can you compile to wasm or otherwise sandbox them? tts seems like it wouldn’t require access to many capabilities
The Evil Chocolate Cookie@GrapheneOS so that blog person was exactly right, you’re the one setting the barrier. Also, you flat out stated it’s not much of a priority which means you’re putting us on the back burner for the fancy graphics and other crap. I’m already severely pissed off today, and you straight out admitting that we’re not the priority and all the other fancy shit is does not help.
d@nny disc@ mc²@GrapheneOS [i promise i'm not trying to cause a problem bc i really respect and trust your judgement on how things like licensing affect user control and i know GPL is not a panacea but a specific legal contract] i'm curious about the restrictions imposed by gplv3 here (i know linux is gpl2 as well). have you spoken on the specific difficulties it poses to the project before? [thanks and no need to reply i'm just curious and not trying to derail. i'm a bit of a license nerd is all]
Alex L 🕊 🇵🇸GPL is working as intended here. Possible solutions:
1. Companies comply with GPL
2. Companies fund a MIT licensed alternative
@alxlg There are multiple permissively licensed text-to-speech implementations including ones far better than eSpeak NG. We're being attacked because we don't want to bundle eSpeak NG but it's far from the best open source option anyway. The people attacking us have little interest in helping us review and fork one of the options, then integrating it into the OS, and that is why it's not done already. Attacking us only drains our resources and extends the timeline for incorporating this.
Can you stop with this whining? You are getting criticized for making sure your product is parasite-friendly. Criticism, not attacks. And you criticize other people's work a lot.
@alxlg We don't spread fabrications about other projects and their development teams as this highly dishonest post was doing.
We're giving away our work for free to the world to use for any purpose. A company working with us and giving back to the project are hardly parasites. On the other hand, how about people using it who are not only not contributing in any way, not making donations and are actively trying to harm us pushing spin and fabrications about us? What do you call that?
I don't care about these "fabrications", "attacks" etc. I am criticizing you because apparently you have no idea of FOSS dynamics:
Rejecting GPL is parasitic, those companies you are talking about are parasitic and you are making sure they will use your product for parasites.
It doesn't matter that you are a security genius, this is about politics, everyone can have their opinion, even criticize you just like you criticize others all the time.
@alxlg There are many open source projects including FreeBSD and OpenBSD where the GPL is strongly disliked and avoided. They have different views about what freedom means and regard the GPL as significantly less free.
GrapheneOS is not one of those projects. We don't have an issue with the GPL. We simply have a pragmatic approach to licensing. We want to keep GrapheneOS usable by a large number of tech companies avoiding GPLv3. Therefore, we stick to using it only outside the OS itself.
@alxlg We use GPLv2-only licensing for a portion of our own code by choice, to protect it from being used by a GPLv3 project which was taking our work without giving back. We tend to use permissive licenses in general. Our experience has been that people using our code without giving back are not hindered by licensing. GPL has almost never helped us protect against it. There's 1 case where we were able to use GPLv2 to protect ourselves from being leeched off without getting anything usable back.
@alxlg That 1 case involved a GPLv3 licensed taking our MIT licensed code while not allowing us to use their GPLv3 licensed code under a license acceptable to us. Therefore, we switched to GPLv2-only which helpfully forbids GPLv3. We had to use the GPLv2 additional permissions feature to permit 2 licenses incompatible with GPLv2 (Apache 2 and the FreeType License). It has mostly worked fine.
In other cases, people did not care what licenses we use and have simply taken our code without credit.
@alxlg In several cases, people have falsely taken credit for the code we have written. In a couple cases, they've claimed they own the code we've written and that we somehow aren't allowed to use it. GPLv2 termination clause proved valuable for after the fact license enforcement against one of the companies which disregarded our licensing and claimed ownership over our work. The usefulness was cutting them off completely due to past violations. That clause was removed in GPLv3.
@alxlg We did not get anything useful back via the GPLv2, we were just able to block 1 group using our code and making it GPLv3 and permanently severed another company's ability to use part of our code after the fact. Neither of these things got us back anything in return. We would have been better off if copyright didn't exist where neither situation would have been a problem for us in the first place.
Walter van Holst@GrapheneOS I rather doubt this is a common reading of the GPLv3. Could you elaborate on this?
@whvholst It is the common reading for GPLv3 and one of the primary reasons it exists. We want it to be possible to use GrapheneOS on locked down devices. GPLv3 does not permit using the software if the person the device is distributed to cannot replace it. We want GrapheneOS to be a direct replacement for AOSP without additional licensing restrictions. Most companies avoid using GPLv3 and we do not want most companies having a licensing reason to avoid using GrapheneOS or working with us.
@GrapheneOS No, GPLv3 forces a distributor to disclose DRM keys if the software cannot work without them. It does not impose any requirements on the end-user. See section 2 (basic permissions) of GPLv3.
@GrapheneOS Mind you, there are plenty of knowledgeable FLOSS lawyers here. People like @neil @kat @luis_in_brief @pchestek to name a few.
Fluchtkapsel@GrapheneOS I'd really like to know what specific issues you have with GPLv3. Which restrictions would apply? What could not be done anymore? Why is this more of an issue than accessibility today? Please don't handwave that away.
@fluchtkapsel AOSP does not include GPLv3 code because most tech companies want to avoid it. If we included it, most companies would be unwilling to use GrapheneOS.
Bundling eSpeak NG would not make GrapheneOS more accessible since it would require setup to use it and so would TalkBack. The setup wizard would need to be completed followed by setting that stuff up. Improving this requires significant work on integrating a text-to-speech implementation and adding further integration for TalkBack.
@fluchtkapsel GPLv3 forbids multiple things not forbidden by GPLv2 including making locked down devices without support for replacing the software under that license. That isn't something we want to do ourselves, but we want to permit using GrapheneOS in any way including to make those kinds of devices. We want GrapheneOS to be something companies can use as a drop-in replacement for AOSP anywhere. We aren't throwing it away and sabotaging potential partnerships to include this specific TTS app.
@fluchtkapsel There are other TTS implementations with acceptable licensing. Regardless of what's chosen, we will need to fork it and turn it into something we can ship. eSpeak NG is not something we want to include for MULTIPLE reasons. Licensing is ONE of the reasons.
eSpeak NG largely consists of a whole bunch of non-battle-hardened C code which has compatibility issues with hardware memory tagging due to some latent memory corruption bugs. This would be enabled-by-default attack surface.
@GrapheneOS Are there really any companies considering the use of GrapheneOS over direct access to AOSP? If it's companies handing out smartphones with GrapheneOS to employees, GPLv3's restrictions do not apply because that is not some kind of distribution requiring source code access or being able to reflash the hardware.
@fluchtkapsel There are companies considering the use of GrapheneOS and talking to us about it. There are companies wanting to build phones we can support. It has been expressed that including GPLv3 code would be a problem because their legal departments were block them moving forward. They would not want to use it with a subset of what we have removed. Bundling GPLv3 code would limit how widely GrapheneOS can be used and significantly reduce interest in it from companies. We aren't doing it.
@fluchtkapsel The best open source text-to-speech implementations are NOT licensed as GPLv3, so why is that a problem? The whole situation is being incredibly misrepresented by that blog post and Mastodon post. It's ignoring that whatever we choose will need to be forked and integrated into GrapheneOS. It's ignoring our security requirements. It's making it seem as if the only thing that's required is including GPLv3 code and then magically there will be the required integration.
Alexander Epaneshnikov@GrapheneOS @fluchtkapsel I totally agree with you. this article and the reaction to it is really causing more problems than it needs to.
about speech synthesizers. as a maintainer of espeak-ng I am really sad to hear that the license has become an obstacle to applying espeak to graphene.
But as a normal person I realize that this decision cannot be influenced by whining articles with factual errors.
have you paid attention to the RHVoice synthesizer, it is distributed under the gpl v2 license so it should suit you at least by this criterion.
Unfortunately, it does not support darect boot yet.
@alex19EP @fluchtkapsel Last time we checked, RHVoice had issues with the licensing for the language models.
https://github.com/k2-fsa/sherpa-onnx has been suggested to us so we need to look at that.
Regardless of what we use, we're going to need to fork it and make changes to set it up to work seamlessly on a fresh install before the setup wizard has run. It's not going to do any good unless it's set up and enabled by default. We then need to add a way to activate TalkBack from the setup wizard.
GitHub - k2-fsa/sherpa-onnx: Speech-to-text, text-to-speech, speaker diarization, speech enhancement, source separation, and VAD using next-gen Kaldi with onnxruntime without Internet connection. Support embedded systems, Android, iOS, HarmonyOS, Raspberry Pi, RISC-V, x86_64 servers, websocket server/client, support 12 programming languages
Speech-to-text, text-to-speech, speaker diarization, speech enhancement, source separation, and VAD using next-gen Kaldi with onnxruntime without Internet connection. Support embedded systems, Andr...
@alex19EP @fluchtkapsel GPLv2 is an acceptable license for GrapheneOS, and we use it ourselves sometimes. However, GPLv2 is incompatible with Apache 2 and Android has a lot of Apache 2 libraries. Combining GPLv2 and Apache 2 requires that an additional permission is made to permit the Apache 2 patent clause. GPLv2 supports doing this, but most people don't realize they need to do it. It's problematic to add this retroactively after a bunch of people have contributed. Legally, we need this.
@alex19EP @fluchtkapsel GPLv2-or-later is ONLY compatible with Apache 2 through using it as GPLv3, which would have the GPLv3 restrictions. Actual GPLv2 + Apache 2 requires that additional permission to be made. GPLv3 addressed this by adding a similar patent clause and permitting other ones.
This is an example of how copyleft licensing can be problematic. GPLv2-only similarly forbids using GPLv3, so you can't use Linux kernel code as a reference in glibc, etc. We need to care about this.
@fluchtkapsel These attacks on the GrapheneOS project are going to take significant resources away from development, reduce contributions, reduce partnerships and that will need to result in us focusing more on the core OS and adding fewer features. The impact of all these attacks on the project add up and play a significant role in how much we can do. People doing it have themselves to blame for feature development going more slowly than they want, and at least 1 partnership was lost due to it.
@GrapheneOS Without piling more on GrapheneOS, my take is that the pragmatic approach would be to just include espeak-ng until a better solution comes up. If companies want to use GrapheneOS, they can simply remove this component.
Security concerns? IMHO, after initial setup there's no need for espeak-ng anymore and can be replaced by something else.
But of course, that's just my position. I guess it's too late for a pragmatic approach now.
@fluchtkapsel Bundling eSpeak NG would not make GrapheneOS more usable for blind users without forking it and integrating it into the OS. It's also hardly one of the best open source implementations of text-to-speech. The post attacking us is thoroughly misrepresenting the situation as if eSpeak NG is the only option available and as if the only reason we aren't including it is GPLv3 licensing, while also ignoring why GPLv3 licensing is a problem and would FURTHER reduce our resources.
> Security concerns? IMHO, after initial setup there's no need for espeak-ng anymore and can be replaced by something else.
In order for this to work as intended, it must be enabled by default and therefore exposed to apps and content by default. Most people are not going to replace or disable the text-to-speech implementation as their first step of using the OS after completion of the setup wizard. Including a poorly secured implementation of TTS goes against what we do.
@fluchtkapsel People can already install eSpeak NG, RHVoice or many other open source TTS apps on GrapheneOS. They work fine simply installed on the OS. They need to be configured to work including downloading required language packs, etc. and activated in the OS settings for TTS which allows enabling 1 TTS app at a time. Most of the open source ones require special setup by the user and are not designed to work seamlessly from simply being installed. They may also stop working due to issues.
@fluchtkapsel If someone is completely depending on it to use the device, it must keep working without issues. That is a much more important property than being able to do the initial setup without assistance. Suddenly needing assistance at an arbitrary time because it broke is a critical issue vs. needing assistance only for the initial installation and setup process being something people can plan around. It's important for a TTS app we include to be robust and secure at a bare minimum.
User@GrapheneOS Unfortunately, your OS is for Pixel phones only
@qyahxm the only reason why @GrapheneOS only supports pixels is because pixels are the only devices that meet their system requirements, see here: https://grapheneos.org/faq#future-devices
