<HTML >
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2769" name=GENERATOR></HEAD>
<BODY >
<DIV>
<DIV>
<P><FONT size=2>FYI,the first draft report of the OSI's License Proliferation
Committee. To join the OSI's license proliferation discuss email list, send an
email to: </FONT><A
href="mailto:license-proliferation-discuss-subscribe@opensource.org"><FONT
size=2>license-proliferation-discuss-subscribe@opensource.org</FONT></A></P>
<P><SPAN class=573141400-29072006><FONT size=2>From here on in, I'd like to keep
discussion on the LP discuss group if possible. This is just an email to let you
know that the group exists.</FONT></SPAN></P>
<P><FONT size=2>Laura<SPAN class=573141400-29072006> Majerus</SPAN></FONT></P>
<P><FONT size=2>-----Original Message-----</FONT></P>
<P><FONT size=2>From: Laura Majerus [</FONT><A
href="mailto:LMajerus@fenwick.com"><U><FONT color=#0000ff
size=2>mailto:LMajerus@fenwick.com</U></FONT></A><FONT size=2>]</P>
<P>Sent: Thursday, July 27, 2006 10:28 PM</P>
<P>To: license-proliferation-discuss@opensource.org</P>
<P>Cc: license-proliferation@opensource.org</P>
<P>Subject: Draft of License Proliferation Committee Report</P>
<P>Inline below is the text of the OSI's License Proliferation Committee Report.
This is a DRAFT that we are submitting for community comments. This draft was
handed out at the OSI BOF at Oscon in Portland Thursday night. Did we get the
licenses in the right buckets? Please read and let us know what you think.</P>
<P>Laura Majerus</P>
<P>----------------------------------------</P>
<P>DRAFT July 2006</P>
<P>MEMO</P>
<P>To: OSI Board</P>
<P>cc: License Proliferation Committee</P>
<P>Subject: Report of License Proliferation Committee and draft FAQ</P>
<P>The purpose of this document is to report on the efforts and recommendations
of the License Proliferation committee of the OSI ("the LP Committee").</P>
<P>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). </P>
<P>The members of the LP Committee were:</P>
<P>John Cowan,</P>
<P>Damien Eastwood,</P>
<P>Bryan Geurts,</P>
<P>Rishab Aiyer Ghosh (observer),</P>
<P>Laura Majerus,</P>
<P>Russ Nelson,</P>
<P>Karna Nisewaner,</P>
<P>Diane Peters,</P>
<P>Eric Raymond,</P>
<P>Sanjiva Weerawarana (observer),</P>
<P>Cliff Schmidt,</P>
<P>McCoy Smith </P>
<P>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.</P>
<P>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.</P>
<P>1. What Does License Proliferation mean?</P>
<P>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:</P>
<P>a) 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.</P>
<P>b) 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.</P>
<P>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 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.</P>
<P>2. What the OSI Can Do About License Proliferation</P>
<P>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 OSI-approved. </P>
<P>i) The license must not be duplicative</P>
<P>ii) The license must be clearly written, simple, and understandable</P>
<P>iii) The license must be reusable</P>
<P>We propose addressing the license picking issue by making available a license
wizard, as discussed below.</P>
<P>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.</P>
<P></P>
<P>3. The Wizard Project </P>
<P>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. </P>
<P>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.</P>
<P>4. The Groups</P>
<P>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. Some people like copyleft. Some don't.
Governmental bodies have specific needs concerning copyright rights. 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 (for example the GPL), or that had a strong community (for example
Eclipse). Thus, we switched from the "recommended"/"non-recommended" terminology
to a more descriptive terminology of:</P>
<P>-Licenses that are popular and widely used or with strong communities</P>
<P>-Special purpose licenses</P>
<P>-Licenses that are redundant with more popular licenses -Non-reusable
licenses -Other/Miscellaneous licenses</P>
<P>We thought that these more descriptive categories may 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. We realize that the
majority of open source projects 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.</P>
<P>We encourage new licensors to use licenses in the "popular and strong
communities" group if any licenses in that group fit their needs. 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 license
proliferation would diminish. </P>
<P> </P>
<P>Here are the groups:</P>
<P>Licenses that are popular and widely used or with strong</P>
<P>communities(9)</P>
<P>- Apache License, 2.0</P>
<P>- New BSD license</P>
<P>- GNU General Public License (GPL)</P>
<P>- GNU Library or "Lesser" General Public License (LGPL)</P>
<P>- MIT license</P>
<P>- Mozilla Public License 1.1 (MPL)</P>
<P>- Common Development and Distribution License</P>
<P>- Common Public License</P>
<P>- Eclipse Public License</P>
<P>Special purpose licenses (3)</P>
<P>- Educational Community License (special purpose: only suitable for
educational establishments)</P>
<P>- NASA (special purpose: for use by an agency of the federal government,
which has special concerns regarding some issues such as copyright protection,
copyright notices, disclaimer of warranty and indemnification, and choice of
law)</P>
<P>- Open Group Test Suite (special purpose: only suitable for tests or test
suites)</P>
<P> </P>
<P>Licenses that are redundant with more popular licenses (9)</P>
<P>- Academic Free License (redundant with Apache 2.0)</P>
<P>- Attribution Assurance Licenses (redundant with BSD)</P>
<P>- CUA Office Public License (redundant with MPL 1.1)</P>
<P>- Eiffel Forum License V2.0 (redundant with BSD)</P>
<P>- Fair License (redundant with BSD)</P>
<P>- Historical Permission Notice and Disclaimer (redundant with BSD)</P>
<P>- Lucent Public License Version 1.02 (redundant with CPL)</P>
<P>- University of Illinois/NCSA Open Source License (redundant with BSD)</P>
<P>- X.Net License (redundant with MIT)</P>
<P>Non-reusable licenses (24)</P>
<P>- Apple Public Source License</P>
<P>- Computer Associates Trusted Open Source License 1.1</P>
<P>- EU DataGrid Software License</P>
<P>- Entessa Public License</P>
<P>- Frameworx License</P>
<P>- IBM Public License</P>
<P>- Motosoto License</P>
<P>- Naumen Public License</P>
<P>- Nethack General Public License</P>
<P>- Nokia Open Source License</P>
<P>- OCLC Research Public License 2.0</P>
<P>- PHP License</P>
<P>- Python license (CNRI Python License)</P>
<P>- Python Software Foundation License</P>
<P>- RealNetworks Public Source License V1.0</P>
<P>- Reciprocal Public License</P>
<P>- Ricoh Source Code Public License</P>
<P>- Sleepycat License</P>
<P>- Sun Public License</P>
<P>- Sybase Open Watcom Public License 1.0</P>
<P>- Vovida Software License v. 1.0</P>
<P>- W3C License</P>
<P>- wxWindows Library License</P>
<P>- Zope Public License </P>
<P>Other/Miscellaneous licenses (5)</P>
<P>- Adaptive Public License</P>
<P>- Artistic License</P>
<P>- Open Software License</P>
<P>- Qt Public License</P>
<P>- zlib/libpng license</P>
<P>Superseded licenses (4)</P>
<P>- Apache Software License v1.1</P>
<P>- Eiffel 1.0</P>
<P>- Lucent 1.0</P>
<P>- MPL 1.0</P>
<P>Licenses that have been voluntarily retired (5)</P>
<P>- Historical Permission Notice and Disclaimer</P>
<P>- Intel Open Source License</P>
<P>- Jabber Open Source License</P>
<P>- MITRE Collaborative Virtual Workspace License</P>
<P>- Sun Industry Standards Source License (SISSL)</P>
<P>--------------------------------</P>
<P></P>
<P>Here are our criteria for placing licenses in the various groups:</P>
<P>Licenses that are popular and widely used or with strong communities 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.</P>
<P>Special purpose licenses</P>
<P>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.</P>
<P>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.</P>
<P>Non-reusable licenses</P>
<P>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.</P>
<P>Superseded licenses</P>
<P>Licenses in this category have been superseded by newer versions</P>
<P>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.</P>
<P>Other/Miscellaneous licenses </P>
<P>These licenses do not fall neatly into any category.</P>
<P>5. What's next?</P>
<P>This is a draft document. We have already advised the stewards of the
licenses of the contents of this document. We have promised to put the groups up
for public comment, possibly on the open source email list or the license
proliferation discuss email list.</P>
<P>After that, the Board needs to decide on a process for newly approved
licenses to be placed in a group at the same time they are approved, so that
grouping can be helpful to new licensors in the
future.</P></FONT></DIV></DIV>
<DIV>
<HR>
</DIV>
<DIV>
<FONT FACE="Tahoma" COLOR="silver" SIZE="2">IRS Circular 230 Disclosure: To ensure compliance with requirements imposed by the IRS, we inform you that any U.S. federal tax advice in this communication (including attachments) is not intended or written by Fenwick & West LLP to be used, and cannot be used, for the purpose of (i) avoiding penalties under the Internal Revenue Code or (ii) promoting, marketing, or recommending to another party any transaction or matter addressed herein.</FONT>
</DIV>
<DIV>
<FONT FACE="Tahoma" COLOR="silver" SIZE="1">
<HR>
ATTENTION:<BR>The information contained in this message may be legally privileged and confidential. It is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited.</FONT>
</DIV>
<DIV>
<FONT COLOR="silver">
</FONT>
<FONT FACE="Tahoma" SIZE="1"> </FONT>
</DIV>
<DIV>
<FONT FACE="Tahoma" COLOR="silver" SIZE="1">If you have received this message in error, please immediately notify the sender and/or Fenwick & West LLP by telephone at (650) 988-8500 and delete or destroy any copy of this message.</FONT>
</DIV></BODY></HTML>