Once besieged by basic questions ranging from “is it open source?” to “will it make money?,” the open source world is increasingly facing more mature, nuanced questions and assertions.
One such that has been picking up steam of late is that open source licensing is less important than commonly assumed. Reacting to a piece from the 451 Group, Eclipse’s Ian Skerrett makes the case that trademarks are the real strategic weapon. Tim O’Reilly, for his part, has famously declared that “open source licenses are obsolete,” largely due to their irrelevance (the Affero and such licenses presumably excepted) to those – like Amazon, Google, et al – that do not distribute software in the traditional sense.
While I understand both arguments, I don’t entirely subscribe to either. From my perspective, the choice of license has far reaching implications on adoption, business models, community size, and more. It’s simplistic to imply, I’d agree, that the choice of a particular license precludes commercial success – or conversely, ensures it. But the license is one of the most fundamental choices any project can make because it dictates – potentially in perpetuity – what users will be able to do and not do with a particular asset.
The Permanence of a License Choice
Even should a project owner decide, for whatever the reason, to shift licenses, there are certain rights and privileges – whether an asset is licensed permissively or restrively – that cannot be revoked or taken back. If you permissively license an asset to me, and I incorporate it into my proprietary software product (as Microsoft did with the networking stack in pre-Vista versions of Windows), you cannot retroactively impose restrictions on the code that I’ve incorporated into my offering. I retain the original rights, even if you decide to license future developments differently.
Likewise, if code is reciprocally licensed under, say the GPL, the rights granted by it to the users cannot be removed legally; with the notable exception of dual license scenarios which may act to remove the restrictions for the licensing entity. For all other consumers and developers of the asset, the rights and privileges granted by the original application of the license must remain.
Licensing decisions, beyond the immediate strategic impact, have relatively permanenc implications. Which, I would argue, makes them important.
The Implications of a License Choice
It’s not debatable that different open source licenses carry different rights and restrictions. And while it’s not unusual for members of various open source communities to prefer one license or license style over another, the market has shown little appetite for a single approach. The LAMP stack, as an example, includes two permissively licensed assets (Apache and PHP) and two reciprocally licensed assets (Linux and MySQL).
Personally, I’m a believer that a license is, ultimately, just a tool. Much as I might choose one tool for one job and choose another for a different task, differing licenses can and should be employed towards different ends. Here’s how we’ve discussed some of the available options previously in an excerpt from an interal report produced for a RedMonk client:
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.
The permissive class of licenses, including the Apache, BSD, and MIT, are chosen for an entirely different set of reasons than those that would compel the selection of a reciprocally style alternative. This will come as news to few.
What may be less obvious, however, is that these choices are no less important than they were years ago.
Trademarks vs Open Source Licensing
As discussed above, 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.
Web 2.0 vs Open Source Licensing
In his piece claiming open source licenses are obsolete, O’Reilly mentions Google and its stable of ubiquitous SaaS – or Web 2.0, if you prefer – applications as proof positive that licensing is obsolete. And certainly, he’s partially correct. The stack that Google runs off includes both permissive and reciprocally licensed assets, which is consumed with little distinction between them because – as previously mentioned – Google is not distributing software and thus has to worry about running afoul of neither style’s restrictions.
But nevertheless, I think O’Reilly’s contention that open source licensing is obsolete because of a Google is incorrect for two reasons.
- First, and most importantly, all software is not Web 2.0. It would be difficult to make the argument, in fact, even that most software is Web 2.0. In his piece, O’Reilly qualifies his remarks somewhat, saying:
Because [open source software’s license] conditions are all triggered by the act of software distribution, they fail to apply to many of the most important types of software today, namely Web 2.0 applications and other forms of software as a service.
Most of which I agree with. But the fact is that the world’s top two or three largest software vendors are not fueled generally speaking by Web 2.0 applications or software as a service. Nor are the hundreds of millions of desktops or billions of mobile devices powered – at an OS level – by SaaS. Until those things change, open source licensing – to me – will be far from obsolete.
I’m as big a believer in Web 2.0 and SaaS as you’re likely to find in the analyst ranks, but last I checked both needed operating systems and browsers to function. And last I checked both OSs and browsers are subject to traditional distribution, and therefore licensing restrictions.
- O’Reilly’s point is well made in that SaaS vendors are indeed able to construct large businesses off of software released under open source software licenses, but that should not be taken to mean that there every open source license is vulnerable to such usage. If preventing usage from SaaS providers is the goal – and to be clear, O’Reilly does not argue that it should be – I think it highly unlikely that Google will ever strategically rely on code licensed thusly. Which is one reason I was entirely unsurprised that the quote unquote ASP loophole was not closed in the revision of the standard GPL. Open source licensing is not so obsolete, apparently, so as to prevent a license response to precisely the concerns that O’Reilly mentioned.
The License is the Foundation
None of the above should be read as an indication that open source licensing is or should be the only concern for those developing it nor those consuming it. Nor even that it’s the most important consideration in every case. And certainly not that the success or failure of a particular project is Calvinistically preordained by its choice of a particular license.
But I am of the belief that the choice of a particular license is important, carries long term responsibilities, and is the foundation upon which business and defenses of those businesses are built.
Recent Comments