Modifying existing licenses in minor ways

kmself at ix.netcom.com kmself at ix.netcom.com
Tue Nov 28 21:01:58 UTC 2000


on Tue, Nov 28, 2000 at 12:25:56PM -0800, Adam C. Engst (ace at xns.org) wrote:
> Hey folks,
> 
> A quick question. If you want to adopt an OSI-certified license to 
> avoid the proliferation of yet more open source licenses, how do you 
> deal with the fact that many of the open source licenses have 
> specific language that doesn't make sense if used by any product 
> other than what the license was generated to address?

This is an issue I've brought up with several parties, including
Mitchell Baker of Mozilla and Danise Cooper of Sun.  It's more of an
issue with copyleft-style licenses (particularly Mozilla) than with
BSD/MIT style, as the latter allows mingling of licenses.

My most recent suggestion, reiterated again, is this:

  - Draft a standard Mozilla-style license.  Lets call it SMozPL.
    Nobody uses it.

  - What people *do* use is their own Derived Mozilla Public License, a
    DMozPL.  This specifically restricts modifications to, say:

    Section 6.1, "New Versions"
    substitutions for "Netscape Communications Corporation", "Netscape",
    etc.

    Section 11, "Miscellaneous"
    Venue -- "California", "United States of America", "Northern
    District of California", "Santa Clara Count, California", etc.

    ...and any additional exhibits.

  - The common license provides that, for derived licenses limiting
    modifications to the specific substitutions specified, code is
    miscable between licenses.

What this does is allow for use of common licensing terms while
reserving to a particular organization the right to modify its terms
(and break compliance) at a later date.

Another option is to dual-license under some license, say MozPL, and the
GNU GPL and/or LGPL.  In this case, two MozPL-style licenses could share
code under the terms either of the "separate files" provisions of
MozPL-style licenses or the GPL.  The latter would, however, have the
effect of making downstream versions of the work essentially GPLd.

> For instance, in the Python license, item 1 starts "1. This LICENSE 
> AGREEMENT is between the Corporation for National Research 
> Initiatives...." How could anyone else use that license without 
> changing it, since CNRI wouldn't be involved in other products?

CNRI may not be particularly involved in Python at the present time
either, but that's another story.

Python has essentially a BSD-style license.  Provided no
incompatibilities were introduced (e.g.:  specific exclusion of works
covered under the Python license), a license replacing organizational
references should be compatible.

> Similarly, the Apache license says "The end-user documentation 
> included with the redistribution, if any, must include the following 
> acknowledgment: "This product includes software developed by the 
> Apache Software Foundation (http://www.apache.org/)."" But that makes 
> no sense if another product were to use the Apache license.

The new BSD license is more forgiving in this regard.

IANAL, this is not legal advice.

-- 
Karsten M. Self <kmself at ix.netcom.com>     http://www.netcom.com/~kmself
 Evangelist, Zelerate, Inc.                      http://www.zelerate.org
  What part of "Gestalt" don't you understand?      There is no K5 cabal
   http://gestalt-system.sourceforge.net/        http://www.kuro5hin.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20001128/45290a14/attachment.sig>


More information about the License-discuss mailing list