Blogs

RedMonk

Skip to content

Google Code vs License Proliferation

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.

Categories: Open Source.

  • http://dague.net Sean

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

  • DeWitt Clinton

    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/

    Cheers,

    -DeWitt

  • http://www.webmink.net Simon Phipps

    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

  • Pingback: tecosystems » AGPL: Open Source Licensing in a Networked Age

  • Pingback: From Tolstoy to Tinker Bell. Down from Berkeley to Carmel. « Tuna Park