Common Misconceptions of the AGPL
Before getting into this post i want to make it clear I’m not a legal expert in any way and the following post is based upon my interpretations from spending a lot of time looking at software licenses.
The GNU Affero General Public License, version 3 (AGPLv3) is a complex & somewhat controversial open source license, but I feel it’s often misunderstood or misrepresented. The complexity does somewhat make room for confusion, but I think there’s also an element of companies/projects leaning into their own “interpretations” to make it fit with their insecurities or concerns, commonly being competitive use or forking. In this post, I’ll go through some of the most common misconceptions I see for this license:
You can’t remove our logos/branding!
For this we’ll use OnlyOffice as an example who provide code under the AGPL. From their FAQ:
Can I remove ONLYOFFICE logo or change it to my own? According to Section 7 of the GNU Affero General Public License v.3 (AGPL v.3) we’re permitted to supplement terms of this License requiring preservation of specified reasonable legal notices. Using this permission we do not allow you to remove the original ONLYOFFICE logo from ONLYOFFICE products and components or change it to your own one. The interactive user interfaces in modified source and object code versions of the Program must display Appropriate Legal Notices, as required under Section 5 of the GNU AGPL version 3. […]
So here they’re saying we can’t change/remove their logos from their AGPL software and this is backed up by references to the AGPL.
Before delving into the license itself, this is quite a clear limit to modification which doesn’t seem very open source. Thinking this through further, if someone did want to fork this to a new project and provide this to others, do you think OnlyOffice will be happy with others using their logo? A logo they prohibit removal of. Within a license file they use for their AGPL work they also state this:
Pursuant to Section 7 ยง 3(e) we decline to grant you any rights under trademark law for use of our trademarks.
So we’re not allowed to remove the logo but we’re also not allow to use their trademarks? Seems like we’re kinda stuck! So what does the AGPLv3 actually say? Section 7 does allow additional terms to be used but it specifically lists what kind of terms can be added. None of which fits OnlyOffice’s requirement to not remove logos. This may be the closest option:
b) Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or
But this can be done outside of specific logos. Preventing certain modification (logo removal) goes far beyond that and from what I understand would go against the rights of the license, the open source definition and the free software defintion. Section 7 later states:
All other non-permissive additional terms are considered “further restrictions” within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term.
So I believe you could effectively ignore such added requirement since, to me at least, preventing modification you’d need to make to not be in conflict with their trademark, is clearly a further restriction. In my view, this extra condition exists specifically as a barrier to forks and competitive use.
OnlyOffice isn’t the only offender of this. I first came across this in TinyMCE when it was LGPL licensed, where it layed out its specific “required” branding requirements.
To be clear, I’m not against attribution, that’s an important & core part of the AGPLv3 like many other open source licenses, but I’m against misrepresenting the license to prevent certain modification that seem to be in the authors benefit.
I can add custom terms to prevent competition!
Related very much to the previous misconception, where I mentioned section 7 and how it allows specific extra terms to be added, I’ve seen this abused in a few other ways too, specifically in preventing competitive code use. Here’s an example added term I recently came across:
SaaS Restriction: This software, or any derivative of it, may not be used to offer a competing product or service (SaaS) without prior written consent from
. Offering the software as a service or using it in a commercial cloud environment without express permission is strictly prohibited.
Not only would this not be considered free nor open source due to limiting use & audience, this type of term does not fit into the allowed categories defined in section 7 of the AGPLv3, so can again be removed following the AGPLv3 license, which creates an odd scenario where you have redundant, removable extra terms that only really act as a threat of the author’s wishes & intent. In this case I queried this addition with the project author and I was pleased to see they were considerate of my input, quickly removing the added restriction to avoid this confusing conflict.
Another prior example of this can be seen with Erxes:
- erxes is not permitted to be hosted as a SaaS version to compete with erxes Inc.
They weren’t so reactive, with no response and my input removed or closed with this additional term still there after a couple of years.
Network use means copyleft!
The core difference between the AGPLv3 and the GPLv3 comes down to network use, with that being where the AGPLv3 considers network use as distribution. This mainly affects when access to the original source and license has to be considered, so if you’re providing an application as a public website, you’ll have to provide public means to access the source & license.
This often gets misunderstood though, with the idea that the AGPLv3’s copyleft requirements come into action upon network use, leading to thoughts that if an “Application A” communicates with an AGPLv3 licensed API, then “Application A” would also have to be licensed to provide the same rights (so effectively be [A]GPLv3 licensed).
This is quite a common idea that I see whenever the AGPLv3 is discussed online (example), especially on Reddit and HackerNews. For a more significant example of this one, I’ll defer to Drew DeVault’s post which talks about how Google misrepresents this.
Forks have to stay public!
A notion that I’ve come across a few times is that forks of AGPLv3 projects have to remain public, in that their sources have to remain up in a publicly accessible location at all times for complete open access to all. A good example of this is with cal.com who’s readme stated the following:
Clone the repo into a public GitHub repository (to comply with AGPLv3. To clone in a private repository, acquire a commercial license)
It’s a bit convenient that this bit of misrepresentation is immediately followed by a link to contact for their commercial license. Within the AGPL there’s no requirement to keep all code completely public. Even if there was, I’m not sure how practical such a requirement would be. Would I need to do this as soon as I’ve made any change? What about cloning to a private GitHub repository? If I leave my changes local without pushing would I then be in breach of the license?
I queried this with the project, to which a co-founder responded. When I asked “What would be considered a “private repository”?” the response was:
when uploading/distributing on github/gitlab etc or when running on your own server as a commercial project
They quoted summaries & blogposts about the license, but never the AGPLv3 text itself. Generally, I got the impression that they didn’t really fully understand their own licence, thinking it provided many more “protections” than its actual text emits. After a further conversation on Hacker News this text was changed to its current form which doesn’t really improve matters.
The AGPL itself has a reasonable scope, and just requires that you distribute sources (under compatible license terms) to those you distribute the software/works/source to. With the AGPL network access/use does count as distribution though, so if you’re providing the software as a publicly accessible service, then you should also provide access the sources/license in a publicly accessible manner. Otherwise there are many scenarios where this would not be required, like using within a company, or providing a service to specific customers, in which case you’d only need to distribute to those customers.
Conclusion
The more time I’ve spent looking at th APGLv3 license, the more I respect it’s ability to ensure open rights to users in a way that’s reasonable in scope. Before then though, I was certainly scared to consider it due to a reputation which I think was not justified, but reinforced through misinformation. I think it’s important to call out such misrepresentation to allow the license be properly considered for what it actually is.