@lanodan >That is quite false. As seen in
Yep, that was one article that I was thinking about, except it kind of proves my point instead of yours.

"there is still the issue of no free re-distribution of the microcode" - as I mentioned, he regards proprietary software you have permission to distribute only to be "free".

"Firmwares (like for instance on a Intel wireless card, or a such) are binary pieces of code that will run on the little processor that is on the wireless card. As an operating system, we need to load the code out to the card. To include a firmware in OpenBSD, we simply need a nice copyright statement from the vendor that lets us distribute the firmware." - he is happy to redistribute proprietary malware as long as the license lets him.

"This is code that is expected to be linked against the operating system and run on the host processor. There are many problems with this. First off, can we trust the code to do what it should do? I don't think so. If there is a bug, can we fix it? No, as developers our hands are tied, and if our user community runs into bugs it just makes us look bad. Therefore when faced with the choice of supporting a device very poorly (as the blob would force us to) we instead choose to wait until we (or someone else) can reverse engineer it or." - his concern with proprietary drivers is not how they are proprietary, rather that such drivers are buggy and can't be fixed.

>There is a difference between accepting free-dist device-software and not wanting to go against it
Choosing to redistribute proprietary malware is directly supporting proprietary servitude, rather than not wanting to go against it.

Remaining neutral on the topic would entail not redistributing such proprietary software.


>Which is rather rare as digitally signing a software is very expensive, specially for peripherals.
Digital handcuff mechanisms have been common since at least 2006 (before?), as doing so is relatively cheap and it's becoming more common.

>I *hate* SecureBoot, I don't even get why GNU/FSF even accepts that garbage.
The FSF doesn't reject the concept of a bootloader optionally implementing digital signatures for the kernels it boots just a long as the user is the one that can set the signatures.

Mind you, the FSF doesn't accept restricted boot: https://www.fsf.org/campaigns/campaigns/secure-boot-vs-restricted-boot

I don't like UEFI as it's a terrible way to boot things (I use grub as my BIOS), but I don't have a problem the concept of UEFI, just as long as the implementation is free software.

>that doesn't protects them anyway given that you can cheat your way out via grub-shim and run malware.
Ideally, a proper UEFI mechanism would allow you to clear out all the default root certificates that sign ??? and import yours only, which would fix that problem.

>I'm not even sure SecureBoot can properly let the OS check that the boot-chain wasn't tampered with.
It can't, but if an attacker has physical access, you're gone regardless.

>Ever looked at the Mozilla Public License or the LGPL? Those are copyleft, sadly they allow proprietary software to use the code instead of requiring free software.
Yes, those all versions of those licenses have holes big enough to drive a truck through, but they still aren't compatible between versions unless compatibility clauses are used to force compatibility, or if the truck sized holes are utilized.

>I'm worried is contributing to software and using it to the point of heavily depending on it, and then being effectively forbidden to use it because of a relicensing I implicitly accepted.
Why would you be forbidden from using existing versions of the software under the original license terms?

No version of the GPL places restrictions on usage - you can use it in any way you wish - the terms only apply if you choose to redistribute with or without modifications.

If some software is GPLv3-or-later licensed and upstream decides to upgrade to GPLv4-or-later, you always have the option to distribute copies of the software you already had under the terms of the GPLv3 and maybe even continue development under the GPLv3 if you wish.

>Copyright assignment meant Oracle just threw the license out
What do you expect from a license written by Oracle?

Provided you don't infringe the terms, the GPLv2 and GPLv3 are irrevocable:
- In the case that all copyright is assigned to one copyright holder, any attempt to terminate the license is null and void - the copyright holder can only choose to stop distributing the software themselves under the original license.
- In the case that the copyright has multiple copyright holders, any attempt by a copyright holder to terminate a license when there is no infringement would be an infringement on the copyrights of the other copyright holders.

>sure, relicensing a massive piece of software with asking consent of everyone takes a long time
One a piece of software grows large enough, without prior arrangement, re-licensing it becomes impossible.

After just a decade, some of the copyright holders are very likely to be almost impossible to contact or be dead.

I would love to be proved wrong by someone getting every copyright holder of Linux to agree to license GPLv2-or-later, but that's not happening.

>I'd rather have that than taking the risk of having a piece of software so complex everyone depends on it, suddenly being unusable because of the decision of one organisation that's borderline a fanclub of RMS (FSF) and one person (relicensing).
A borderline fanclub? The church of Emacs isn't a mere fanclub.

Just because upstream decides to release some software under slightly different terms doesn't change the existing copies of the software you have and the terms you have them under one bit.

Usually you cannot trust organizations, but the FSF is one of the few organizations you can trust to make the GPLv4 similar in spirit, if it's required.