Reading the AGPL
writing.kemitchell.com
writing.kemitchell.com
If you don't like the GPL then you won't like this. OK, I generally disagree, but reasonable people can disagree.
If you do like the GPL this merely fixes an important corner case.
And if you are someone who pretends to like the GPL but hides their work behind a network connection: just grow up and admit you don't like the GPL. Don't lie for PR purposes.
I think the AGPL is nonfree. It attempts to redefine the provision of a service as the same as the provision of software. They are not the same thing at all.
I believe that software freedom includes the right to keep my own local modifications private, if I'm not distributing the software (but only using that software locally to provide a network service).
The AGPL (and I would argue that even the GPLv3) attempt to restrict Freedom 0 to prevent "evil companies" (or if you want to word it differently "dumb customers") from foot gunning themselves. The AGPL and the GPLv3 would not be NEEDED if customers refused to use those products - but since the vast majority of people don't care about software freedom, the AGPL and GPLv3 try to prevent it - by restricting Freedom 0. Perhaps slightly, perhaps it's a good trade-off, but it's still a restriction.
I care a lot more about Freedom 0 than trying to "fix" the legitimate choices of customers and vendors.
Distributing software and providing a service via an API are not in any way the same thing. One is a noun and one is a verb!
Imagine a situation where I provide a human based service: someone comes to me and asks me to add two numbers together. I return the next day and tell them the sum. They are not entitled to know whether I used pen and paper, computer, software, whatever. That's private information, and it's my freedom not to share information that's not relevant to that business transaction.
It actually has nothing to do with software.
I theorize that the AGPL isn't actually enforceable as a result. I don't know of any actual AGPL enforcements against service providers.
You can still have trade secrets. You just can't have a trade process. Realize in most cases, you run up against this because you took someone else's code and are running it for profit.
Anyway, you’re not entitled to modify, copy, etc even if the software is distributed to you. Copyright exists exactly to guarantee that the creators have a monopoly over their creations and can more easily profit from them. It is just a consequence of that that users do not have the freedom of running, modifying, studying, etc the software they use as they see fit. You have to give them that freedom, if you want. By default you’re not required to do so, and you don’t want to, which is fair enough. AGPL is there for those who want to give the users even more freedom than the GPL gives them.
I don’t know if AGPL is enforceable or not. Using software remotely can be seen as a form of distribution, that’s what needs to be proven in court, I suppose. I don’t think it’s clear cut. Something like gmail using AGPL software seems a lot more likely to be a breach of the license than if someone publishes some graphs that were generated by a batch job linking to AGPL libraries.
You do realise that the AGPL does not apply to every software you could possibly ever use, and only to software whose copyright is held by someone else, that you downloaded, modified, and then used to answer such a question over a network, right? Sorry, I'm just bewildered at what you think the AGPL does, given your other responses in this thread so far.
But to use your very example: if you used another person (instead of pen and paper or whatever), asked them the sum of the two numbers you were given, and they said they'd give you the answer, but only if you introduce them to whoever originally asked you the question when you respond to them with the answer, and you said "Yes" to them (thus entering into an oral contract), and then went back privately to the original asker and gave them the answer, without introducing the two people to each other, then you're in breach of contract.
That's one way to look at it, but I think it's a distinction without a difference.
Take as an example a GPL library wrapped with a thin IPC interface (that is open sourced) which is used by a separate proprietary program running in its own process. Is this okay? What if they're running on two separate and independent microcontroller cores connected over the same memory bus? What about over a serial link? Add a few more OSI layers and you get to the AGPL.
In the end it's a matter of degree and its up to the author to decide where they want that line drawn for their project.
Nuance: The AGPL allows you to keep your modifications private _if you're not distributing the software_. It simply considers over-the-network usage as "distribution". That is how it defines it, in the legal text. This makes sense in many cases, where software is written primarily or solely for the purposes of providing network services. Authors of such software need a way to define network access as "distribution", and they have the AGPL for such software.
> I believe that software freedom includes the right to ...
Similarly, the permissive-licenses camp also believes software freedom includes the right to some things that the copyleft camp does not provide. Fundamentally, it comes down to a tradeoff: between the rights of a developer and the rights of an end-user. The permissive-licenses spirit places the former over the latter, and the copyleft spirit does it the other way. But in both cases, software freedom is maintained, even if for at most one type of persons. Sadly, it is logically impossible to maintain software freedom for both developers and end-users.
Disagree. As the article states, it's importantly different from the GPL, even under the FSF's own philosophy. As others have already pointed out, it could be said to infringe on Freedom Zero, The freedom to run the program as you wish, for any purpose. [0]
At the risk of just writing a far inferior rehash of the article: under the GPL, you can take code, modify it (Freedom 1), and run that code on your machine under whatever terms you want, e.g. as an Internet-enabled service. You are not obligated to publish the resulting source code, provided you also refrain from publishing the binaries corresponding to the modified source. With the AGPL, that's no longer the case.
One could argue it's just a matter of degree, as the GPL imposes rules on linking against non-GPL code, but I think the difference is still an important one.
Following copyleft, the FSF understanding of being free to do something typically doesn't preclude free but with an obligation to release your source under a Free Software licence. They do seem to have a limit though. The FSF consider the Watcom 1.0 licence to be non-Free because of its far-reaching source-publication requirements, which can apply even to private use. [1] The AGPL does something similar, except it only applies when your deployment is publicly accessible. (This is, of course, the whole point.)
Quite apart from all that, this isn't the first time I've read of technical legal issues with the way the licence is written, far exceeding those of the GPLv3.
As long as you don’t distribute it.
>If you modify an AGPL blog platform to add a feature I like, and share the source code with me, but don’t offer it to anyone else, there’s nothing in AGPL that requires me to send the change back to the maintainer. Nor, arguably, is there any obligation on me to offer source code when I run the program to host my own blog. If the maintainer finds out about it, and comes after me, my first argument is simple. I didn’t violate section 13. I didn’t modify the program. That’s the way it’s written.
This is a very interesting loophole. It's highly unlikely any company would be willing to risk it (as if company A pays company B to modify AGPL code and provide it to them it'd be a relatively easy argument that for the purposes of the license they're operating "as one") but it does seem a loophole that's not easy to work around. Always requiring the modified code be available would make it a license violation to download an AGPL work, change one file, and then delete it because you're bored.
Perhaps Google being terrified of AGPL is enough to do what it wants.
Imho the reasonable way to make it work is this: Assume Alice writes an AGPL software, Bob makes a modification and sends it to Claire, and Claire then uses it to host a blog, and David then reads the blog. Then Claire should be required to tell David where the source can be found, either by referring him to Bob's repo, or to a repo she herself hosts.
Right, but you don't have to require that (you can close the "transitive distribution loophole" by explicitly calling it out), and a clause like this would not be enforceable anyway, because all of this relies on copyright law, which is fundamentally about distribution. If there is no distribution, then the license terms do not apply.
IANAL, though, and this is where it gets dicey for me: can you really legally frame "putting software on a server that others can access through an API" as "distribution"? Or does that part not rely on distribution at all, making the AGPL sort of a combo copyright license and EULA?
(1) is immaterial to the discussion; I can copy to my heart's content in private, and as long as I don't distribute it, no one will know, and no one will take any action against me. At any rate, fair use defenses #1 and #4[0] are pretty compelling to cover private, non-distributive copying.
(2) is similar to (1) in that it has no teeth until you try to distribute your derivative work.
(3) is explicitly about distribution.
(4) & (5) & (6) are about public display/performance, which don't apply to software, and I would argue are also about distribution anyway.
Reproduction is inherent in execution, development, etc. on computers. See "licensed, not sold" and the analysis of the ways 117 differs from the CONTU rec.
Say Alice modified some AGPL software, and gives it to Bob, who then hosts his blog with it. It's true that the AGPL doesn't directly impose anything on Bob. However, as Alice modified the software, she must make her modified software offer source code. As Bob is using that software, his blog also offers the source code. He cannot remove that offer, because then he has modified the software and he is required to add the offer.
Yes, this could be problematic if Alice violates the license and doesn't make it offer source code, but every license fails when it's violated.
You modified the software to make a pull request, you even distributed it to github. You need a valid license to do this. You didn't update the software to point at your github repository, after all if you did that your pull request would be rejected. So the software is presumably not serving users an offer to download the source code (with the exception of quines) since it's now pointing at the wrong repository. So congrats, you didn't have a valid license and are committing copyright infringement.
---
I'm not sure it's valid, it's not clear to me that the source code of a program is a "version [that] supports such [remote] interaction [with users via computer networks". It strikes me as the case that only copies of programs running on physical hardware serving requests, or capable of being moved (not copied) to such hardware, are capable of such remote interaction.
The end user meanwhile takes your version not capable of supporting such an interaction, and compiles/interprets into a version that is capable of supporting such an interaction. But remember that the licenses defines "To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission". Compiling/interpreting/running the program does not require copyright permission [1].
[1] See (a), 1 https://www.law.cornell.edu/uscode/text/17/117
PS. Note I am not a lawyer and this is not legal advice.
for example, someone has a vanilla debian server running AGPL software -- would they unintentionally need to become a mirror of ftp.gnu.org ?
> 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
So if someone modifies the program to remove access to source and provides the program to someone else, they have violated the license. Who hosts it doesn't matter, it's the person modifying the program that must make sure the modified version has some way of offering source.
I download some AGPL code, modify it, including removing the part where it offers to make source available, and run it in some application where there are no users who interact with it remotely through a computer network.
I don't trigger the AGPL source clause, because I don't have interactive remote users. This means that for me the license is essentially plain GPLv3, not AGPL.
I choose to publish my modified source in some public place.
Alice downloads that source, runs it on her own server, and she do have users who interact with it remotely through a computer network.
But she has not modified the program, so she doesn't trigger the AGPL source clause either.
If I later choose to take down my modified source (which I can do because I was not obligated in the first place to publish is), and no one else happens to have made a copy avaiable, then we end up with Alice running a modified AGPL program with users interacting remotely over a network, and with no one obligated to provide source.
You can't just hand-wave "I have no remote users" so my source turns into GPL and therefore I've removed source access for network users. Come download my source and run it on a network.
Your misunderstanding is believing you don't trigger the source clause. You do, it's just that you don't have users so you ignore the clause assuming your program will never have remote users ever. Mistake by you. Why give Alice the source to something not complying to the license? That's on you.
Programs running on Linux are already considered not "linked" to Linux, which means they can stay closed source without breaking the terms of the kernel's GPL license. That likely wouldn't change if the kernel was AGPL: programs running on it wouldn't need to be AGPL.
So the difference would be that for direct interaction with a Linux system, the source code of the kernel would need to be released (the kernel itself, not programs)? That doesn't sound too hard at all.
GPLv3 -> prevents tivoization, some companies (see Apple) are scared/annoyed by it. Doesn't stop SaaS.
AGPL -> all of the above, makes many companies deathly afraid.
Licensing, itself, is political, so you cannot separate political from non-political when it comes to the political topic of licensing.
edit: in fact, the act of copy-lefting some work is a political action.
Kind of like web standards, actually: you may think RSS/ATOM are terrible standards and JSON Feed is the only way to go, but if you're writing blogging software, it should probably be able to generate an RSS feed.
What do you mean by compatible? the GPL and the AGPL are explicitly compatible to each other.
> It [the AGPL] is also technically not compatible with GPLv3 in a strict sense: you cannot take code released under the GNU AGPL and convey or modify it however you like under the terms of GPLv3, or vice versa.
In my mind, this is a pretty bad limitation. If I'm writing software for the free software community, it seems bad to me if someone working on a GPL project cannot take my code and use it as part of their project without the whole project then being under a mixed license. The terms of the AGPL would apply to a derived work even if all the other code was GPL. While it might sometimes be possible for someone to do everything they want that way, the added complexity means that using part of an AGPL project may be a non-starter even in those cases.
The AGPL is also not compatible at all with GPL 2, which many projects are still using.
Sounds like the Non-Profit OSL 3.0: https://opensource.org/licenses/NPOSL-3.0
GNU complains about the following provision:
> If You distribute or communicate copies of the Original Work or a Derivative Work, You must make a reasonable effort under the circumstances to obtain the express assent of recipients to the terms of this License.
This does seem pretty sketchy because I don't know what counts as a reasonable effort. GNU suggests that placing the software in publicly accessible version control or on an FTP server might be in violation of the license because it would allow recipients of your copies to obtain the software without providing "express consent" to the license terms. I think this is a bad requirement.
For example, PM2 is a dual-licensed (AGPL/commercial) NodeJS process manager available on npm.
I bet more than one SaaS company has had a significant problem to fix months or years after adding one of these libraries as a dependency in a project.
More reading: https://news.ycombinator.com/item?id=21966864
Seems like you wouldn't even need to do this much, no? It should be possible to "unquine" such a program with any ol' proxy that:
1. Blocks whichever URLs are used to obtain copies of the source code, and optionally
2. Edits the page HTML in-flight to remove links to those blocked URLs
Step 2 obviously assumes that the HTML itself is not the program's code - i.e. the same assumption by which we don't need to subject ODF documents to the GPL just because LibreOffice or whatever is GPL'd.
As a independent open source author, if big corp doesn’t abide by my license, am I really going to pay lawyers from my modest savings to sue them so that they abide by my license? Seems there’s a practical asymmetry that makes open source licensing largely theoretical for all but a handful of the biggest projects out there. Of course, I’d very much like to be proven wrong.
This article catches on one important detail that really ought to be more heavily emphasized (and if the author reads Hacker News, I would like to see a post on this topic specifically): what is the actual legal interaction between software, software licenses, copyright law, and contract law? As I understand it (IANAL), the actual legal answer is that it is about as clear as mud.
As a software developer, it feels like software copyright and derivative works should extend only to the natural API boundary. That is to say, if the project in question is simply a library and it's being included in an application, unmodified, and interacted only via the API--then the larger application shouldn't be considered a derivative work of the library, and a license granting further copyright shouldn't be required. However--again, AIUI--this is not what the law actually holds to be the case. Instead, the courts generally tend to view applications holistically and struggle to separate out tiny components.
For a clear example of the actual legal stakes here, just look at the recent Google v Oracle decision. Both Google and Oracle agree that Google did not copy the JVM implementation, nor the Java libraries; only the API of Java was copied and only the API of Java is at stake in the analysis. But look closely at the fair use analysis: very quickly, the analysis is being done under the assumption that all of Java is being copied, not just the API [1]. When the issue at hand is over a tiny cog in a larger product, I do not have a lot of faith that courts will be able to strictly limit themselves to look only at that cog.
In more concrete terms, then. If I have an application, and I use a GPL library, the standard interpretation of the GPL is that my entire application has to be distributed under the GPL as a result. By analogy, extend this to network services, and the library is now an individual network service (say, a message queue service) and the application an entire website (say, facebook.com). Does this mean that the website is now a derivative work of the network service? [2] More importantly, if you think it is not, but your opponent in court claims that it is, how sure are you that you can convince the judge to agree with you and not your opponent? Now on top of this you throw the AGPL's extra clause, and you might come to understand why there is some real reason to be reluctant to use the AGPL.
At the end of the day, the real problem here is that IP law isn't all that well-designed for software, especially modern software development practices (such as combining a lot of off-the-shelf libraries together). And the licenses that we use are an annoying mishmash of industry terms and legal terms that don't help the situation at all.
[1] This is much more evident in Thomas's dissent, but Breyer's opinion does dip into this. Although Breyer is mostly using this to point out that the API is only a small component of the product as a whole.
[2] For extra fun, you can also invert the question--if the website isn't a derivative work of a network service, then why should an application be a derivative work of a library it uses? And if the application isn't, then how can the GPL in practice be any different from the LGPL?
To be precise, if you do NOT distribute under the GPL you are in violation of the license (which has been read as a contract by some courts) - the result of said violation is up to the process and law; releasing your code on the GPL simply removes the violation; you're never "forced" to do so.
I'm kind of surprised that the GPL loophole I'm thinking of hasn't occurred in the wild yet, as far as I know, because it seems like it would be an easy one to have happen unintentionally.
Here is this loophole.
1. Alice decides to make a generic hardware/software platform to sell to people who want to make IoT devices. Her hardware has two flash card slots, one which is used for the boot partition and OS partition, and the other is empty. She includes a modified Linux-based OS that has drivers for all the hardware in the system, and user-mode libraries for accessing everything.
2. She ships these systems configured to initialize all the hardware, then look for a flash card in the second slot that contains a Linux filesystem, mount it, and look for an executable named iot-app in the root of that filesystem, and then exec that application.
The idea is that if you want to build some IoT device you can buy one of these systems from Alice, and then you just have to write a user-mode application to provide whatever service or functionality you are trying to sell.
3. Bob is making an IoT device. He orders 5000 of Alice's systems. Alice ships them to Bob. Alice includes with every single system she ships a CD-ROM containing the complete machine readable source code for everything on the boot/OS flash card.
Note that this satisfied Alice's GPL requirements. She has accompanied all GPL code that she has distributed in object form with the corresponding source code.
4. Bob writes his iot-app application, makes 5000 flash cards formatted with a Linux filesystem that contain that application, sticks them in the second card slot, puts each system in a nice box with a manual, and starts selling them to end users.
Bob has no use for the 5000 source CD-ROMs, and tosses them in the big green recycling bin out back.
5. Carol buys one of Bob's system, realizes that the system is Linux-based, and asks for the source code.
Q: who, if anyone, is obligated to give Carol the source?
I don't think Alice is. She included source with every copy of the code she shipped, thus satisfying all of her GPL obligations.
As far as Bob goes, he bought copies of a copyrighted work, those copies were lawfully produced, and he then sold those copies to others including Carol. He has not made any copies, nor has he modified the copies. He just passed them on, one for one, from Alice to his own customers.
This sure seems like it falls squarely under the first sale doctrine, which would mean that Bob does not need permission of the copyright owner(s) to do this. But if Bob is not doing anything that requires permission of the copyright owner(s), Bob does not have to worry about copyright licenses.