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.

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.

Huh, I’ve never heard of SoftMaker Office before, good to know it exists. I might check it out.

To add to some of the other comments, I have heard that the issue for LibreOffice is that Microsoft’s own parser isn’t compliant with the OOXML standard that they created. Yet the most important thing is compatibility with Microsoft Office, so you can’t simply build a parser according to the open standard and expect it to work with Microsoft Office. Instead, you need a parser to work the same way as Microsoft’s, which is proprietary. However, admittedly I have never read the OOXML standard or checked MS Office documents for compliance myself.

Therefore, if what I have heard is correct, I would assume that SoftMaker Office has either struck a deal with Microsoft before to improve compatibility, or has simply been better at reverse engineering. Alternatively, what I have heard could be wrong.

I think people do think it should fail. Snap isn’t bad, but when people run a command, they expect it to do as asked, or fail. The fact it does something else breaks that intuition, as it’s doing what it thinks you will want instead.

With that being said, it’s not a big deal.