Recently, Open Core Ventures posted a blog entry called “AGPL license is a non-starter for most companies.” It commented:
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.
The blog made some interesting points, but I disagree with the conclusion, so I wanted to add some of my own perspective.
AGPL has come a long way. About a decade ago, I wrote an article called “AGPL–Out of the Shadows.”* That article identified some of the same issues with AGPL adoption mentioned in the OCV blog, but mentioned a budding trend toward increased understanding and acceptance. After all these years, it’s time for an update on how AGPL is used in the 2020s. Actually, AGPL has emerged the license of choice for commercial open source software (COSS) companies in application space.
When is a Ban not a Ban?
The fear of AGPL is still out there. Google still bans AGPL. Most companies don’t publish their open source usage policies, but Google does, so its policy is one of the few public data points about corporate open source policy, and lots of other companies pay attention to that. Lots of companies still place AGPL on their “stop” list, (see the example policy here) because they worry they don’t have the internal controls to comply with it. That’s a conservative approach, and there’s nothing wrong with being careful.
But the “stop” category in a license policy is not the same as a ban. Having worked with hundreds on 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.
This has always been how copyleft licenses work. Copyleft is complicated. There is a non-zero price to understanding anything complicated. For GPL, the killer app was Linux. It took nearly 20 years for companies to calm down about GPL and adopt Linux. For AGPL, the killer app was originally MongoDB. (In the 2010’s, in my legal practice, almost every approval of AGPL software in a corporate “stop” list were for MongoDB.) Products drive adoption, not licenses. Users don’t adopt licenses, they adopt software. The license simply represents a tax–in the economic sense–on its use. In other words, the conditions of the license are the cost of using the software. And for years, AGPL didn’t have enough killer apps to make many corporate users develop compliance processes for its conditions.
So, the friction OCV described exists, but it’s not entirely about the license. It’s about the balance between the complexity of AGPL with the attractiveness of software products using it.
Applications Thrive as Open Source
What’s changed since 2016 is an explosion in COSS development. At OSS Capital, we have embraced that phenomenon. But we believe the licenses serve the products, not vice-versa. To us, open source development is a huge business advantage, and that advantage can be gained with any open source license.**
Since we started our fund, many excellent COSS businesses have chosen AGPL as part of their licensing and business strategy. At this moment, it’s probably fair to say that Grafana is the “killer app” of AGPL in the business world. But there are many, many startups choosing AGPL. And in this difficult economy, their success is truly amazing. That’s no accident, because open source adoption wins a lot of business during recessionary and inflationary periods. Below is a list of only some of the companies using AGPL very successfully from OSS Capital’s own network. If AGPL does not work, that’s news to all these companies.
So, why does AGPL work for all these companies, if it is so scary? First, AGPL is not really all that scary. As I alluded to back in 2016, the main problem with AGPL was that it was relatively new, and different from other open source licenses, and required compliance processes that most companies had never implemented. Over time, adopters have become less fearful about AGPL. Compliance processes have improved. Recent focus on software BOMs and security have hauled most companies into open source compliance, because the same tools usually track both needs. So these days, it’s easier to track AGPL code in an organization.
But more importantly, the rise in adoption of AGPL in COSS has tracked the rise of COSS in applications. That’s a relatively recent development. Open source originally thrived in the basic computing stack. Permissive licenses like Apache or MIT work great for infrastructure software. Copyleft, in general, is more problematic for IT managers adopting infrastructure software, because they need flexibility to make significant changes to integrate infrastructure code, and don’t want to wade into analyzing copyleft licensing requirements. Consider Confluent, Redis, Elastic (back in their Apache days)–the list goes on. All of those infrastructure tools grew up under permissively licensed cores.
But application space is different. From the use point of view, the copyleft compliance requirements in application space are less troubling than in infrastructure. Applications are usually stand-alone processes, not libraries or tools. That means the scope of copyleft requirements (one “Program”) is not so difficult to figure out. Also, most users of applications today are accustomed to using SaaS instead of installed software. That means if you choose copyleft, you need a network copyleft license, so AGPL is the only real choice.
CLAs and Loopholes
OCV, and many others, have pointed out a “loophole” that allows vendors of AGPL applications to grant alternative commercial licenses. But that “loophole” merely describes the limits of what an open source model can do. Copyleft licenses don’t limit or condition the use of software by its authors.
In privately funded business, AGPL is almost always used as part of a dual licensing strategy. That means the software is available under AGPL, but if you don’t want to comply, you can buy an alternative license from the vendor. In that case, vendors almost always use a contribution license (CLA) for contributions from the community. Otherwise, the vendor sometimes can’t sell alternative licenses, because the contributions are encumbered with AGPL conditions. For an explanation about how this works, see my video here.
There is a lot of FUD about CLAs, but at the end of the day, if a contributor doesn’t want to allow her contributions to an open source code base to be used in a vendor’s commercial products, the license allows her to fork the code as a pure AGPL project. But of course, that means someone has to fund the maintenance of that fork. Given private companies sink millions of dollars, not to mention years of their founders’ lives, into maintaining open core products, contributors often feel that signing a CLA is a reasonable quid pro quo for that commitment of capital and sweat equity. Those who object to CLAs, at the end of the day, mostly object to privately funded open source development as a general proposition. And that’s a personal choice for contributors.
For a COSS developer, the choice is between a permissive license, like Apache/BSD/MIT, and AGPL. Most in-between choices eventually migrate to one pole or the other. Infrastructure is mostly under permissive licenses, and applications are mostly under AGPL.
Don’t Believe Me, Just Watch
In any case, try out some of the great products that are thriving under the AGPL/dual-licensing model! The proof of the pudding license is in the eating using.
*That link shows the article as authored by the “Synopsys Editorial Team” but if so, they used a time machine and a LLM to write an article in exactly my style. But seriously, I wrote it, and as far as I know, I’m not on their staff. It’s pretty rare that anyone tries to take credit for my writing– most authors would not want to take the heat for the things I say!
**Well, not exactly. Non-standard or superseded licenses like Common Public License don’t work so well. But that’s about standardization, not substantive license terms. COSS businesses usually need to choose one of the “big 6”: AGPL, GPL, LGPL, BSD, MIT, Apache.
