Modifying existing licenses in minor ways

Mitchell Baker mitchell at mozilla.org
Tue Nov 28 22:36:53 UTC 2000


The MPL is due for a revision before long.  I'd like to make the revised 
version as neutral as possible for just this reason.

mitchell

kmself at ix.netcom.com wrote:

> 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.
> 




More information about the License-discuss mailing list