A blog for the enterprise open source community
A capitalist guide to open source licensingMatthew Aslett, January 14, 2010 @ 11:06 am ET
We’ve provided a few examples recently of vendors choosing permissive licenses for open source software projects with the express purpose of rapidly driving adoption of a particular technology (Day Software, JetBrains, SpringSource).
The last of those was interesting as compared to SpringSource’s previous decision to use the GPL for the same project with the intention of maximizing its return on investment. Another example of that strategy in action was provide this week by Sonatype’s Jason van Zyl.
“We thought for a long while before selecting the GNU Public License (GPL) for Nexus and we made it clear right from the start why we chose the GPL. We knew that we would invest heavily in Nexus. Even though the people involved with Sonatype are traditionally users of Apache style licenses, we didn’t know how our business would evolve and we wanted to choose a license that would offer adequate protection for that investment. We were honest and upfront about it. We chose a more restrictive license first this allows us to adapt and use a less restrictive license in the future if we think it is appropriate for the community.”
Our recent post on SpringSource prompted Matt Asay to state “moral of story? platforms flourish on permissive licensing. GPL is a capitalist’s best friend. Apache/EPL are a community’s”.
It is a massive generalization of course, which is the nature of the 140 character limit, but there is some truth in it. To get to that truth you have first to deal with a couple of related issues.
GPL and community
Matt’s statement suggests, and he confirmed in a follow-up, that it is harder to build a community with a restrictive license. The obvious argument against that statement is the number of community projects based around GPL code: the Linux kernel, the GNU project, Samba, Drupal, Gnome, and KDE for example.
Clearly the GPL does not prevent vibrant community development projects. The important point about those projects is that they are the result of true development communities, however, rather than a vendor-initiated effort to create a community.
The truth is, however, that for vendor-initiated open source projects it is hard to build a true collaborative community. This is true of the vendor is generating revenue directly from the project in the form of support/subscriptions, but especially so if the vendor in question elects to exert copyright control in order to generate revenue directly from that open source project via dual or open-core licensing strategies.
Update – As Jason van Zyl explains in his discussion of why Sonatype chose the GPL for Nexus: “Less restrictive licenses enable wider integration and make it easier to drum up community participation.”
van Zyl aslo explains that starting with a more restrictive license enables the company to move to a more permissive license at a later date without upsetting community users. “You can’t start a project using a less restrictive license to grow a community – because this tends to be easier with less restrictive licenses – and then switch. Such a practice is dishonest and you will never see Sonatype make a similar move.” – update.
Community and capitalism
Matt’s statement also suggests that community members aren’t driven by capitalist tendencies. Of course it is true to say that there are both capitalists and non-capitalists involved in EPL/Apache communities, but in the examples listed above (Day, JetBrains, SpringSource) it is worth noting that the decision to use permissive licenses is specifically driven by the desire to expand commercial opportunities for the vendor concerned to exploit indirectly via complementary products.
In Day’s case it took a while to work out how to precisely to monetize that opportunity by building on top of the open source code, while in JetBrain’s case it is a pre-meditated attempt to increase potential adoption of its proprietary products. As for VMware/SpringSource, it is not immediately obvious how the company stands to benefit from the Virgo project, although anything that encourages adoption of OSGi arguably benefits VMware by reducing the reliance on a full-blown operating system.
So the question is not which license is the capitalist’s best friend, but which license best fits the capitalist’s monetization strategy. Assuming you get to choose your license for a direct monetization strategy a reciprocal license is your best bet, while for indirect monetization strategy choose a permissive license.
Update – I should have said, of course, that the choice of open source license is one factor among many. As noted in the comments, community governance and copyright assignment policies also play a big part. I touched on the issue of copyright control recently, and we will be considering the bigger picture in an update to our Open Source is Not a Business Model report, later in the year.
Meanwhile, I will be expanding on this argument, and providing a snapshot of our ongoing research in relation to open source-related business strategies in a presentation at OSBC 2010 in March.
Comments (19) Categories: Business strategies,Licensing,Software