MPL Release Candidate 1 released - please review and comment!
Luis Villa
I'm happy to announce the release of MPL 2 Release Candidate 1 - the
text that we hope will become MPL 2.0 and serve the open source
community well for the next decade (or three). The plain text of the
license is here:
http://mpl.mozilla.org/wp-content/uploads/2011/08/MPL-RC1.txt (other
formats available through http://mpl.mozilla.org/participate/rc )
Changes
=======
We received excellent and useful feedback on Beta 2, which led us to
make a lot of smaller changes (definition cleanups, readability
changes, etc.) and one larger change - a reorganization of the
language on compatibility, merging the bulk of it with the "Larger
Works" language. This should not change the meaning from Beta 2, but
the language is very different, and hopefully more clear and
understandable. You can see the changes in this pdf:
http://mpl.mozilla.org/wp-content/uploads/2011/08/MPL-B2-to-RC1.pdf
FAQs
====
Along with the RC, we have also posted two draft FAQs that we would
also love feedback on.
The first FAQ is the license FAQ:
http://mpl.mozilla.org/wp-content/uploads/2011/08/FAQ-RC.html
The second FAQ is about the process that created MPL 2, and the
changes that occurred between 1.1 and 2.0:
http://mpl.mozilla.org/wp-content/uploads/2011/08/Revision-FAQ-RC.html
We welcome comments on those as well - either comments on the answers,
or suggestions for further questions.
Feedback
========
As is usual with release candidates, we would like to use this text as
the final release with no changes, but we need this group (and anyone
else you know who may be interested) to review the license and make
sure it is up to snuff.
To comment, the same channels used in previous releases are available:
commenting tool (linked to from the primary participation page,
below); this mailing list, or direct contact with me, Gerv, or Harvey.
A link suitable for tweeting, emailing, etc., that has all the links
above (and more!) is here:
http://mpl.mozilla.org/participate/rc
Scheduling and Mozilla Adoption
========================
We have not set a firm deadline for feedback and the final release,
but we hope it will be in the next few weeks. Please keep that in mind
while reviewing.
Publication of MPL 2.0 is *not* the same as adoption of MPL 2.0 by the
Mozilla Project - that is a separate discussion, that will be led by
Gerv in the near future. Keep an eye out for that email and discussion
on the main governance list and other Mozilla project discussion
channels, not here.
Thanks-
Luis
Leland Brown
recently heard about the MPL 2.0 effort. My interest is as a
professional
software engineer, and outside my job I've been working on software I
plan
to release soon as open-source, probably with an MPL license.
I have some concerns about the philosophy and wording related to
compatibility/incompatibility with GPL. This issue is at the heart of
my
choice of MPL over other licenses. Let me explain my perspective, and
after
my general comments I'll make a specific recommendation on wording.
It's often said that licenses like BSD are at one end of a spectrum
and GPL
at the other, with MPL in the middle. From the perspective of the
modification and distribution rights given to recipients, this is
true.
But from the perspective of a software developer, and the protections
afforded to ensure those rights are maintained downstream, I believe
GPL is
in the middle, with BSD and MPL 1.1 at opposite ends of the spectrum.
What
makes MPL unique to me is that it affords *stronger* protections than
GPL,
and I'm concerned that these may be eroded in MPL 2.0.
My personal desire is for my software and all future (distributed)
modifications of it to be freely available, including free to be
linked
into published proprietary software. GPL does not allow all these
freedoms;
BSD allows them for the current version but doesn't guarantee them for
future modifications. Of the three, only MPL 1.1 guarantees these
rights to
all downstream recipients.
Notice that the tri-license also does not meet my criteria, in that it
doesn't guarantee the rights if modifications are ever redistributed
under
GPL alone. It has the advantage of allowing linking to GPL code, but
neither does it guarantee this right downstream (if modifications are
first
redistributed under MPL alone). Thus, while providing more rights
initially, the tri-license actually has fewer downstream guarantees
than
either MPL 1.1 or GPL. In this sense the tri-license is a step toward
the
BSD license, providing more initial rights but fewer protections.
Without marking code as "Incompatible Software," the draft MPL 2.0
license
is more like the tri-license. Thus, I believe it creates a more
weakly-
protected license, rather than continuing the historic tradition of
the
strongly-protected MPL 1.1 license. Section 3.3 of the draft MPL 2.0
attempts to address this, as I understand it, by "requiring that the
initial distribution of changes occurs under both licenses and not
just the
GPL" [from the MPL 2.0 changes FAQ]. But that simply pushes the
potential
problem one step further downstream.
My primary purpose here is to raise this philosophical issue and make
sure
it has been duly considered before the new license is final.
My secondary purpose is to discuss the wording, "Incompatible
Software."
I'm glad to see this feature in the draft license, since it allows me
a way
to achieve the protections I want, and it also allows more consistency
for
existing code transitioning from the MPL 1.1 license.
However, I have two concerns with the wording. This first is that it
has a
negative connotation, as though it's adding a limitation to the
license -
whereas it seems to me it's adding strength and extra protection to
the
license. Perhaps a more neutral (or even positive) term of some sort
could
be used. With MPL 1.1, the strong license was the default, and the
weaker
tri-license required extra wording. I'd be disappointed to see the
situation reversed in MPL 2.0. To me, the great advantage and unique
feature of MPL in the first place appears to be getting deprecated
now.
My second concern is that "Incompatible Software" is in some sense a
misnomer. It implies that the incompatibility rests with this software
or
its license, which arguably is not the case. For example, suppose I
write
software licensed under MPL 1.1, and you write software licensed under
GPL,
and then Joe links them together and redistributes the combined code.
You
can sue him (maybe, depending on how the courts interpret "derivative
works") for violating your license; but I cannot - he has not violated
the
MPL license. Thus, in a very real sense, it is the GPL license that
created
the incompatibility. Under MPL 2.0, why should I have to flag my
software
as "Incompatible," in relation to a third-party's license, because of
restrictions placed by that third party on what can be done with their
software?
Once again, alternative wording may suffice to satisfy me here.
Perhaps
something like "Fixed License Software," "Single License Software,"
etc. -
indicating that the software cannot be redistributed under another
(Secondary) license. Those are more neutral terms as well.
Thanks for taking the time to hear my concerns. I appreciate all your
effort to modernize the license, and I look forward to an excellent
finished product.
-- Leland
Pandu Poluan
>
> My personal desire is for my software and all future (distributed)
> modifications of it to be freely available, including free to be
> linked
> into published proprietary software. GPL does not allow all these
> freedoms;
> BSD allows them for the current version but doesn't guarantee them for
> future modifications. Of the three, only MPL 1.1 guarantees these
> rights to
> all downstream recipients.
>
I'm with you on this one.
Rgds,
--
FdS Pandu E Poluan
~ IT Optimizer ~
• LOPSA Member #15248
• Blog : http://pepoluan.tumblr.com
• Linked-In : http://id.linkedin.com/in/pepoluan
Gervase Markham
> Notice that the tri-license also does not meet my criteria, in that it
> doesn't guarantee the rights if modifications are ever redistributed
> under GPL alone.
What you have hit upon here is that the rights
A) to use code in GPLed software; and
B) to always be able to use any downstream version of the code in
proprietary software
are mutually incompatible. You cannot write a licence which gives you
both these rights - because if you can use the code in GPLed software,
it must be relicensable under the GPL, and if it's relicensable under
the GPL, you can't guarantee that every derivative will always be
available to be used in proprietary software.
The MPL 1.1 alone gives you right B) but not right A).
The MPL tri-license gives you right A) but not right B).
The MPL 2 without the Incompatible Software clause gives you right A)
but not right B).
The MPL 2 with the Incompatible Software clause gives you right B)
but not right A).
> My secondary purpose is to discuss the wording, "Incompatible
> Software."
> I'm glad to see this feature in the draft license, since it allows me
> a way
> to achieve the protections I want, and it also allows more consistency
> for
> existing code transitioning from the MPL 1.1 license.
I'm glad you like it :-)
> However, I have two concerns with the wording.
Several people have commented that, in different ways, this wording is
not ideal.
> This first is that it
> has a
> negative connotation, as though it's adding a limitation to the
> license -
> whereas it seems to me it's adding strength and extra protection to
> the
> license.
That would be hotly debated by various groups :-) But we might aim for a
more neutral term, if we could find one which is equally or more
explanatory.
> My second concern is that "Incompatible Software" is in some sense a
> misnomer. It implies that the incompatibility rests with this software
> or its license, which arguably is not the case.
The author of the software has chosen, by adding that text, to make
their software not usable under the GPL - "incompatible with the GPL" in
everyday language. Therefore the incompatibility is just as much due to
the software as due to the GPL.
> Perhaps
> something like "Fixed License Software," "Single License Software,"
> etc. -
> indicating that the software cannot be redistributed under another
> (Secondary) license. Those are more neutral terms as well.
These are interesting suggestions. I hope Luis will consider them :-)
Gerv
Mitchell Baker
and thanks for your very thoughtful comments. This aspect is one of the
most complicated parts of the license; it's very helpful to hear your
thoughts.
mitchell
On 8/19/11 7:59 AM, Gervase Markham wrote:
> On 19/08/11 08:53, Leland Brown wrote:
>> Notice that the tri-license also does not meet my criteria, in that it
>> doesn't guarantee the rights if modifications are ever redistributed
>> under GPL alone.
> What you have hit upon here is that the rights
>
> A) to use code in GPLed software; and
> B) to always be able to use any downstream version of the code in
> proprietary software
>
> are mutually incompatible. You cannot write a licence which gives you
> both these rights - because if you can use the code in GPLed software,
> it must be relicensable under the GPL, and if it's relicensable under
> the GPL, you can't guarantee that every derivative will always be
> available to be used in proprietary software.
>
> The MPL 1.1 alone gives you right B) but not right A).
> The MPL tri-license gives you right A) but not right B).
>
> The MPL 2 without the Incompatible Software clause gives you right A)
> but not right B).
> The MPL 2 with the Incompatible Software clause gives you right B)
> but not right A).
>
>> My secondary purpose is to discuss the wording, "Incompatible
>> Software."
>> I'm glad to see this feature in the draft license, since it allows me
>> a way
>> to achieve the protections I want, and it also allows more consistency
>> for
>> existing code transitioning from the MPL 1.1 license.
> I'm glad you like it :-)
>
>> However, I have two concerns with the wording.
> Several people have commented that, in different ways, this wording is
> not ideal.
>
>> This first is that it
>> has a
>> negative connotation, as though it's adding a limitation to the
>> license -
>> whereas it seems to me it's adding strength and extra protection to
>> the
>> license.
> That would be hotly debated by various groups :-) But we might aim for a
> more neutral term, if we could find one which is equally or more
> explanatory.
>
>> My second concern is that "Incompatible Software" is in some sense a
>> misnomer. It implies that the incompatibility rests with this software
>> or its license, which arguably is not the case.
> The author of the software has chosen, by adding that text, to make
> their software not usable under the GPL - "incompatible with the GPL" in
> everyday language. Therefore the incompatibility is just as much due to
> the software as due to the GPL.
>
>> Perhaps
>> something like "Fixed License Software," "Single License Software,"
>> etc. -
>> indicating that the software cannot be redistributed under another
>> (Secondary) license. Those are more neutral terms as well.
> These are interesting suggestions. I hope Luis will consider them :-)
>
> Gerv
>
> _______________________________________________
> governance-mpl-update mailing list
> governance...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/governance-mpl-update
Michael Kay
> My secondary purpose is to discuss the wording, "Incompatible
> Software."
>
> misnomer.
I raised this point strongly in a comment on the previous version, and I
thought the comment was accepted. I'm disappointed it hasn't been
addressed. No-one wants to stick a label on their software saying "This
software is incompatible". For 99% of readers, it will be misunderstood
and will raise quite unnecessary alarm bells.
Michael Kay
Saxonica
Luis Villa
the time to engage deeply with this tricky issue. Some comments
inline:
On Fri, Aug 19, 2011 at 7:59 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 19/08/11 08:53, Leland Brown wrote:
>> Notice that the tri-license also does not meet my criteria, in that it
>> doesn't guarantee the rights if modifications are ever redistributed
>> under GPL alone.
>
> What you have hit upon here is that the rights
>
> A) to use code in GPLed software; and
> B) to always be able to use any downstream version of the code in
> proprietary software
>
> are mutually incompatible. You cannot write a licence which gives you
> both these rights - because if you can use the code in GPLed software,
> it must be relicensable under the GPL, and if it's relicensable under
> the GPL, you can't guarantee that every derivative will always be
> available to be used in proprietary software.
>
> The MPL 1.1 alone gives you right B) but not right A).
> The MPL tri-license gives you right A) but not right B).
>
> The MPL 2 without the Incompatible Software clause gives you right A)
> but not right B).
> The MPL 2 with the Incompatible Software clause gives you right B)
> but not right A).
Gerv's analysis here is essentially correct, though I might rephrase
(B) as "to always be able to use any downstream version of the code
under the original license terms, which in this case includes the
ability to use any downstream version in proprietary software."
It is important to note that while MPL 2 without the Incompatible
Software option can't *guarantee* B, we do take steps to minimize the
circumstances in which the license can be changed when compared to a
simple, traditional dual-license. Specifically, Section 3.3 says:
If the Larger Work is a combination of Covered Software with a work
governed by a Secondary License, and the Covered Software is not
Incompatible Software, You may additionally distribute such Covered
Software under the terms of that Secondary License, so that the
recipient of the Larger Work may, at their option, further distribute
the Covered Software under the terms of either this License or that
Secondary License.
Two things are going on here:
1) The Larger Work must be "a **combination** of Covered Software with
a work governed by a Secondary License." So a licensee can't just say
"I really prefer GPL" - the licensee must need to combine with
another, existing GPL work. (Compare to a traditional dual-license,
which does not require you to combine - you can just roll out of bed
and say "I've decided to be GPL-only.")
2) The licensee can "**additionally** distribute" under GPL. In other
words, they have to make available to their recipients under both MPL
and GPL. Someone downstream from them can then take under GPL-only or
MPL-only, but it has to be that downstream. Again, compare to a
traditional dual-license- you never have to issue under both licenses,
so you always have the option of releasing incompatible code.
[I think that I like this explanation enough that Gerv or I should
incorporate a version of it into the FAQ, so please let us know if
this explanation makes sense to you.
>> However, I have two concerns with the wording.
>
> Several people have commented that, in different ways, this wording is
> not ideal.
>
>> This first is that it
>> has a
>> negative connotation, as though it's adding a limitation to the
>> license -
>> whereas it seems to me it's adding strength and extra protection to
>> the
>> license.
>
> That would be hotly debated by various groups :-) But we might aim for a
> more neutral term, if we could find one which is equally or more
> explanatory.
>
>> My second concern is that "Incompatible Software" is in some sense a
>> misnomer. It implies that the incompatibility rests with this software
>> or its license, which arguably is not the case.
>
> The author of the software has chosen, by adding that text, to make
> their software not usable under the GPL - "incompatible with the GPL" in
> everyday language. Therefore the incompatibility is just as much due to
> the software as due to the GPL.
>
>> Perhaps
>> something like "Fixed License Software," "Single License Software,"
>> etc. -
>> indicating that the software cannot be redistributed under another
>> (Secondary) license. Those are more neutral terms as well.
>
> These are interesting suggestions. I hope Luis will consider them :-)
I will do so; I'm not eager to make changes at this point but
something that is purely the name of a term, rather than an actual
change of the language, would be much easier to do.
Luis
Luis Villa
>
>> My secondary purpose is to discuss the wording, "Incompatible
>> Software."
>>
>> misnomer.
>
> thought the comment was accepted. I'm disappointed it hasn't been addressed.
> No-one wants to stick a label on their software saying "This software is
> incompatible". For 99% of readers, it will be misunderstood and will raise
> quite unnecessary alarm bells.
We knew it was an issue, but could not find a better wording at the
time. A suggestion has since come in that might work, and of course
we're still open to suggestions.
Luis
Leland Brown
really able to understand that paragraph clearly. So I definitely
think it would be a good addition to the FAQ. This does seem like a
substantive improvement over the dual- or tri-license.
I appreciate that it's too late to be making many changes to the
license, so I'll keep my comments relevant to just finding a
replacement term for "Incompatible Software."
Quoting Gerv:
> What you have hit upon here is that the rights
>
> A) to use code in GPLed software; and
> B) to always be able to use any downstream version of the code in
> proprietary software
>
> are mutually incompatible.
Yes. If my goal is to provide right A), there's another license
available for this (the GPL itself). But if I want to provide right
B), then the MPL is pretty much the only choice available to the
community. That's why the wording of MPL 2.0 is so important to me,
and why I believe this is the salient feature of MPL that makes it
unique.
It would be nice to see license wording that recognizes that feature,
rather than just focusing on the resulting incompatibility with
someone else's license. As you pointed out, case B) provides
*different* rights, trading off one set for another that the author
finds valuable. The phrase "This ... is Incompatible Software"
indicates *lesser* rights, referencing only the lack of one set of
rights.
Regarding incompatibility:
> The author of the software has chosen, by adding that text, to make
> their software not usable under the GPL - "incompatible with the GPL" in
> everyday language.
Yes, but not necessarily in the way implied by the FAQ when it says,
"Some MPL 1.1 licensors chose to use the MPL specifically in order to
avoid compatibility with the GPL." That is not my intent. My goal is
simply to provide right B) above, and incompatibility with GPL is then
an unavoidable - and to me unfortunate - consequence.
By way of illustration - I might be tempted to write my license
statement with an explanatory note as follows:
This software is licensed under the terms of the Mozilla
Public License Version 2.0. This Source Code Form is
Incompatible Software as defined by the License.
The term "Incompatible Software" protects your rights to
use the software in commercial products.
While basically true, I think the last sentence would make a lot of
people scratch their heads in confusion; it's counterintuitive. The
words "Incompatible Software" focus on what I see as a side effect
rather than the intent. If you replace this with something like
"Single-License Software" in the text above, I think it reduces the
confusion and also makes an explanatory note less necessary.
Anyone have a another suggestion for neutral wording?
-- Leland
Mitchell Baker
something more neutral and intuitive (or at least less
counter-intuitive). So far, I haven't been able to think of why
"Single License Software" or something like that would generate
problems. It could be that be reviewing very use of the term will
suggest a problem. I'm sure Luis will do this :-)
mitchell
On 8/20/11 12:37 PM, Leland Brown wrote:
> Luis's explanation of Section 3.3 is helpful. I confess I was not
> really able to understand that paragraph clearly. So I definitely
> think it would be a good addition to the FAQ. This does seem like a
> substantive improvement over the dual- or tri-license.
>
> I appreciate that it's too late to be making many changes to the
> license, so I'll keep my comments relevant to just finding a
> replacement term for "Incompatible Software."
>
> Quoting Gerv:
>
>> What you have hit upon here is that the rights
>>
>> A) to use code in GPLed software; and
>> B) to always be able to use any downstream version of the code in
>> proprietary software
>>
>> are mutually incompatible.
> Yes. If my goal is to provide right A), there's another license
> available for this (the GPL itself). But if I want to provide right
> B), then the MPL is pretty much the only choice available to the
> community. That's why the wording of MPL 2.0 is so important to me,
> and why I believe this is the salient feature of MPL that makes it
> unique.
>
> It would be nice to see license wording that recognizes that feature,
> rather than just focusing on the resulting incompatibility with
> someone else's license. As you pointed out, case B) provides
> *different* rights, trading off one set for another that the author
> finds valuable. The phrase "This ... is Incompatible Software"
> indicates *lesser* rights, referencing only the lack of one set of
> rights.
>
> Regarding incompatibility:
>
>> The author of the software has chosen, by adding that text, to make
>> their software not usable under the GPL - "incompatible with the GPL" in
>> everyday language.
> Yes, but not necessarily in the way implied by the FAQ when it says,
> "Some MPL 1.1 licensors chose to use the MPL specifically in order to
> avoid compatibility with the GPL." That is not my intent. My goal is
> simply to provide right B) above, and incompatibility with GPL is then
> an unavoidable - and to me unfortunate - consequence.
>
> By way of illustration - I might be tempted to write my license
> statement with an explanatory note as follows:
>
> This software is licensed under the terms of the Mozilla
> Public License Version 2.0. This Source Code Form is
> Incompatible Software as defined by the License.
> The term "Incompatible Software" protects your rights to
> use the software in commercial products.
>
> While basically true, I think the last sentence would make a lot of
> people scratch their heads in confusion; it's counterintuitive. The
> words "Incompatible Software" focus on what I see as a side effect
> rather than the intent. If you replace this with something like
> "Single-License Software" in the text above, I think it reduces the
> confusion and also makes an explanatory note less necessary.
>
> Anyone have a another suggestion for neutral wording?
>
> -- Leland
Gervase Markham
> I agree it would be good to change the term "Incompatible software" to
> something more neutral and intuitive (or at least less
> counter-intuitive). So far, I haven't been able to think of why
> "Single License Software" or something like that would generate
> problems. It could be that be reviewing very use of the term will
> suggest a problem. I'm sure Luis will do this :-)
The only possible objection I can think of to "Single License Software"
is that it might cause confusion if:
a) someone makes the software multiply-licensed, but not using the MPL
compatibility scheme - so, say, I dual-license some code under the MPL2
and the Eclipse Public License.
b) someone offers a product which contains some code under MPL and some
other code under another licence. Therefore, the MPL code says "this is
Single License Software", and yet the document explaining the licensing
will talk about multiple licences.
In these cases, if the code header said "this is Single License
Software", it would seem to go on and contradict itself by then offering
a second licence.
Perhaps we could fix it by more explicitly limiting the scope?
"This _file_ is 'Single License' Software, as defined by the License."
If we put "Single License' or 'Single License Software' in quotes, it
also gives more of an impression that it's a defined term and they
should carefully read the licence to see what it means.
Gerv
Luis Villa
> On 21/08/11 18:51, Mitchell Baker wrote:
>> something more neutral and intuitive (or at least less
>> counter-intuitive). So far, I haven't been able to think of why
>> "Single License Software" or something like that would generate
>> problems. It could be that be reviewing very use of the term will
>> suggest a problem. I'm sure Luis will do this :-)
>
> is that it might cause confusion if:
>
> a) someone makes the software multiply-licensed, but not using the MPL
> compatibility scheme - so, say, I dual-license some code under the MPL2
> and the Eclipse Public License.
>
> b) someone offers a product which contains some code under MPL and some
> other code under another licence. Therefore, the MPL code says "this is
> Single License Software", and yet the document explaining the licensing
> will talk about multiple licences.
>
> In these cases, if the code header said "this is Single License
> Software", it would seem to go on and contradict itself by then offering
> a second licence.
This seems *very* confusing to me for this reason.
Gerv, perhaps you could share your other suggestion here?
Luis
Gervase Markham
> Gerv, perhaps you could share your other suggestion here?
How about the following Exhibit B:
This file is 'Incompatible With Secondary Licenses', as defined by
the License.
The single quotes are important; otherwise we are using the word
"License" unqualified in two senses in the same sentence. Capital W to
make the entire thing a defined term.
I've changed "software" to "file" to try and make the scope a bit more
clear.
Other possibilities, off the top of my head:
* This file may not undergo 'License Conversion', as defined by the License.
(Or Migration or Transformation or...)
* This file is 'Non-Combinable Software', as defined by the License.
(This wording might work, because you have to combine with Secondary
Licensed software to trigger the change. No one is going to assume they
know what this means, they'll have to read the licence. Which is good.)
Gerv
Housekeeping: we would then define that entire term, tweaking the
current definition of Incompatible Software:
1.5. “Incompatible With Secondary Licenses”
refers to Covered Software
to which the initial Contributor has attached the notice
described in Exhibit B; or
which was made available under the terms of version 1.1 or
earlier of the License, but not also under the terms of a Secondary License.
and then in 3.3:
.... and the Covered Software is not Incompatible With Secondary Licenses ...
Mitchell Baker
It has 2 benefits: it's specific, i don't think it leads to the
confusion Gerv outlined below; and
it's SO unintelligible on its own that it should drive people to look at
the definition.
it's not an elegant solution, I acknowlede that. But making it clear
people need to read the definition, not assume they know what the
definition is, may be the best solution.
mitchell
On 8/22/11 7:13 AM, Luis Villa wrote:
> On Mon, Aug 22, 2011 at 2:29 AM, Gervase Markham<ge...@mozilla.org> wrote:
>> On 21/08/11 18:51, Mitchell Baker wrote:
>>> I agree it would be good to change the term "Incompatible software" to
>>> something more neutral and intuitive (or at least less
>>> counter-intuitive). So far, I haven't been able to think of why
>>> "Single License Software" or something like that would generate
>>> problems. It could be that be reviewing very use of the term will
>>> suggest a problem. I'm sure Luis will do this :-)
>> The only possible objection I can think of to "Single License Software"
>> is that it might cause confusion if:
>>
>> a) someone makes the software multiply-licensed, but not using the MPL
>> compatibility scheme - so, say, I dual-license some code under the MPL2
>> and the Eclipse Public License.
>>
>> b) someone offers a product which contains some code under MPL and some
>> other code under another licence. Therefore, the MPL code says "this is
>> Single License Software", and yet the document explaining the licensing
>> will talk about multiple licences.
>>
>> In these cases, if the code header said "this is Single License
>> Software", it would seem to go on and contradict itself by then offering
>> a second licence.
> This seems *very* confusing to me for this reason.
>
> Gerv, perhaps you could share your other suggestion here?
>
> Luis
Mitchell Baker
mitchell
On 8/22/11 7:26 AM, Gervase Markham wrote:
> On 22/08/11 15:13, Luis Villa wrote:
>> Gerv, perhaps you could share your other suggestion here?
> How about the following Exhibit B:
>
> This file is 'Incompatible With Secondary Licenses', as defined by
> the License.
>
> The single quotes are important; otherwise we are using the word
> "License" unqualified in two senses in the same sentence. Capital W to
> make the entire thing a defined term.
>
> I've changed "software" to "file" to try and make the scope a bit more
> clear.
>
> Other possibilities, off the top of my head:
>
> * This file may not undergo 'License Conversion', as defined by the License.
> (Or Migration or Transformation or...)
>
> * This file is 'Non-Combinable Software', as defined by the License.
> (This wording might work, because you have to combine with Secondary
> Licensed software to trigger the change. No one is going to assume they
> know what this means, they'll have to read the licence. Which is good.)
>
> Gerv
>
>
> Housekeeping: we would then define that entire term, tweaking the
> current definition of Incompatible Software:
>
> 1.5. “Incompatible With Secondary Licenses”
>
> refers to Covered Software
>
> to which the initial Contributor has attached the notice
> described in Exhibit B; or
>
> which was made available under the terms of version 1.1 or
> earlier of the License, but not also under the terms of a Secondary License.
>
> and then in 3.3:
>
> .... and the Covered Software is not Incompatible With Secondary Licenses ...
>
>
>
>
Leland Brown
I see that the term "Single License Software" would be confusing in
some cases.
> This file is 'Incompatible With Secondary Licenses',
> as defined by the License.
Despite my earlier objection to the word "Incompatible," I actually
like this one. Unlike the term "Incompatible Software," which tends to
imply the *functionality* is incompatible, this one is more precise.
It makes clear that the incompatibility is in the licenses, as well as
exactly which licenses are incompatible. The quotes and capitalization
also imply that not only the whole phrase but also the term "Secondary
Licenses" are defined in the License text, which is both true and
important.
This also feels a lot less negative to me, probably because saying "A
is incompatible with B" is much more accurate and meaningful than
saying "A is incompatible."
> This file is 'Non-Combinable Software', as defined by the License.
But part of the point of using a file-level copyleft is that it does
allow software files to be combined, at least with some licenses. "Non-
Combinable With Secondary Licenses" would be more clear. But I think I
prefer "Incompatible" in this case - it feels more like a statement of
fact than a "Thou shalt not...."
Thanks for letting me be a part of the discussion.
-- Leland
Leland Brown
(without Exhibit B) be redistributed under MPL 2.0 with Exhibit B -
analogous to the way tri-licensed software could be redistributed
under MPL 1.1?
I've not been able to figure out the answer by reading the license, so
this may also be a good topic for the FAQ.
-- Leland
Gervase Markham
> On a slightly different topic: Can software licensed under MPL 2.0
> (without Exhibit B) be redistributed under MPL 2.0 with Exhibit B -
> analogous to the way tri-licensed software could be redistributed
> under MPL 1.1?
No, you cannot remove Exhibit B from MPLed software you did not write.
MPL 2, section 3.4:
"You may not remove or alter any license notices (including copyright
notices, patent notices, disclaimers of warranty, or limitations of
liability) contained within the Source Code Form of the Covered
Software, except to the extent required to remedy known factual
inaccuracies."
Exhibit B is a license notice.
Gerv
Leland Brown
> No, you cannot remove Exhibit B from MPLed software you did not write.
That much is clear. But I want to know, can I *add* Exhibit B to MPLed
software I did not write? Say I'm incorporating some code into a
project that uses the Exhibit B license, and I want to keep the
license consistent across my project, or maybe the incorporation does
not respect file boundaries (e.g., I want to cut and paste part of a
file into my file). Can I do this, or do I need to keep the code in
separate files with separate licenses?
-- Leland
Dr. Ernie
I may as well weigh back in on this issue, since Leland was kind
enough to bring it up again:
A few other terms, some of which I may have suggested before when this
first came up:
* Immutable Software / Immutably-Licensed Software
(since the license can't be changed, and immutable is a well-known
term of art for programmers)
* GPL-Incomptabile Software (since that's pretty much the only effect,
right?)
Alternatively: Non-Copyleft Software (Non-Viral, if you want to start
a fight :-)
* Permanently Licensed Software (can't be relicensed)
Uniquely-Licensed
Fixed
* Inseparable Software (can't be removed from the MPL)
* Reserved Software (can't be shared with another license)
Unequivocal
Distinct
Restricted
Precisely-Licensed
Exclusively-LIcensed
Strictly-Licensed
--- Ernie "I love my thesaurus" Prabhakar
Disclaimer: Leland is an old friend of mine, and I did suggest he
check out MPLv2, but I didn't incite him to raise this stink about
"Incompatible Software", honest! :-)
Frédéric Buclin
> This file is 'Incompatible With Secondary Licenses', as defined by
> the License.
+1!
The Exhibit-B text as proposed in the RC1 is definitely too confusing,
and required gerv to explain us what this means on bmo. This is IMO a
good enough reason to reword it as suggested above. Else it really
sounds like "we use this licence, but this code is not in agreement with
it" or something like that.
LpSolit
Gervase Markham
> On Aug 23, 8:24 am, Gervase Markham <g...@mozilla.org> wrote:
>
>> No, you cannot remove Exhibit B from MPLed software you did not write.
>
> That much is clear. But I want to know, can I *add* Exhibit B to MPLed
> software I did not write?
No.
Section 3.1: "You may not attempt to alter or restrict the recipients’
rights in the Source Code Form." If Exhibit B is not present, those
rights include the right to combine the source with software under a
Secondary License. And you may not restrict that right.
If you wanted to copy code from what we shall call a "B file" into a
"non-B file", you can make the non-B file into a B file if you hold the
copyright to it or get permission from the copyright holders. Otherwise,
you'll need to have a separate file and use a function call or #include
or similar.
This makes it wise for individual projects to pick either B or non-B for
their code and stick with it consistently.
Gerv
Gervase Markham
> A few other terms, some of which I may have suggested before when this
> first came up:
Thanks for the suggestions!
> * Immutable Software / Immutably-Licensed Software
> (since the license can't be changed, and immutable is a well-known
> term of art for programmers)
Immutable Software sounds like you can't change the code.
Immutably-Licensed Software is better, although it might imply you can't
use later versions of the MPL.
> * GPL-Incomptabile Software (since that's pretty much the only effect,
> right?)
We want to retain the right to change the list of Secondary Licences in
the future, and therefore we can't have references to particular
licences or groups of licences outside the definition of Secondary License.
> Alternatively: Non-Copyleft Software (Non-Viral, if you want to start
> a fight :-)
:-)
> * Permanently Licensed Software (can't be relicensed)
That sounds like that software without the clause is only Temporarily
Licensed.
> Uniquely-Licensed
Every file has a different licence? :-)
> Fixed
"Fixed License Software"? Possible...
> * Inseparable Software (can't be removed from the MPL)
Sounds like you can't take bits of it and include it in something else...
I think perhaps any adjective has to be written as to apply to the
licence, and not the software, otherwise we'll get confusion.
I would say the top two candidates from your list are:
Immutably-Licensed Software
and
Fixed License Software
Gerv
Leland Brown
> This file is 'Incompatible With Secondary Licenses',
> as defined by the License.
along the lines of the discussion.)
If we were voting I think I'd still pick the first one. It breaks the
paradigm of "This ... is ____ Software," allowing it to be more
expressive than just an adjective without resorting to something
awkward like "Secondary License-Incompatible Software."
Have there been any decisions made on this?
-- Leland
Michael Kay
Michael Kay
Saxonica
On 12/09/2011 11:07, Leland Brown wrote:
> So it sounds like the top three contenders are something like this:
>
>> as defined by the License.
> along the lines of the discussion.)
>
> If we were voting I think I'd still pick the first one. It breaks the
> paradigm of "This ... is ____ Software," allowing it to be more
> expressive than just an adjective without resorting to something
> awkward like "Secondary License-Incompatible Software."
>
> Have there been any decisions made on this?
>
> -- Leland
Luis Villa
Unfortunately it has more potential changes than we initially expected so it
isn't out the door quite yet.
> I would vote for the first.
>
> Michael Kay
> Saxonica
>
> On 12/09/2011 11:07, Leland Brown wrote:
>> So it sounds like the top three contenders are something like this:
>>
>>> as defined by the License.
>> along the lines of the discussion.)
>>
>> If we were voting I think I'd still pick the first one. It breaks the
>> paradigm of "This ... is ____ Software," allowing it to be more
>> expressive than just an adjective without resorting to something
>> awkward like "Secondary License-Incompatible Software."
>>
>> Have there been any decisions made on this?
>>
>> -- Leland