Open Source Licensing: Obsolete or Of Importance?

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

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.


  1. […] Open Source Licensing: Obsolete or Of Importance? – A good run-down of some of the current issues from RedMonk’s Stephen O’Grady. […]

  2. I’d argue that for successful projects, the ability to adapt their licensing (be it just a shift from an old version of the license they are using, to a new one) is even more important than picking the ‘right’ license at the start. User and developer bases tend to change as projects grow.

  3. Steve,

    I certainly agree that licensing is still important and projects need to understand the implications of their choice.

    However, as was initially claimed, I don’t see the GPL license as being the only path to commercial success. An open source project can be commercially successful with other licenses.

    I am still not convinced on the Oracle Linux example. Even if Oracle could make extensions, RedHat has the brand (trademark) that is driving their success. In fact today, Oracle could provide ‘value add’ services to differentiate themselves from RedHat, for instances packaging of Oracle software or support, but I still believe RedHat would continue to win.


  4. “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.”

    Technically speaking, that’s not correct, at least not in the U.S. Though, practically speaking it probably is:

    § 203. Termination of transfers and licenses granted by the author

    (a) Conditions for Termination. — In the case of any work other than a work made for hire, the exclusive or nonexclusive grant of a transfer or license of copyright or of any right under a copyright, executed by the author on or after January 1, 1978, otherwise than by will, is subject to termination under the following conditions:

    (3) Termination of the grant may be effected at any time during a period of five years beginning at the end of thirty-five years from the date of execution of the grant; or, if the grant covers the right of publication of the work, the period begins at the end of thirty-five years from the date of publication of the work under the grant or at the end of forty years from the date of execution of the grant, whichever term ends earlier.


  5. licenses may “not matter” for hackers but they sure as shit matter for business people. My biggest problem with the assertion about Google and “Web 2.0 is great, who needs a license” is that Google also doesn’t really offer contracts per se. There are others in the world of mapping that have to sit back and watch Google take “liberties” with licensing terms they would normally enforce. Same in book publishing and so on. Maybe the license doesn’t matter, or maybe they do. O’Reilly has talked about data as the Intel inside. In the open world we tend to like CreativeCommons licensing, but that’s not an absence of copyright, its a simplification. And I seem to remember a bit of a tizzy when someone else called a conference Web 2.0…

    we need steady foundations to build businesses upon. they are the basis of effective markets.

    Finally I would like to add that Ian makes a great great point. Increasingly it may be that trademark is RedMonk’s one and only truly enforceable business protection.

  6. […] as the terms of Microsoft’s patent and open specification promises. As I’ve discussed previously, given the often permanence of legal promises, contracts and licenses, it’s not unreasonable […]

  7. […] Open Source Licensing: Obsolete or Of Importance?, Redmonk’s Stephen O’Grady. […]

  8. […] Open Source Licensing: Obsolete or Of Importance?, RedMonk – tecosystems, Stephen O’Grady (Blog) […]

  9. […] for one, has argued that this limitation arguably makes open source licenses obsolete (I didn’t agree). Fabrizio Capobianco has called the loophole “the cancer of open source.” Matt Asay, […]

  10. […] 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 […]

  11. […] restricting the unfettered usage of any given codebase. Copyright also has its role to play, as do trademarks. And while most of the media attention is paid to the licenses, and the differences between them […]

Leave a Reply

Your email address will not be published. Required fields are marked *