Building the Cloud: Notes on Apache CloudStack (incubating)
Notes on work that's going on in the Apache CloudStack (incubating) project. Event announcements, progress reports, and more.
Do We Need an Affero Cloud? Nah.
Donnie Berkholz of RedMonk has argued that the “infrastructure stack” needs an Affero LGPL to prevent the dreaded fragmentation. Do we? I’m not convinced that it’s necessary, desirable, or likely to catch on at all.
Donnie’s argument is that an Affero LGPL (as opposed to AGPL) would be workable because it would allow businesses add proprietary bits that link to the stack, but be forced to open up their changes to the actual infrastructure stack itself.
…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.
While I like the intent to Donnie’s thinking, I don’t think that the problem is as dire as to introduce the need for a new license. Nor do I think businesses are likely to embrace a even more reciprocal license when they’ve been reluctant to embrace copyleft on infrastructure in the first place.
Many companies that contribute to open source IaaS projects don’t like copyleft. As an individual, I like copyleft licenses just fine. The reality is, though, that companies like SunGard aren’t comfortable with GPL – especially GPLv3.
One of the reasons for this is the headache that comes with license compliance. An Affero LGPL would be a major headache for license compliance, as it adds the complexity of worrying about which code is under copyleft and which code is proprietary and ensuring that users can always download the right code. Companies, or more accurately their lawyers, would flee from the ALGPL like it was a burning building.
As Stephen O’Grady writes, it’s also a bit of a solution in search of a problem:
To begin with, fragmentation is at best a theoretical risk for most projects. Consider popular permissively licensed projects like Hadoop, Subversion or the Apache web server. None enjoy protections from fragmentation, all can be privately modified, distributed and packaged and yet none have, at present, major issues with forks. And even if fragmentation was more common, distributed version control systems such as Git have turned forking from negative to positive.
Nor is there any evidence that open source contributions in general are a problem. If anything, the industry trend seems to be towards opening more software rather than less, because it more and more rarely confers a competitive advantage. On an anecdotal basis as well as a quantitative, software is provably less worth protecting than it was a decade ago.
While I can point to instances of companies using CloudStack without contributing changes back, I’m not convinced it’s a significant problem that merits adopting an AGPL or ALGPL. Especially because I’m fairly certain that most companies would not adopt an ALGPL’ed IaaS cloud.
The key reason that companies should contribute back to projects like Apache CloudStack are because it’s in their best interest to do so, not because they’re forced to do so by the licenses. There’s really no way to force a reciprocal license like this into use, but you can (sometimes slowly) convince companies to upstream their changes and work with the community because it’s better for them in the long run.
Luckily, Donnie seems to get this and the ALGPL idea was in response to the suggestion that the GPL wasn’t needed anymore. The GPL is great for projects that have an explicit goal of forcing copyleft, but you also have to realize that when you’re working in a space with a lot of enterprise interests, you probably won’t have a lot of success with trying to force companies to adopt GPL – especially with permissive-licensed alternatives.