

Well, you certainly made me feel much more optimistic, thank you.


Well, you certainly made me feel much more optimistic, thank you.


I suppose you’re right that copyleft is not the primary motivator for contributions.
I’m aware that forks happen often when a takeover is attempted. There are many big success stories in FOSS. However, my point was that most FOSS software isn’t that successful. There are plenty of projects out there with very few contributors, and it is those I’m saying are easy for taking over. Perhaps they get taken over because most of the community doesn’t care, but it still happens from time to time. I originally commented because you seemed to make out that proprietisation was impossible.
I get your point that it’s incredibly unlikely for anything that matters however.
Edit: I think I misremembered an example I gave of a successful fork after an attempted takeover, but it was something Oracle.


I suppose it’s true that neither would have been called feature complete by its authors, proprietisation is much more likely when there is still a lot missing. But I would still caution against thinking that having all the features you need means you’re immune to it.


Sorry, I didn’t explain what I was talking about.
The problem is that in the modern software environment there’s a constant need for updating and patching, and if a proprietary fork provides those updates and a free original can’t keep up for whatever reason, the proprietary fork (that could have contributed otherwise) gains inertia until the free original dies. This is admittedly harder to pull off in a mature and well maintained free software ecosystem, but I think you’d be surprised how many important free software projects lack needed manpower. It doesn’t help that MIT practically encourages people not to publish code, compared to GPL.
People make out forking like it’s a big protection against proprietisation, and it is, but it’s not foolproof. Good forks are usually founded by community members that already understand and contribute to the code, most forks actually die quickly. The fewer contributors relative to the project’s size and complexity, the more realistic it is to either be overtaken by a more competitive proprietary fork, or for the maintainers to sell out and relicense without anybody to fork it.
Realistically, I don’t know how likely this would happen to anything decently important, but it has happened at least a few times. I remember using Paint .NET while it was still MIT licensed years back, but nobody forked it. Since we’re on Lemmy, Reddit used to use a Free software license.


Code complete is arguably a myth when talking about security. You need to update when vulnerabilities are found at minimum. Sometimes, the changing software environment changes and so the software has to start adding features again or get replaced. Rarely old features are the vulnerability, and have to be removed.


As far as I’m aware, contributor license agreements can include a clause stating that you agree to hand over copyright on submission of code. If every contributor has signed the CLA, there is only only one copyright holder, making relicensing easy.
However, successfully using this to relicense to something less open is extremely rare, and this isn’t a concern anyway as they don’t have a CLA.


I should probably add: if it becomes proprietary, the remaining soft fork will likely die. Turns out very few people have the technical knowledge for Audacity.
If you want to read the telemetry controversy/drama, I found this one I’d read years ago: https://github.com/audacity/audacity/pull/835
I remember feeling a bit bad for the maintainers. There’s a lot of complaining for a minor and optional change, but at the same time it’s interesting that they added telemetry anyway. (Not unmodified however)


As far as I remember, Audacity’s maintainers, previously just some volunteers with no organisation, decided to sell the ownership of the project to a company with some guitar platform. Nothing changed at first, they employed the maintainers to work on the same project they were already working on.
Then they started adding controversial telemetry and some soft forks appeared. I vaguely also remember hearing that there’s some contract that the company owns the source code, so relicensing to a proprietary licence is easy and possible in future. All the new software the company launches is proprietary, and there’s signs they want to tie it all together into a single suite.
Nothing majorly bad has happened to Audacity, yet. But decisions are no longer community driven, as shown by the telemetry drama. I fear it’s a matter of time.


What stops those open source projects having that same rugpull? AOSP was open source and for a long time could be installed on one’s phone indefinitely.
You could argue ownership, but if Audacity can be bought then so can nearly anything.
Fortunately cash is still a common option in Australia (and I’m here), and likely will remain so for a long time. However, I’m increasingly hearing that other countries are increasingly refusing to accept cash.
It’s probably best to get something working on Linux phones before it’s too late, but as you said Google is worse than a thief, so whatever is made should not use it. Best to maximise the freedom for people in a horrible future, lest Android or iOS ever become the only viable options. Problem being I don’t know how that would work, especially since banks would probably hate freedom respecting systems.
I agree basic functionality is higher priority, but I fear tap to pay will reach basic functionality status in some other countries when their banks phase out any alternative. (I don’t think cryptocurrencies will ever become common). It may not directly impact me that other countries phase them out, but it will gradually kill the Linux phone ecosystem.
That’s fair, I’m quite happy on Graphene OS.
I feel like you’re conflating some things here. Tap to pay is more private and secure than a bank card, and is more private than most cryptocurrencies. Cash is obviously better, but it is increasingly looking like it might be phased out of some places eventually (I really hope not, but is a legitimate concern). However, you are right that it’s not open source and relies on trusting big companies that don’t like user freedom.
So I would say that some of the people using tap to pay don’t necessarily not care about privacy more than convenience. Some of them just want to be able to use money in places where cash is dying out.
I don’t use tap to pay personally.
Depending on what bank they have, tap to pay won’t work with Graphene OS either.
I don’t think that’s the issue with tap to pay. Linux already works with NFC, the issue is banks and payment apps.


As much as it’s dumb, many other places (such as Australia, where I live) are similar at this point.
If you want something not Google, I used to have Ubuntu Touch on a Fairphone before Australia’s 3G network was switched off. It would have to be an older Fairphone however.


It’s good, I would have thought the same if I were to stumble on it now. Somebody must have provided an extremely quick downvote, because I hadn’t downvoted you


This comment section wasn’t so full or censored when I commented that, and I know the ones I saw before they were censored weren’t saying that.


I feel like you’ve built two straw-men and conflated them together. I haven’t seen anybody arguing either case on the left side of the meme in response to the images depicted (or similar) on the right side of the meme. People wanting to send weapons to Ukraine generally tend to also say it doesn’t have a Nazi problem (and may compare Russia with Nazis), and people wanting pacifism in Palestine also don’t like weapons and support sent to Israel.
Pale Moon is criticised precisely because its developers don’t have the resources to keep it fast, feature complete and secure.