Report of License Proliferation Committee and draft FAQ

Page created on July 31, 2006 | Last modified on January 25, 2023

The purpose of this document is to report on the efforts and
recommendations of the License Proliferation committee of the OSI
(“the LP Committee”).

The LP Committee is an advisory committee. Its charter states “[t]he
purpose of the Committee is to identify and lessen or remove issues
caused by license proliferation.” (Charter attached).

The members of the LP Committee were:

  • John Cowan,
  • Damien Eastwood,
  • Bryan Geurts,
  • Rishab Aiyer Ghosh (observer),
  • Laura Majerus (chair),
  • Russ Nelson,
  • Karna Nisewaner,
  • Diane Peters,
  • Eric Raymond,
  • Sanjiva Weerawarana (observer),
  • Cliff Schmidt,
  • McCoy Smith

This document contains a policy statement from the LP Committee
about its understanding of the definition of license proliferation
and some suggestions about what to do about it.

This document also contains a suggestion for license groups and a
FAQ to explain why the committee made groups and how it expects it
will help in lessening license proliferation.

What Does License Proliferation mean?

One thing that became clear as we talked among ourselves and listened
to the open source community was that different people meant different
things when they used the term “license proliferation.” Comments broke
down into three main groups:

  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.

What the OSI Can Do About License Proliferation

The first thing we can do is to make sure that licenses calling
themselves “open source” truly meet the Open Source Definition.
In 2005, the OSI has suggested three guidelines that they would
apply to proposed licenses to determine whether they should be

  1. The license must not be duplicative
  2. The license must be clearly written, simple, and understandable
  3. The license must be reusable

We propose addressing the license picking issue by making
available a license wizard, as discussed below.

We propose an on-going project to group existing open source licenses.
The goal of such categorization is to help the community determine
which licenses are useful in which circumstances.

The Wizard Project

Volunteers from USC law school and San Francisco State engineering
department are currently working on a web-based wizard to allow
people to see which open source licenses meet criteria that they find
important. These volunteers are Prof. Jennifer Urban and Prof.
Sameer Verma, along with their research assistants. For example,
if a user indicates that having a copyleft license with explicit
patent grants is important, the wizard will look through the
OSI-approved licenses and output a list of licenses that meet
(or almost meet) those criteria.

The wizard assists new licensors in choosing which licenses meet
their goals. The wizard also lets licensors find licenses that
almost meet their goals. We hope that being able to generate a
list of existing licenses that meet defined goals will lessen
the need for people to create their own new licenses.

The Groups

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.
Thus, we switched from the “recommended”/”non-recommended” terminology to
a more descriptive terminology including the following categories:

  • Licenses that are popular and widely used or with strong
  • Special purpose licenses
  • Licenses that are redundant with more popular licenses
  • Non-reusable licenses
  • Other/Miscellaneous licenses

We thought that these more descriptive categories would help
people initially picking a license to use one of the more
popular licenses, thereby helping to reduce the numbers of
different licenses commonly used.

While it might at first sight not seem appropriate for the popularity of a license to be significant in categorizing it, popular and long-established licenses have an important thing going for them: the existence of an established interpretive tradition and a well-developed set of expectations about correct behavior with respect to them. This is significant in reducing confusion and (especially in common-law countries) is even likely to condition judicial interpretation
of the licenses.

Here are the groups:

Licenses that are popular and widely used or with strong
communities (9)

  • Apache License, 2.0
  • New BSD license
  • GNU General Public License (GPL version 2)
  • GNU Library or “Lesser” General Public License (LGPL version 2)
  • MIT license
  • Mozilla Public License 1.1 (MPL)
  • Common Development and Distribution License
  • Common Public License
  • Eclipse Public License
Special purpose licenses (3)
  • Educational Community License (special purpose: only
    suitable for educational establishments)
  • NASA (special purpose: for use by an agency of the
    United States federal government, which has special
    concerns regarding some issues such as copyright protection,
    copyright notices, disclaimer of warranty and indemnification,
    and choice of law)
  • Open Group Test Suite (special purpose: only suitable for
    tests or test suites)
Licenses that are redundant with more popular licenses (9)
  • Academic Free License (redundant with Apache 2.0)
  • Attribution Assurance Licenses (redundant with BSD)
  • CUA Office Public License (redundant with MPL 1.1)
  • Eiffel Forum License V2.0 (redundant with BSD)
  • Fair License (redundant with BSD)
  • Historical Permission Notice and Disclaimer
    (redundant with BSD)
  • Lucent Public License Version 1.02 (redundant with CPL)
  • University of Illinois/NCSA Open Source License
    (redundant with BSD)
  • X.Net License (redundant with MIT)
Non-reusable licenses (24)
  • Apple Public Source License
  • Computer Associates Trusted Open Source License 1.1
  • EU DataGrid Software License
  • Entessa Public License
  • Frameworx License
  • IBM Public License
  • Motosoto License
  • Naumen Public License
  • Nethack General Public License
  • Nokia Open Source License
  • OCLC Research Public License 2.0
  • PHP License
  • Python license (CNRI Python License)
  • Python Software Foundation License
  • RealNetworks Public Source License V1.0
  • Reciprocal Public License
  • Ricoh Source Code Public License
  • Sleepycat License
  • Sun Public License
  • Sybase Open Watcom Public License 1.0
  • Vovida Software License v. 1.0
  • W3C License
  • wxWindows Library License
  • Zope Public License
Other/Miscellaneous licenses (5)
  • Adaptive Public License
  • Artistic License
  • Open Software License
  • Q Public License
  • zlib/libpng license
Superseded licenses (4)
  • Apache Software License v1.1
  • Eiffel 1.0
  • Lucent 1.0
  • MPL 1.0
Licenses that have been voluntarily retired (4)
  • Intel Open Source License
  • Jabber Open Source License
  • MITRE Collaborative Virtual Workspace License
  • Sun Industry Standards Source License (SISSL)

Here are our criteria for placing licenses in the various groups:

Licenses that are popular and widely used or with strong
We used statistics obtained from public sources to determine
which licenses are widely used. We believed that there were a few
licenses that, while not the most popular, were widely used within
their communities and that these also belonged in this group.
Special purpose licenses
Certain licensors, such as schools and the US government,
have specialized concerns, such as specialized rules for
government copyrights. Licenses that were identified as meeting a
special need were placed in this group.
Licenses that are redundant with more popular licenses
Several licenses in this group are excellent licenses and
have their own followings. The committee struggled with this
group, but ultimately decided that if we were to attack the
license proliferation problem, we had to prune licenses. Thus,
licenses that were perceived as completely or partially redundant
with existing licenses were placed in this group.
Non-reusable licenses
Licenses in this group are specific to their authors and
cannot be reused by others. Many, but not all, of these licenses
fall into the category of vanity licenses.
Superseded licenses
Licenses in this category have been superseded by newer
Licenses that have been voluntarily retired
Self-defining category. No one should use these licenses
going forward, although we assume that licensors may or may
not choose to continue to use them.
Other/Miscellaneous licenses
These licenses do not fall neatly into any category.