Modifying existing licenses in minor ways

[kmself at ix.netcom.com]

on Tue, Nov 28, 2000 at 02:36:53PM -0800, Mitchell Baker (mitchell at mozilla.org) wrote:
> 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.

> 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

I don't see how you're going to get around the fundamental issues of
versioning authority and jurisdiction, though the reserved names could
be offloaded to an appendix.

The idea of a MozPL licensing authority has certain attractions.  It's
been part of my argument with Larry Rosen WRT the Jabber License.  While
I agree with him in being able to move beyond the current state of art
in licensing, rather than being stuck with static terms dictated by
another party, I still have very strong misgivings over license
proliferation.

Fortunately, the practice appears to be fading somewhat, and projects
which have adopted distinctive licenses are either fading or adopting
one of the emergent standards (GPL, BSD/MIT, or MozPL).

-- 
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/b4c2b6b4/attachment.sig>