451 CAOS Theory 
A blog for the enterprise open source community
A capitalist guide to open source licensing
Matthew Aslett, January 14, 2010 @ 11:06 am ETWe’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.
See also, The 451 Group’s assessments of:
Day Software
JetBrains
VMware’s acquisition of SpringSource
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
Social comments and analytics for this post…
This post was mentioned on Twitter by caostheory: New post: A capitalist’s guide to open source licensing. http://bit.ly/6GlilS…
Matt,
I think the governance model is just as important as a license decision. If a company wants to have indirect revenue from a widely deployed platform, they stand a much better chance of success doing this in an existing community like Apache, Eclipse, etc. A vendor-neutral governance model provided by these Foundations make it more inviting for others to adopt the platform.
Keep up the great posts.
Ian Skerrett
Eclipse Foundation
This is true. Licensing is of course just part of the bigger picture, which we will be considering again in an update to our Open Source is Not a Business Model report, later in the year.
[...] is the original: 451 CAOS Theory » A capitalist's guide to open source licensing This entry was posted on Thursday, January 14th, 2010 at 10:06 am and is filed under Linux, [...]
Great post. There are also factors beyond just the license. Though TurboCASH is GPL I am seeing bitter comments about requiring registration.
[...] 451 CAOS Theory » A capitalist’s guide to open source licensing blogs.the451group.com/opensource/2010/01/14/ – view page – cached An open source blog by The 451 Group. See all Top 5K for the451group.com [...]
Comparing licenses without comparing copyright assignment policies doesn’t work. A strong reciprocal license without a strong assignment policy actually prevents some direct monetization strategies.
Agreed. See my response to Ian.
[...] 451 CAOS Theory » A capitalist's guide to open source licensing Tags: entry, filed-under, krauthgamer, linux, posted-on-thursday, resolved-the-conflict, rikki, should-look Water Waves: The Mathematical Theory With Applications – download hereNew research resolves conflict in theory of how galaxies form …Rev Theory : Artist Page : dgcrecords.comForex Education – Making Huge Profits With Dow Theory Part 1 …Conspiracy Theory (Theatrical Trailer) | Free Celebrity VideoTheory of Intelligence | MICHAEL YIP | 叶志坚Financial Accounting Theory | TextBook Classified AdsThe 2012 Conspiracy Theory with Jesse Ventura | The Economy CollapseMolecular Theory of Evolution: Outline of a Physico-Chemical …(Notes on) Politics, Theory & Photography: Passings ~ Philippa … View the Contact Powered by Video [...]
[...] A capitalist’s guide to open source licensing 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. [...]
Some thoughts on the relevancy of Licensing with respect to community
http://blogs.rivetlogic.com/rdanner/2010/01/16/open-source-licensing-and-community/
Thanks Russ
OpenGamma faced this precise question early-on in its life as we released the Fudge Messaging project out into the wilds. We also have some very good lawyers who are fully aware of Open Source licensing, who actually seemed quite shocked and impressed that we chose the APLv2.
My opinion? Aside from the copyright-assignment issues above, you’re going to start seeing more people going with APL-style licenses going forward; the potential commercial advantages you get out of avoiding the FSF licenses is completely dwarfed by the perceptual problems you have with going with a *GPL* license.
Thanks for the insight Kirk
[...] http://blogs.the451group.com/opensource/2010/01/14/a-capitalists-guide-to-open-source-licensing/ [...]
[...] 451 CAOS Theory » A capitalist’s guide to open source licensing blogs.the451group.com/opensource/2010/01/14/a-capitalists-guide-to-open-source-licensing/ – view page – cached An open source blog by The 451 Group. [...]
[...] of the two and the best way to achieve commercial success with open source software. As Matt highlights, we are seeing a choice of non-GPL licensing in order to more effectively foster community and [...]
[...] have also pointed to increased use of more permissive licenses, either in order to encourage widespread adoption and rapid community formation, or to enable easier integration with proprietary [...]
[...] project and generate revenue from its complementary products and services (see also “A capitalist guide to open source licensing”). However, it seems likely that Activiti could also be a prelude to a more liberally-licensed [...]