Proprietary software is a societal ill, like spyware is. Getting people to understand that will be similar to when societies have figured out other things are wrong, like child labor is wrong. While proprietary software runs rampant, certain parts of our overall freedom and privacy has regressed in comparison to before computers, and in comparison to how they should be. It is not a lost cause to think that the software we depend on to live our lives should act in our interests, and having the 4 freedoms on that software is simply an essential part of it acting in our interest.
The government arguments against encryption are so ridiculous, but we need articulate explanations like this to help refute them.
They remind me of things like: if you don't vote to ban driving, you must want children to die. After all, driving a leading cause of death among children.
> Making it inaccessible to tinkering is strictly worse for the user in all respects.
"all respects" is wrong. It also makes it so the proprietary developer can't say "here is a new version, but you must agree to some very nasty license terms, or accept some malicious feature along with it." NOT having a capability does have advantages, a physical book is impossible to be remotely deleted out of existence by DRM, but sure, you can't tinker with the software.
edit: yes, I understand in that the case of sticking the exact same software in a rom vs a read-write memory hurts the ability of a user reverse engineering it, which could ironically decrease user freedom over time. Calling this out for FSF to address is a good thing.
You're taking the vendor at their word. You can't do this. It has happened before (see Intel vPro) that some feature is not actually impossible to activate, etc.
If you try to pin down someone on the fly who is publicly advocating for something on what exceptions are ok, expect them to be stubborn. But there is a lot of pragmatism at work. It's why we have the LGPL, GPL, and AGPL. https://www.gnu.org/philosophy/pragmatic.en.html
Ah yes, the AGPL. The license that wants to be an EULA (because that's the only way you can actually close the SaaS loophole), but can't, because being an EULA would be against the FSF's core values (Freeedom Zero), so instead it's a cute hack that is trivial to work around if you want to, while simultaneously being almost impossible to comply with for regular developers. And then the FSF plays it like it has EULA powers and makes everyone believe it is useful and harmless to the free software ecosystem.
Let's break down this amazing license:
> 9. Acceptance Not Required for Having Copies.
>
> You are not required to accept this License in order to receive or run a copy of the Program.
So it's not an EULA. Cool. You can freely run the program as long as you don't modify it. Freedom Zero.
> Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so.
But if you touch the code, you'd better comply with the License. Great. (These clauses are identical to the GPLv3).
Now the magic AGPL clause. Brace for it, and read it very carefully:
> 13. Remote Network Interaction; Use with the GNU General Public License.
> Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.
Let's break it down:
> If you modify the Program
That is if you are a developer making changes to the source code (or binary, but let's ignore that option)
> your modified version
The modified source code you have created
> must prominently offer all users interacting with it remotely through a computer network
Must include the mandatory feature of offering all users interacting with it through a computer network (computer network is left undefined and subject to wide interpretation)
> an opportunity to receive the Corresponding Source of your version
A direct copy of the source code you have just modified
> from a network server
Directly from a server, without any human involved
(the rest of the statement is irrelevant).
Let's say I am Amazon, and I want to SaaS some AGPL software. How about this:
Step 1: Put it in an internal Git repo (No license implication yet, no changes made)
Step 2: Make that Git repo accessible externally with a specific URL or access key (so it is not guessable) (Clause 9 plus plain redistribution, no modifications, no problem)
Step 3: Modify the software to include a link to that Git repo including the secret key (invokes and is fully compliant with Clause 13) with every response
Step 4: Deploy that software on their internal network (Freedom Zero, invokes Clause 9 during deployment, no extra requirements)
Step 5: Stick a reverse proxy in front that deletes the source code offer (No license implication, does not modify the AGPL software in any way, see Clause 9)
Step 6: Profit
Turns out you have to pick one: either control what people do with your software (which makes your license into a non-free EULA), or don't (which means there is no way for you to control any interaction people have with the software). You can't have it both ways.
I know what you're saying: "But a judge would see right through this trick! Amazon is both modifying the code and setting up the reverse proxy!" Great, then just have different entities do each part. Each part, on its own, is unambiguously not in violation of the license; the developing party is only responsible for including the source code offer, and the running party has no responsibility that it actually reach users if they don't touch the code. Now your license defense relies on proving collusion. Good luck with that if the people involved were careful enough not to write down their evil plans anywhere. Heck, this situation could easily happen semi-organically - a reverse proxy doesn't have to be designed to explicitly remove the source code offer, it could merely be a protocol translator/wrapper that has no support for that specific message/tag, which is something that happens all the time.
Now let's say I am a regular developer of AGPL software and I want to work on it like any other open source project.
Step 1: Clone the GitHub repo
Step 2: Make a change to the code - oops, license violation! Clause 13! I need to change the source code offer first!
Step 1.5: Change the source code offer to point to your repo
Step 2: Make a change to the code and push it
Step 3: Open a pull request with your change
Your change includes the source code offer commit in the history, and cannot be auto-merged. Any AGPL project accepting pull requests from third parties (or even their own developers, if there is no copyright assignment and each developer retains their own copyright) is accepting that everyone is repeatedly violating the AGPL as part of the normal development process, if they're using the GitHub flow and the source code links were not updated in the branches to be merged.
Note that the license doesn't even say anything about Clause 13 being restricted to redistribution or execution or deployment to external users. Merely downloading some AGPL software and changing some code locally is an instant license violation, if you haven't previously made that version accessible and changed the source code offer. Somehow. I don't know. The whole thing is crazy. It's setting rules for mandatory features that must be implemented in the code. It's not a Freedom Zero violation, but it's a Freedom 1 violation instead: The freedom to study how the program works, and change it to make it do what you wish. AGPL Clause 13 restricts how you are allowed to change programs.
As far as I can tell, there is precisely one kind of open source project that could conceivably benefit from the AGPL without being an undue burden on developers and a danger to users: Web apps with nontrivial amounts of JS source code (which would be covered under the license), with the source code offer in that code (so it cannot be removed without invoking the license, even by an automated process, maybe, hopefully a judge would see it that way), and a source code offer mechanism that has the app read its own source code from the live copy, so that no updates to the URL need to happen for different forks.
Anything else, and it's just a terrible license. But the FSF will tell you it's amazing and fixes the SaaS loophole, because they've long since given up on actually being honest and just want to have their cake and eat it too, even when it just isn't possible.
> Step 2: Make a change to the code - oops, license violation! Clause 13! I need to change the source code offer first!
No you don't, as that's not creating any users, the source code repo is the source code repo, not a distributed program you provide as service for anybody.
It seems there are further misunderstandings in that wall of text, I'd heavily recommend talking to someone with (FOSS) legal experience if you're involved in such distributions, no offense meant.
We're providing most of our code base under the AGPLv3 and have never faced any such issue either for people contributing to our projects or us contributing to other AGPLv3 projects.
Granted, some FANG company refused to use us (officially that is, I know personally of unofficial use), but that's not something really hurting us in any way, and definitively better than getting stabbed in the back like some other projects got from some SaaS companies due to having a permissive license that allowed them to deploy changes without giving them back anymore.
> No you don't, as that's not creating any users, the source code repo is the source code repo, not a distributed program you provide as service for anybody.
The license is a copyright license and deals exclusively in modification and redistribution, not usage - that includes the source code. "Users" mean "potential users" in this context; whoever hypothetically uses the software in any given version, as it exists in source code form, regardless of whether such users come into existence or not. It doesn't matter whether the software is deployed or not; the license cannot and does not claim to control or have anything to do with that. If it did - if the violation only occurred at the point where the software is deployed and run - then again that would imply this is an EULA that controls usage and violates Freedom Zero.
Again, consider my "two parties" scenario. I make some changes to AGPL software, but never deploy it or offer it as a service. According to you, that is perfectly OK. I then send it to someone. According to you, again, that is perfectly okay, just like contributing to an AGPL project. Then that someone makes zero changes to the code - therefore not triggering clause 13, obviously - and deploys it without updating the source code offer. No problem. If the license worked as you claim, then it doesn't work to close the SaaS loophole at all.
It does not, and the entire hack the FSF came up with is precisely this, converting a usage restriction into a responsibility for the developer making modifications. Everyone defending the AGPL misunderstands this, because the FSF has been very careful to never bring up that this is what they did. They treat it like schrodinger's license: simultaneously claiming it can do things that require it to restrict usage (making it nonfree) and claiming it is a free software copyright license.
> I'd heavily recommend talking to someone with (FOSS) legal experience if you're involved in such distributions, no offense meant.
It's rather difficult to find someone who will consider entertaining the idea that the FSF is completely backwards in their license design, because nobody wants to open that can of worms. People are much happier to just pretend nothing is wrong and move on.
> We're providing most of our code base under the AGPLv3 and have never faced any such issue either for people contributing to our projects or us contributing to other AGPLv3 projects.
Of course, because neither you nor your contributors actually parsed the AGPL properly nor are you aware of the violations occurring on a daily bases. That nobody knows there is a problem doesn't mean there isn't one :)
> Granted, some FANG company refused to use us
No surprise there. I have a hard time using AGPL software too; last time I discovered some on my system I was already in violation, because my distro had patched it without adding a source code offer, and since I use a source-based distro (Gentoo) that patch occurred on my machine, making me responsible for it. On top of that, I was running it as a network service behind a protocol-translating proxy, just because that is how it was meant to be used, so even if it did have a source code offer, it would have been invisible to external users. I was ticking all the boxes for AGPL abuse without even knowing it.
(What nefarious service was I running taking advantage of a poor AGPL project? My personal email server, which used dspam as a spam filter - although not directly exposed to the internet, it could easily be argued that everyone sending mail to me is a "user" of dspam since the data they sent is piped to it, quite directly, and the AGPL does not make any attempt to carefully define these terms)
Right now the only AGPLed software I (knowingly!) run is Nextcloud (with 2 other users besides myself) and (as of a recent license change, sigh) Grafana, but I once thought of making a little patch to a Nextcloud CSS file as a joke, and had to remind myself that that would've been an AGPL violation without packaging it up and distributing it and updating the source link in the footer. For Grafana I also had a tiny proxy-inserted patch (just because it was easier that way than rebuilding, this was before the AGPL change) just to add the ability to display image icons next to dashboard names (again for a little joke displaying character images for servers), but I'm going to get rid of that before the AGPL update on that box because I just don't want to deal with any of this. Not exactly a comfortable feeling knowing I can't even make a trivial change to "free software" running on my own system without breaking the license. And it gives me zero incentive to contribute to these projects. I don't want to support this kind of ecosystem.
(Web apps: for fuck's sake, if you insist on being AGPL, please implement self-serving source code so we don't have to deal with any of this nonsense, and then maybe you can take GitHub pull requests without everyone violating the license too.)
I once had a discussion with the authors of a DAW that used the AGPL license, and pointed out that MIDI is technically a network protocol - meaning their DAW would have to figure out a way to make source code offers over MIDI, to be presented to users on the other end, even though MIDI doesn't even have any standard mechanism for user-interface text. Never mind that MIDI can even be used over a unidirectional transport, so you couldn't even do that at all in some cases. The AGPL doesn't even begin to consider these problems; it was written assuming everything is a web server or something. I got crickets from the devs. Sigh. (Why is a DAW AGPLed to begin with even?)
Seriously, it's a completely broken license, written by some lawyer who though they were being clever and had magically solved the SaaS + free software issue, without bothering to consider the consequences of what they were creating. And now everyone's sweeping the problem under the rug and nobody wants to seriously talk about it. Because how could the FSF be wrong about free software licensing?
> but that's not something really hurting us in any way
I dunno, for what it's worth the AGPL definitely turns me off from contributing to projects, but maybe you aren't losing enough contributors to care ¯\_(ツ)_/¯
This is of course still predicated on you not caring that your contributors are all violating each other's license. Is that a problem? In practice, probably not, if nobody actually makes legal demands over it. But it's a fact, whether it's a problem or not. And I don't like relying on "people being nice and not enforcing license violations" to run my open source projects. We have licenses for a reason, ignoring them and encouraging certain violations just because the situation isn't a problem (or because nobody understands the license) invalidates the entire point of licenses.
> and definitively better than getting stabbed in the back like some other projects got from some SaaS companies due to having a permissive license that allowed them to deploy changes without giving them back anymore.
Too bad that, as I explained, if a company really wants to use AGPL software without contributing back, they still can.
Personally, everything I've written recently is MIT or dual licensed, but I understand the desire not to allow companies to deploy modified versions of open source software without giving back. The AGPL just doesn't fix that problem. At all. Fixing that problem is incompatible with the Free Software Definition. If you really, really want to fix that problem that badly, you have to accept that your license cannot be a Free Software license by the standards we use today. It's one or the other.
A thought that's probably dumb: how many of these issues could you resolve by just adding the word "reasonable"? Ie:
> If you modify the Program, you must make a reasonable effort to offer all users interacting with the modified program remotely through a computer network [...] an opportunity to receive the Corresponding Source of your version
IANAL, but offering the source to users of a web app seems pretty reasonable. offering the source over MIDI does not.
This doesn't solve the problem of having two different parties, of course.
I'm sympathetic to the need for a license like the AGPL. But—perhaps it should be just be a EULA. Maybe freedom zero was a bad idea. It was written in a world where AWS didn't exist, and there's no shame in realizing that you need to change with the times.
Burden on devs and danger to users? Just give us the damn code. Take a look at the SSPL as well. Corporations will do all sorts of gymnastics to benefit off FOSS without releasing anything. I wish there was a "just give us the damn code" license, but there isn't. Calling the AGPL a EULA is just an insult.
> To do my job and boot my laptop nonguix is required but not even allowed to talk about it with the OS it intends to support, is not something I can agree with
The OS isn't a person. The OS has online discussion forums and the people who develop the OS CAN talk about it in the appropriate forum. Identifying and separating nonfree issues is a useful tool in their goals.
> In other words, you can’t microcode update a CPU to add or substantially change capabilities.
There is CCC security presentation floating around where someone reversed engineered microcode before it was signed, and designed a backdoor into it, a remote code execution triggered by going to a specific webpage. That is a substantial capability that exists in todays microcode.
> It is good nonfree software, just give up and accept it.
You already accepted it when you bought the CPU and it came with the base version. Your choices are to install a bugfix, or not. The FSF advocates for not installing the bugfix, or even informing users of the possibility of doing so. That is utterly illogical. There is no reason whatsoever to run broken proprietary software over fixed proprietary software.
> You already accepted it when you bought the CPU and it came with the base version.
No, that is a version you can't physically modify. The other version is one you can't modify because of it's license and signature verification. You are simply ignoring important differences, like saying an elevator is no different than a flight of stairs, they both get you up, and anyone who avoids elevators must be an idiot.
... but you can modify the base version. That's how microcode updates work, they patch it (via a patch register CAM). Are you trying to argue that the physical mechanism used for patching matters? That's an implementation detail, it has nothing to do with freedom.
Your CPU comes with patchable proprietary software. Period.
There is some read-only memory that contains the base version. It is executed on boot. You can tell the cpu to run a different version by pointing it to a different version during the boot process (or later). You can't change the version in the read-only memory.
The way it works is that the microcode update gets loaded into some (smaller) RAM next to the ROM, and then patch registers are loaded which virtually rewrite some ROM locations to jump to the RAM (at least for the duration of this boot), in order to update the broken bits.
You are literally hot-patching the ROM with an overlay. You are not replacing it wholesale.
And either way, as I said, the underlying technical mechanism is completely irrelevant for the purposes of assessing user freedom. You're running proprietary code. You could be running a less buggy version of the same proprietary code. Choosing not to is silly and only hurts you. Trying to take that option away from users of your software is anti-freedom.
If the FSF thinks that even having proprietary blobs is bad, why does the rule apply only to mutable copies? Why not just refuse to certify devices with hardware that contains blobs contrary to their values? There's no practical argument as to why it's only acceptable to allow a nonfree blob if it's not burned into silicon. Even if it did matter, from the perspective of a normal person, microcode in a chip versus microcode loaded after boot offers no meaningful distinction in functionality or freedoms. If the point is high standards, then why have this loophole at all?
If the answer is "because then nothing could be certified or recommended" (which I expect it would be) then you need to stop marketing the certification as a recommendation for actual people to buy hardware and instead market it as a certification of whether the product is in line with their ideals.
It has one tiny blob for ram initialization, people are looking into removing it. It may become RYF certified. Freedom wise, it is the best modern laptop.
The imx.8 can't even initialize RAM without blobs. If it comes with a modern WiFi it will need blobs too. Don't know the details about the display, but I don't think it affects all RK3399 devices.
The malicious/abusive parts of nonfree software are almost always tied to it's updatability. Avoiding updatable nonfree software prevents users from entering into an abusive relationship with a nonfree software vendor. https://www.gnu.org/proprietary/proprietary.en.html, 550 instances of malicious functionalities, I'd bet all instances are for software where the vendor can update it.
Your argument is like "Banning guns will incentivize people to use knives, people who want to only ban guns for violence sake are hypocrites." There is a kernel of truth, but it's really just ignoring the bigger reality.
People keep bringing this up like proprietary software can always be unilaterally updated by the vendor. That's not how it works with firmware blobs, the vast, vast majority of the time. The user has the choice to run whatever firmware version they want, for as long as they want. They have strictly more freedom than if the software were not updatable, since they can choose the least evil version.
I can't believe people are still trying to use this argument. It's plainly evident that mutable software gives you more choice than immutable software. Making the argument that autoupdaters are evil and can be abused doesn't suddenly make all mutable software more evil than immutable software.
> Sony restricted access to the PlayStation 3 GPU, so people who installed a GNU/Linux operating system on the console couldn't use it at full capacity. When some of them broke the restriction, Sony removed the ability to install other operating systems. Then users broke that restriction too, but got sued by Sony.
I'm one of the people who got sued by Sony. And I still think the FSF's take on all this is terrible.
And if free software existed for any of those chips, FSF would require it. If there is any room for consistency in the criteria, it would be to deal with the fact that some of the computers have less nonfree firmware than others. Eg: the raptor computer has far less than the x200.
Unpublished CLA is a no go. I assume the CLA says you can distribute my code under a proprietary license. Nope, nope, nope. Fix that, then I'll take a look.
