MPL Beta 2 released
Luis Villa
I'm happy to announce that we have released MPL 2 Beta 2- hopefully
our final beta. The text of the beta is here:
http://mpl.mozilla.org/wp-content/uploads/2011/03/MPL-2-B2.pdf
There are only a small number of changes here from Beta 1, but one of
these changes is particularly significant.
Specifically, in this Beta, GPL compatibility changes from opt-in to
opt-out; in other words, the default is that MPL is now GPL
compatible. This has required a change in mechanics; users upgrading
from MPL 1.1 are asked to add an additional license header if the
original code is distributed solely under the MPL 1.1 and not under a
dual-or-tri-license. We have tried to mitigate the impact of the
change for projects which use only MPL 1.1 by including this upgrade
mechanism, but we would be interested to hear from any and all comers
on this subject- does the mechanism make sense? Does it make anyone
uncomfortable? We recognize this is a potentially significant policy
change, and we're open to reverting it if people are bothered by it.
On the flip side, anyone who strongly appreciates this change, we'd be
happy to hear from you too ;) Please feel free to respond here, in
private to me at this address or vil...@gtlaw.com, or just schedule a
call with me.
An annotated version showing this change (along with a handful of
others) is here:
http://mpl.mozilla.org/wp-content/uploads/2011/03/MPL-B1-to-B2.pdf
On a slightly lighter vein, I've also published a "FAQified" version
of the license, which attempts to make the license easier to read by
changing the traditional legal section headers to questions. The
actual license text is unmodified. This is purely experimental, and
not something we're sure we would ever formally release, but we are
curious about the feedback of non-lawyers. The text is here:
http://mpl.mozilla.org/wp-content/uploads/2011/03/MPL-as-FAQ-B2.pdf
Unlike previous releases, because the change is so small, I've
preserved the comments in the commenting tool; please continue to
leave comments, as we'll try to address all the remaining ones before
the RC.
All the links above, as well as text/html versions, and links to the
comment tool, are here:
http://mpl.mozilla.org/participate/beta
Thanks-
Luis
Gervase Markham
> Specifically, in this Beta, GPL compatibility changes from opt-in to
> opt-out; in other words, the default is that MPL is now GPL
> compatible. This has required a change in mechanics; users upgrading
> from MPL 1.1 are asked to add an additional license header if the
> original code is distributed solely under the MPL 1.1 and not under a
> dual-or-tri-license. We have tried to mitigate the impact of the
> change for projects which use only MPL 1.1 by including this upgrade
> mechanism, but we would be interested to hear from any and all comers
> on this subject- does the mechanism make sense? Does it make anyone
> uncomfortable? We recognize this is a potentially significant policy
> change, and we're open to reverting it if people are bothered by it.
> On the flip side, anyone who strongly appreciates this change, we'd be
> happy to hear from you too ;)
Thank you for that invitation :-) I was someone who argued strongly for
this change, and I'm very pleased to see it in the latest draft.
It is worth clarifying some important points here:
1) This does not allow someone to make MPL 1.1-only code GPL compatible
by upgrading it to MPL 2. If the code was originally MPL 1.1-only,
anyone distributing it under MPL 2 has to add the "Incompatible
Software" notice.
This means that people who chose MPL 1.1 specifically because it was
GPL-incompatible _will_ have their wishes respected.
2) However, tri-licensed code, i.e. code which is already under the LGPL
and GPL, can be converted to "Compatible" (i.e. standard) MPL 2, which
allows us to meet our licensing and boilerplate simplification goals.
3) "Compatible by default" leads to the enormous advantage that the
default text of the latest versions of all of the major free software
licenses are now upwardly compatible with each other - that is, you can
include code under any of them in projects under any of those further to
the right in this diagram:
MIT -> BSD -> Apache 2 -> MPL 2 -> LGPL 3 -> GPL 3 -> AGPL 3.
I think this is an _awesome_ thing for free software community
code-sharing, co-operation and license compatibility. It should mean far
fewer licensing headaches for people.
In 10 years time, I think we will be very glad we chose "compatible by
default".
Gerv
Gervase Markham
> our final beta. The text of the beta is here:
> http://mpl.mozilla.org/wp-content/uploads/2011/03/MPL-2-B2.pdf
>
> There are only a small number of changes here from Beta 1
One of those changes is the move of the text about the effective date
into section 2.1. I would like to oppose that change; I think it makes
the license harder to read, and it's a very confusing place to start.
(This confusingness is particularly obvious, incidentally, in your
FAQ-ified version.) When it talks about "the licenses granted in section
2.2", it is talking about something of which a first-time reader of the
license knows nothing. This clause makes far more sense at the end of
section 2 IMO.
Gerv
Michael Kay
> Specifically, in this Beta, GPL compatibility changes from opt-in to
> opt-out; in other words, the default is that MPL is now GPL
> compatible.
This is a really bad change from my point of view.
My users are scared stiff that the license under which I issue software
will be "viral"; they don't want to touch my software if there's any
danger of that. I know this license isn't viral, but I know it's going
to be hard to persuade some of my users of this - many of them appear to
employ lawyers who can't read.
The term "Incompatible Software" is unfortunate. Most people reading the
source code and seeing this phrase won't know that the MPL gives a
special and non-obvious meaning to the term. It just looks negative.
Could we change Exhibit B to "This Source Code may not be distributed
under any Secondary License"?
And it seems that under 10.4 I am obliged to add this statement to all
modules that I have "received". I don't know what that means. There are
many modules that I wrote, but which have received subsequent
contributions (sometimes very small ones) from others. Logically, on the
(not unreasonable) assumption that the contributors licensed this code
to me under MPL 1.1, these should be treated as if I "received" the
whole module. And it doesn't seem to match the wording in 1.5(b): the
modules "which were made available" are not the same as the modules
"which were received". It would make more sense if 1.5(b) said "which
You received, or which contain contributions which you received, under
the terms of...".
Finally, 3.1 "All distribution of Covered Software in Source Code form,
including any Modi cations that You create or to which You contribute,
must be under the terms of this License." seems odd. It's not clear whom
it applies to - surely it should say what "You" can and can't do. It's
not clear to what extent it binds someone who chooses to distribute
under a secondary license, or the end user who receives the code under a
secondary license. It also appears to rule out the user having access to
the same code under a different license unrelated to MPL, or to say that
this license constrains them from doing something even if they have
another license that permits it - which of course is logically
impossible, because a license cannot stop people doing something they
would be able to do in the absence of the license.
Michael Kay
Saxonica
Robert Kaiser
> Specifically, in this Beta, GPL compatibility changes from opt-in to
> opt-out; in other words, the default is that MPL is now GPL
> compatible.
I find that a very good change and welcome that MPL tries to make the
code available for the widest possible use (prohibiting that other, more
strictly licenses FLOSS projects can use the code is always a bad idea
in my eyes) - and IIRC now even with a way that we get the possibility
to re-integrate changes back to MPL code!
For me, this is a very welcome clause to make borders between
differently licensed FLOSS projects easier to pass (and makes me laugh
even harder at that comment I once read about "the CDDL basically being
the MPL 2").
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community needs answers to. And most of the time,
I even appreciate irony and fun! :)
Gervase Markham
> My users are scared stiff that the license under which I issue software
> will be "viral"; they don't want to touch my software if there's any
> danger of that. I know this license isn't viral, but I know it's going
> to be hard to persuade some of my users of this - many of them appear to
> employ lawyers who can't read.
It is difficult to write licenses which make people who don't read them
happy :-)
> The term "Incompatible Software" is unfortunate. Most people reading the
> source code and seeing this phrase won't know that the MPL gives a
> special and non-obvious meaning to the term. It just looks negative.
> Could we change Exhibit B to "This Source Code may not be distributed
> under any Secondary License"?
I think that's a reasonable point, but I'm not entirely sure what the
fix is. Perhaps changing Exhibit B improves things, but we still need a
Capitalized Term to describe software which is not so distributable. And
I can't think immediately of a better one. Ideas?
> And it seems that under 10.4 I am obliged to add this statement to all
> modules that I have "received". I don't know what that means. There are
> many modules that I wrote, but which have received subsequent
> contributions (sometimes very small ones) from others. Logically, on the
> (not unreasonable) assumption that the contributors licensed this code
> to me under MPL 1.1, these should be treated as if I "received" the
> whole module. And it doesn't seem to match the wording in 1.5(b): the
> modules "which were made available" are not the same as the modules
> "which were received". It would make more sense if 1.5(b) said "which
> You received, or which contain contributions which you received, under
> the terms of...".
I think you have misunderstood; but perhaps that means we need to make
it clearer :-)
The idea is that if you receive software under MPL 1.1, and want to
distribute it under MPL 2, you have to add the Incompatibility notice.
If you continue to distribute under MPL 1.1, as if MPL 2 didn't exist,
you don't have to do anything.
Receiving software means precisely that - software other people have
given you. Your confusion, I think, is that you think this means you
need to do something even if you then redistribute the software under
1.1, not 2. Is that right?
> Finally, 3.1 "All distribution of Covered Software in Source Code form,
> including any Modi cations that You create or to which You contribute,
> must be under the terms of this License." seems odd. It's not clear whom
> it applies to - surely it should say what "You" can and can't do.
Not just "You". The default for copyright law is that you can't
distribute without the copyright holder's permission. So this is the
clause which gives someone - anyone - that permission to distribute - as
long as it's under the terms of the license.
I guess it could say "All distribution performed by You of Covered
Software...".
> It's
> not clear to what extent it binds someone who chooses to distribute
> under a secondary license, or the end user who receives the code under a
> secondary license.
The sections about secondary licensing should make that clear.
> It also appears to rule out the user having access to
> the same code under a different license unrelated to MPL, or to say that
> this license constrains them from doing something even if they have
> another license that permits it - which of course is logically
> impossible, because a license cannot stop people doing something they
> would be able to do in the absence of the license.
I don't think it does. (And if it does, this problem is a problem with a
large number of licenses which say this sort of thing!) If the copy of
the code you have is under the MPL, you have to distribute it under the
MPL. If you have another copy of exactly the same code under different
terms, those different terms apply.
Gerv
Michael Kay
>
> The idea is that if you receive software under MPL 1.1, and want to
> distribute it under MPL 2, you have to add the Incompatibility notice.
> If you continue to distribute under MPL 1.1, as if MPL 2 didn't exist,
> you don't have to do anything.
>
I'd like to distribute under a license that allows people to mix my code
with code issued under any other open source license, without the
license that I use being in any way viral. I was hoping that the new
MPL, combined with the provision in previous MPL versions that I could
release under any later MPL version, would allow me to do that. It looks
as if this is not the case; about 5% of my code comes from other
contributors who in some cases are untraceable, and it looks as if I
can't migrate this code to a GPL-compatible license without adding the
Incompatibility notice to the affected modules, which in effect makes
the whole product GPL-incompatible. That's a shame.
But hold on... The new license can't constrain what I'm permitted to do
under the terms of the old license. The old license permits me to
reissue my contributors' code under any new version of the MPL. If this
is a new version of the MPL, then I can use it, even if the new version
says I can't. Odd.
[Incidentally, there is zero risk that any of my contributors will
object to anything I decide to do. My only problem is persuading my
users, some of whom employ lots of lawyers, that there is a zero risk.
Sometimes I'm prepared to tell such users that they don't have to use my
software if they don't like it... But not always.]
Michael Kay
Saxonica
Luis Villa
>
>>
>> The idea is that if you receive software under MPL 1.1, and want to
>> distribute it under MPL 2, you have to add the Incompatibility notice. If
>> you continue to distribute under MPL 1.1, as if MPL 2 didn't exist, you
>> don't have to do anything.
>>
I'd add that MPL-only projects that are particularly concerned about
this could theoretically add the MPL 2 "incompatible" language on
their own, so that they could be absolutely sure, though obviously
this is not ideal.
> I'd like to distribute under a license that allows people to mix my code
> with code issued under any other open source license, without the license
> that I use being in any way viral. I was hoping that the new MPL, combined
> with the provision in previous MPL versions that I could release under any
> later MPL version, would allow me to do that. It looks as if this is not the
> case; about 5% of my code comes from other contributors who in some cases
> are untraceable, and it looks as if I can't migrate this code to a
> GPL-compatible license without adding the Incompatibility notice to the
> affected modules, which in effect makes the whole product GPL-incompatible.
> That's a shame.
If that's your goal, yeah, that is unfortunate. We've been trying very
hard to balance between the goals of folks who deliberately chose to
be incompatible, and the goals of folks who would like to be
compatible. This mechanism is the best route we've come up with so far
for that, but I think we'd all admit is imperfect.
> But hold on... The new license can't constrain what I'm permitted to do
> under the terms of the old license. The old license permits me to reissue my
> contributors' code under any new version of the MPL. If this is a new
> version of the MPL, then I can use it, even if the new version says I can't.
> Odd.
We were, frankly, trying to prevent this kind of thing, specifically
to protect original authors whose intent was to avoid GPL
compatibility. I agree that it is odd, though, given what we said in
MPL 1.1.
> [ ... My only problem is persuading my users, some of
> whom employ lots of lawyers, that there is a zero risk. Sometimes I'm
> prepared to tell such users that they don't have to use my software if they
> don't like it... But not always.]
The mechanics of the upgrade process are slightly awkward, but if
there are any concerns about risk once the process is complete (from
anyone on this list) please do share- we've worked really hard to
define this compatibility in a very concise and constrained way
specifically so that it can be very low-risk for MPL users while still
productive and constructive for the GPL-using community. It would have
taken a lot less work if we were able to tolerate more risk ;)
Luis (will go back and read Gerv's opus later tonight, but wanted to
get these few points out there on the table.)
Luis Villa
> On 29/03/11 15:41, Michael Kay wrote:
>>
>> will be "viral"; they don't want to touch my software if there's any
>> danger of that. I know this license isn't viral, but I know it's going
>> to be hard to persuade some of my users of this - many of them appear to
>> employ lawyers who can't read.
>
> happy :-)
But there are things we can do to help that process along anyway. Most
notably, we know we need to write good FAQ entries on this point, and
my earlier email about FAQ questions still stands. I will note this
question about risk/"viral" GPL compatibility and make sure we address
it.
The general form of the answer will be along the lines "We're only
compatible with the GPL if you need it, because you're combining with
existing GPL code. If you don't need the GPL, because (for example)
you're using MPL with proprietary code, you won't get GPL- you get the
long-trusted MPL."
>> The term "Incompatible Software" is unfortunate. Most people reading the
>> source code and seeing this phrase won't know that the MPL gives a
>> special and non-obvious meaning to the term. It just looks negative.
>> Could we change Exhibit B to "This Source Code may not be distributed
>> under any Secondary License"?
>
> I think that's a reasonable point, but I'm not entirely sure what the fix
> is. Perhaps changing Exhibit B improves things, but we still need a
> Capitalized Term to describe software which is not so distributable. And I
> can't think immediately of a better one. Ideas?
Definitely open to suggestions. I don't like it either, but like Gerv
said, it was hard to think of a better one that was still concise.
>> And it seems that under 10.4 I am obliged to add this statement to all
>> modules that I have "received". I don't know what that means. There are
>> many modules that I wrote, but which have received subsequent
>> contributions (sometimes very small ones) from others. Logically, on the
>> (not unreasonable) assumption that the contributors licensed this code
>> to me under MPL 1.1, these should be treated as if I "received" the
>> whole module. And it doesn't seem to match the wording in 1.5(b): the
>> modules "which were made available" are not the same as the modules
>> "which were received". It would make more sense if 1.5(b) said "which
>> You received, or which contain contributions which you received, under
>> the terms of...".
>
> I think you have misunderstood; but perhaps that means we need to make it
> clearer :-)
>
> The idea is that if you receive software under MPL 1.1, and want to
> distribute it under MPL 2, you have to add the Incompatibility notice. If
> you continue to distribute under MPL 1.1, as if MPL 2 didn't exist, you
> don't have to do anything.
Right.
It might be more clear if the order of the clauses were reversed;
something like "You must attach the notice described in Exhibit B of
this License before You distribute Incompatible Software (as defined
in Section 1.5(b)) that you have received from others."
>> Finally, 3.1 "All distribution of Covered Software in Source Code form,
>> including any Modi cations that You create or to which You contribute,
>> must be under the terms of this License." seems odd. It's not clear whom
>> it applies to - surely it should say what "You" can and can't do.
>
> Not just "You". The default for copyright law is that you can't distribute
> without the copyright holder's permission. So this is the clause which gives
> someone - anyone - that permission to distribute - as long as it's under the
> terms of the license.
We've had this language since Alpha 1 so I'm very reluctant to change
it now without very strong reason.
>> It's
>> not clear to what extent it binds someone who chooses to distribute
>> under a secondary license, or the end user who receives the code under a
>> secondary license.
>
> The sections about secondary licensing should make that clear.
>
>> It also appears to rule out the user having access to
>> the same code under a different license unrelated to MPL, or to say that
>> this license constrains them from doing something even if they have
>> another license that permits it - which of course is logically
>> impossible, because a license cannot stop people doing something they
>> would be able to do in the absence of the license.
>
> I don't think it does. (And if it does, this problem is a problem with a
> large number of licenses which say this sort of thing!) If the copy of the
> code you have is under the MPL, you have to distribute it under the MPL. If
> you have another copy of exactly the same code under different terms, those
> different terms apply.
Yup.
Hope this helps clear things up a bit, Mike, but let's keep the
conversation going- I really appreciate your feedback (especially
since so much other feedback has been fairly quiet ;)
Luis
Andy Dufilie
> On 29/03/11 15:41, Michael Kay wrote:
> > The term "Incompatible Software" is unfortunate. Most people reading the
> > source code and seeing this phrase won't know that the MPL gives a
> > special and non-obvious meaning to the term. It just looks negative.
> > Could we change Exhibit B to "This Source Code may not be distributed
> > under any Secondary License"?
> I think that's a reasonable point, but I'm not entirely sure what the
> fix is. Perhaps changing Exhibit B improves things, but we still need a
> Capitalized Term to describe software which is not so distributable. And
> I can't think immediately of a better one. Ideas?
The problem described above boils down to the use of a specially defined term in a document separate from where it is defined. I suggest that the solution is not to use different specially defined terms, but to eliminate them completely. Why not change Exhibit B so that it uses the definitions of the terms rather than the terms themselves?
Here's a first attempt:
This source code is incompatible with any version of the GNU General Public License, the GNU Lesser General Public License, or the GNU Affero General Public License.
Andy Dufilie
> > The term "Incompatible Software" is unfortunate. Most people reading the
> > source code and seeing this phrase won't know that the MPL gives a
> > special and non-obvious meaning to the term. It just looks negative.
> > Could we change Exhibit B to "This Source Code may not be distributed
> > under any Secondary License"?
> I think that's a reasonable point, but I'm not entirely sure what the
> fix is. Perhaps changing Exhibit B improves things, but we still need a
> Capitalized Term to describe software which is not so distributable. And
> I can't think immediately of a better one. Ideas?
The problem described above boils down to the use of a specially defined term in a document separate from where it is defined. I suggest that the solution is not to use different specially defined terms, but to eliminate them completely. Why not change Exhibit B so that it uses the definitions of the terms rather than the terms themselves?
Luis Villa
> On Tuesday, March 29, 2011 11:12:32 AM UTC-4, Gervase Markham wrote:
>> > The term "Incompatible Software" is unfortunate. Most people reading the
>> > source code and seeing this phrase won't know that the MPL gives a
>> > special and non-obvious meaning to the term. It just looks negative.
>> > Could we change Exhibit B to "This Source Code may not be distributed
>> > under any Secondary License"?
>> I think that's a reasonable point, but I'm not entirely sure what the
>> fix is. Perhaps changing Exhibit B improves things, but we still need a
>> Capitalized Term to describe software which is not so distributable. And
>> I can't think immediately of a better one. Ideas?
>
>
> Here's a first attempt:
>
> This source code is incompatible with any version of the GNU General Public License,
> the GNU Lesser General Public License, or the GNU Affero General Public License.
That is very lossy compression, and tempts people to refer to the
normal, dictionary definition of incompatible, which is not what we
have in mind here.
Luis
Gervase Markham
> Here's a first attempt:
>
> This source code is incompatible with any version of the GNU General
> Public License, the GNU Lesser General Public License, or the GNU
> Affero General Public License.
The trouble with this is that it breaks, or causes all sorts of
compatibility difficulties, if that list of licenses ever changes in a
future version of the MPL. We don't see an immediate need for that
(otherwise we'd have added whatever the extra license was already) but
it's a flexibility we want to retain. The license landscape may look
very different again in 10 years time.
(Also, we don't want to say "any version" - that's significantly looser
than the current definition.)
Gerv
Michael Kay
of the Mozilla Public License".
Michael Kay
Saxonica
On 06/04/2011 02:05, Gervase Markham wrote:
> On 02/04/11 05:28, Andy Dufilie wrote:
>> Here's a first attempt:
>>
>> This source code is incompatible with any version of the GNU General
>> Public License, the GNU Lesser General Public License, or the GNU
>> Affero General Public License.
>
> The trouble with this is that it breaks, or causes all sorts of
> compatibility difficulties, if that list of licenses ever changes in a
> future version of the MPL. We don't see an immediate need for that
> (otherwise we'd have added whatever the extra license was already) but
> it's a flexibility we want to retain. The license landscape may look
> very different again in 10 years time.
>
> (Also, we don't want to say "any version" - that's significantly
> looser than the current definition.)
>
> Gerv
>
> _______________________________________________
> governance-mpl-update mailing list
> governance...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/governance-mpl-update
>
enclair
licenses).
On Mar 29, 5:12 pm, Gervase Markham <g...@mozilla.org> wrote:
> The idea is that if you receive software under MPL 1.1, and want to
> distribute it under MPL 2, you have to add the Incompatibility notice.
I don't understand why.
Also, why someone who wants to be incompatible with the GNU licenses
doesn't stick with the MPL 1.1 or doesn't choose another license (CDDL
for example)?
David Illsley
> Hi, all-
>
> I'm happy to announce that we have released MPL 2 Beta 2- hopefully
> our final beta. The text of the beta is here:http://mpl.mozilla.org/wp-content/uploads/2011/03/MPL-2-B2.pdf
>
> There are only a small number of changes here from Beta 1, but one of
> these changes is particularly significant.
>
> Specifically, in this Beta, GPL compatibility changes from opt-in to
> opt-out; in other words, the default is that MPL is now GPL
> compatible. This has required a change in mechanics; users upgrading
> from MPL 1.1 are asked to add an additional license header if the
> original code is distributed solely under the MPL 1.1 and not under a
> dual-or-tri-license. We have tried to mitigate the impact of the
> change for projects which use only MPL 1.1 by including this upgrade
> mechanism, but we would be interested to hear from any and all comers
> on this subject- does the mechanism make sense? Does it make anyone
> uncomfortable? We recognize this is a potentially significant policy
> change, and we're open to reverting it if people are bothered by it.
> On the flip side, anyone who strongly appreciates this change, we'd be
> happy to hear from you too ;) Please feel free to respond here, in
> call with me.
>
> An annotated version showing this change (along with a handful of
> others) is here:http://mpl.mozilla.org/wp-content/uploads/2011/03/MPL-B1-to-B2.pdf
>
> On a slightly lighter vein, I've also published a "FAQified" version
> of the license, which attempts to make the license easier to read by
> changing the traditional legal section headers to questions. The
> actual license text is unmodified. This is purely experimental, and
> not something we're sure we would ever formally release, but we are
> curious about the feedback of non-lawyers. The text is here:http://mpl.mozilla.org/wp-content/uploads/2011/03/MPL-as-FAQ-B2.pdf
>
> Unlike previous releases, because the change is so small, I've
> preserved the comments in the commenting tool; please continue to
> leave comments, as we'll try to address all the remaining ones before
> the RC.
>
> All the links above, as well as text/html versions, and links to the
> comment tool, are here:
>
> http://mpl.mozilla.org/participate/beta
>
> Thanks-
> Luis
Perhaps unsurprisingly, my main questions are about GPL/FSF
compatibility.
- Does this license allow me to take an MPL 2.0 licensed file
(without incompatibility statement), tear off the MPL header and add a
GPLv2.0 one and distribute? (I'm assuming per 3.4, the answer here is
no).
- Does this license allow me to take some code from an MPL 2.0
licensed file (without incompatibility statement) and paste it into a
GPLv2.0 licensed file without mention of the MPL? (I'm assuming per
3.1, the answer here is no).
If these 2 assumptions are correct, then I don't see a reason for the
"Incompatible Software"* thing. I can see why if my assumptions are
incorrect that it's important...
If my assumptions are incorrect, then I'd suggest section 11 could be
clearer.
David
* "Incompatible Software" doesn't have its plain-english meaning..
even something as simple as"Secondary License Incompatible Software"
would be an improvement.
Gervase Markham
> Perhaps "This source code is GPL-incompatible, as defined in clause N.N
> of the Mozilla Public License".
Again, the list of licenses may not always just be a list of GPL-family
licenses.
Gerv
Gervase Markham
> I'm really happy with this change (the MPL compatible with the GNU
> licenses).
>
> On Mar 29, 5:12 pm, Gervase Markham<g...@mozilla.org> wrote:
>> The idea is that if you receive software under MPL 1.1, and want to
>> distribute it under MPL 2, you have to add the Incompatibility notice.
>
> I don't understand why.
Because some people who picked the MPL 1.1 only, made that choice
because they wanted a license that is incompatible with the GPL. If we
updated the license and made their code compatible with the GPL, they
might be upset.
> Also, why someone who wants to be incompatible with the GNU licenses
> doesn't stick with the MPL 1.1 or doesn't choose another license (CDDL
> for example)?
You can't "stick with the MPL 1.1" - the ability to upgrade to a later
version is written directly into the license. It's not an option you can
choose or not choose.
Gerv
Gervase Markham
> - Does this license allow me to take an MPL 2.0 licensed file
> (without incompatibility statement), tear off the MPL header and add a
> GPLv2.0 one and distribute? (I'm assuming per 3.4, the answer here is
> no).
No. You can add a GPLv2 header and distribute it under a dual license.
Then, someone who is not under your control or direction could, if they
choose, remove the MPL option and redistribute _again_ under the GPL
only. But you yourself, acting on your own, cannot remove the MPL-ness.
> - Does this license allow me to take some code from an MPL 2.0
> licensed file (without incompatibility statement) and paste it into a
> GPLv2.0 licensed file without mention of the MPL? (I'm assuming per
> 3.1, the answer here is no).
No, not without going through the full process above, including the
third party step.
> If these 2 assumptions are correct, then I don't see a reason for the
> "Incompatible Software"* thing. I can see why if my assumptions are
> incorrect that it's important...
The Incompatible Software stuff means that you can't go through any part
of the process in my first paragraph.
> * "Incompatible Software" doesn't have its plain-english meaning..
> even something as simple as"Secondary License Incompatible Software"
> would be an improvement.
This point has been noted; we are still trying to see if there is a
better option.
Gerv
David Illsley
> On 06/04/11 11:47, David Illsley wrote:
>
> > - Does this license allow me to take an MPL 2.0 licensed file
> > (without incompatibility statement), tear off the MPL header and add a
> > GPLv2.0 one and distribute? (I'm assuming per 3.4, the answer here is
> > no).
>
> No. You can add a GPLv2 header and distribute it under a dual license.
> Then, someone who is not under your control or direction could, if they
> choose, remove the MPL option and redistribute _again_ under the GPL
> only. But you yourself, acting on your own, cannot remove the MPL-ness.
>
> > - Does this license allow me to take some code from an MPL 2.0
> > licensed file (without incompatibility statement) and paste it into a
> > GPLv2.0 licensed file without mention of the MPL? (I'm assuming per
> > 3.1, the answer here is no).
>
> No, not without going through the full process above, including the
> third party step.
>
> > If these 2 assumptions are correct, then I don't see a reason for the
> > "Incompatible Software"* thing. I can see why if my assumptions are
> > incorrect that it's important...
>
> The Incompatible Software stuff means that you can't go through any part
> of the process in my first paragraph.
Thanks for the clarifications. For information, and FWIW, there
probably are situations where, given those answers, I'd consider the
'Incompatible Software' option to ensure that I could use all
derivative work under the terms of the MPL.
Cheers,
David
enclair
> Because some people who picked the MPL 1.1 only, made that choice
> because they wanted a license that is incompatible with the GPL. If we
> updated the license and made their code compatible with the GPL, they
> might be upset.
Ok, another related question.
I believe the MPL 1.1 was compatible with the LGPL, since one can
_link_ a LGPL software with almost anything.
Will it be still true with the MPL 2 + the "incompatible software"
statement?
Gervase Markham
> I believe the MPL 1.1 was compatible with the LGPL, since one can
> _link_ a LGPL software with almost anything.
> Will it be still true with the MPL 2 + the "incompatible software"
> statement?
This is a good point. Yes, it will. We will look at how we can change
language to avoid people thinking it won't.
Gerv
a.w....@gmail.com
> On 06/04/11 11:47, David Illsley wrote:
> > - Does this license allow me to take an MPL 2.0 licensed file
> > (without incompatibility statement), tear off the MPL header and add a
> > GPLv2.0 one and distribute? (I'm assuming per 3.4, the answer here is
> > no).
>
> No. You can add a GPLv2 header and distribute it under a dual license.
> Then, someone who is not under your control or direction could, if they
> choose, remove the MPL option and redistribute _again_ under the GPL
> only. But you yourself, acting on your own, cannot remove the MPL-ness.
>
> > - Does this license allow me to take some code from an MPL 2.0
> > licensed file (without incompatibility statement) and paste it into a
> > GPLv2.0 licensed file without mention of the MPL? (I'm assuming per
> > 3.1, the answer here is no).
>
> No, not without going through the full process above, including the
> third party step.
>
> > If these 2 assumptions are correct, then I don't see a reason for the
> > "Incompatible Software"* thing. I can see why if my assumptions are
> > incorrect that it's important...
>
> The Incompatible Software stuff means that you can't go through any part
> of the process in my first paragraph.
>
> Q: May I combine MPL-licensed code and GPL-licensed code in the same executable program?
> Yes, as long as the MPL-licensed code is not marked as “Incompatible Software”, and you comply with the requirements of Section 3.3.
This item of the FAQ, together with another reading of Section 3.3, seem to say that if I want to combine MPLed code with GPLed code, then I need to explicitly relicense first... Which is fine. How about the situation when I am writing an integration or bridge, between a MPL web application and a GPL web application, can I simply distribute the bridge under MPL 2.0 (without incompatibility clause), and thereby letting users to use all three on their sites?
It seems to me that the answer should be yes, the bridge is designed to run with both of them, using API calls, but I am not distributing anything else than MPL code which is GPL-compatible itself.
a.w....@gmail.com
> > - Does this license allow me to take an MPL 2.0 licensed file
> > (without incompatibility statement), tear off the MPL header and add a
> > GPLv2.0 one and distribute? (I'm assuming per 3.4, the answer here is
> > no).
>
> No. You can add a GPLv2 header and distribute it under a dual license.
> Then, someone who is not under your control or direction could, if they
> choose, remove the MPL option and redistribute _again_ under the GPL
> only. But you yourself, acting on your own, cannot remove the MPL-ness.
>
> > - Does this license allow me to take some code from an MPL 2.0
> > licensed file (without incompatibility statement) and paste it into a
> > GPLv2.0 licensed file without mention of the MPL? (I'm assuming per
> > 3.1, the answer here is no).
>
> No, not without going through the full process above, including the
> third party step.
>
> > If these 2 assumptions are correct, then I don't see a reason for the
> > "Incompatible Software"* thing. I can see why if my assumptions are
> > incorrect that it's important...
>
> The Incompatible Software stuff means that you can't go through any part
> of the process in my first paragraph.
>
Gervase Markham
> This item of the FAQ, together with another reading of Section 3.3,
> seem to say that if I want to combine MPLed code with GPLed code,
> then I need to explicitly relicense first... Which is fine.
myself:
>> No. You can add a GPLv2 header and distribute it under a dual
>> license. Then, someone who is not under your control or direction
>> could, if they choose, remove the MPL option and redistribute
>> _again_ under the GPL only. But you yourself, acting on your own,
>> cannot remove the MPL-ness.
> the situation when I am writing an integration or bridge, between a
> MPL web application and a GPL web application, can I simply
> distribute the bridge under MPL 2.0 (without incompatibility clause),
> and thereby letting users to use all three on their sites?
Gerv
a.w....@gmail.com
> On 08/12/11 12:37, a.w....@gmail.com wrote:
> > This item of the FAQ, together with another reading of Section 3.3,
> > seem to say that if I want to combine MPLed code with GPLed code,
> > then I need to explicitly relicense first... Which is fine.
>
> Er, no. See my earlier answer above. You can't tear the MPL off. Quoting
> myself:
>
> >> No. You can add a GPLv2 header and distribute it under a dual
> >> license. Then, someone who is not under your control or direction
> >> could, if they choose, remove the MPL option and redistribute
> >> _again_ under the GPL only. But you yourself, acting on your own,
> >> cannot remove the MPL-ness.
>
> > How about
> > the situation when I am writing an integration or bridge, between a
> > MPL web application and a GPL web application, can I simply
> > distribute the bridge under MPL 2.0 (without incompatibility clause),
>
> Yes. The compatibility clause lets you do that.
>
> > and thereby letting users to use all three on their sites?
>
> ....I'm not sure what this bit means.
>
> Gerv
I realize these questions aren't of much help for your work in particular at this point, please don't doubt that this work is appreciated though.
Even if I'll end up specifying incompatibility, the fact is that compatibility matters for users and I'd try to make sure that I'm understanding the alternative as much as possible.
a.w....@gmail.com
> > This item of the FAQ, together with another reading of Section 3.3,
> > seem to say that if I want to combine MPLed code with GPLed code,
> > then I need to explicitly relicense first... Which is fine.
>
> Er, no. See my earlier answer above. You can't tear the MPL off. Quoting
> myself:
>
> >> No. You can add a GPLv2 header and distribute it under a dual
> >> license. Then, someone who is not under your control or direction
> >> could, if they choose, remove the MPL option and redistribute
> >> _again_ under the GPL only. But you yourself, acting on your own,
> >> cannot remove the MPL-ness.
>
> > the situation when I am writing an integration or bridge, between a
> > MPL web application and a GPL web application, can I simply
> > distribute the bridge under MPL 2.0 (without incompatibility clause),
>
> Yes. The compatibility clause lets you do that.
>
> > and thereby letting users to use all three on their sites?
>
> ....I'm not sure what this bit means.
>
> Gerv
Gervase Markham
> I am wondering, in this particular case, would I need to dual-license
> myself, or both the MPLed application, and the MPL bridge, can be
> distributed as is, by me, as separate pieces of software, without the
> need to dual-license any of them?
leaving them as-is. If you distribute as a GPLed Larger Work, people
will understand that this gives them the GPL-only option for further
distribution.
Gerv