One less open source licence to worry about

Open source licence proliferation has long been recognised to be a problem. The Open Source Iniatitives License Proliferation Committee wrote the following in May 2006:

  1. too many different licenses makes it difficult for licensors to choose
    Some people use “license proliferation” to mean that there are just too many licenses and that someone needs to take steps to reduce the number. While this would be great, the OSI cannot make anyone use or not use a particular license. All we can do is educate and urge people to use a smaller subset of licenses. This comment generally came from individuals and small companies.
  2. some licenses do not play well together
    Some people use “license proliferation” to refer to the fact that some open source licenses do not inter-operate well with other open source licenses. While we can urge people not to mix non-mixable licenses, we cannot keep people from doing so. This comment generally came from larger companies.
  3. too many licenses makes it difficult to understand what you are agreeing to in a multi-license distribution
    This is related to the previous comment, but is somewhat different since it doesn’t complain about how the licenses interact, just that there are too many different individual licenses covering certain distributions and that it takes a lot of time to read and understand them all. This comment usually came from larger companies.

The OSI has, since the publication of this report, grouped licences as either “popular and widely used”, “special purpose”, “redundant”, “non-reusable”, “superseded” or “other”. OSS Watch encourage everyone to use one of the “popular and widely used” licences as these cover the major needs of most community and business models (the special purpose licences do have their place, but they are minority licences).

Today it was announced that the number of licences in the recommended group has been reduced from nine to eight since the Eclipse Foundation, along with IBM, have taken the steps necessary to supersede the Common Public License 1.0 (CPL) with the Eclipse Public License 1.0  (EPL).

Hurrah!!!

5 thoughts on “One less open source licence to worry about

  1. Since 1999 at least, debian project contributors have been categorising licences as common-licenses as part of the base-files maintenance. The debian list is better than OSI’s because it’s popularly compiled, based on actual use for actual software and not by studying licences in abstract. You can view one version of the list at http://www.uk.debian.org/legal/licenses/

    It’s nice that OSI have finally started doing something similar, but they’re rather late to this effort after years of helping license proliferation by approving licences in abstract without regard to whether they’re popular in either sense.

  2. At the end of the day, keeping track of the licenses in a project manually is impractical. My developers do not understand (and some, frankly, do not care) about the nuances of licenses. As a project manager I have had to educate myself and my team about some basic aspects of the licenses. IP management automation (we use IP Analyzer from Protecode and run it weekly) is the only way we can find out what has crept into the repository, and if the license or copyright is ok for us. I expect continuous IP management will become as common (and necessary) as version control practice.

  3. I think it’s very clever to educate development teams about licensing. It sounds like there’s not much higher-level support for that yet – would that be accurate?

    We need to educate developers and education is part of my company’s mission, right there alongside providing IT services, but it seems we’re very unusual about that. Automation is helpful (again, look at things like machine-readable copyright control from the debian project, which are in their infancy but could be useful soon) but no substitute for education and vigilence.

  4. MJ Ray, you note that Debian has been categorising licences for some time and I agree this is very useful.

    One advantage of the OSI lists is that the licences are scrutinised by Lawyers before they are published. The OSI job is to ensure a “so-called” open source licence is indeed open source (and thus free software). Furthermore, whilst approval of licences is dependent only on their legal status, the categorisation of licenses is based on actual use.

    Does the Debian process have lawyers looking at the licences?

    I agree that automated tools are not sufficient in IP management processes. They are helpful, sure, but nothing beats an understanding of the licence terms and a proper audit trail and accountability.

    OSS Watch are here to help projects based in the education sector manage their IP correctly.

  5. The Debian process does have lawyers looking at licences, but by referral from the maintainers or managers, rather than routinely (because that would quickly get expensive and/or slow and 99% of licensing problems are obvious application goofs, rather than questions about the actual license).

    The OSI process described at http://www.opensource.org/approval and linked pages seems to encourage a lawyer only on the license-advocate side and not require one on the OSI side, unless I missed something? So while that means you’ve almost always got a lawyer involved (good), it means there’s almost always a lawyer on the license-advocate side (bad). I thought that was why OSI has been such a proliferation catalyst for most of its life, because it’s driven by “please approve our cool new licence” open-sourcer egoism rather than “should we accept this licence?” debianer pragmatism.

    Anyway, the recent changes are most welcome. Sinner that repenteth and so on.

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>