Reading Black Duck Software’s newest paean to the Affero General Public License (AGPL) (“The Quietly Accelerating Adoption of the AGPL“), one could be forgiven for thinking AGPL is rocking the open source licensing planet. After all, Black Duck executive Phil Odence laced his post with fancy charts showing explosive growth of the license, ultimately declaring the AGPL “very popular,” and a license his firm sees frequently in audits.
Maybe, maybe not. For all AGPL’s supposed popularity, Black Duck can only come up with 8,000 or so projects (among over 60 million open source repositories) that carry the license, with the only reasonably well-known project being MongoDB. That’s hardly how I’d characterize “popular.”
Meanwhile, permissive licenses like Apache and BSD control virtually any promising project that developers will actually use, from Kubernetes to TensorFlow to Kafka. It’s permissive licensing all the way down. Why? Because it’s developers that increasingly run the world, and they don’t want to get locked out of preferred projects by a license.
The Amazon GPL
It’s not surprising that companies would choose the AGPL to control their code. The AGPL is the closest thing possible to a proprietary software license. But…but…but…open source! No, it’s free software, as in users are free to use it, and corporations are free to charge money for it (through dual-licensing arrangements), but the AGPL is absolutely not free in any meaningful sense for developers.
This, by the way, is almost certainly the reason that Black Duck is blogging about it. After all, the AGPL must be the open source gift that keeps on giving to a company that makes money by first convincing customers that open source is risky and then selling them the way to de-risk their software. AGPL takes that risk factor to the nth degree (“If GPL3 is scary to private businesses, then AGPL is even scarier,” as one recent Black Duck blog post highlights).
AGPL is a way to make one’s software radically open, like dropping a nuclear bomb on someone’s lap and urging them to keep it.
It’s also a way to keep the big clouds of the world from turning one’s project into their product. Small wonder, then, that some companies that license their code under the AGPL internally describe it as the “Amazon GPL.” AWS, for example, has made orders of magnitude more money from MySQL than MySQL AB (and now Oracle) ever hoped to make (through RDS). By licensing with the AGPL, these companies ensure that no one besides themselves can monetize the project.
Safe, legal, and rare
The collateral damage in this bargain, however, is developers. Developers want to get stuff done with a minimum of overhead (be it infrastructure or lawyers). In fact, this shift toward permissive licensing has become so pronounced that on GitHub it’s still far too common for projects not to have a license at all. The GitHub generation is having to be coaxed into slapping on a license at all. (Redmonk analyst James Governor dubbed this “post open source software.”)
SEE: How to get an open-source job (ZDNet)
This is why, by Black Duck’s own analysis of over two million open source projects, permissive licenses power over 50% of all open source projects (and even more if we recognize that GPL 2.0 licensing effectively acts like a permissive license in cloud computing contexts):
AGPL? It accounts for fewer than 1% of these two million open source projects. And if we add in the other 58 million open source projects….Well, the AGPL’s share of those 60 million projects is virtually zero (as in “none”).
As such, don’t believe Black Duck’s AGPL hype. Yes, the license FUD serves the company’s sales and marketing operations well, but it doesn’t serve developers, or the companies for which they build applications, well at all. Most successful open source projects have a single company or a small group of companies behind them, as a Linux Foundation study uncovered. Fortunately, most of these same companies recognize that developer freedom is the first freedom they need to prioritize. It’s why they eschew the AGPL, and you probably should, too.
Subscribe to the Developer Insider Newsletter
From the hottest programming languages to commentary on the Linux OS, get the developer and open source news and tips you need to know. Delivered Tuesdays and Thursdays