On Thu, 12 Jan 2012 14:19:00 +0000 Gervase Markham wrote:
> On 05/01/12 23:16, Francesco Poli wrote:
> > Clause 1.5(b) fails to solve existing compatibility headaches.
> >
> > It disables the default (L)GPL compatibility (caused by clause 3.3) for
> > those works that were previously incompatible because they were only
> > licensed under the MPL v1.1 (or earlier). This means that any existing
> > compatibility headache stays unfixed, unfortunately.
>
> As you can imagine; this was an intentional choice. Some people chose
> the MPL because it was GPL-incompatible; pulling the rug from under them
> would have been an unreasonable move.
Fair enough.
Nonetheless, all the existing GPL-incompatibilities due to the MPL
v1.1, including the *unintentional* ones, won't be solved, except for
the cases where the copyright holders may be tracked down, and convinced
to explicitly enable the compatibility: they may be unreachable or they
may simply not care enough to actively take action.
I mean: for all the existing GPL-incompatibilities, the situation is
not incredibly better than before, when the issue could already be
cured through an active action by the copyright holders
(dual-licensing).
[...]
> > Clause 2.3 limits the patent license grant when Covered Software is
> > modified. This may create troubles (legal uncertainty) for people
> > willing to modify the work (see DFSG#3).
>
> No-one is going to offer to license any and every applicable patent they
> own relating to a work which can be arbitrarily modified. Otherwise,
> it's effectively giving a licence to everyone for every patent you own,
> because any software can be incrementally transformed into any other
> software.
That's a reasonable and convincing explanation.
Unfortunately, the clause does not include some additional words to
clarify this rationale. As a consequence, some people willing to modify
an MPL-licensed work could feel legal uncertainty and be scared away...
That's basically what I meant, when talking about legal uncertainty.
>
> > If I understand correctly, accompanying the Executable with the Source
> > Code is considered an acceptable way to satisfy clause 3.2(a). Also, if
> > someone offers access to the Executable Form from a place, then
> > offering equivalent access to Source Code from the same place (at a
> > further charge no more than the cost of distribution) is considered
> > another acceptable way to satisfy this clause.
>
> Both of those are corect, although in the second case, it would be wise
> to include a notice in the executable form about where the download
> location is.
Thanks a lot for confirming!
>
> > Clause 3.2(b) allows to sublicense the Executable Form under different
> > terms, while the corresponding Source Code must remain available under
> > the terms of the MPL. This is very confusing, IMHO: having Source Code
> > and Executable forms under different licenses makes things unclear for
> > the recipients.
>
> This is inherent in the idea of a copyleft licence which does not
> necessarily cover all the code in an Executable Form. LGPLv3 section 4
> does the same for the LGPL ("You may convey a Combined Work under terms
> of your choice...").
I am not sure that this is exactly the same as in the GNU LGPL.
The LGPL seems to only give this permission for Combined Works, while
the MPL seems to allow sublicensing even for the Executable Form of an
unmodified MPL-licensed Source Code...
>
> > This clause states that any law or regulation doing something shall not
> > apply to this License: how can this be enforceable? can I write a
> > license that "disables" laws, by simply stating that they do not
> > apply?!?
>
> You can do that for laws which allow it to be done. The method of
> resolving license ambiguities is a default rule, but can be changed by
> the contract itself.
OK.
[...]
> It is effectively a protection for the Contributor, who might otherwise
> be stuck with a problem caused by Mozilla's inability to write clear
> English.
Yes, but it may be a problem for the licensee, which, as far as I
understand Free Software, should be the ultimate target of "protection".
>
> > Warning for people thinking to license their own works under the terms
> > of the MPL: you have to really trust the Mozilla Foundation to always
> > get things right, if you decide to license anything under the MPL!
>
> As with the FSF and the GPL (if you use "or later").
The key difference is that, with the GPL, you may avoid using the "or
later" mechanism.
I have done so myself in many cases, since I prefer the GNU GPL v2 over
the broken-copyleft of the GNU GPL v3 and I no longer trust the FSF to
always publish good licenses (there are too many past examples of bad
licenses published by the FSF: any version of the GFDL, AfferoGPL v3,
Verbatim Copying License, ...).
With the MPL the "or later" mechanism is active by default and cannot
be disabled.
[...]
> > It's good that this is permitted, but it should have been strongly
> > discouraged!
>
> It has been:
> http://www-stage.mozilla.org/MPL/2.0/FAQ.html#making-my-own-license
That's good, but I would have put at least one word *into* the license
text.
Too few people read license texts, but I am afraid that not many more
read the FAQs... :-(
--
http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
New GnuPG key, see the transition document!
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
Attachment:
pgpIWDunr0uSY.pgp
Description: PGP signature