undefined | Better HN

0 pointsmarcan_424y ago0 comments

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.

0 comments

tlamponi4y ago

> 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.

marcan_42OP4y ago

> 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.

Wowfunhappy4y ago

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.

Bancakes4y ago

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.

j / k navigate · click thread line to collapse