@fireborn at least to me this sounds like a legal issue, more than one of principle. What I am unsure is how licensing would propagate here... Interacting with GPL3'd systems does not require GPL'd "callers". The License always stays with the code and its direct results, but I am no lawyer, and dont even know how boot level accessibility works.

@fireborn What I find weird is: afaik NVDA is GPL v2, but uses eSpeak NG which is v3. Did they request an exception? If not, is that legal (don't think so)?

@fireborn GOS has a lot of other issues too.

I got targeted by them (they attempted to doxx me) cuz I called them out in public for refusing to deal with queerphobic moderators. They failed so they made up slander instead.

Their approach to security is dangerous.

So seeing this is not at all surprising.

@fireborn you shouldn’t have to be ashamed. They’re clearly in the wrong here. They’re turning their nose up at a perfectly viable solution. I yelled at them because they’re making excuses. I won’t take that back. They straight up admitted we weren’t the priority. Shiny things are the priority. if they have a problem with what you said, that’s a them problem. They didn’t get attacked because you made a post. They got attacked because they attacked.

@fireborn Yeah I think that was a good call. I'm sorry I boosted this without first reading their side of things, and after doing so I wasn't a big fan of how the devs were being treated by some who responded. With that being said, accessibility isn't a feature that is nice to have, and while I completely understand the many issues around making a hole OS without much in the way of money or devs to work on the project, I think they could've handled this situation a little better.

@fireborn re: the decision to remove this, I still want to say thank you for posting it in the first place, even though I know why you removed it

ultimately, blind people are forced to advocate for themselves in a very hostile FOSS environment and I don't think that these folks fully understand just how big of a deal not being able to set up the OS yourself is

like, theoretically you might be able to perfectly follow a guide to press the right buttons on a desktop Linux distro to set it up (I am doubtful) but a phone especially makes this effectively impossible with touch gestures. plus, it's not a simple task either way and it is not only awful to be forced to rely on someone else to set it up for you, but the person helping may not be as able to do so due to the technical knowledge required, making it an even more drawn-out activity

basically, I hope that more folks feel comfortable speaking out about this and the situation slowly improves

@fireborn
Reasons why I will never use #GrapheneOS
- Too few compatible devices
- Restrictive
- Head-in-Ass developers
- The answers from GrapheneOS to this thread

@fireborn YOu need to write a blog post. Call them out, if you know name, call them out by name. Put them on blast, nothing else will work.

@fireborn respect for your willingness to listen and say you're wrong. I hope everyone got something from this conversation.

@fireborn Talk to a lawyer, fork it, see if you can do better.

@pavel we ended up having quite an in-depth discussion on why this approach wouldn't work. It boils down to, not every system might allow access to the store, so it needs to be a base component. It can't be a base component because partnership doors would be closed if *any* gplv3 components were introduced. There's an ongoing discussion about other options that I put some feedback in.

@rooktallon I had one. I took it down due to a few reasons.

@fireborn Unless you were sued, there's no reason to take anything down. Change is brought about by calling out bad behavior and what you posted here is bad behavior.

@rooktallon what I posted was a misunderstanding of why things are in the state they are. It's a sorry state, but it is that way for a reason. A reason I might not like, but a reason none the less.

@clarfonthey I don't intend to stop speaking out. I will continue to do so in the way that I do — I don't think my approach will change. This one was just unfortunately clumsily worded because I was already annoyed and tired, which I didn't recognise at the time.

@ity @fireborn They have a loooong history of attacking anyone they deem to have 'harassed' them, going as far as essentially stalking people's online accounts for any 'problematic' statements to swarm their replies with 'corrections' which tend to argue about technical semantics instead of addressing the more general criticisms raised. "I didn't crush that person's spine, it was my car that did it!" type of stuff. This thread is evidently no exception.

The founder/lead dev Daniel Micay, who played a big role in fostering this kind of behaviour in his communities, attacked Louis Rossmann for "harassment" and got publicly suplexed in return, which finally got him to "step down" from the project. This didn't actually last long, as he returned to working on the project a few months later. This was possible to check on his Github activity for his website's repo, but his profile is privated now.

@molytov @ity I think there's some things I could have expressed better, but I won't say they didn't come out swinging rather than have a conversation. The first thing I got essentially boiled down to abuse. I'm exhausted at FOSS spaces being "you want change, do it yourself. Look. we gave you half the car. Now clap."

@fireborn @molytov @ity TBH, what leaves more of a bitter taste in my mouth is the repeated assertion that if disabled users express any degree of frustration, those users will be the catalyst for any subsequent reduction in accessibility efforts because of how "demotivating" it is for the team. Holding one person responsible for deprioritisation affecting a wider group isn't what inclusion looks like.

i've worked with teams before that insist on playing the victim through walls of text designed to batter the opposition into guilt ridden submission. It very rarely ends well.

@jscholes @molytov @ity I did end up redacting the post for my own reasons, one of those being that some of the things I said were objectively incorrect because I didn't have context that I was given later. I think I was interacting with 2 different people, one person who was taking that approach, and someone else who was much more understanding of where the original comments came from. I'm hopeful that some actual progress can come of this now that the right questions are being asked, and I don't think there's a need to leave something in place that has incorrect info in it. Of course, I'll continue to call out bad accessibility when ever and wherever I see it, but in future, I'll at least calm down first, like I did for the linux situation.

@fireborn @molytov @ity Very fair. But while I support a team's right to defend themselves or correct misunderstandings, they'd also do well to consider who's running the social media accounts with the project's name on it and how, with an eye to creating more proportionate responses to the actions of a single person.

@jscholes @molytov @ity I agree. Had I had that context from the start, this would have not ballooned in the way that it did.

@sukiletxe @fireborn If you want to read GrapheneOS's side, you should read this thread: https://grapheneos.social/@GrapheneOS/114569530347582880

We do care about our users and have a fork of TalkBack where a lot of the issues with it have been fixed. The issue with licensing is if GPLv3 code is added to the OS, it'll just add restrictions to how it can be used.

@mpldr They allow gpl v3 in the app store though. So surely they could: upload espeak to the app store. Install it as a standard system component (from the app store) that could be uninstalled. It could even be a choice at flash time via their website via a checkbox (do you want this or not?) they have much more experience with negotiating complex licenses than myself, and they have decided that via the app store they can distribute gpl v3. It took me all of 2 seconds to come up with a flow that would allow people to still have the choice to not include it, but would enable those that need it to simply check a box to get what they need. As for the configure it by default bit, talkback will use the first detected d-boot enabled speech engine installed, unless they broke it in their fork. No configuration needed.

@fireborn @mpldr Allowing a user to install third party apps from another source is substantially legally different to bundling/aggregation/distribution of a mix of licenses.

I'm amending this post with saying that I'd hope they could find a work-around - merely pointing out that the example cited doesn't imply they're being malicious, because they're not the same thing.

@larsmb @mpldr But what I’m saying is, could they not post it on the third-party source, and then, at install time, prompt the user to check a box if they are okay with, require, or otherwise want to install the specific component from the specific third-party source? Like certain Linux distributions do with non-free applications and firmware. See debian/ubuntu/mint installers. I'd say just "not caring" as they are doing currently, is malicious. Everything they've said at the moment is passing the torch onto someone else. Someone needs to make an engine. Someone needs to update a component. Someone needs to configure it. They are accepting absolutely none of the responsibilities themselves.

@fireborn
You are spot-on, they could do this. They could find a way that works within the rules they set for themselves.

I have some sympathy for open-source purity distributions. Principles can create momentum to produce better open source solutions. But that's a niche. Most people want software that works.

And what the hell is wrong with GPLv3 anywhere? it's a perfectly good free license.
@larsmb @mpldr

@fireborn @larsmb @mpldr People can already install and activate TTS apps on GrapheneOS. What's needed is bundling one which is integrated to be functional by default with everything it needs for that configured. This requires choosing a good TTS implementation meeting our security, licensing and other requirements, then forking it and integrating it. eSpeak NG does not meet the security or licensing requirements. There are better open source TTS apps available, so why use fork one specifically?

@fireborn @larsmb @mpldr I think we've done a fairly good job of explaining the reasoning behind the way things currently are. It's very unfortunate that you've taken that and decided to write this article which misrepresents our stance and paints the project as cruel or bigoted. We do care about accessibility. We have a section on our website discussing the topic dating back a very long time. We have threads discussing accessibility topics dating back years (see https://xcancel.com/GrapheneOS/status/1596245397596692480#m as one example of that).

Claiming that we do not care about accessibility isn't just inaccurate, it's personally deeply saddening to me. You don't have to care about my feelings, of course, but I do feel that I have to express that.

You're claiming that GrapheneOS is passing the torch to others rather than assuming responsibility for this ourselves. Other than the fact that we've had endless discussions on how to tackle this internally, which of course you cannot know, I would like to posit this question:

Isn't that what open source is about?

GrapheneOS is a project providing privacy and security to hundreds of thousands of people around the world. Doing that requires constant maintenance and work to keep everything up to date and secure. Despite that, we take on as much work as we can muster. On this particular topic, isn't it reasonable for us to want someone to provide something we can use? There appear to be engines which are compatible which need to be turned into an Android app. That's something that someone could advocate for or even work on themselves to contribute to GrapheneOS. It would certainly be more helpful than being called bigoted. I understand that you might not have the necessary skillset, time, or inclination to contribute something like this, but wouldn't it be more productive to hear the project's reasoning and advocate for something being made that meets the project's needs?

Despite the end result being very unfortunate, I do understand that you probably wrote this with good intentions. It just hasn't come out that way because it misunderstands multiple parts of GrapheneOS as well as what our issue with the licensing is (as multiple people have already expanded on in their replies to your post).

I have seen replies from you that make me think that you're reasonable and that we could discuss the topic further. If I'm right about that, feel free to reach out and we can chat more.

@matchboxbananasynergy I did right this with the best of intentions, this is correct. I do think that there are ways that this could have been tackled before now. I will admit at being frustrated at the wording of the posts I quoted, as it certainly read like what I've read in a lot of FOSS spaces which is "You want a thing to change, do it yourself." I think there's things that can be learned by both sides here, for example, the install process can be completed accessibly, it's just the setup that can't, so I think making that a lower priority project is maybe done from a lack of information about what steps are actually problematic

@fireborn I think that we understand more than you might initially think, especially since we've been doing work on our Talkback fork with the help of a blind GrapheneOS user for a very long time. People like that are very important for noting any regressions to accessibility (which we address before they become an issue to people in production since we realize that accessibility features breaking puts people that depend on them in a very difficult situation where they'll need help from a third-party to get things up and running again).

I want to reiterate something. This is NOT something that we don't care about, or that we're ignoring/neglecting. You can find us talking about this and us wanting to improve things in that area for a very long time. As you noted in your article, we did request direct boot support from eSpeak NG which means that GrapheneOS users or users of other OSes that don't use Google's app for this can use their devices BFU.

If we didn't care about this, don't you think we wouldn't be talking about it or taking those steps? We take time to do things right, and I fully understand that this is something that's important for people to be able to do independently and without help from a third party. If I could snap my fingers and have a workable solution that we can use in GrapheneOS, I would do it, but that doesn't exist today. Like I said, there seem to be promising leads for models we could use, but nothing that meets our requirements and is ready to use right now.

I'm glad that you're mentioning that you were frustrated by something (which perhaps wasn't understood fully, or might have seemed like us waving away a problem when that isn't what we're doing) because that means that you're willing to see that the way the blog post was written is accusatory and doesn't apply nuance or any amount of good faith towards GrapheneOS.

I'm hoping that you can take another look and take our back-and-forth as context, and maybe amend it.

At the end of the day, both sides want the same thing - I'd say that there may not even be sides in the first place.

@matchboxbananasynergy I'm considering various options. I'm not sure setting the post as draft until I can go over it is appropriate, or that it would prevent a mailing list post being sent. deleting it would also seem like a full retraction, which it isn't. This is still a problem.Could that blind user have provided instructions on how they got through any setup? I myself have plenty of experience flashing android devices. I made a flashable twrp zip to work around this issue on LOS based ROMs but not sure how much it would apply here. I still think that while a solution is being designed, there could be some way of supporting what currently exists, even if it requires a user opt in or a separate build while the tooling is made to unify the experience.

@fireborn I can ask them. I assume that they either have their own build of GrapheneOS which includes something like eSpeak NG, or that they enlisted someone's assistance when setting the device up.

I understand that both of these options might not be feasible for some people, but they are certainly options until there's a permanent solution that works out of the box.

The article as it stands right now unfortunately gets things about GrapheneOS works incorrectly (such as the section about sandboxed Google Play which has led many people to agreeing with you based on a false premise that we include Google Play by default, which we don't).

It is really causing harm to the project and is very saddening to our team because we're being accused of being ableist or not caring about accessbility. I don't believe that this is the purpose of the article, but rather pushing for a solution and potentially getting the word out to help a reasonable solution be developed, whether by our team or a third-party contributor. I don't believe the article currently does that and I really wish we weren't put into this position of having to defend the project and ourselves by explaining we're not something that we aren't.

Unlisting it so that it can be reworded (I am happy to help provide input and make sure things are at the very least factual) seems like the best option right now, if you do not want to delete it instead.

@matchboxbananasynergy what I meant by that was support for enabling that is super easy and discoverable. Enabling tts not so much. There are guides on enabling it. provided instructions. A user is hand-held through that process.

@matchboxbananasynergy If they have a build that includes espeak-ng, is this not something that GOS could provide instructions on building? Not very streamlined that's for sure, but something.

@fireborn I would need to check with them to see what they're using nowadays. They've told us that options like RHVoice and eSpeak NG aren't actually usable in practice, and they are likely using Google's app for this for their day-to-day.

As far as maintaining your own build with something like eSpeak NG goes, I don't assume that it would differ a lot from bundling any other app in a custom GrapheneOS build. If someone wanted to do that, they should be able to do it with relative ease, but at the end of the day, the solution needs to be something we can actually ship in official builds.

@matchboxbananasynergy it does, but a guide in the mean-time on how to package it yourself would go a long way towards making the process at least doable. I don't know, I personally use espeak every day and don't really plan on using anything else. Espeak can reach higher speech rates than most other things while still remaining understandable, and I don't like tts options with inflection that changes in the way that neural tts does.

@fireborn We can consider this, we do have https://grapheneos.org/build today which guides you through making your own GrapheneOS build.

@fireborn Could you elaborate on what you mean, I think I lost you there.

@matchboxbananasynergy Enable g. play services is something that is documented and discoverable. Enabling tts is less so. Could there be a modification made to settings that adds the install espeak-ng option to the text-to-speech output settings if it isn't installed?

@fireborn What would be the purpose of that? If someone has gone through the installation and setup of GrapheneOS and they want to use eSpeak NG, obtaining it wouldn't be the difficult part. Given that we have feedback that it also isn't practically usable day-to-day, and that most people end up going with Google's service for this, nudging people towards something that they'll end up needing to switch away from seems a bit counterproductive.

@matchboxbananasynergy Mostly discoverability. If you have a tech-illiterate friend/parent/who ever helping you, it's a lot easier to tell them to open settings, navigate to accessibility, and select the install and activate option or whatever the flow is, rather than get them to open an app store, maybe find the right app somehow, then install it, then go into settings and configure it. The latter option maybe would require you know what icons represent what apps. Most people generally know what a settings icon looks like.

@fireborn I can see the value in that. I think my first priority would be to collect a lot more feedback about what works for blind users. How many people use eSpeak NG, how many people use Google's app, or something else entirely.

Adding a setting to set up a specific one (such as eSpeak NG in this instance) means that we're essentially endorsing it -- which is fine is it does a good job, but so far we have conflicting feedback about that.

We could mirror it in our app store. We could do the same for Google's app, although both can be obtained from their respective app stores.

Do you believe that a video that shows the steps required to enable this would help? They would be meant as a guide for someone who is assisting the blind user to set it up. It doesn't address the root concern, but might be a stopgap in the meantime.

@matchboxbananasynergy Something else entirely would be the most common response. I really don't know who said that google's option was the best. I can demonstrate it for you if you like, but the basic idea is this. Give it more than 500 characters and your speech might be gone. or it might not. if it crashes, it might come back. or it might not.

@fireborn That's based on feedback we've received from the blind GrapheneOS user that helps us maintain our fork of Talkback.

Are you aware of other options that could be used on Android? I'm aware that for PCs etc. there must be a load of options.

@matchboxbananasynergy There's RHVoice, which you know of. It's free. Acapella and Vocalizer both exist, but are paid. Both do have a history of working with companies though, so I might be able to help you make contact if there's interest.

@fireborn Thanks, I will check those out.

@matchboxbananasynergy there's also this, but I'm super unclear on what the license is. https://poretsky.github.io/android/smartvoice/

@fireborn I looked but wasn't able to find any source code -- maybe I need to look more into it, though.

@matchboxbananasynergy i wasn't either, but I thought it was FOSS. maybe not, in which case absolutely not.

@j_j @larsmb @mpldr I fully understand they want purity. That's fine. If they want that, then they need to propose the solution.