Ben Bucksch wrote:
>> Modifying the MPL itself would have taken more time and effort
>
>
> There is no support in the FAQ for this claim.
Allow me to expand on what I wrote in the FAQ. (Most of what I'm going
to write here is just my personal opinions and not necessarily something
that other mozilla.org staff would agree with, which is why I didn't
include these comments in the FAQ itself.)
On the subject of GPL incompatibility, I strongly believe that it is
impossible (not difficult, impossible) to create a non-GPL copyleft
license that the FSF would endorse as GPL compatible, without including
clauses that make the license terms essentially equivalent to the GPL
and/or allowing the license terms to be converted to the GPL proper.
Note that in
http://www.fsf.org/licenses/license-list.html#GPLCompatibleLicenses
the only GPL-compatible copyleft licenses are the GPL, the LGPL,
GPL-based licenses like the Guile license, and dual licenses allowing
the GPL as one particular option. All the non-FSF copyleft licenses are
listed as GPL-incompatible
http://www.fsf.org/licenses/license-list.html#GPLIncompatibleLicenses
including the MPL and MPL variants, the Jabber Open Source License, and
the Sun Industry Standard Source License. Coincidence? I think not.
To repeat what I've written before: License "incompatibility" in
practice isn't something you can decide like it's a question in formal
logic, and it doesn't even mean that a court has ruled one way or
another; it simply means that the FSF says a particular license is
"incompatible". This means little to courts or lawyers (professionals or
amateurs), but a great deal to the many developers who favor use of the
GPL and take their guidance on the GPL from the FSF.
Partly this (IMO) impossibility of creating non-GPL GPL-compatible
copyleft licenses is because whenever you have two licenses that both
explicitly attempt to dictate what license terms must be (or can be)
used for derivative works (which is what a copyleft license does), it's
very easy to find contradictions and conflicts when you attempt to
combine code under both licenses in a single work.
And partly this impossibility is simply because the FSF is strongly
motivated to discourage the use of copyleft licenses that they
themselves do not create or control, to the point of nitpicking on
certain license provisions deemed to be "restrictions over and beyond
the GPL", and even to the point of being sometimes vague and unspecific
in their public statements as to why a particular non-FSF license is
incompatible. (For example, that the MPL "has some complex restrictions
that make it incompatible with the GNU GPL.")
So when I say "modifying the MPL itself would have taken more time and
effort" I am _not_ talking about simply removing things like
jurisdiction clauses. I am talking about having to introduce into the
MPL itself (and not simply as a dual license option) explicit
recognition of the GPL and explicit conversion to GPL terms -- basically
replicating within the MPL itself what the FSF did with the LGPL.
This would have occasioned responding to and addressing (where possible)
all the objections raised to the MPL/GPL/LGPL tri-license scheme, _plus_
the additional work of actually doing a new MPL revision, _plus_ dealing
with any other MPL "bug fixes" people might want to make at the same
time. Hence my belief that it would have taken longer.
>> the Mozilla project (like other projects) was already making use of a
>> multiple license scheme without apparent problems.
>
>
> There obviously are problems with some people who don't like the GPL.
> Those probably just didn't happen to contribute to NSPR or JS.
My point in writing the above sentence was simply to emphasize that most
(not all, most) people and companies involved with Mozilla seem to have
little or no objection to the dual licensing scheme used for some time
now for some parts of Mozilla, no one appears to have gotten in any sort
of legal trouble over it, and no one (to my knowledge) has gone off to
try and promote GPL-only forks of the dual-licensed code.
>> Changing the MPL would also have potentially affected developers who
>> had adopted the MPL for use with their own code, independently of the
>> Mozilla project. If those developers did not like the new MPL changes
>> then they would have to explicitly use an older version of the MPL, or
>> create their own MPL-based license.
>
>
> We can't know, if other projects would object, if we don't know, which
> terms are those. I don't think, any project would object the removal of
> the jurisdiction clause. In fact, it will probably help some (OpenH323
> for example).
As I said above, I think changing the MPL to be GPL-compatible (to the
satisfaction of the FSF) would require either changing it to be a
non-copyleft license or changing it to be like the LGPL in explicitly
providing for conversion of MPL terms to GPL terms, within the license
itself. And I'm sure anyone objecting to the tri-license scheme would
object to this latter change, and would prefer the current MPL 1.1 or
something close to it.
>> Finally, changing the MPL would have required re-submitting it to the
>> Open Source Initiative <http://www.opensource.org/> for certification
>> in connection with the Open Source Definition
>> <http://www.opensource.org/docs/definition.html> , another potentially
>> time-consuming process.
>
>
> That's bogus. The mail I quoted also says that FSF and OSI were quick to
> respond on the new Python license.
I'll partially grant your point here. I think there would be some delay,
but the OSI would probably give a revised MPL priority in consideration.
I threw this point in to bolster my case, not as the main argument.
And note that a) I did say "_potentially_ time-consuming", not
"time-consuming"; and b) even a small delay in getting certification
would be a delay not incurred with the tri-license scheme, and thus
supports my earlier statement about an MPL change taking "more time and
effort".
I do try to word these FAQs very carefully, you know :-)
Frank
--
Frank Hecker
[EMAIL PROTECTED]
