Opening the infrastructure stack: Why we need an Affero LGPL

When you’ve got open-source software available under a permissive license with multiple companies trying to make money off it, an eternal concern is fragmentation. Fragmentation of standards, of APIs, of implementations, that either contribute to long-term unmaintainable codebases or to customer confusion and desertion, much like what happened with UNIX. It’s not unique to computing; even in supermarkets, when people are given too many options, they’re more likely to walk away than to purchase anything at all.

In the vast majority of cases, however, companies around a piece of open-source software — particularly infrastructure-level software — aren’t interested in making money directly from the software. Instead, they aim to profit from a host of opportunities surrounding the code itself: support, professional services, proprietary differentiation on higher layers, and so on. A rare exception is the dual-license model a la MySQL or ownCloud, where you can purchase a proprietary license to the same (strongly copylefted and corporate-owned) codebase so you can build closed products by modifying it or building upon it.

In my opinion, the Affero GPL (AGPL) has always been an underappreciated license. Its goal was to require that even when software was provided as a service, the underlying GPL code would still remain open. Unfortunately, it never really took off to the same extent, in part because SaaS tends to build upon permissively licensed software, if it uses open source at all. Nobody wants to give up their opportunity to differentiate, but the GPL will follow you all the way up the stack and force it all to be open.

With those dual and seemingly opposing forces in mind, what I propose would solve many of these problems is an Affero LGPL (ALGPL). Code using the LGPL, unlike the GPL it’s based upon, must stay open itself while allowing other code that links to it to stay closed. This provides for the potential of a forcibly open infrastructure stack that still enables companies to differentiate at higher layers. It means companies would be free to build products on top of it as long as they returned any modifications only to the ALGPL codebase itself.

Here’s a concrete example: If you build an OpenStack cloud, then add additional proprietary standalone components to that cloud, you’re good — even if they link to ALGPL components. Feel free to make money all day long. If you modify existing components, you need to return those changes (if you’re providing any externally facing services).  As mentioned, this will have the benefit of reducing fragmentation without preventing differentiation in interesting ways.

I received strenuous responses to an earlier piece suggesting that people generally get why they should contribute back to open source, so here’s an alternative. For people and businesses new to open source, provide fences so they can’t work contrary to their own long-term interests.

What do you think?

Disclosure: Rackspace is a client. Oracle and ownCloud are not clients.