Mr. Michael Tiemann, President,
Ms. Danese Cooper, Secretary & Treasurer,
Mr. Russ Nelson, Director,
Mr. Ken Coar, Director,
Mr. Bruno Souza, Director,
Ms. Laura Majerus, OSI Director of Legal Affairs (and Chair of License Proliferation Committee)
Mr. Ernie Prabhakar, Board Observer
Late: Mr. Sanjiva Weewarawana, Director (@ noon PDT)
Quorum reached at 11:00am EDT
1. Discussed agenda for meetings at upcoming O’Reilly Open Source Conference (OSCON) and EuroOSCON
-Tackle two subjects: one in AM and one in PM.
-Ms. Cooper will obtain a room at the 5th Avenue Suites Hotel for the entire day Monday July 24th (same room as last year).
-Planned attendance at EuroOSCON: Mr. Souza, Mr. Weewarawana, Mr. Ghosh, Ms. Cooper. Mr. Coar is still waiting on travel approval.
*Open Standards @ OSCON
-Plan to use occasion of OSCON to build community support list.
-Mr. Tiemann will cause artwork to be created for a run of “post cards” with the Open Standards Requirements (OSR) and OSI logo on one side and will have them printed for OSCON.
-Consider preliminary announcement about OSR the week before EuroOSCON?
*Website Work @ OSCON
-Possible reorganization around “Broad Themes of Open Source”
-Dynamic Content: Agreement that we are not organized to maintain a lot of dynamic content (aside from RSS feeds of our personal blogs)
-Discussion around how to best organize to build new pages during OSCON: Content Sprint?
-Ms. Cooper will try to make sure our webmaster, Mr. Steve Mallett, is planning to attend our meeting @ OSCON
2. License Proliferation
*Ms. Majerus sent Draft Report today to Board of Directors:
DRAFT July, 2006
To: OSI Board
cc: License Proliferation Committee
Subject: Report of License Proliferation Committee and draft FAQ
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. It’s 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, 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 “tiers” and a FAQ to explain why the committee made tiers and how it expects it will help in lessening license proliferation.
1. 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.”
a) too many different licenses makes it difficult for licensors to choose
Some people use the term 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 a particular license. All we can do is educate and urge people to use a smaller subset of licenses. This comment generally comes from individuals and small companies.
b) some licenses do not play well together
Some people use the term 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 can’t keep people from doing so. This comment usually comes from larger companies.
c) 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 re 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 comes from larger companies.
2. What 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 additional guidelines that they would apply to proposed licenses to determine whether they should be OSI-approved. Those guidelines are: i) the license must not be duplicative, ii) The license must be clearly written, simple, and understandable, iii) The license must be reusable
We propose addressing the licensing picking issue by making available a license wizard, as discussed below.
We propose an on-going project to categorize existing open source licenses. The goal of such categorization is to help the community determine which licenses are useful in which circumstances.
3. 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 se which OSI approved licenses meet criteria that they find important. For example, if 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.
This assists new licensors in choosing which licenses meet their goals. The wizard also lets licensors find licenses that almost meet their goals.
4. The Tiers
Originally, the LP Committee started to divide the OSI approved licenses into “recommended,” “non-recommended” and “other” tiers. As we met and discussed, however, it became apparent that there is no one open source license that serves everyone’s needs equally well. Governmental bodies have specific needs concerning copyright rights. Some people like copyleft. Some don’t. As we discussed which licenses should be “recommended,” it became clear that the recommended licenses were really the same as licenses that were either widely used, or that had a large following (for example, the GPL or Eclipse). Thus, we switched from the “recommended”/”non-recommended” terminology to a more descriptive terminology of:
-Licenses that are popular and widely used or with strong communities
-Special purpose licenses
-Licenses that are redundant with more popular licenses
We thought that these more descriptive categories may help people initially picking a license to generally use one of the more popular licenses, thereby helping to reduce the numbers of different licenses commonly used. We realize that the majority of open source licenses currently use the GPL and that the GPL does not always play well with other licenses. We also realize that the GPL is a great license choice for some people and not so great a license choice for others. Thus, we can’t just recommend that everybody use the GPL. While such a recommendation would solve the license proliferation problem, it is not realistic.
The OSI would be happy if everyone really tried to use licenses that a popular and widely used and/or that have strong communities. There are only nine licenses in this group and if everyone considered these licenses first when choosing a license for their project, some of the issues relating to LP would diminish.
Here are the tiers:
Licenses that are popular and widely used or with strong
- Apache License, 2.0
- New BSD license
- GNU General Public License (GPL)
- GNU Library or “Lesser” General Public License (LGPL)
- MIT license
- Mozilla Public License 1.1 (MPL)
- Common Development and Distribution License
- Common Public License
- Eclipse Public License
Special purpose licenses (3)
- NASA (special purpose: for use by an agency of the federal
government, which has special concerns regarding some issues
copyright protection, copyright notices, disclaimer of warranty
and indemnification, and choice of law)
- Open Group Test Suite (special purpose: only suitable for
- Educational Community License (special purpose: only
Other/Miscellaneous licenses (5)
- Adaptive Public License
- Artistic License
- Open Software License
- Q Public License
- zlib/libpng license
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
- X.Net License (redundant with MIT)
Non-reusable licenses (25)
- Apple Public Source License
- Computer Associates Trusted Open Source License 1.1
- EU DataGrid Software License
- Entessa Public License
- Frameworx License
- IBM Public License
- MITRE Collaborative Virtual Workspace License (CVW 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
Superseded licenses (4)
- Apache Software License v1.1
- Eiffel 1.0
- Lucent 1.0
- MPL 1.0
Licenses that have been voluntarily deprecated (3)
- Intel Open Source License
- Jabber Open Source License
- Sun Industry Standards Source License (SISSL)
Here are our criteria for placing licenses in the various tiers:
-Licenses that are popular and widely used or with strong
We used statistic obtained from public sources to determine which licenses are widely used. We believed that there were a few licenses that, while not most popular, were widely used within their communities and that these also belonged in this category.
Special purpose licenses (3)
Certain licensors, such as 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 category.
Licenses that are redundant with more popular licenses (9)
Several licenses in this category are excellent licenses and have their own followings. The committee struggled with this category, but ultimately decided that if we were to attack the license proliferation problem, we had to prune licenses. Thus, licenses that were perceived as duplicating existing licenses were placed in this category.
Licenses in this category are specific to their authors and cannot be reused by others. Many, but not al, of these licenses fall into the category of vanity licenses.
Licenses in this category have been superseded by newer versions
Licenses that have been voluntarily deprecated
Self-defining category. No one should use these licenses going forward, although we assume that licensors may or may no choose to continue to use them.
These licenses do not fall neatly into any category.
This is a draft document. I need to get approval from the committee members. We have also agreed to run these categories past the license stewards first. After that, we have promised to put the categories up for public comment.
After that, the Board needs to decide on a process for newly approved licenses to be placed in a tier at the same time they are approved.
*Discussion about whether to produce 100 copies of FAQ and Report for distribution at OSCON.
*Caution from Ms. Majerus that per working agreement on the License Proliferation Committee we need to give specific license stewards a heads up before public conversation starts.
3. License Approval Committee
Summary of recommendations for this meeting:
*Mindtree Public License…not reusable, not responsive to comments
*Microsoft Licenses…haven’t been submitted by Microsoft yet, so should pause discussion until that happens
*TrueCrypt Public License…defer for more discussion
*Broad Institute Public License…defer for more discussion
*Mr. Nelson motions that we accept the License Committee report for July 11, 2006, Mr. Tiemann seconds. Passed unanimously.
Meeting adjorned 1:00pm EDT