Norah - She/They

Thank you for the history, I appreciate it. Hopefully Valve releases SteamOS properly soon, it could be the resurgence of the Steam Machine!

Disk encryption doesn’t protect against what Secure Boot does. They are very different, often complimentary, systems.

Yeah no, it makes heaps of sense. It just initially sounded to me like the person was implying the Steam Deck is Valve’s escape hatch from running the Steam store. Which would be ridiculous, the two business sectors aren’t even close to the same order of magnitude.

Huh. That’s actually a pretty good take.

What do you mean by an escape hatch. Valve have been messing with hardware and Linux for way longer than the Steam Deck.

This is why Microsoft made WSL, they knew they were losing ground big time amongst devs.

No, it doesn’t, because the cost of that software is on the business because it makes them money. This person is literally smoking crack if they think it should ever be on the employee. There is never, ever, ever a situation where an employee paying an employer is a good thing.

Yes, the word free in English both means free as in gratis, without cost, as well as free as in freedom.

Wow. I don’t think I’ve seen a dumber take than “Windows good because it prevents an Apple monopoly” in a long while.

Yeah honestly these feelings are so bloody valid after the way they’ve been used lately. It’s always good to be sure of these things.

I’d imagine there would have to be script support, as KDE runs on many distros that all have very different update flows.

I’m actually wondering if it’s not just applications. That text talks of installing drivers to devices, so I’m actually wondering if this is about better support for hardware that’s paired to specific software. The recent use-case that’s got it on my mind is Rekordbox with Pioneer DJ decks. My housemate was curious so I tried running it under WINE and it launches just fine, but it could not see the decks at all, nor the encrypted license key verification it does with it’s driver. And I did manually install the driver into the prefix first.

However, I’m not positive this is it. It’s just a hunch.

Would you not consider signing a CLA (without remuneration) if it binds a project to releasing your code under an OSI license? The only way they could have done better I think is by specifying AGPL instead. I’m not trying to argue that all CLAs are good here, but I don’t think that when they achieve the goals of the free software movement, they should be treated with suspicion or derision.

Honestly, all of the recent light shone on CLAs is a great thing. But there are still valid reasons to maintain a unified copyright for a project. None of these projects would have been able to move to AGPL without having used a CLA for that purpose. It also allows enforcement of that license via things like litigation, because you can have one entity on the docket, instead of a thousand contributors all defending their copyright.

I think the correct course of action isn’t to avoid signing one, but to force projects to commit to the social contract of open source in writing. I think there’s also a discussion that no one has earnestly talked about. A contributor license agreement is a contract between two parties, and under contract laws both parties must materially benefit. “I will get x, and you will get y”. This is known as consideration, and courts will nullify contracts that only benefit one of the parties. The only consideration I think there is to be found in most of the CLAs that have been brought up lately, is basically “your code will be merged into the project and released under it”. They don’t specify the continuation of open source, but it’s heavily implied by the aforementioned social contract. So when someone like RHEL goes and closes their source, they’ve essentially changed that contract to “you will sign over your copyright to us, and we will exploit your labour for profit”. That is not consideration, and it calls into question the validity of every single CLA signed. I genuinely think there’s grounds for every RHEL contributor that signed one to form a class and sue, and I would love to see FSF or EFF organising and supporting that sort of effort.

Back to Element for a second though, as far as I can see, their new CLA is a valid contract, because it gives a right to the contributor, that their code will always be released under an OSI license. So if a successful suit was brought against someone like RHEL, or Hashicorp, we could see other projects scramble to repeat Element here. That would be, in my opinion, a very good thing for the free software movement.

Look, owning that means you’re already doing better than 99% of people who do this :)

C’mon, that’s like, worse than not reading the article.

Honestly, I really should have already, but spaced on it. Thank you for reminding me.

Did you just, not read the OP and come straight to this person’s comment to argue with them based off the least charitable interpretation? The OP already uses Linux Mint Debian Edition. This person mentioned “flavours” of Linux, clearly meaning the various 𝑥-based families of distros (ie Debian, Fedora, Arch etc). Which is pretty solid advice when it comes to learning the CLI in my opinion. I think they were trying to gently nudge OP away from their second EndeavourOS install, as even though ArchWiki is great (sorry KDE but it has better Plasma docs), OP would end up pretty lost on trying to use those skills back on LMDE.

But to circle back around, Debian, the distro, actually is a good choice for learning the CLI because it can be installed without a desktop environment, potentially using something like Distrobox. That way OP could learn the CLI within their LMDE installation in a sandbox, so they don’t risk messing up their main computer.

Except both of the projects you just linked too have CLAs, which they updated on switching to AGPLv3. Both use them as a way to offer dual-licensing, so they can charge companies for an AGPL-exception by selling them a proprietary-licensed version, which then supports the FOSS-development. They both were also only able to change to AGPL because of already existing CLAs. At least in Element’s case though, they created a two-way commitment in their CLA:

Now, CLAs come in all shapes and sizes: some good and some bad. It’s critical to understand that our reason for requiring one here is to give us the right to sell AGPL exceptions: not to “do a Hashicorp” and switch to a non-FOSS licence in future. We’ve made this clear in the wording of the CLA (using a similar approach to Signal’s CLA) by committing to distributing contributions as FOSS under an OSI-approved licence – many thanks to those who gave feedback on the original announcement to suggest this. You can find the final CLA wording here, derived from the well-respected Apache Software Foundation CLA.

Here’s the specific text from the CLA:

Element shall be entitled to make Your Contribution available under Element’s proprietary software licence, provided that Element shall also make Your Contribution available under the terms of an OSl-approved open-source license.

I personally consider that a fairly reasonable term. Especially because they specified an OSI-approved license. Element are always going to be bound to that now. This is like the copyleft of contributor license agreements.

What would suggest is a better option for beginners than a Debian-base?

I mean, this is literally what someone in the original mailing list said:

How about a sysctl that does “for the love of kbaek, don’t ever kill these processes when OOM. If nothing else can be killed, I’d rather you panic”?