Updated FAQ item list [was Re: suggestions for MPL FAQ entries?]
Luis Villa
<marcandr...@gmail.com> wrote:
> Hi,
>
> I would have a suggestion for a question to be answered in the FAQ:
>
> Is the MPL known to be compatible or incompatible with particular application stores, such as Apple's App Store, the Android Market, or the Microsoft App Hub?
>
> With cases like the removal of VLC and GNU Go from the App Store, I think there is a need for alternative licenses like MPL.
Thanks for the suggestion, Marc-Andre. Unfortunately, I don't think
that this is something that we can directly answer in the FAQ, since
the answer depends in large part on the specific terms of service for
the App Stores, which can change at any time and which we can't
interpret on behalf of others. That said, we did think about this use
case when drafting the license, and so we will consider if or how we
can reasonably mention this in the FAQ.
Relatedly, we've been quietly working on the FAQ, which has now been
split in two pieces: one for the license itself, and one for questions
about the changes between MPL 1.1 and MPL 2.0. The current list of
proposed questions is below. As before, suggested new questions are
welcome.
MPL FAQ
-------------
# About MPL
## Q: What is the Mozilla Public License?
## Q: Why yet another license?
## Q: Who maintains the MPL?
# Common Questions
## Q: I want to use software which is available under the MPL. What do
I have to do?
## Q: I want to distribute software which is available under the MPL,
either changed or unchanged, within my organization. What do I have to
do?
## Q: I want to distribute (outside my organization) complete and
unchanged executable programs built from MPL-licensed software by the
author of that software. What do I have to do?
## Q: I want to distribute (outside my organization) executable
programs that I have compiled from someone else's unchanged
MPL-licensed source code. What do I have to do?
## Q: I want to distribute (outside my organization) MPL-licensed
source code that I have modified. What do I have to do?
## Q: I want to distribute (outside my organization) an executable
program based on MPL-licensed source code that I have modified. What
do I have to do?
## Q: How 'viral' is the MPL? If I use MPL-licensed code in my
proprietary application, will I have to give all the source code away?
## Q: May I combine MPL-licensed code and BSD-licensed code in the
same executable program? What about Apache?
## Q: May I combine MPL-licensed code and GPL-licensed code in the
same executable program?
## Q: Is "[minified](http://en.wikipedia.org/wiki/Minification_%28programming%29)"
JavaScript Source Code?
## Q. What does "distribute" mean?
## Q: Should MPL be used for non-software works?
## Q: Section 3.4 says I can't offer a warranty on behalf of another
Contributor, but I'd like to go into business with another Contributor
and offer warranties to users. Is this permissible?
## Q: Can I remove or change notice statements which are displayed by
a piece of software?
## Q: What is the purpose of the "Incompatible Software" requirements?
## Q: Does Sec. 11 lead to more license proliferation?
## Q: I've downloaded a copy of some MPL software. Am I an "owner" of
that software for purposes of Section 1.1?
MPL 1.1 to 2.0 FAQ
-----------------------------
# About the MPL 2.0 Revision Process
## Q: How was MPL 2.0 drafted?
## Q: Is the revision process publicly documented?
## Q: Section 6 of MPL 1.1 says Netscape can update the license, but
Mozilla isn’t Netscape. Can Mozilla still update the license?
# Upgrading a project from MPL 1.1 to MPL 2.0
## Q: I use MPL 1.1 for my project. Why should I upgrade to MPL 2.0?
## Q: I am the author of code which I have placed under MPL version
1.1. How do I license my project under MPL 2.0 instead of MPL 1.1?
## Q: I am distributing code written by someone else under the terms
of MPL 1.1. Can I distribute that code under the terms of MPL 2.0
instead of MPL 1.1? If so, how?
# Changes from MPL 1.1
## Q: What has not changed between MPL 1.1 and MPL 2.0?
## Q: What things changed between MPL 1.1 and MPL 2.0?
## Q: Why did the new license remove the government entities language?
## Q: Why doesn't the new license require distributors to include a
complete copy of the license with the distributed Source Code?
## Q: Why did the new license remove the reference to build scripts
and documentation from the definition of Source Code?
## Q: Section 3.2 now requires that I "inform" recipients how they can
obtain the Source Code form. Could you give some examples of what it
means to "inform"?
## Q: Unlike MPL 1.1, MPL 2.0 contains explicit provisions for
distribution alongside GPL- and LGPL-licensed code. Why?
Benoit Jacob
1. What does 'compatible' mean for licenses, as in 'license X is compatible with Y' ?
My understanding is that it means 'one may relicense code from X to Y'. One very important thing to stress is that contrary to what the word 'compatible' suggests, this isn't symmetric: just because X is compatible with Y, doesn't mean that Y is compatible with X.
2. Explain in great detail the MPL's concept of 'file-level copyleft'. Give example, including an example of how it's different from the LGPL's copyleft in practice.
Thanks,
Benoit
> _______________________________________________
> governance-mpl-update mailing list
> governance...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/governance-mpl-update
Marc-André Moreau
> I haven't yet looked carefully at the new FAQ, but here are two things I believe are very important to explain in it --- sorry if they're already well-covered.
Correct me if I'm wrong, but here is my understanding:
>
> 1. What does 'compatible' mean for licenses, as in 'license X is compatible with Y' ?
>
> My understanding is that it means 'one may relicense code from X to Y'. One very important thing to stress is that contrary to what the word 'compatible' suggests, this isn't symmetric: just because X is compatible with Y, doesn't mean that Y is compatible with X.
http://en.wikipedia.org/wiki/License_compatibility
license compatibility does not mean that one can relicense code to
another compatible license, unless otherwise stated. For instance, the
GPL has a clause which allows "updating" of the license to later
versions. Each copyright holder owns copyright on specific parts of
code, and grants you a license for its usage under certain conditions.
Changing the license requires the agreement of the copyright holder.
License compatibility with GPL, for instance, would mean that the MPL
includes no condition that would fall in contradiction with the terms
of the GPL. For instance, if a license were to explicitly allow
tivoization, it would be considered incompatible with GPLv3, since
GPLv3 forbids tivoization.
>
> 2. Explain in great detail the MPL's concept of 'file-level copyleft'. Give example, including an example of how it's different from the LGPL's copyleft in practice.
The level of copyleft with LGPL/GPL is much higher. For instance, you
can link to an LGPL library only under certain conditions. From my
understanding, you could have your proprietary code *dynamically link*
to an LGPL library, but not *statically link*. With MPL and its level
of copyleft propagation, the copyleft is limited to individual files,
and does not start defining boundaries for propagation based on how
the code is linked. This means that under certain conditions given by
the MPL, you could have code from a different license cleanly
separated into its own files, that would dynamically or statically
link to the MPL code, without having the MPL copyleft propagate to
them.
With GPL, the copyleft is highly viral: you link to GPL code, your own
code must be copyleft, end of the story. Then people start trying to
use GPL code from separate processes or over the network to attempt to
limit the copyleft propagation, which is why licenses like the AGPL
came to existence.
> > governance-mpl-upd...@lists.mozilla.org
> >https://lists.mozilla.org/listinfo/governance-mpl-update
Luis Villa
<marcandr...@gmail.com> wrote:
> On Jun 22, 9:01 pm, Benoit Jacob <bja...@mozilla.com> wrote:
>
>>
>>
>> My understanding is that it means 'one may relicense code from X to Y'. One very important thing to stress is that contrary to what the word 'compatible' suggests, this isn't symmetric: just because X is compatible with Y, doesn't mean that Y is compatible with X.
>
>
> license compatibility does not mean that one can relicense code to
> another compatible license, unless otherwise stated. For instance, the
> GPL has a clause which allows "updating" of the license to later
> versions. Each copyright holder owns copyright on specific parts of
> code, and grants you a license for its usage under certain conditions.
> Changing the license requires the agreement of the copyright holder.
>
> License compatibility with GPL, for instance, would mean that the MPL
> includes no condition that would fall in contradiction with the terms
> of the GPL. For instance, if a license were to explicitly allow
> tivoization, it would be considered incompatible with GPLv3, since
> GPLv3 forbids tivoization.
These are good pointers (in particular, I didn't know that Wikipedia
had an entry here.) I think Benoit's point was that we should address
this in the FAQ. Given the complexity and nuance of the issue, my
instinct is to avoid addressing this in something as simplistic as a
FAQ, but we'll discuss it, and perhaps avoid using the word
"compatible" altogether if possible.
>> 2. Explain in great detail the MPL's concept of 'file-level copyleft'. Give example, including an example of how it's different from the LGPL's copyleft in practice.
>
> The level of copyleft with LGPL/GPL is much higher. For instance, you
> can link to an LGPL library only under certain conditions. From my
> understanding, you could have your proprietary code *dynamically link*
> to an LGPL library, but not *statically link*. With MPL and its level
> of copyleft propagation, the copyleft is limited to individual files,
> and does not start defining boundaries for propagation based on how
> the code is linked. This means that under certain conditions given by
> the MPL, you could have code from a different license cleanly
> separated into its own files, that would dynamically or statically
> link to the MPL code, without having the MPL copyleft propagate to
> them.
>
> With GPL, the copyleft is highly viral: you link to GPL code, your own
> code must be copyleft, end of the story. Then people start trying to
> use GPL code from separate processes or over the network to attempt to
> limit the copyleft propagation, which is why licenses like the AGPL
> came to existence.
We're trying not to pick a fight with (L)GPL, so we probably won't go
into too much detail on the differences there. But we can probably
stand to explain the scope of the copyleft a little better.
Luis
Michael Kay
>>> My understanding is that it means 'one may relicense code from X to Y'. One very important thing to stress is that contrary to what the word 'compatible' suggests, this isn't symmetric: just because X is compatible with Y, doesn't mean that Y is compatible with X.
>>
>> license compatibility does not mean that one can relicense code to
>> another compatible license, unless otherwise stated.
I think the usually understood meaning of license compatibility is that
licenses A and B are compatible if it is possible to construct a piece
software containing components licensed under A alongside components
licensed under B.
>
>> The level of copyleft with LGPL/GPL is much higher. For instance, you
>> can link to an LGPL library only under certain conditions. From my
>> understanding, you could have your proprietary code *dynamically link*
>> to an LGPL library, but not *statically link*.
It's anyone's guess how the courts would interpret the GPL/LGPL
language. It's reasonable to try and gloss the intended meaning of the
MPL, but don't try and do it for anyone else's license!
Note, GPL doesn't prevent you linking proprietary code to a GPL or LGPL
library, it only prevents you distributing the resulting entity under a
non-GPL license. Since dynamic linking is something done by the user of
your application rather than by you prior to distribution, it's very far
from clear whether GPL can really prevent this. This lack of clarity is
one of the reasons I don't use GPL.
>> With MPL and its level
>> of copyleft propagation, the copyleft is limited to individual files,
>> and does not start defining boundaries for propagation based on how
>> the code is linked. This means that under certain conditions given by
>> the MPL, you could have code from a different license cleanly
>> separated into its own files, that would dynamically or statically
>> link to the MPL code, without having the MPL copyleft propagate to
>> them.
>>
It might even be worth pointing out while that the MPL copyleft requires
you to make available the source of any modified files, it doesn't even
require that the modified source be compilable. If your modification
introduces calls to proprietary routines defined elsewhere, your
modified code may be totally useless to anyone else, but you are still
required to make it available.
Michael Kay
Saxonica
Benoit Jacob
> > http://en.wikipedia.org/wiki/License_compatibility
>
> These are good pointers (in particular, I didn't know that Wikipedia
> had an entry here.) I think Benoit's point was that we should address
> this in the FAQ. Given the complexity and nuance of the issue, my
> instinct is to avoid addressing this in something as simplistic as a
> FAQ, but we'll discuss it, and perhaps avoid using the word
> "compatible" altogether if possible.
Either that, or maybe give the wikipedia link in the FAQ.
>
> >> 2. Explain in great detail the MPL's concept of 'file-level
> >> copyleft'. Give example, including an example of how it's different
> >> from the LGPL's copyleft in practice.
> >
> > The level of copyleft with LGPL/GPL is much higher. For instance,
> > you
> > can link to an LGPL library only under certain conditions. From my
> > understanding, you could have your proprietary code *dynamically
> > link*
> > to an LGPL library, but not *statically link*. With MPL and its
> > level
> > of copyleft propagation, the copyleft is limited to individual
> > files,
> > and does not start defining boundaries for propagation based on how
> > the code is linked. This means that under certain conditions given
> > by
> > the MPL, you could have code from a different license cleanly
> > separated into its own files, that would dynamically or statically
> > link to the MPL code, without having the MPL copyleft propagate to
> > them.
> >
> > With GPL, the copyleft is highly viral: you link to GPL code, your
> > own
> > code must be copyleft, end of the story. Then people start trying to
> > use GPL code from separate processes or over the network to attempt
> > to
> > limit the copyleft propagation, which is why licenses like the AGPL
> > came to existence.
>
> We're trying not to pick a fight with (L)GPL, so we probably won't go
> into too much detail on the differences there. But we can probably
> stand to explain the scope of the copyleft a little better.
I believed that it would be possible to offer a comparison with LGPL without entering into a fight, but I can understand that you don't want to enter into specific comparisons. Maybe at least mention the bare fact that the MPL's file-level copyleft is different from the LGPL's copyleft. After all, the MPL and the LGPL are basically the only two weak-copyleft licenses, so the question of how they differ is inevitable. It should also be possible to illustrate the concept of file-level copyleft with examples without comparing with other licenses.
Benoit
Marc-André Moreau
I agree that we shouldn't start a fight on which copyleft is better, but as
you said, the question on how they differ is inevitable. I think it is
better to clearly define how the MPL is different. I could easily see a lot
of people look into the MPL because they are unsatisfied with the GPL or
LGPL, but do not want to go for a permissive license like Apache, MIT or
BSD. Those people will want to know where the MPL fits, and how it is
different from others. Giving a simple, clear example should be sufficient.
>
> Benoit
>