Blogs

Redmonk

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.

Popularity: 3% [?]

by-sa

Share This

This entry was written by sogrady and posted on August 6, 2008 at 6:55 am and filed under Open Source. Bookmark the permalink. Follow any comments here with the RSS feed for this post. Post a comment or leave a trackback: Trackback URL.

3 Comments

  1. Sean
    Posted August 6, 2008 at 7:36 am | Permalink

    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. DeWitt Clinton
    Posted August 6, 2008 at 7:56 am | Permalink

    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

  3. Simon Phipps
    Posted August 6, 2008 at 2:44 pm | Permalink

    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

View this post on FriendFeed
  • August 6, 2008 at 8:27 am DeWitt Clinton
    Assuming that all open source licenses are equally good (they're not, but for sake of argument, let's say they are), and that you wanted to use source code from 100's of projects, all licensed differently. To do the right thing before using that code one would need to vet, and I mean legally vet, the license before adopting the code. That process is time consuming and expensive. And because no code is an island, open source code even less so, in order to create a derivative work and be stay legal compliance with each license you'd have to vet whether every permutation of licenses can be combined with the others. So it becomes at n! combination problem -- the cost of incorporating code under any new license is exponential.
  • August 6, 2008 at 8:29 am DeWitt Clinton
    The net effect of that explosion of combinational complexity is that consumers of open source code may ignore the responsibility of compliance in the first place. Which is a bad thing. It puts the pain and burden on the user of open source code. How many open source licenses have you personally read and understood, and had your lawyers read and understand? The answer 2 or 3 is reasonable. 20 or 30 is not.
  • August 6, 2008 at 9:50 am stephen o'grady
    A momentous occasion indeed: this marks my first actual comment on FriendFeed, I think. Still undecided on the tool That trivia aside, it's not the macro intent or direction I question, but rather the timing and the logistics. The why now question still stands, I think, if we assume that staving off license proliferation is the end goal. The MPL is no more or less viable as a license than it was at launch time, yet the decision has been made to remove it as an option. That's Google's right, and I'm not even necessarily arguing that it's a bad thing, but why now? Beyond that, few people - no one, really - would question the assertion that 20 or 30 licenses are not impractical but a real threat to open source consumption. But the question becomes, if 2 or 3 are reasonable, _which_ 2 or 3 will remain? Google's position here seem to be one permissive (Apache), one project reciprocal (GPL), and that's it. No file reciprocal (CDDL, EPL, MPL, etc), with the possible exception of the LGPL (which the FSF discourag
  • August 6, 2008 at 9:58 am stephen o'grady
    ...which the FSF discourages use of). Which is, again, Google's right. I just don't happen to share that philosophy.
  • August 6, 2008 at 9:59 am DeWitt Clinton
    Just an idea, but if existing code released under the MPL and the EPL (and other MPL derivatives) were relicensed under say, the CDDL, then there would be a single weak copyleft license that has something like 6-7% market share. That would facilitate interoperability between those projects (making one bigger island), and be a step in the right direction.
  • August 6, 2008 at 10:01 am stephen o'grady
    Also, one private commenter argued that the MPL is dead, to which I'd respond by pointing here (http://labs.mozilla.com/2008/08/introducing-the-concept-series-call-for-participation/). Relevant bit: "We only ask that all concepts and related source materials be freely redistributable and remixable under either a Creative Commons license (for Ideas and Mockups) or the Mozilla Public License (for Prototypes) so that we can all effectively collaborate on the exploration."
  • August 6, 2008 at 10:03 am DeWitt Clinton
    Stephen, how many of your clients primary concern is as a *consumer* of open source licensed code? Most of them are vendors trying to find the business advantage in releasing it, right? To properly stay in compliance one needs to compute the transitive closure of all applicable licenses before code is even compiled. The cost of this goes all the way down to how the internal code repositories and the internal build systems are architected. Increase that cost, and fewer consumers will be in compliance..
  • August 6, 2008 at 10:06 am DeWitt Clinton
    Heh. That statement precisely makes my point. IMHO, it is not a good thing that a community would say "in order to contribute we need you to use our proprietary open source license." Isn't the goal getting the code out there and reusable without arbitrary restrictions?
  • August 6, 2008 at 10:11 am stephen o'grady
    I'd be all all for a centralization of the MPL/EPL/CDDL/etc assets, but it's not likely to happen. The odds of the Eclipse EPL assets, for example, being rereleased under the CDDL are probably near zero. Realistically, I think we're stuck in a world that will have three rough styles of licenses and at least two options within each style (if only due to versioning). Illogical as this might seem, I think this is the reality for the foreseeable future.
  • August 6, 2008 at 10:16 am DeWitt Clinton
    I agree with your assessment about the likelihood of relicensing. However, Google Code can put a tiny little bit of pressure on the community when it comes to new code by saying, if you want to host it here, please pick one of the major non-product-specific license choices. Is that sufficient to change major established projects, like Mozilla's codebase or Eclipse? Probably not. But those are a small fraction of all open source projects, and the goal is to change the future, not the past.
  • August 6, 2008 at 10:20 am stephen o'grady
    I don't think we disagree at all on the advantages to a world with fewer licenses, whether it's from the vendor combinatorial or consumer comprehension perspectives. Where we break, I think, is in the achieveability of that goal. Specifically, I think the world that Google would like to see is a very much a perfect world scenario. Achievable within the confines of Google Code, certainly, but unrealistic on a wider scale. Unless massive changes of incentive occur.
  • August 6, 2008 at 10:26 am DeWitt Clinton
    I don't know... We're all so new at this. A dozen years ago there were only a handful of open source licenses. Then it became trendy to write your own -- the Mozilla license even encouraged it by saying "copy this license for your project, just change the name and fork." A decade later, with the benefit of hindsight, we're seeing that this approach was probably a mistake.
  • August 6, 2008 at 10:27 am DeWitt Clinton
    And 10 years from now we may have moved past that, and companies that are interested releasing open source software will use a standard license, rather than fragmenting the open source ecosystem with more one-off licenses. At the very least, Google Code can take the position of not being an enabler of that fragmentation. [Edited, because I think I accidentally came across as blaming you for what's going on -- I didn't mean that!]
  • August 6, 2008 at 10:30 am stephen o'grady
    One last thought: the desired end state of easy recombination of assets is already sacrificed, even in the world of Google Code. The simplest way to guarantee free combination would be to reduce everything to one license: Apache. The allowance is made, however, for the GPL's philosophy and vision of freedom. Why? Because there's a lot of GPL code, presumably. In that context, the MPL deletion is more about volume than philosophy. Which is fine. Just important to note, I think.
  • August 6, 2008 at 10:34 am stephen o'grady
    DeWitt, come on, give us _some_ credit. We would never, under any circumstances, recommend that a client use a one off license. Today, not in future. That's off the table. You and I agree on the implications of license proliferation, I'm pretty sure: we just differ in how aggressively it must be combated, and how strictly the licenses must be pared back.
  • August 6, 2008 at 10:35 am DeWitt Clinton
    Sorry, Stephen. I had already went back and edited my comment on that. No offense meant!
  • August 6, 2008 at 10:35 am Rob Sayre
    Google Code's license options are up to them. It's nice that they offer the service at all. I soured on it a bit when I discovered that they mingle the project hosting with closed source SDKs and network interfaces to closed source serverside stuff. I don't oppose closed source software on moral grounds, but I don't like that Android and AppEngine etc live on Google Code, because I feel like hosting a project there is a tacit endorsement of that stuff.
  • August 6, 2008 at 10:39 am DeWitt Clinton
    Hey, Rob! Welcome to FriendFeed. Do you mean that code.google.com now has more than just open source project hosting on it? (The developer product apis, the Google Code University stuff, etc?) [Ahh, you updated your comment...]
  • August 6, 2008 at 10:42 am stephen o'grady
    None taken: I just didn't want passers by to think we were out there recommending vanity licenses ;)
  • August 6, 2008 at 10:42 am DeWitt Clinton
    Interesting point, Rob. I guess I like it because I think it is great that there can be an interplay and exchange between developer apis and open source code. And frankly, the more that open source philosophies can inform developer products, the better. But that's interesting about "endorsement". I never thought of it that way. Do you think mixed communities like sf.net or collabnet have the same problem?
  • August 6, 2008 at 10:44 am stephen o'grady
    Rob: agreed. I've maintained pretty consistently that it's Google's right to choose whatever licenses they like for their service, since they are the ones hosting and maintaining it. My point in the piece and here was rather to debate their reasoning, since I don't happen to agree. Not to question their right to it.
  • August 6, 2008 at 11:28 am Rob Sayre
    DeWitt: network APIs don't really bother me. I'm not sure network APIs conflict with open source much, though it does feel like sharecropping. I put a crash processing server on Google Code for work because I figured it would get more contributors. Later on, I found Google Code hosting Google products that are not open source, but it all looks very similar. When combined with videos of execs claiming Android is "open top to bottom" (not true for now), it started to smell for me.

Post a Comment

Your email is never published nor shared. Required fields are marked *
*
*

Note: This post is over 3 months old. You may want to check later in this blog to see if there is new information relevant to your comment.

Close
E-mail It