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 think the point of both is that even if he skipped all the text explaining he’s about to break the system, he would have still have had to type the words explaining them, and therefore hopefully think about the words he’s typing. It might not protect against copy-paste as effectively, but there’s a higher chance he’d read what he’d copied than a wall of text. Not 100% effective, but it’s probably going to catch more users than “do as I say”, where he still thought he was installing Steam, so it’s good those changes were made.

But yes, it won’t catch everyone like Linus because they either won’t think about it or they will copy-paste without reading. Ultimately an immutable distro might be best for him. Then again he might still find a way to break it somehow.

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.

I think there were a few other changes indirectly inspired by what had transpired, but admittedly I can’t remember most of them. I think Debian also modified apt.

I also think I remember immutable distros taking off just after this.

I sometimes forget that us Linux users often lack social skills. Understanding other people is hard.

Anyway, I’ll try this grass, is it on GitHub?

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.

I remember being a big fan of FLIF when it came out. I remember it had come out of nowhere to steal PNG’s crown, and then the author suddenly disappeared before finishing it. I soon learned they had been picked up by a company to work on a successor named FUIF and then some time after that FUIF was merged into JPEG XL.

Because of this, I was really excited when JPEG XL came out. An obscure but brilliant format had essentially been merged into the successor to JPEG, and I thought it was really going to take off. It had support from many major tech companies including Google. Browsers quickly started adding experimental support and then… nothing.

Soon after JPEG XL was finalised, AVIF was too, and AVIF was essentially Google’s attempt at making a successor to WebP, by using much the same technology as AV1. So the question was, which one to support? Google made a comparison between image formats, focusing almost exclusively on lossy compression ratios (which I think isn’t entirely fair, considering they both have a lossless mode to compete with PNG) and AVIF won. So they dropped JPEG XL from Chromium, claiming lack of interest or something (which was wild, I’d never heard of a faster uptake of an image format). Soon after, Firefox was talking about removing it too, but ended up deciding to wait and see.

Things looked bleak until Apple picked it up, and then things have just stalled since. I’m happy there’s still interest in JPEG XL, its FLIF/FUIF derived lossless encoding produces smaller files than both AVIF’s lossless encoding and PNG, while having features neither could dream of.

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.