Tackling proliferation

Tackling proliferation

Posted Mar 25, 2008 3:10 UTC (Tue) by man_ls (subscriber, #15091)
In reply to: Bruce Perens and the OSI board by BrucePerens
Parent article: Bruce Perens and the OSI board

Bruce, I received your request for help but didn't sign it because I didn't really see the problem with OSI: nowadays it approves licenses and otherwise keeps a low profile. Now that I have read your extended description, it seems that this blind approving of licenses is precisely one of the issues you have. Please excuse or ignore this lengthy message, but I think your message is well worth an in-depth response.

Correct me if I'm wrong: you want OSI to have not just the "OSI-certified" label, but a new "OSI-recommended" badge for a limited set of (four) licenses. That is actually a very good idea, and something that should have come out of the license proliferation committee if at all possible. But the devil, as they say, is in the details. Which licenses do you select for this recommended set?

In your most interesting message you suggest a set of exactly four licenses: in FSF terminology they would be permissive non-copyleft (as BSD), weak copyleft (LGPL), strong copyleft (GPL) and strong interactive copyleft (AfferoGPL). However, whether it is better to go with existing licenses (essentially as FSF recommends) or to craft new ones (responding to specific concerns) is left open. So let us discuss both scenarios with a couple of thought experiments and see where we get.

First, what if OSI goes with new licenses and creates them. Responding to license proliferation with even more license proliferation, in the form of four new licenses, is probably not going to be well received. And besides: similar efforts in the past have all failed to make an impact against the workhorse of free software licenses, the GPL. So in all likelihood this effort will probably be ignored by all major players, who seem to be already happy with what they have, and so will leave OSI recommending four licenses which nobody uses. Hardly the way to make OSI more relevant than they are today.

Then, we are left with what if OSI recommends BSD and three GPLv3 derivatives, which you imply fit essentially all of the requirements. As another commenter suggests, OSI would then recommend essentially the same licenses as the FSF. But this was already tried by the proliferation committee: in their report they state their initial intent to do exactly this, and how they failed. In their words:

Originally, the LP Committee started to divide the OSI approved licenses into "recommended," "non-recommended" and "other" tiers. The committee concluded, however, that any such normative characterization would properly be a matter for policy matter for the OSI Board to decide.

So, "a matter for policy matter"... or in plain English: OSI didn't want to step on any toes. The first problem is why recommend one license over another where some equally good candidates exist. From your analysis it would seem that your set of four is perfectly rounded, with maybe a few details to discuss, e.g.: maybe Apache 2.0 should be preferred over BSD. But there is a gaping hole in your criteria: what here on LWN was reported as "a commercial version of the GPL".

This is where things get really hairy. This license is not simply weak copyleft: as with the MPL, portions of the code can be incorporated into proprietary works on a file-by-file basis, and continue being free software. As Russ Nelson explained in that same LWN interview:

CDDL. Or more properly, the MPL, since it already has traction in the community (clearly, since Sun wrote the CDDL based on the MPL). A lot of licenses are derived from the MPL. If we can figure out why they derived the MPL rather than using it, we can fix the problem in the MPL that caused them to do that.

There is obviously a need for this kind of license since a few of them have been proposed. Note that in OSI's report, the "recommended" category (which finally was "Licenses that are popular and widely used or with strong communities") lists four candidates for this "commercial GPL": MPL, CDDL, CPL and EclipsePL. Apparently the committee couldn't "figure out why they derived the MPL rather than using it" and so included all of them. The report also recommends three permissive non-copyleft: BSD, MIT and Apache 2.0, presumably trying once more to avoid to step on any toes.

And then there is a second toe-stepping problem: there were other special interests which didn't fit into a limited license set (like your four licenses plus "commercial GPL"). Who is the OSI anyway to decide what commercial interests are? In the end they reported on seven convoluted categories, and as could be expected never got anywhere.

But this cannot be blamed on OSI. Either you get knee-deep into "matters for policy matters", as the FSF, and step on whatever toes are necessary, with the consequences we all know; or you are left with convoluted categories and bland policy statements. I'm not so sure there is a middle road. So, I'm left wondering what you would do if you were in OSI that would make any difference.

---

(Log in to post comments)