AGPL license is a non-starter for most companies
The original version of this article strongly argued that AGPL licenses as generally bad for commercial software. Since publishing, I’ve received feedback and counterarguments from open source licensing expert Heather Meeker and decided to update the blog post. The conversation around the AGPL license is ever-evolving and more nuanced than simply “it’s good” or “it’s bad”. My goal in updating the article is to capture this nuance. OCV’s official policy is that we strongly prefer MIT-licensed open source software and may choose to not start a company around an AGPL-licensed project.
Thanks for sharing, great article. We agree about the friction, that it is lower for application software than infra, and that in the age of SaaS AGPL makes more sense than GPL. BTW Mattermost also licenses their binary as MIT to reduce friction, might be interesting to others.
— Sid Sijbrandij (@sytses) October 20, 2023
The AGPL license was designed to close what’s perceived by some as a loophole in the GPL license. The GPL is a popular free software license that guarantees anyone who has received a copy of the software the right to run, study, modify, and share it for free or for a fee. Distributors of GPL-licensed software are not allowed to place restrictions on the rights guaranteed by the license. For example, distributing the software under a non-disclosure agreement is forbidden. The license terms follow derivative works and are directly applied to modified code when distributed. The GPL was designed to ensure that all copies of the software remain open source, regardless of who or how the software is changed.
The GPL was created before SaaS took off so the license text only applies to distributing downloadable software. When someone distributes software via a SaaS model, the binaries are never distributed to the end-user meaning the license terms don’t apply. This allows SaaS providers to take GPL-licensed software and distribute it under other license terms. To the authors of the GPL, the Free Software Foundation, the SaaS “loophole” is considered an abuse of free software so they created the AGPL to close that loophole. The AGPL license is nearly identical to the GPL with the exception of the addition of clause 13 which states if you make access to modified software available to users over a network, you must make your source code available to those users.
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. 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.
Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License.
One of the major problems with the additional text is that it is vague. It only specifies how GPL and AGPL licensed code works together, but not other licenses. It also doesn’t specify what qualifies as access, stating only that “users interacting with it remotely through a computer network” are guaranteed access to the source code. When incorporated into a company’s codebase, it’s unclear what other code may be exposed to the virality of the license. The fear is that a company could be forced into open-sourcing software that was not intended to be open source.
AGPL restrictions make compliance hard, hindering corportate accessibility and adoption
The Free Software Foundation has a specific point of view on free and open source software that all computer users are entitled to the four freedoms to run, study, modify, and redistribute software. It’s founded on the ethical principle that all software should be free. As a result, licenses like the AGPL restrict how an end user can apply the software. The unintended result is that the AGPL tends to hinder open source use instead of making more software open. Google has gone so far as to completely ban the use of any AGPL-licensed software within the company.
Many open source users see the SaaS “loophole” as a natural use of open source software since it doesn’t place restrictions on how the software can be used or distributed. Some argue that trying to force the AGPL will result in companies writing their own proprietary software: “If all open source developers insisted on AGPL…what would happen is that companies will avoid it entirely, and write their own instead. Since corporate-funded development far outstrips freelance in terms of hours of work contributed to open source, what would result is thus mostly bad closed source, plus some also-ran AGPL projects with no funding,” writes Reddit user temujin9. “So if you believe ‘all software should always be open source’, you’re actively working against that aim by making your software a less accessible, less broadly acceptable type of open source.”
Instead of creating standards for how to comply with the AGPL, many businesses retract completely. Recently, Agnostiq changed Covelent’s licensing from AGPL to Apache 2.0 citing, “accessibility to a broader community of users, removing the previous barriers imposed by the AGPL license” as the primary reason. “Many Covalent users have expressed challenges with the AGPL license and its copyleft requirements,’’ said Oktay Goktas, CEO at Agnostiq. “Moving to Apache removes the constraints imposed by AGPL and gives the community what it needs to flourish.” The AGPL license is complex which makes compliance more difficult for companies. Often, it’s easier for a company to create a policy disallowing use of the AGPL than it is for them to implement compliance policies. This hinders the project’s ability to gain traction.
Acceptance may be growing for application software
According to open source licensing expert, Heather Meeker, corporate fear around AGPL compliance may be easing, especially with application software. “But the “stop” category in a license policy is not the same as a ban,” she explains. “Having worked with hundreds of clients on open source compliance in my law practice over the years, I’ve seen first-hand how this works. It means ad hoc human approval is needed to use software under the license. That approval does create friction in adoption. But what balances against that friction is a great product.” She argues that users adopt software, not licenses, and that as more AGPL-licensed open source projects become hugely popular, the less resistance there will be to the license. Plausible and Grafana are two companies that recently switched to the AGPL license, and many other up-and-coming COSS companies are choosing the license.
Just noticed that nearly all of these are AGPL. https://t.co/9Vq4AYE84l
— JJ — e/acc (@JosephJacks_) October 21, 2023
One of the reasons for its growing popularity is the rise of commercial open source application software. Compared to infrastructure, it’s less complex for application software to comply with licensing requirements. “Open source originally thrived in the basic computing stack. Permissive licenses like Apache or MIT work great for infrastructure software,” Heather explains in her blog post. “Copyleft, in general, is more problematic for IT managers adopting infrastructure software, because they need the flexibility to make significant changes to integrate infrastructure code, and don’t want to wade into analyzing copyleft licensing requirements.” Alternatively, application software is typically stand-alone and doesn’t require the user to make many or any modifications to run.
AGPL dual licensing loophole
The AGPL is not immune to its own loopholes. Under the AGPL, the original author has copyrights and thus the exclusive right to dual commercial licensing. They can release software as open source under the AGPL and then release a SaaS version under a commercial license. This phenomenon was summarized by Flask developer Armin Ronacher in 2013:
“The AGPLv3 was a terrible success, especially among the startup community that found the perfect base license to make dual licensing with a commercial license feasible. MongoDB, RethinkDB, OpenERP, SugarCRM as well as WURFL all now utilize the AGPLv3 as a vehicle for dual commercial licensing. The AGPLv3 makes that generally easy to accomplish as the original copyright author has the rights to make a commercial license possible but nobody who receives the sourcecode itself through the APLv3 inherits that right.” - Armin Ronacher, Licensing in a Post Copyright World
The issue with this “loophole” is that it allows a company to promote itself as free and open source while cutting off SaaS competition. While the downloadable version is open, the SaaS version is closed off from open source collaboration, innovation, and competition.
AGPL is still risky
Companies fear the AGPL because of the risk of a developer combining code in a way that would require them to open source parts of their code base that were not intended to be open source. It restricts a user’s ability to adapt the code to their needs to the point where it gives exclusive commercial rights to the original copyright holder. While the license may be growing in popularity for application software, companies are still leery of the license due to its vague language and lack of compliance standards.
The complications with AGPL go beyond companies not incorporating AGPL-licensed code into their own codebases. Many corporations will forbid end-users from installing any AGPL-licensed code on corporate devices out of an abundance of caution. This means that not only are libraries affected, but software end-user adoption has a significant hurdle.
Not all businesses are going to default to all open source. While acceptance of open source has hugely grown, trying to force the AGPL risks causing a backtracking from open source, making software less open, not more open.