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
[EMAIL PROTECTED] wrote:
> on Tue, Nov 28, 2000 at 12:25:56PM -0800, Adam C. Engst ([EMAIL PROTECTED]) 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.
>