Google Code vs License Proliferation

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

Ok, so the answer to the question of why is license proliferation. I’m a bit dubious, as I think the prohibition of AGPL licenses for one is about more than preventing license proliferation – which I’m fine with, candidly, I’d just like to see the reasoning stated more clearly – but let’s go with it.

A few more questions.

Is license proliferation that serious a problem?

I’ll confess that I’ve been in the minority on this question for some time amongst the open source types I speak with regularly, but I remain unconvinced that the problem is as dire as it’s often made out to be. Left unchecked, it did indeed pose a serious threat, as no one wants to parse a new license for each project to determine their obligations and restrictions.

But licensing has been trending for some time, in my opinion, towards the necessary consolidation. Though I suppose it’s possible that systems like Google Code have had some hand in this, the current direction predates that launch significantly. The market, as ever, seemed to be seeking efficiency.

I don’t see much Computer Associates Trusted Open Source License 1.1 usage these days. Or many MITRE Collaborative Virtual Workspace Licenses. Or RealNetworks Public Source Licenses. Probably because, OSI approved or not, those licenses are effectively dead. As they should be.

I’m in agreement with the Google camp that there are good reasons that both the permissive style Apache licenses and the project based reciprocal licenses such as the GPL are popular. Also, that there are advantages to projects being primarily licensed using one of those two styles. I’m even fine with the idea that those advocates of free software and open source should attempt to restrict themselves to the two best designed licenses that represent those camps in the GPL and the Apache.

But I cannot concur with the implicit assertion that those should be the only permissible license styles. There is room in my philosophy for file based reciprocal licenses such as the CDDL, EPL, and MPL. While they may create “islands of code,” some of those islands are very large indeed. Which tells me that they are serving a pragmatic purpose, and filling a need. I’m in full agreement with Mark that more choice is often a negative; I just don’t think one more choice is the proverbial straw.

If you want to contract the Computer Associates Trusted Open Source License 1.1, you’ll get no objection from me. But I have trouble with the idea that licensing can be boiled down to a mere two camps, rather than the three that have each fostered communities and ecosystems of considerable size.

That said, it’s Google’s system, and I of course respect their right to restrict to the system to whatever licenses they want. Even if I don’t happen to agree with their choices.

Why cut the license now?

The MPL was one of six (seven with the Perl Artistic/GPLv2) permitted licenses at the time of the launch of Google Code. Two years in, it was at 2.7% of the total project licenses, against 42.6% GPL, 25.8% Apache, and ~8% for a few other license.

So clearly, it wasn’t the most popular license on Google Code. But I haven’t seen that cited as the reason for its deletion. Just “license proliferation.”

Granted, the MPL license is imperfect and has its issues. But it did then, as well. The timing of this decision seems curious to me. License proliferation is surely not more of a risk today than it was at launch. Were there projects that Google pragmatically wanted to get in the door before suspending the availability of the MPL? Have conditions change to make the MPL more of a potential threat than it was previously?

What finally convinced Google to remove the MPL? If they wanted to restrict the available licenses choices, why not do so from the beginning?

Frankly, I have no idea. But maybe someone will tell us.

Ultimately, it’s clear that Google and its some of its very bright employees take the problem of license proliferation seriously. Far more seriously than I do – something I’ll have to think about, and seriously enough to design a system around it. I do believe, however, that other motives are being obscured by the blanket “license proliferation” justification, and I can’t help but be curious as to what those might be.


  1. One of the rationales for this may be something mike muller pointed out to me a while ago (http://www.enduden.com/~mmuller/news/index.html)

    “I’ve also decided to move away from my own BSD-ish license and onto something more standard – in this case, the LGPLv3. For a long time I used my own license because I feared the GPL to be too restrictive for businesses to be willing to use GPL code. None of the less restrictive licenses in use seemed to express what exactly I wanted. These days, however, it seems that pretty much everybody is using GPLed code, and I’ve come to accept that a lot of the restrictive provisions of the license (particularly some of the anti-patent provisions of GPL3) are really important for the FOSS community. Also, as it turns out, it is now the special one-off licenses like mine that hinder business adoption of the code – they create a whole new hurdle of having to be approved by the legal department. So ODB is now released under LGPLv3. “

  2. Hey Stephen,

    I started a thread over on FriendFeed in response. The basic concern is that it increases the burden of compliance for the users of open source code, and ultimately reduces the reusability of the code, which runs counter to the presumed original intent of the licensor. See: http://friendfeed.com/e/a6edd1dc-8857-2458-d645-63e22e07faa8/Google-Code-vs-License-Proliferation/



  3. All well and good, DeWitt, but the way to fix it is at source at OSI rather than usurping their authority. Like Stephen, I can’t help suspecting this is more about justifying Google’s rejection of AGPL and CDDL. And I actually do oppose proliferation, as I’ve blogged in the past[1].

    [1] http://blogs.sun.com/webmink/entry/addressing_proliferation_deeds_not_just

  4. […] it comes to license styles and trends, I tend towards laissez-faire, to be sure (e.g. my apathetic response to the license proliferation crisis). In this, the ASP loophole question is no exception. If the […]

  5. […] and become the most well known.   The estimable Stephen O’Grady of RedMonk raises good points about the need not to get one’s knickers in a twist about the large number of open source […]

Leave a Reply

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