What does the AGPL require?
24 points by runxiyu
24 points by runxiyu
In the GPL FAQ, the FSF writes:
Linking a GPL covered work statically or dynamically with other modules is making a combined work based on the GPL covered work.
Since GRHS uses Furgit as a library, it is making a combined work based on Furgit. Therefore, GRHS is indeed a “modified version” of Furgit.
It's worth keeping in mind that this is the opinion of the FSF, and not necessarily true across all legal jurisdictions. For example, in the EU, the prevailing legal opinion seems to be that linking, statically or dynamically, does not constitute a "modified version" or a derived or combined work, and therefore that GRHS is not a modified version of Furgit.
That said, I believe there was a case in Germany recently where someone was sued for not following the restrictions set out in the GPL, although I'm not sure whether the case hinged on this particular distinction. My impression of this detail is that it is legally very untested, and there are a lot more claims about the meaning of a derived or combined work than there are actual judgements or clear-cut answers.
It's also an opinion that goes completely against common sense. Or mine at least. Using a library shouldn't be "morally" different from calling into an external binary or a remote service, because all of that is just minute technical detail of how things work. The FSF's intent clearly is activist in nature — to use legal trickery to ensure "moar freedomz" by forcing proprietary services to release their entire source if they happen to use an AGPL dependency. But I believe it shouldn't work at all. I'm glad the prevailing legal opinion in the EU agrees.
This is extremely concerning.
Releasing free software is all about activism. It's about all the hackers out there who share the same values. It's all about creating a software ecosystem where we are in control of our computers, rather than being controlled by them. All other concerns are secondary.
Take that away, and there's no point. Choosing an open source license is just asking to be taken advantage of. It's either AGPLv3 or all rights reserved. If the AGPLv3 doesn't work, then I might as well go proprietary. Copyright 2025 all rights reserved.
I am trying to cook up a new copyleft stronger license for hobby project. Hope to solve these issues but hard to enforce even license is formed.
Given that the LGPL/EUPL exist for that purpose, it's clear that the intent on using AGPL is to force the release of the source code if linked against.
Using legal trickery to get out of the AGPL/LGPL/EUPL is to the detriment of these licenses existing. Morally, if one uses this trickery, it means that they are contrary to having "moar freedomz" and for them is not enough with not using these licenses and the code licensed with them. But that they explicitly want to do the amoral thing of misusing the licenses, contrary to the will of the authors of the source and the license.
I mean, this is how the license works. The goal of the license is to trigger copyright protection (via the existing mechanism of derived works) and then grant a specific license for those derived works that conforms to the principles of free software. That's not necessarily a bad thing, but it hinges on the idea that linking creates a derived work under existing copyright law, and that's where things start getting murky. We can't just rely on the intent of the license authors here, because the license authors are in turn relying on existing copyright law working the way they want to, and they don't get to define that.
That said, it's really difficult to get a clear answer on whether the law works the way the FSF want, which is what makes the use of *GPL licenses difficult (unless you in turn just release everything under the same license). Even if you believe you're right, proving that is going to be an expensive and risky business. I don't think this is a question of morality, and it's not about using legal trickery to "get out" of these licenses, it's all comes down to the legal question of how derived works are defined and created.
Hence why I think the EUPL is quite a nice alternative. There is still a certain amount of ambiguity in how a derived work is defined (because that's ultimately decided by the law and the courts), but (a) the authors clearly acknowledge that ambiguity, (b) the authors clearly do not intend for linking to create a derived work, and (c) the authors explicitly provide the legal framework by which one would argue that linking does not create a derived work, at least under EU law. As a result, you can use EUPL software and be much more confident about exactly what rules you will need to abide by, at least within the EU. And as a software author, when people do create derived works, you still have the same protections against proprietary works that the *GPL licenses provide.
The license itself is the trickery here, specifically the attempt to specifically define derivative works to be something unreasonably broad.
Something I'm missing from these hypothetical scenarios is a grounding in real-world practice.
As in, if GRHS would be VC backed, it would give exactly zero fucks about the license, because they can stay in court for a decade, and the author can't. If GRHS is not VC backed, they'll either won't mind being AGPL themselves, or they'll steer clear of anything viral.
If you want to avoid the first case, use something like the Komorebi license, or any of the post-open source licenses. Sure, they're not OSI nor FSF approved, but chances are, no corporation will consider using them either.
I dunno. I've worked for a few VC-funded companies now, over the years, and we were always really really careful about licensing.
Granted there are some high-profile exceptions (baaaasically every AI would-be-unicorn out there training models on Copyrighted material), and VC funding has some not great aspects. But honestly I've not observed this myself.
If a VC company wouldn't care about following AGPL, why would they care about following the Komorebi license? It seems to me like using Komorebi over AGPL would only hurt companies that would comply with AGPL.
Because they already know an AGPL case can be stalled in court ~forever. Komorebi? Probably that too, but it's an explicitly anti-commercial license, unlike the AGPL. Considerably harder to stall if it comes to that.
There's already an MIT licensed git client in libgit2 so GRHS just links with libgit2 for accessing the contents of the git database. GRHS can call the GPL licensed Git CLI for things like repacking repos, which is fine cause that's not a linking relationship.
And then that's not my problem, and the license I chose did what it was supposed to do. Mission accomplished!
What did you chose it to accomplish? It sounds like we're still not entirely on the same page so I'd love to hear where you're coming from.
Since GRHS uses Furgit as a library
Does the logic still follow if furgit is a binary that GRHS calls?
Or, as more AGPL-specific example: if GRHS RPCs furgit over the network
I think that would depend on whether the end-user is "interacting with [furgit] remotely through a computer network", which is interesting in its own right (although rather different)
I think that's a separate question... I could easily see an interpretation where
I find the AGPL very confusing.
PyMuPDF is an excellent Python library for working with PDF files: https://pymupdf.readthedocs.io/
It is AGPL licensed, with an option to commercially license it: https://pymupdf.readthedocs.io/en/latest/about.html#license-and-copyright
Can I write a piece of Python code that starts with the line import pymupdf and release that under a license other than AGPL?
Their own licensing page says the following while trying to upsell to their commercial license:
You cannot deploy our open-source as part of a server-based application or service, without disclosing your own application’s full source code under AGPL to any users interacting with it.
So if I use the line import pymupdf anywhere in my software I need to make the entire thing AGPL licensed?
What if I were to create a web service using that library which is entirely AGPL itself but exposes an API endpoint where I can POST http://my-api/process-pdf and send it a PDF file? Do I still need to AGPL-license any code that calls that API that I built?
Another fun question today is if an LLM can generate a license violation. PyMuPDF is often generated by an LLM and then run in a sandbox (eg: OpenAI will happily do that).
Hah. Claude Code for web is a "network service". If they generate me a PDF using that library do they need to AGPL their entire stack?
Can I write a piece of Python code that starts with the line import pymupdf and release that under a license other than AGPL?
You must release it under the AGPL, and you can additionally release it under any license that is also compatible with the AGPL (I'm not aware of any).
Can I write a piece of Python code that starts with the line import pymupdf and release that under a license other than AGPL?
You must release it under the AGPL
I'm not entirely sure but I don't believe this is correct. Assuming your work is not a derivative work of pymupdf (and it usually won't be a derivative work) I believe you're free to release it under whatever license you want. You're only plausibly required to release it under the AGPL as well if you expose it as a network API endpoint (because at that point the thing you are running is a plausibly a derivative work by virtue of being a combined work and the AGPL's networking clause kicks in requiring you release the full combined work).
Otherwise you just outright own the copyright on the non-combined work (i.e. the sourcefile that imports pymupdf but doesn't actually contain a copy of pymupdf) and should be able to do whatever you want with it. If you don't give it an AGPL compatible license you're going to make it difficult for other people to legally use and distribute... but that doesn't mean you have to.
(I'm not aware of any).
Wouldn't most open source non-copyleft licenses be? E.g. the MIT?
You're only plausibly required to release it under the AGPL as well if you expose it as a network API endpoint (because at that point the thing you are running is a plausibly a derivative work by virtue of being a combined work and the AGPL's networking clause kicks in requiring you release the full combined work).
Yes, this is correct, and I should have made this more clear: If you do not "propagate" the work by making the "covered work" available, then the AGPL distribution requirement doesn't kick in, i.e. you are not forced to AGPL-license your own part of the combined work.
I have a lot more experience dealing with the precursor of AGPL v3, which is called Affero GPL v3, and is not the same thing: An older license, called the Affero General Public License and published by Affero, was designed to accomplish similar goals. This [AGPL license] is a different license, not a version of the Affero GPL, but Affero has released a new version of the Affero GPL which permits relicensing under this license. Of course, the AGPL then goes on to refer to itself repeatedly as the Affero GPL license 🤦♂️. You can't make this s*** up.
I'm not entirely sure but I don't believe this is correct. Assuming your work is not a derivative work of pymupdf (and it usually won't be a derivative work) I believe you're free to release it under whatever license you want.
The AGPL does not use the "derivative work" language. The definitions you are looking for are "modify", "covered work", and "propagate", defined in section 0 of the AGPL v3 license. From my reading, I would expect that any good lawyer would tell you that your belief is incorrect.
If you use the AGPL code (including using it over the network, e.g. as a web service) and make that (or anything built with / on top of that) available, then you must provide the totality of that source under an AGPL license:
You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy.
... and ...
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. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.
... and ...
A secondary benefit of defending all users' freedom is that improvements made in alternate versions of the program, if they receive widespread use, become available for other developers to incorporate. Many developers of free software are heartened and encouraged by the resulting cooperation. However, in the case of software used on network servers, this result may fail to come about. The GNU General Public License permits making a modified version and letting the public access it on a server without ever releasing its source code to the public. The GNU Affero General Public License is designed specifically to ensure that, in such cases, the modified source code becomes available to the community. It requires the operator of a network server to provide the source code of the modified version running there to the users of that server. Therefore, public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version.
I will say, having read all of the GNU licenses many times over the past 30+ years, that they are generally very poorly written, and relatively confusing, which is a Very Bad Thing (tm) in a license. I'm fairly sure that the GNU licenses were not written by lawyers, and if they were, I'm terribly disappointed in the quality of the lawyers that GNU had access to. The Affero version of the license, on the other hand, appeared to me at the time to have actually been written by a lawyer. But like most of the other GNU licenses, the AGPL v3 (trying to encompass the Affero goals) appears to have been written primarily by Richard Stallman, or someone of that same ilk.
The AGPL v3 license is short enough to read through in a few minutes.
Wouldn't most open source non-copyleft licenses be? E.g. the MIT?
No. You cannot relicense GPL (or AGPL etc.) work under the MIT license.
On the other hand, you can take MIT licensed code an relicense it under the GPL (or AGPL etc.) license. That has been done many times.
The AGPL does not use the "derivative work" language.
By that logic neither does GPLv3. Colloquially this section is what people refer to when talking about derivative work with the AGPL:
To "modify" a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a "modified version" of the earlier work or a work "based on" the earlier work.
With regards to that statement:
If you use the AGPL code (including using it over the network, e.g. as a web service) and make that (or anything built with / on top of that) available, then you must provide the totality of that source under an AGPL license
That is not correct. The AGPL's network clause triggers only for the program that contains, links to, or is based on AGPL code. It does not propagate across any network API boundary.
The AGPL on a very fundamental level runs into the FSF's own freedoms and is a hack around it. The practical result has been that there are people in the free software and open source community who take the view that it's very inconvenient for developers but might also be legally possible to work around it with enough motivation. See for instance Hector Macan's view on it.
The AGPL does not use the "derivative work" language.
The language comes from copyright law, not the AGPL. You're right that I'm being slightly imprecise here, because I believe the actual boundary is that it is both a derivative work as defined by law, and a covered work as defined by the AGPL. If it is both then you'd be required to license the file AGPL even if you aren't serving network requests with it. If it is only one, or neither, you would not be... because either the law means you don't need a license to distribute the file in the first place or the license says you don't need to license it AGPL or both.
No. You cannot relicense GPL (or AGPL etc.) work under the MIT license.
Of course not, but you can grant additional rights to the portion you have copyright on. To expand my understanding here is
I definitely agree on the quality (or lack thereof) of the GPL licenses.
If you use the AGPL code (including using it over the network, e.g. as a web service) and make that (or anything built with / on top of that) available, then you must provide the totality of that source under an AGPL license:
I don't believe this is remotely clear in either direction.
People occasionally discuss whether there should be a license that's similar to LGPL (linking to an LGPL library does not force a program to become free software) but with a network clause (like AGPL).
https://web.archive.org/web/20150512001521/http://mo.morsi.org/blog/node/270
The EUPL is essentially this. It works under the principle that linking does not constitute creating a derivative work, but other than that it is copyleft (any changes or derived works must be released under the same license), and has a network clause.
As I understand it, the biggest issues are that it's not as widely known about (and therefore your legal team may not want to deal with it), it's EU-based (and therefore your legal team may not want to deal with it), and it has a clause that allows derived works to use other copyleft licenses such as the GPL, which could in theory negate the network clause.
is 'Linking' applicable to Javascript packaging methods?
For example, is LGPLed javascript library packaged into 'same javascript bundle' a statically linked or dynamically linked?
If using, say, webpack to package an LGPLed library into ones proprietary web UI, woulbe considered 'static linking' -- then an LGPLed library also becomes 'viral' meaning it infects with its licese anything that's statically linked to it.
I believe the FSF's definition of static linking is any situation where the end-user can't replace the package themselves. So a single JS bundle would be statically linked, but arguably if you'd left the LGPL library as-is and imported it at runtime, it would be dynamically linked. But this is just the FSF's opinion, and I don't believe these details have ever been tested in court, at least not for the JavaScript case.
Again, an advantage of the EUPL, where the distinction between static and dynamic linking is irrelevant, because it's all allowed.
The FSF’s model is nonsense. It attempts to encode the C/UNIX linkage model in legalese.
We had long discussions with their lawyers over Objective-C categories and the LGPL. An Objective-C category can replace a method in a class. GNUstep is LGPL’d. If I modify it to fix a bug in a method, I must distribute that fix. If I put a category in my app that replaces a method to fix a bug, I don’t need to distribute that. For extra fun, I can put methods in categories and use reflection APIs to dynamically modify the classes in the LGPL’d library that mean my code won’t run with a modified version of the LGPL’d code, unless you reverse engineer my binary (which I can prohibit with a EULA).
https://runxiyu.org/blog/agpl/#:~:text=i%20am%20not%20a%20lawyer was what I was afraid that I was going to see in that post
From my experience lawyers are not really going to help you except for telling you not to touch the license.
My experience with lawyers is that they are extremely resistant to giving a clear yes or no answer to any question. That doesn't appear to be how the law works. Their job is to help you evaluate the risks involved in picking one or other answer to your question, and they'll try to help you understand how much of a gamble you are taking against any future legal action. It's really frustrating!
I've had 2 outcomes that mirror your experience, and one outcome when the corporate lawyers convened about it and gave it the a-ok (specifically the "over the network" part, not pulling in a library dep)
My personal opinion is that if it's considered verboten enough for Google, then I don't want to be a trailblazer
My personal opinion is that if it's considered verboten enough for Google, then I don't want to be a trailblazer
The counterpoint is that precisely because it's considered verboten enough for Google, you might want to do it.
Google's policies are based on Google's priorities, which are, roughly, 1) to take as much as possible while giving back as little as possible and 2) to expend every possible effort on shielding themselves from any possible legal attacks, even ones where they would be in the right (because winning still drains your bank).
Essentially, Google is treating free software as an extremely adversarial environment. Probably—hopefully—that isn't your goal.
I mean this in all seriousness: do you honestly believe that Google gives back as little as possible? I can think of about 5 or 6 very famous, FOSS licensed, Google originated projects that have dramatically improved my day to day life. Now, I understand that there is quite a bit of Google hatred in the world, but I feel it is disingenuous to say they've given very little back
Essentially, Google is treating free software as an extremely adversarial environment.
That's not true!
... they're also treating it as an unregulated commons, too 😜
The AGPL unfortunately is probably used as a license to push people into a commercial license. There are very few large projects that don’t use a CLA. It works be really helpful for that license to make it to a court one day through an enforcement related to a genuine fork under the AGPL terms to see what the actual behavior of that license is.
Why "unfortunately"?
Because it means that unlike the GPL the license is sometimes used in combination with a CLA only which creates imbalances between the rights holder and contributors. I wrote about this extensively when the company I worked for launched a fair source license: https://lucumr.pocoo.org/2024/9/23/fsl-agpl-open-source-businesses/
It is totally okay for non-lawyers to read and interpret legal texts.
As with all things, quality may differ.