Understanding the AGPL: The Most Misunderstood License
The advent of open-source changed the entire software industry, for once and for ever. But the control on who can do what with open-sourced code, has been a challenge, and is still a challenge. That’s when open-source licenses came to the rescue. But always remember this: there’s no land without stone and no meat without bone. There are over 80 OSI approved licenses and the numbers have only increased, making it hard for open-source developers to choose licenses for their projects, with each license having its own benefits and drawbacks. The AGPL, short for the Affero General Public License is one of these licenses, more specifically a strong copyleft license, and is arguably one of the most misunderstood licenses.
Why another GPL?
Wait, what? Another GPL? Umm, yes. The AGPL is almost identical to the GPL, except for this addition to Section 13:
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 has one direct implication — if you let users access any AGPL licensed software over a network, then that is also a form of distribution. This is what the GPL had missed out. With the boom of the cloud era, SaaS has exploded, and instead of distributing software directly, developers and vendors started digitally delivery of software.
Let’s take an example of a binary application (not a library) developed by Bob. For the sake of representation, let’s call it XBin, which can be used to, say, automatically allocate more resources whenever a web app runs out of them. (PS: This is an example)
Step 1: Bob uses the GPL
Bob decides to use the GPL. It’s great for him as all of his users send patches to him whenever they find a bug or want a feature to be added. Bob happily merges their code — and is happy! But one day he sees that a big cloud provider, ProviderX, is providing XBin as a part of its project management suite with more features. He’s unhappy about this fact, because he’d have liked ProviderX to have submitted these as patches to improve XBin. Now, Bob can’t do anything legally, because the GPL doesn’t cover network distribution!
Step 2: Bob switches to the AGPL
After realizing the drawbacks of the GPL license, Bob switches to the AGPL from the next release. Now, whenever ProviderX makes any change and distributes it as a service to it’s users, it will have to make the changes available in source form under the same license. Hence, Bob can merge any improvements made by them into his own source code. Now, it’s fair play! Since then, Bob coded happily ever after.
The acceptance problem
However, the big cloud guys didn’t like this! Several companies have their own AGPL policies, like this and some guys have even voiced out against the adoption and use of the AGPL, calling it toxic. But AGPL adoption continues to grow among several SaaS providers, and DBaaS providers are among the most popular adopters. The point, that most people miss, is that, the AGPL is just a super-set of the GPL, which terms distribution to also be network distribution, and nothing more!
Now let’s take a look at the YAYs and NAYs when using an AGPL licensed binary. I’ll take my project, Skytable as an example.
Scenario 1: Using an unmodified AGPL binary
Bob is back again — but this time, he decides to build a web app while using Skytable, which is an AGPL licensed database, for storing data. His app lets people sign up and save their favorite books, and this data is stored in the AGPL licensed database.
Bob’s confusion: Do I have to open-source my app’s code?
The answer: No! The AGPL has got nothing to with Bob’s app! Since Bob has not modified the database, and is merely using it in binary form, “as-is”, he doesn’t have to do anything other than improving his app!
Scenario 2: Using a modified AGPL binary
Bob now realizes that it would have been better if Skytable would have a query type X, it would have been more convenient for him. So he downloads the source code and modifies it. Now he has built, what would be called, a derivative work, but, he hasn’t distributed it directly.
Bob’s confusion: Do I have to open-source my app’s code?
The answer: No! He doesn’t even have to give back the changes he made to the database, since he is not letting users directly access the database. His app’s code — remains his own.
Scenario 3: Using a modified version, in private
People at Bob’s office like the modified version of Skytable, and they want to use it inside their workplace. Bob’s fellow workers have also added some authentication features to Skytable, to enable workplace users to authenticate themselves. But this code isn’t safe to be given back to the author of Skytable (I mean, that’s me!).
Bob’s confusion: Do I have to disclose the changes?
The answer: No! Since Bob is using it internally, within his organization, he is not distributing it to other people. Such copies of modified AGPL software, can be kept, without disclosing changes.
If you followed this example well enough — you can clearly see that the AGPL doesn’t really bother with your app, or service which uses the AGPL binary as a backend, but instead, cares about what you do with the the AGPL licensed binary.
Conclusion
To put it in one simple line — if you use an AGPL licensed binary “as-is”, without any modification, then you don’t have to think much — just work on your stuff man! But, if you make changes to the AGPL code and distribute it — then you’ll have to make your modifications available to your users in source form, to remain legally correct.
Now before you blow up the comment section — here’s one thing: this is not legal advice in any way! Feel free to correct me if I happen to have mislead you (and myself), somewhere.
Interesting reads
- Lack of leadership in open source results in source-available licenses
- Source Available vs Open Source vs Free Software
- The Amazon Effect on Open Source
If you like what you just read, consider giving a 👋🏻 and sharing this article! Also, do take a look at Skytable on GitHub!
Revision history
Update #1: October 6, 2021: TerrabaseDB in now Skytable
Update #2: September 13, 2022: Thanks to reader Aaron Wolf for making a correction around upstream contributions
