Open Source Licensing: Obsolete or Of Importance?
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.
