Given that I’ve used the “Does x matter?” conceit myself, I understand completely that John Edwards’ “Does the GPL matter?” headline is merely a rhetorical device. Nor does it escape me that its sensationalism is designed, either by Edwards or his editor, to attract the very attention it’s receiving.
Still, it’s a surprisingly one sided piece. And, no, it’s not just me. Stallman’s terms for the interview proved unacceptable? Fine, that’s not the first time and it certainly won’t be the last. But there are plenty of other GPL advocates that would be only too happy to defend the license. I’m pretty sure Matt Mullenweg would, for one.
But given the dearth of context in the piece, I feel obligated to take the bait and respond, though I am no GPL zealot. Let’s tease apart the arguments a bit in a Q&A.
Q: Before we continue, do you have anything to disclose?
A: Not particularly. We work with clients that develop and release software under a variety of open and closed source licensing mechanisms. On the open source side, we’ve recommended at various times everything from MIT style permissive licenses to the GPL.
Q: Now, does the GPL matter?
A: Of course. It’s indisputable. According to the article’s own table, derived from Black Duck data, the GPLv2 is more popular than all of the other licenses on the list…combined. Throw in its governance of major, high profile projects like Linux, MySQL and WordPress, and the answer is obvious: the GPL matters. Seriously matters.
Q: What’s your view on the purpose of licensing?
A: I’m a pragmatist at heart, and thus I view open source licensing as nothing more or less than a different tools for different jobs proposition. If we think of licensing as a spectrum, we have two ends: permissive licenses such as the Apache, BSD, or MIT, and reciprocal licenses such as the GPL. The former permit developers to do more or less what they like with code, while the latter require developers distributing code to distribute their changes under precisely the same terms. The crux of the difference comes down to differing definitions of freedom: permissive license advocates tend to believe that freedom should be granted to developers to do with an asset what they wish, even if that means taking it proprietary. Reciprocal license advocates, on the other hand, typically espouse the belief that user – not developer – freedom is to be championed; that if you are given software to use, you should have the right to take it apart and remake it as you see fit, provided you share your changes if you plan to distribute the updated version.
While these beliefs might not seem fundamentally incompatible, in practice, they often are because user and developer interests do not always align particularly well. Even relative compromises like file-based licenses such as the EPL or MPL (and its derivatives like the CDDL) can be viewed as either unnecessarily restrictive or insufficiently protective, depending on your particular philosophy.
Q: Which side do you come down on?
A: Neither. I look at it instead pragmatically. My primary concern is the project itself, and my belief is that the license will only ultimately matter in cases where the project is at least moderately successful. Given that, I generally default to favoring the license which gives a project the best chance of succeeding. Licenses, you see, have very different strengths and weaknesses, and the right license for one project is absolutely not guaranteed – in my opinion – to be the right license for another. In that, Eclipse’s Mike Milinkovich and I are in perfect agreement: the world most certainly needs more than one license choice. In certain cases, then, I would and have advocated for reciprocal licenses, while in others we’ve recommended permissive choices.
Here’s how we’ve described this in the past to clients, for example:
Platform Licensing:
Of particular interest in this case are the strategies employed by platforms. While the GPL remains the overwhelming license of choice for applications in general, and is the choice of perhaps the most popular open source platform in Linux, platform technologies trend towards permissive style licenses as opposed to reciprocal approaches. The BSD distributions are perhaps the most obvious example, but the licensing for PHP – perhaps the most ubiquitous dynamic language at the current time – is another.At one time, PHP was dual licensed under the GPL and the PHP license, but dropped the GPL as of PHP version 4 because of the reciprocal restrictions. Python’s license is similarly permissive, as it employs its own custom BSD style style license. Mozilla’s Firefox, additionally, was as previously mentioned trilicensed specifically to address the limitations imposed by its original reciprocal-style license.
Generally speaking, the preference for permissive licenses by platform technologies is that they impose the least restrictions on users and developers, thus offering significant advantages should ubiquity and adoption be an important goal. These advantages, however, come with a price: permissively licensed technologies can be easily and legally forked, or incorporated into proprietary code, or repurposed. The lack of restrictions is both its biggest strength and biggest weakness.
For a commercial entity, then, permissive licensing is best applied to platforms when the vendors wants to grow the market around the platform, monetizing other parts of the market rather than the core platform. For example, the platform may be “free” but tools to interact with and create content in the resulting ecosystem may cost.
Q: What about the argument that businesses prefer Apache and other licenses to the GPL?
A: Of course they do, why wouldn’t they? Permissive licenses permit businesses to do pretty much whatever they want with code; the Windows networking stack, for example, in the NT days was famously derived from BSD code. So yes, businesses overwhelmingly prefer permissive licenses to reciprocal licenses, because they impose far fewer restrictions on the business models. But in spite of – or perhaps because of – what the piece calls the GPL’s “excessively restrictive aspects,” the largest single commercial ecosystems are built on top of GPL’d assets. While there are tremendously popular and commercially permissive assets from the likes of the Apache Software Foundation, and file based projects like Eclipse have fostered massive ecosystems of for pay software, the Linux project is still setting the pace. It’s been so successful commercially, remember, that even Microsoft decided to contribute to the project.
So yes, businesses prefer what makes their life easier, which is the least restrictive licenses. The question that wasn’t asked in the piece, however, was whether that actually made for successful projects.
Q: Well, do permissively licensed assets make for more successful projects?
A: In some cases, certainly. If you’re creating a language and runtime, for example, and your primary goal is maximizing distribution, my recommendation would be to select as permissive a license as possible. If, on the other hand, you’re creating a more significant platform technology and the risk of forks is significant, the GPL offers some protections that a permissive license will not. I cannot, for example, see the Linux community being as successful to date absent the license that governs it. Consider Oracle’s entry into the market and the licensing implications; here’s what I’ve said about that in the past:
Eclipse’s Ian Skerrett has argued that trademarks are more important strategically than the license choice. Those that argue this case might cite the example of Oracle’s Linux foray, which clones Red Hat’s Enterprise Linux offering as is their legal right by virtue of the GPL. The protection afforded Red Hat then, it’s asserted, is primarily due to its trademark rather than its license.
Personally, I disagree. If the Linux codebase were available under the BSD, Oracle would still not have the right to the trademark, but they would have the right to take the entire stack – or perhaps merely portions of it – and make it proprietary. What would the business benefit to such an approach be? Perhaps nothing, but it seems at least possible that Oracle would be able to introduce proprietary extensions – similar to the approach that EnterpriseDB currently takes with the PostgreSQL codebase – and sell them at a premium. More to the point, Oracle would be potentially be in a higher ground position, in which they would have the right to borrow from Red Hat while Red Hat would have no such rights in return.
Before the Apache people begin arguing that the above is unlikely, let me acknowledge that that may well be true. But it is possible, given the differences between the rights afforded by the licenses.
While some might point to Oracle Linux, then, as an illustration of the value of the trademark over the open source license, I’d argue precisely the opposite: the trademark’s value hinges on the protections afforded by the choice of license.
So the answer to the question of which license makes more successful project is one that probably could have been predicted: it depends.
Q: So is the GPL the perfectly protective license, then?
A: Hardly, and that’s one of the things that was interesting about the piece questioning the license’s relevance. These days, when people are questioning whether the GPL, they’re arguing it’s insufficiently restrictive, not the other way around. Critics of the GPL typically focus on its relevance in a world in which its primary protections – which kick in when software is distributed – are made academic by software as a service and cloud computing environments. To be fair, those who would criticize the GPL for its ASP loophole would generally acknowledge that, with the exception of the AGPL, competing licenses such as the Apache, BSD, EPL, MIT, or MPL offer no more protection than the GPL in such cases, but it’s the GPL that tends to absorb the brunt of such criticism.
In the face of that line of criticism, however, has been the reality that the even more restrictive AGPL – which closes the so-called ASP loophole – has seen very little adoption, high profile exceptions like Launchpad notwithstanding. Which may mean that the GPL has the protections it needs, and none of those it does not.
Q: What about the decline in popularity of the license? To quote the piece, “The survey found that despite strong growth in GPLv3 adoption [1], the percentage of open source projects using GPL variants dropped from 70 to 65 percent from the previous year.”
A: Well, we’re talking about a decline from the most popular license choice to…the most popular license choice, so I certainly don’t think it will be used as evidence to prove that the GPL doesn’t matter. But to the macro point: is it significant and worth watching? Absolutely. But the license is still – by far – the most popular. Second, the decline was – in all likelihood – inevitable. That level of popularity was unlikely to be sustainable as more developers became aware of the license choices and implications available to them.
Q: What about Simon Phipps’ point: “It’s worth noting the difference of the GPL when copyright is centralised vs community-shared”? What is meant by that?
A: Simon is, I assume, referring to the various governance structures that projects create relative to copyright, and by extension, the economic models that serve them. For example, MySQL owns all of the copyright to the code it produces, which allows it to re-license the code – creating a dual-license, in effect – if it is economically incented to do so. This is called the dual license model. For all of its economic advantages, however, the approach has its downside: because it needs to own the copyright to retain the right to issue a second license, the distribution produced by MySQL cannot legally include patches whose copyright has not been assigned to them. Which means that, today, some of the MySQL forks are better versions of the database – because they can include all GPL patches and fixes, irrespective of their copyright assignment – than can be had from MySQL itself. This is MySQL dilemma with the centralization of its copyright: it’s an economically rewarding system, but it’s unclear whether it will be sustainable over the longer term.
Contrast that with the Linux project, where there is no centralization of copyright, and the difference is obvious. With Linux, there is no central entity to whom copyright is assigned, and therefore no one entity that has the authority to rescind the licensing requirements. Thus the changes or fixes that Oracle writes to their version of Red Hat’s distribution must be made available to Red Hat under exactly the same terms.
While some focus on perceptions of the equitability of the two approaches, the more important point, from my perspective, is what’s more viable over the long term. While MySQL certainly proves that the dual license model can be viable for an extended period of time, the rise in popularity of forks like OurDelta and Percona argue that it might not be sustainable indefinitely. Supporting that assertion is the fact that the MySQL developers that created Drizzle decided to eschew the centralized copyright approach with that project, favoring a community held copyright model from day one.
All of that said, the dual license model is approach that has been successfully monetized.
Q: What about Jim Jagielski’s assertion that “the GPL, as written, is just a little bit hard to understand”?
A: It is undeniably true that in certain cases, it’s been sufficiently unclear as to what’s been considered derivative that legal opinions have been required to clarify. It is also true, because it’s permissive, the Apache license will not trigger the same questions. But that’s due as much to the fact that one license is reciprocal and one license is permissive as it is to the wording of the GPL itself. And because that condition is generally a problem for those building on top of a project, rather than writing the project itself, it’s not always a primary consideration when selecting licenses for the author of a given asset.
Q: Anything else to add?
A: Nope, that’s been more than long enough. If anyone has questions I didn’t get to, drop them in the comments and I’ll see what I can do about getting you an answer.
