What "notification" means to me

[Mitchell Baker]

After looking at the notification provisions for a good while with Luis and Gerv, a seemingly simple idea like "notice" has a bunch of ideas in it, and the following questions need to be addressed.

1.  Location of notices - full notice in each file is awkward; move from file to directory or elsewhere?

2.  Content of notices -- do we need everything the MPL currently requires?

3.  Maintenance of notices  -- what's the simplest mechanism that works? 

4.  Placement of notices in new files --  Some new files can be Modifications subject to the MPL, so getting some notice in them could be important. What's a good simple mechanism for this?

5.  Identification of contributors to Covered Code - It's become clear that the current requirements of doing this in the source files themselves are awkward and not working well.  Should the license require some mechanism, or should we leave it to projects to figure out?  

We'll work on these.  If there's an issue that isn't included in that list, let us know.   

mitchell

[Robert Kaiser]

Mitchell Baker wrote:
> *1. Location of notices - *full notice in each file is awkward; move from file
> to directory or elsewhere?

I think a notice in the file is good, esp. in the environment we're
working in at Mozilla that doesn't need any specific opt-in into a
license for being able/allowed to post a patch and get it into the source.

That said, the currently required/used boilerplate is too large, I'd
hope that a notice what license it is and where to find more details,
along with the contributors list, should be enough. Also, the note of
"Original Code", "Initial Developer" and "Contributor(s)" is either
redundant or confusing in many cases.

> *5. Identification of contributors to Covered Code* - It's become clear that the

> current requirements of doing this in the source files themselves are awkward
> and not working well.

I'm not so sure that's clear - actually, I don't think anyone would
update it if it was to be made elsewhere. What people are actually
updating is adding their own name in a file they edit anyhow.

Robert Kaiser

[Mitchell Baker]

On 4/2/10 5:58 AM, Robert Kaiser wrote:
> Mitchell Baker wrote:
>> *1. Location of notices - *full notice in each file is awkward; move
>> from file
>> to directory or elsewhere?
>
> I think a notice in the file is good, esp. in the environment we're
> working in at Mozilla that doesn't need any specific opt-in into a
> license for being able/allowed to post a patch and get it into the
> source.
>
> That said, the currently required/used boilerplate is too large, I'd
> hope that a notice what license it is and where to find more details,
> along with the contributors list, should be enough. Also, the note of
> "Original Code", "Initial Developer" and "Contributor(s)" is either
> redundant or confusing in many cases.

Yes, some sort of stub header which is a pointer to the full text is a
likely solution. And we'll look at whether we need Original code,
Initial Developer, and the copyright language as well.

>
>> *5. Identification of contributors to Covered Code* - It's become
>> clear that the
>> current requirements of doing this in the source files themselves are
>> awkward
>> and not working well.
>
> I'm not so sure that's clear - actually, I don't think anyone would
> update it if it was to be made elsewhere. What people are actually
> updating is adding their own name in a file they edit anyhow.

this surprises me; my understanding is that noting every change and who
made it *in the file* is not a desired practice; am thinking that our
logs may be the best source of info on this.
>
> Robert Kaiser
> _______________________________________________
> governance-mpl-update mailing list
> governance...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/governance-mpl-update

[Luis Villa]

On 4/2/10 5:58 AM, Robert Kaiser wrote:

>> *5. Identification of contributors to Covered Code* - It's become
>> clear that the
>> current requirements of doing this in the source files themselves are
>> awkward
>> and not working well.
>
> I'm not so sure that's clear - actually, I don't think anyone would
> update it if it was to be made elsewhere. What people are actually
> updating is adding their own name in a file they edit anyhow.

If someone has the time, I'd be very curious to see what %age of an
average file's committers actually add themselves to Contributors for
that file. (Or more precisely, given the gap in data caused by the hg
import, the ratio of recorded # of committers to the number of listed
Contributors.)

For example, nsBrowserApp.cpp has only one person listed in
Contributors, where hg blame suggests there are at least five people
who've contributed to the file since the hg import. If this is typical
across a sampling of files in the codebase, that suggests that people
are already ignoring this and moving it to a separate file (or
eliminating it altogether, or what have you) wouldn't radically change
what works in practice. Alternately, if this is atypical, it might be
good to understand why.

Obviously this is just a single example, and Mozilla is an atypical
project in a lot of ways- are other projects here seeing similar
behaviors in their communities?

Luis

--
Luis Villa, Mozilla Legal
work email: lvi...@mozilla.com (preferred)
work phone: 650-903-0800 x327
personal: http://tieguy.org/about/

[Robert Kaiser]

Mitchell Baker wrote:
> On 4/2/10 5:58 AM, Robert Kaiser wrote:
>> I'm not so sure that's clear - actually, I don't think anyone would
>> update it if it was to be made elsewhere. What people are actually
>> updating is adding their own name in a file they edit anyhow.
> this surprises me; my understanding is that noting every change and who
> made it *in the file* is not a desired practice; am thinking that our
> logs may be the best source of info on this.

Not sure how good the info the logs provide is in terms of copyrightable
contributions. You can get lots of coverage by logs when you just
mechanically correct typos in comments and things like that, for example.

Robert Kaiser

[Robert Kaiser]

Luis Villa wrote:
> If someone has the time, I'd be very curious to see what %age of an
> average file's committers actually add themselves to Contributors for
> that file. (Or more precisely, given the gap in data caused by the hg
> import, the ratio of recorded # of committers to the number of listed
> Contributors.)

The usually used rule is to add oneself when you're doing significant
changes to the code - and when you don't add yourself, you don't
consider your changes significant enough that you should be listed as
one of the copyright holders (or you forgot and don't care much to be
mentioned).

I'm not sure how legally correct it is to do things that way - I'm just
describing actual practice here, of course.

Robert Kaiser

[Luis Villa]

Information on actual practice is really good for us to have; the
further we stray from what people actually do, the more justification we
need.

(For what it is worth, the license says anyone who makes any change is a
Contributor, but then says only that Contributors 'may' add a line to
the header- they aren't required to one way or the other.)

[Mike Connor]

On 2010-04-02, at 6:45 PM, Luis Villa <lvi...@mozilla.com> wrote:

> Information on actual practice is really good for us to have; the
> further we stray from what people actually do, the more
> justification we need.
>
> (For what it is worth, the license says anyone who makes any change
> is a Contributor, but then says only that Contributors 'may' add a
> line to the header- they aren't required to one way or the other.)

I'm pretty terrible at this. Unless I'm creating files, I generally
fail on self-identifying. I guess it just feels weird to put that in
a patch.

- Mike

[timeless]

I'm worse. however 99% of my changes are 'trivial' and i don't think
it's useful to have my name in every single mozilla file. and there's
also the minor detail that i decided i didn't really want my real name
and my email address to be connected (certain people have foiled me in
my goal, but if you ignore the module owners page and one hg repo,
i've done a moderately good job).

when i started working on mozilla, there were one or two people who
had left an imprint on a large portion of the codebase, and they were
nearly universally reviled for that.

another problem i have is that my email address has changed w/ time,
and i don't really like inviting people to spam me. traditionally the
line has been of the form:

Real Name <user@employer>

for a while, mozilla.org contributors were changing employers every 2
years, which means half of that information became wrong w/in a few
years (non-deliverable). At first I wasn't changing employers too
often, but I kept losing email addresses. I believe at this point,
each of bemail.org, mac.com and myrealbox.com are dead, and my
mozdev.org account needed an update recently because it was pointing
to one of the dead ones... That isn't counting my current mailboxes
which also roll over every 2-3 years, but which I've managed to keep
safely forwarding (unlike mac/myrealbox/mozdev which were also
forwarders but failed the 'safe' part).

I think the reason email addresses were included was to enable people
to contact contributors with questions, however for mozilla, it's
better for people to use bugzilla, irc, or newsgroups than to contact
people directly. I believe that Gerv has once or twice relied on the
email addresses when trying to contact people about relicensing,
however for mozilla, the bugzilla and commit records should have been
more useful than a likely dead email address in a file.

[Alexis Richardson]

Hi

This is slightly OT for this thread, but one of my gripes with MPL 1.1
is that it does not make it completely clear how the rights of
Contributors differ (if at all) from those of Initial Developers. Can
anyone explain?

alexis

(using MPL with RabbitMQ)

[Luis Villa]

On 4/3/10 5:10 PM, Alexis Richardson wrote:
> Hi
>
> This is slightly OT for this thread, but one of my gripes with MPL 1.1
> is that it does not make it completely clear how the rights of
> Contributors differ (if at all) from those of Initial Developers. Can
> anyone explain?

Mitchell can explain in more detail, perhaps, but the intent is that the
rights/responsibilities aren't substantially different. The distinction
was just intended to help clarify when and how the patent grants kick
in; the Initial Developer gives a grant to the Original Code, while the
Contributors give grants to a slightly more complicated combination of
Contribution + Contributor Version.

Hope that helps clarify.

[Robert Kaiser]

Luis Villa schrieb:

> On 4/3/10 5:10 PM, Alexis Richardson wrote:
>> Hi
>>
>> This is slightly OT for this thread, but one of my gripes with MPL 1.1
>> is that it does not make it completely clear how the rights of
>> Contributors differ (if at all) from those of Initial Developers. Can
>> anyone explain?
>
> Mitchell can explain in more detail, perhaps, but the intent is that the
> rights/responsibilities aren't substantially different. The distinction
> was just intended to help clarify when and how the patent grants kick
> in; the Initial Developer gives a grant to the Original Code, while the
> Contributors give grants to a slightly more complicated combination of
> Contribution + Contributor Version.

Would be nice if we could completely merge those two in the newer
version. That would also fit the goal I would like to see of having the
per-file notice reduced to something like:

/* This file is licensed under the Mozilla Public License (MPL) 2.0
* See the full license text at http://www.mozilla.org/MPL-2.0
* Contributor(s):
* Joe User <joe....@mozilla.com>
* Markus Mustermann <mar...@mustermann.de>
*/

I think something like that would be reasonable, and have a good upgrade
path from the current notices. Of course, I assume here that the new
version makes redistribution/use under GPL or LPGL possible by itself,
so we can strip the whole tri-license part as well.

Robert Kaiser

[Mitchell Baker]

Alexis, Kairo

The distinction was, as Luis says, created primarily for the timing of
when rights and obligations apply. Other than that they were intended
to be (and as far as i know, are) the same. Combining the two into a
single definition is definitely on the list to consider; I think we'll
try to look at that next. You should see that shortly. (I'm on
vacation 3 days next week, so I won't be doing anything then, but soon.)

Robert, as to your suggestion make sense;
the first two lines make sense, we'll probably do something like that.
not sure about tracking contributor(s) , doing it in the file still
seems awkward
i have no idea how we will handle GPL /LGPL yet; if any better
solutions is possible. Would certainly like to simplify, not sure yet.

mitchell

[David Illsley]

<snip>
5.  Identification of contributors to Covered Code- It's become clear

that the current requirements of doing this in the source files
themselves are awkward and not working well.  Should the license
require some mechanism, or should we leave it to projects to figure
out?  

I guess it depends what the purpose of this actually is. I can see it
being potentially useful in the case of copyright/patent/provenance
questions arising over an MPL file you 'find' somewhere - be it via
Google or in some other distribution of code. However the fact that
it's not a requirement mitigates that a bit. If the intention is to
allow contributors to take some credit, then that definitely does seem
like a per-project decision (e.g. the Apache community actively
discourages author marks in source code). Unless there's a legal
requirement that *someone* asserts ownership for the license to
actually work, I don't see a compelling case for it.

David

[Mitchell Baker]

Yes, one big topic to look into is the copyright/patent/provenance
question to raise, both if one finds it as you describe and in the case
of a dispute.
Thanks for the info re Apache, that's helpful. Do you happen to know
how the "provenance" questions are addressed the Apache cases?

mitchell

[Alexis Richardson]

Luis

On Sat, Apr 3, 2010 at 10:09 PM, Luis Villa <lvi...@mozilla.com> wrote:
> On 4/3/10 5:10 PM, Alexis Richardson wrote:
>>
>> Hi
>>
>> This is slightly OT for this thread, but one of my gripes with MPL 1.1
>> is that it does not make it completely clear how the rights of
>> Contributors differ (if at all) from those of Initial Developers.  Can
>> anyone explain?
>
> Mitchell can explain in more detail, perhaps, but the intent is that the
> rights/responsibilities aren't substantially different. The distinction was
> just intended to help clarify when and how the patent grants kick in; the
> Initial Developer gives a grant to the Original Code, while the Contributors
> give grants to a slightly more complicated combination of Contribution +
> Contributor Version.

Thanks, that makes sense.

So the Initial Developer does not have *more* rights than the
Contributor, right? Only more obligations.

alexis

> Hope that helps clarify.

[Alexis Richardson]

+1

[Luis Villa]

On 4/4/10 7:20 AM, Robert Kaiser wrote:
> Luis Villa schrieb:
>> On 4/3/10 5:10 PM, Alexis Richardson wrote:
>>> Hi
>>>
>>> This is slightly OT for this thread, but one of my gripes with MPL 1.1
>>> is that it does not make it completely clear how the rights of
>>> Contributors differ (if at all) from those of Initial Developers. Can
>>> anyone explain?
>>
>> Mitchell can explain in more detail, perhaps, but the intent is that the
>> rights/responsibilities aren't substantially different. The distinction
>> was just intended to help clarify when and how the patent grants kick
>> in; the Initial Developer gives a grant to the Original Code, while the
>> Contributors give grants to a slightly more complicated combination of
>> Contribution + Contributor Version.
>
> Would be nice if we could completely merge those two in the newer
> version.

http://mpl.mozilla.org/scope/initial-distributorcontributor-distinction/ :)

It should be doable, but it is important to get it right, obviously.

[David Illsley]

As far as Apache is concerned, there are 2 aspects (as there is for
Mozilla). There's the License and the Foundation. It was foundation
projects I was referring to. ASF projects use CLAs and explicit grants
(SGA) [1] to ensure the provenance of code in foundation repositories
and releases. Those processes mean that it's possible to examine
Foundation source control systems+mail archives to answer provenance
questions. Author marks are then removed from individual files because
(AIUI) they imply individual rather than community ownership of files.
HTH.
David

[1] http://www.apache.org/licenses/

> > governance-mpl-upd...@lists.mozilla.org
> >https://lists.mozilla.org/listinfo/governance-mpl-update

[Mitchell Baker]

Oh yes, that's helpful to know. Thanks a bunch.

ml

[Gervase Markham]

On 02/04/10 19:01, Luis Villa wrote:
> If someone has the time, I'd be very curious to see what %age of an
> average file's committers actually add themselves to Contributors for
> that file.

I don't have stats, but I strongly suspect it's not more than 50%, and
probably much less.

Manual maintenance is not a useful way to construct a list of copyright
owners, IMO.

Gerv

[Mitchell Baker]

On 4/4/10 5:05 PM, Alexis Richardson wrote:
>
> Thanks, that makes sense.
>
> So the Initial Developer does not have *more* rights than the
> Contributor, right?

Right, that's the intent. Note that an Initial Developer of new code
(code that is not a Modification) can always decide whether or not
something new is covered by the MPL in the first place.
> Only more obligations.
>
>
I'm not sure there are *more* obligations. The obligations (or license
grants) will be effective at different times.
> alexis
>
>
>
>
>

mitchell

[Alexis Richardson]

Thanks Mitchell.

I've had all sorts of arguments with people as to who can 'relicense'
MPL code and under what terms. The Initial Developer vs Contributor
has (believe it or not) been read by some as allowing the former more
rights over that than the latter. Hence my question.

And, in general, it would be good for MPL2 to be super clear about who
can relicense and to what and when.

alexis

[timeless]

[disclaimer: IANAL, this is not legal advice, consult an attorney]

On Thu, Apr 8, 2010 at 1:16 AM, Alexis Richardson
<alexis.r...@gmail.com> wrote:
> I've had all sorts of arguments with people as to who can 'relicense'
> MPL code and under what terms.  The Initial Developer vs Contributor
> has (believe it or not) been read by some as allowing the former more
> rights over that than the latter.  Hence my question.

wow, that's unfortunate. In general any licensing scheme which doesn't
provide assignment or have a special update clause does not entitle an
initial developer the ability to change the license on any work for
which there is a copyrighted bit owned by someone else.

FSF uses copyright assignment: http://www.gnu.org/licenses/why-assign.html

MPL has an update bit (which enabled mpl1.0 to be updated to mpl1.1,
and which in theory should enable mpl1.1 to be updated to mpl2).

Note that when mozilla.org wanted to add GPL and later LGPL licenses,
mozilla.org had to go collect approval from all contributors, not just
the ones who contributed 'original code'. I think a number of us
remember the pain involved and assumed that since it made news
worldwide other people would be aware of it:
http://www-archive.mozilla.org/MPL/relicensing-faq.html

> And, in general, it would be good for MPL2 to be super clear about who
> can relicense and to what and when.

http://www.apache.org/dev/apply-license.html is an interesting
document. Is it sort of what you're looking for?

Note that for MPL, there was an annotated version:
http://www.mozilla.org/MPL/MPL-1.1-annotated.html

although it sadly doesn't answer all questions.

[Alexis Richardson]

Sorry to topline this...

Thanks for reminding me of those links. And yes something like the
ASF statement would be helpful.

So let me try and point out reasons why people might get confused.

1. http://www.gnu.org/licenses/why-assign.html

This uses vague phrases like "substantial procedural advantages",
"generally not possible", "most effectively". The only actual claim
that I can see is "only the copyright holder or someone having
assignment of the copyright can enforce the license". But, in the
case of MPL, what does 'enforce' mean?

2. http://www-archive.mozilla.org/MPL/relicensing-faq.html

"If such files remain under their current licenses, then there are two
possible outcomes: If one or more of the files in question are
currently licensed under the MPL (only), then code in those files may
be used by developers creating and distributing Mozilla-based products
under the MPL or proprietary licenses, but may not be used by
developers creating and distributing software under the LGPL or GPL."

Suppose party A, an Initial Developer, has copyright to 50000 LOC of
some codebase, and the same codebase has another 50000 LOC which are
copyright another party B acting as Contributor. Then exactly which
licenses can A use to license the whole codebase of 100000 LOC?

alexis

[timeless]

[standard disclaimer]

On Thu, Apr 8, 2010 at 2:31 AM, Alexis Richardson
<alexis.r...@gmail.com> wrote:
> Suppose party A, an Initial Developer, has copyright to 50000 LOC of
> some codebase, and the same codebase has another 50000 LOC which are
> copyright another party B acting as Contributor.  Then exactly which
> licenses can A use to license the whole codebase of 100000 LOC?

so, licenses can be at any level.

GPL is roughly speaking an application license.
LGPL is roughly speaking a library license.
MPL is roughly speaking a source file license.

BSD in interesting flavors can have non BSD insertions which are
essentially source paragraph licensed.

In order to use a set of files (A.c, B.c, D.c) you need to find a set
of compatible licenses.

It's easier to pick incompatible licenses.

A-gpl.c is incompatible with B-mpl.c, so you can't generally produce
anything from that pair.

UNLESS, you happen to be the only contributor to one of A-gpl.c or
B-mpl.c, in which case you can using your _ownership_ of the file do
something to the file under any other license of your choice. But this
isn't something enabled by the license assigned to the file, it's
enabled by your ownership of the contents of the file.

Let's say that you were the only contributor to A-gpl.c and there are
two contributors (you and me) to B-mpl.c

You could ignore the license listed in A-gpl.c and use it with B-mpl.c
as long as you can satisfy the requirements of B-mpl.c. Since MPL is a
per file license, that's trivial.

Now, if I contribute a copyrightable change to A-gpl.c under the terms
of the GPL, and you want to take A-gpl-with-my-changes.c and use it
with B-mpl.c, you're in trouble. You can't use the magic trick you
used earlier. You have two basic choices:
1. ask me for permission to relicense my changes under another license
(e.g. MPL)
2. take a version which doesn't have my contribution (A-gpl.c)

More people contributing more changes to files under licenses which
will not be compatible with a goal you have will result in more
headaches.

That's the general idea. Basically you don't want to try to mix
licenses, and you don't want to try to change them. You should aim to
pick a license in advance which will satisfy your needs as well as
those of your potential contributors.

[Mike Connor]

On 2010-04-07, at 7:31 PM, Alexis Richardson wrote:

> 2. http://www-archive.mozilla.org/MPL/relicensing-faq.html
>
> "If such files remain under their current licenses, then there are two
> possible outcomes: If one or more of the files in question are
> currently licensed under the MPL (only), then code in those files may
> be used by developers creating and distributing Mozilla-based products
> under the MPL or proprietary licenses, but may not be used by
> developers creating and distributing software under the LGPL or GPL."
>

> Suppose party A, an Initial Developer, has copyright to 50000 LOC of
> some codebase, and the same codebase has another 50000 LOC which are
> copyright another party B acting as Contributor. Then exactly which
> licenses can A use to license the whole codebase of 100000 LOC?

IANAL, but generally copyright holders control relicensing. If two parties have copyright over portions of something, they have to agree on a license change. I can't contribute code to project X, then relicense all of project X as I see fit, unless the license allows me that freedom.

-- Mike

[Mitchell Baker]

O
> And, in general, it would be good for MPL2 to be super clear about who
> can relicense and to what and when.
>

> alexis
>
>
>
>
ah, that's good to know, thanks!

mitchell

[Alexis Richardson]

@timeless

I understand all that. In the case of the GPL there is a known MPL
1.x incompatibility issue that makes composite works undistributable.

The question is *which* licenses are problematic wrt the MPL and
*which are not* and why?

For example consider files A.c and B.c both being MPL and copyright A
and B respectively. Let's also (iiuc, wlog) assume A is the I/Dev of,
and B the Contributor to, some hypothetical larger project
"licensezilla" made out of A.c and B.c. Can A offer licensezilla
under a commercial license of their choosing? It would appear the
answer is Yes. Can A offer licensezilla under the MPL? Again, Yes.
Can A offer licensezilla under an open source license of their
choosing that is NOT the MPL? It would appear the answer is "not the
GPL but in other cases it depends"...?

alexis

On Thu, Apr 8, 2010 at 1:00 AM, timeless <time...@gmail.com> wrote:
> [standard disclaimer]
>
> On Thu, Apr 8, 2010 at 2:31 AM, Alexis Richardson
> <alexis.r...@gmail.com> wrote:

>> Suppose party A, an Initial Developer, has copyright to 50000 LOC of
>> some codebase, and the same codebase has another 50000 LOC which are
>> copyright another party B acting as Contributor.  Then exactly which
>> licenses can A use to license the whole codebase of 100000 LOC?
>

[Alexis Richardson]

Mike

On Thu, Apr 8, 2010 at 1:18 AM, Mike Connor <mco...@mozilla.com> wrote:
>
> On 2010-04-07, at 7:31 PM, Alexis Richardson wrote:
>
>> 2. http://www-archive.mozilla.org/MPL/relicensing-faq.html
>>
>> "If such files remain under their current licenses, then there are two
>> possible outcomes: If one or more of the files in question are
>> currently licensed under the MPL (only), then code in those files may
>> be used by developers creating and distributing Mozilla-based products
>> under the MPL or proprietary licenses, but may not be used by
>> developers creating and distributing software under the LGPL or GPL."
>>

>> Suppose party A, an Initial Developer, has copyright to 50000 LOC of
>> some codebase, and the same codebase has another 50000 LOC which are
>> copyright another party B acting as Contributor.  Then exactly which
>> licenses can A use to license the whole codebase of 100000 LOC?
>

> IANAL, but generally copyright holders control relicensing.  If two parties have copyright over portions of something, they have to agree on a license change.  I can't contribute code to project X, then relicense all of project X as I see fit, unless the license allows me that freedom.

Understood, my question concerns the possibility of multiple differing
interpretations of what freedoms are allowed with respect to which
closed or open licenses are used for X.

alexis

[timeless]

On Thu, Apr 8, 2010 at 6:31 AM, Alexis Richardson
<alexis.r...@gmail.com> wrote:
> @timeless
>
> I understand all that.  In the case of the GPL there is a known MPL
> 1.x incompatibility issue that makes composite works undistributable.
>
> The question is *which* licenses are problematic wrt the MPL and
> *which are not* and why?

there are roughly speaking an infinite number of licenses. and trying
to maintain a list is mostly impractical.

IMO, MPL is only incompatible w/ GPL/LGPL because FSF says it is.
There are people who believe otherwise. However, given that it's the
generally accepted view, I wouldn't suggest challenging it....

the general idea is that licensing is a spectrum....

Public Domain
MIT
BSD
Artistic
MPL
LGPL
GPL

Generally, things closer to public domain can be included by things
further from it, but not necessarily the other way around.

If you're trying to decide if you can mix two licenses, you really
should engage a lawyer.

> For example consider files A.c and B.c both being MPL and copyright A
> and B respectively.  Let's also (iiuc, wlog) assume A is the I/Dev of,
> and B the Contributor to, some hypothetical larger project
> "licensezilla" made out of A.c and B.c.  Can A offer licensezilla
> under a commercial license of their choosing?  It would appear the
> answer is Yes.  Can A offer licensezilla under the MPL?  Again, Yes.
> Can A offer licensezilla under an open source license of their
> choosing that is NOT the MPL?  It would appear the answer is "not the
> GPL but in other cases it depends"...?

Again, you generally can't relicense a file to which you don't own
100% of the copyright.

One thing to keep in mind is that MPL is a source code license, GPL
roughly speaking operates on the binary. So as it happens, with MPL
you can provide a distribution license on the resulting binary as long
as the license doesn't make any claims that violate MPL and as long as
the terms of MPL are satisfied. MPL amongst other things will (roughly
speaking) require you to provide the changes you've made to A.c and
B.c.

If you own the entire file A.c, then you could in theory choose to
ignore the printed license on A.c, but it would generally speaking not
be a good idea, you're likely to get confused, and what's the point?
The reason for licensing under MPL is to get changes back, if you make
an improvement which introduces a bug and someone else can't see the
change you've made and thus can't fix it, you've defeated the benefit
you could have received under MPL. If you need a file which is
private, MPL suggests that you take that source file and license it
without the MPL (roughly "this file is (c) A, and proprietary. Source
release isn't authorized")

With MPL, you have two files A.c and B.c under MPL, you can then
choose to produce a binary and offer it under some other license. The
license can be pretty much anything as long as it doesn't make a
promise you can't keep. Since you can't relicense B.c under GPL, you
can't make your binary available as GPL since you can't satisfy the
GPL requirements of providing B.c under GPL. Most commercial licenses
make no promises about source code, and thus don't run afoul of MPL.

Note that Mozilla Corporation (iirc) provides Firefox under a binary
license. As long as the license doesn't make claims that Mozilla
Corporation can't keep, there isn't a problem with this. Part of the
reason for doing something like this is to prevent people from taking
the product, adding a virus (or some other malware) and claiming it's
Mozilla Corporation's Firefox. Doing this would be perfectly
acceptable under MPL, but it's a violation of the license provided
with the binary, and that's what would enable Mozilla Corporation to
seek damages.

Again, this is all very rough, and I'm making tentative suggestions
about what Mozilla Corporation might do (which is probably a bad idea
-- one shouldn't make claims about other entities...). License
compatibility is basically established by reading the pair of licenses
together to see if they make contradicting claims. If they do such
that you can't satisfy both sets of claims, they aren't compatible,
and you probably can't/shouldn't use them.

[Alexis Richardson]

@timeless

Thanks for taking the time to reply. More below...

On Thu, Apr 8, 2010 at 9:53 AM, timeless <time...@gmail.com> wrote:
> On Thu, Apr 8, 2010 at 6:31 AM, Alexis Richardson
> <alexis.r...@gmail.com> wrote:
>> @timeless
>>
>> I understand all that.  In the case of the GPL there is a known MPL
>> 1.x incompatibility issue that makes composite works undistributable.
>>
>> The question is *which* licenses are problematic wrt the MPL and
>> *which are not* and why?
>
> there are roughly speaking an infinite number of licenses. and trying
> to maintain a list is mostly impractical.

Indeed, but the legalese apparently does not imply a predicative
definition either.

> IMO, MPL is only incompatible w/ GPL/LGPL because FSF says it is.
> There are people who believe otherwise. However, given that it's the
> generally accepted view, I wouldn't suggest challenging it....

Yes, I have noticed this. I am among those who believe the FSF
interpretation to be uncharitable, yet alas also unchallengeable.

> the general idea is that licensing is a spectrum....
>
> Public Domain
> MIT
> BSD
> Artistic
> MPL
> LGPL
> GPL
>
> Generally, things closer to public domain can be included by things
> further from it, but not necessarily the other way around.

I agree, but the problem I am trying to get at, is that this spectrum
is a matter of interpretation made difficult by vague license terms.
Where does Apache fit in for example, or EPL? There seems to be a
partial and not a total order, with a number of obscure
incompatibilities.

One of the reasons we chose MPL 1.1 for RabbitMQ, back in late 2006,
was that it is one of the clearest licenses. But, it could be clearer
;-)

> If you're trying to decide if you can mix two licenses, you really
> should engage a lawyer.

See, it should rarely be necessary to engage lawyers. The fact that
it is, suggests complexity and hampers adoption.

>> For example consider files A.c and B.c both being MPL and copyright A
>> and B respectively.  Let's also (iiuc, wlog) assume A is the I/Dev of,
>> and B the Contributor to, some hypothetical larger project
>> "licensezilla" made out of A.c and B.c.  Can A offer licensezilla
>> under a commercial license of their choosing?  It would appear the
>> answer is Yes.  Can A offer licensezilla under the MPL?  Again, Yes.
>> Can A offer licensezilla under an open source license of their
>> choosing that is NOT the MPL?  It would appear the answer is "not the
>> GPL but in other cases it depends"...?
>
> Again, you generally can't relicense a file to which you don't own
> 100% of the copyright.

Sorry, I was perhaps not clear enough: By "project" I mean Larger Work.

As in:

3.7. Larger Works.
You may create a Larger Work by combining Covered Code with other code
not governed by the terms of this License and distribute the Larger
Work as a single product. In such a case, You must make sure the
requirements of this License are fulfilled for the Covered Code.

So let's say that:

* A is the Initial Dev and creates A.c under MPL
* B is a Contributor of B.c under MPL
* A creates a Larger Work, "licensezilla" in which B.c is unmodified
* A distributes licensezilla as an executable

Then:

* Can A license the binary of licensezilla any way it likes? MPL 3.6
would appear to imply the answer is Yes, and from what you wrote
(below) I think you would agree because B.c is unchanged.
* Does A being the Initial Dev give it any privileges in relation to
the previous question, compared to some third party C?

And, in the above:

* Does the answer change if the licensezilla license is commercial vs
open source?
* Does the answer change if licensezilla is distributed only as a
source code bundle?

> One thing to keep in mind is that MPL is a source code license, GPL
> roughly speaking operates on the binary. So as it happens, with MPL
> you can provide a distribution license on the resulting binary as long
> as the license doesn't make any claims that violate MPL and as long as
> the terms of MPL are satisfied. MPL amongst other things will (roughly
> speaking) require you to provide the changes you've made to A.c and
> B.c.
>
> If you own the entire file A.c, then you could in theory choose to
> ignore the printed license on A.c, but it would generally speaking not
> be a good idea, you're likely to get confused, and what's the point?
> The reason for licensing under MPL is to get changes back, if you make
> an improvement which introduces a bug and someone else can't see the
> change you've made and thus can't fix it, you've defeated the benefit
> you could have received under MPL. If you need a file which is
> private, MPL suggests that you take that source file and license it
> without the MPL (roughly "this file is (c) A, and proprietary. Source
> release isn't authorized")
>
> With MPL, you have two files A.c and B.c under MPL, you can then
> choose to produce a binary and offer it under some other license. The
> license can be pretty much anything as long as it doesn't make a
> promise you can't keep. Since you can't relicense B.c under GPL, you
> can't make your binary available as GPL since you can't satisfy the
> GPL requirements of providing B.c under GPL. Most commercial licenses
> make no promises about source code, and thus don't run afoul of MPL.

OK.

> Note that Mozilla Corporation (iirc) provides Firefox under a binary
> license. As long as the license doesn't make claims that Mozilla
> Corporation can't keep, there isn't a problem with this. Part of the
> reason for doing something like this is to prevent people from taking
> the product, adding a virus (or some other malware) and claiming it's
> Mozilla Corporation's Firefox. Doing this would be perfectly
> acceptable under MPL, but it's a violation of the license provided
> with the binary, and that's what would enable Mozilla Corporation to
> seek damages.
>
> Again, this is all very rough, and I'm making tentative suggestions
> about what Mozilla Corporation might do (which is probably a bad idea
> -- one shouldn't make claims about other entities...). License
> compatibility is basically established by reading the pair of licenses
> together to see if they make contradicting claims. If they do such
> that you can't satisfy both sets of claims, they aren't compatible,
> and you probably can't/shouldn't use them.

Yes, and again thanks for taking time to write up your thoughts on this.

I think the whole issue of source vs binary licensing is really
interesting, especially for 'commercial open source' providers who -
like us - don't like the 'dual GPL license' approach.

Another area of interest is the whole game around attribution, mark
enforcement, and passing off. For those who did not follow it, the
discussion between the IETF and Debian community was fascinating:
http://www.mail-archive.com/debian...@lists.debian.org/msg38567.html

alexis

[timeless]

On Thu, Apr 8, 2010 at 12:28 PM, Alexis Richardson
<alexis.r...@gmail.com> wrote:
> I agree, but the problem I am trying to get at, is that this spectrum
> is a matter of interpretation made difficult by vague license terms.
> Where does Apache fit in for example, or EPL?

so, from memory I believe that Apache and EPL are roughly near MPL on
my scale. However from memory there's some incompatibility floating
around there. I haven't spent much time recently (or even generally)
reading them to remember how they interact. So I think I'm just going
to pass -- hopefully someone else can comment.

> There seems to be a
> partial and not a total order, with a number of obscure
> incompatibilities.

That's about right, sadly.

> One of the reasons we chose MPL 1.1 for RabbitMQ, back in late 2006,
> was that it is one of the clearest licenses.  But, it could be clearer

Yep

> See, it should rarely be necessary to engage lawyers.  The fact that
> it is, suggests complexity and hampers adoption.

Yes and Yes

> Sorry, I was perhaps not clear enough: By "project" I mean Larger Work.

> * A is the Initial Dev and creates A.c under MPL
> * B is a Contributor of B.c under MPL
> * A creates a Larger Work, "licensezilla" in which B.c is unmodified
> * A distributes licensezilla as an executable

> * Can A license the binary of licensezilla any way it likes?

essentially, yes.

> MPL 3.6 would appear to imply the answer is Yes, and from what you wrote
> (below) I think you would agree because B.c is unchanged.

yep.

> * Does A being the Initial Dev give it any privileges in relation to
> the previous question, compared to some third party C?

A being the only author of a document gives it more privs than a third
party C, but only while no one else has contributed to it.

> * Does the answer change if the licensezilla license is commercial vs
> open source?

Only to the extent that commercial licenses rarely say anything about
source code and thus are less likely to contradict the source license.

As long as the open source license doesn't make any contradictory
claims (which it sadly is likely to do), then it's just as possible.

In reality you're probably going to have a "commercial" license which says:
* This commercial license disclaims any warranty and liability.
* [Re]Distribution [is | is not] allowed
* A fee [may | may not] be charged for distribution
* You may not use our name to endorse your product
* You may use this product for personal, private, commercial, and public use.
* We make no claims about the source code, however, because we're
feeling nice, we'd like to note that it's based on A.c and B.c which
are available under MPL, for more information, see: <url>

> * Does the answer change if licensezilla is distributed only as a
> source code bundle?

BTW, *-zilla is subject to a claim by Toho Co.,
http://www.wired.com/threatlevel/2008/11/godzilla-terror/ is the first
Google hit for this subject. I'd suggest picking something else as
your sample "AcmeWidgetMaker".

For source code bundles, you shouldn't really provide any additional
license. Instead, each file should be provided as is, with its
original license exactly as you retrieved it.

> Another area of interest is the whole game around attribution, mark
> enforcement, and passing off.  For those who did not follow it, the
> discussion between the IETF and Debian community was fascinating:
> http://www.mail-archive.com/debian...@lists.debian.org/msg38567.html

I'm going to have to add that to my reading list. But as with the url
I offered above, somehow I don't think it'll make good bedtime
reading... too likely to lead to nightmares.

[Alexis Richardson]

Thanks, that is an excellent answer.

Re EPL, yes it's a lot like MPL and yes it's another license I
personally would rather not be incompatible with ;-)

So, to TPTB at mozilla.org, I would be thrilled if an MPL2 could make
Q&A of the type this thread has included, unnecessary.

alexis

[Luis Villa]

On 4/2/10 11:01 AM, Luis Villa wrote:
> If someone has the time, I'd be very curious to see what %age of an
> average file's committers actually add themselves to Contributors for

> that file. (Or more precisely, given the gap in data caused by the hg
> import, the ratio of recorded # of committers to the number of listed
> Contributors.)

Last week at a conference I met the author of this paper:
http://turingmachine.org/~dmg/papers/#sec-3.2.1

It is about Seamonkey (and other projects) rather than Firefox, but some
interesting data in there. The question I asked above is not directly
answered, but more than 1/2 of Mozilla committers have never formally
listed themselves as a Contributor in any file; the ratio is similar for
other projects studied (Samba, Squid, and ArgoUML.)

Intuitively, commits that included a change to the Contributor list were
likely to be much larger than commits that did not include such a change.

Unintuitively, people who didn't list themselves contributed
substantially more lines of code, on average, than people who did list
themselves. I think that may be an artifact of how the history was
taken, but if it is correct, it suggests that lots of major committers
do not formally mark themselves as Contributors.

Ultimately I don't think this tells us much about what MPL should
require, but it does strongly suggest that lots of code and lots of
coders are not represented in our current Contributor lists- even more
than I assumed, frankly.

[timeless]

On Mon, Apr 12, 2010 at 11:58 PM, Luis Villa <lvi...@mozilla.com> wrote:
> Last week at a conference I met the author of this paper:
> http://turingmachine.org/~dmg/papers/#sec-3.2.1

> Intuitively, commits that included a change to the Contributor list were

> likely to be much larger than commits that did not include such a change.
>
> Unintuitively, people who didn't list themselves contributed substantially
> more lines of code, on average, than people who did list themselves. I think
> that may be an artifact of how the history was taken, but if it is correct,
> it suggests that lots of major committers do not formally mark themselves as
> Contributors.

One thing about Mozilla, which I'm not certain they took into account
is that for CVS the committer is not necessarily the author. It looks
like they only checked the license header block and the cvs committer.
Some of us in cvs times were doing commits on behalf of other people,
in which case the commit message had the actual author.

I'm not sure this would matter much. However it probably results in a
significant underrepresentation of minor contributors, because we'd
rarely be adding it for them.

> Ultimately I don't think this tells us much about what MPL should require,
> but it does strongly suggest that lots of code and lots of coders are not
> represented in our current Contributor lists- even more than I assumed,
> frankly.

This doesn't surprise me.

[Luis Villa]

On 4/12/10 2:41 PM, timeless wrote:
> On Mon, Apr 12, 2010 at 11:58 PM, Luis Villa<lvi...@mozilla.com> wrote:
>> Last week at a conference I met the author of this paper:
>> http://turingmachine.org/~dmg/papers/#sec-3.2.1
>
>> Intuitively, commits that included a change to the Contributor list were
>> likely to be much larger than commits that did not include such a change.
>>
>> Unintuitively, people who didn't list themselves contributed substantially
>> more lines of code, on average, than people who did list themselves. I think
>> that may be an artifact of how the history was taken, but if it is correct,
>> it suggests that lots of major committers do not formally mark themselves as
>> Contributors.
>
> One thing about Mozilla, which I'm not certain they took into account
> is that for CVS the committer is not necessarily the author.

Probably the case with most projects of any significant size (though at
least with git this is now trackable- is that also the case with hg?),
and no, as far as I can tell no correction is made.

> I'm not sure this would matter much. However it probably results in a
> significant underrepresentation of minor contributors, because we'd
> rarely be adding it for them.

And some overrepresentation of those who commit a lot of other people's
code.

>> Ultimately I don't think this tells us much about what MPL should require,
>> but it does strongly suggest that lots of code and lots of coders are not
>> represented in our current Contributor lists- even more than I assumed,
>> frankly.
>
> This doesn't surprise me.

It doesn't surprise you that my assumptions are off? :) Seriously, I
mostly mentioned it because it puts some hard data to what I think most
of us already assumed.

It definitely confirms that if we want to do code forensics on our
current codebase, we need to go well beyond the Contributor line;
unfortunately all the surveyed projects have optional Contributor lines,
so it is hard to conclude whether or not making such a thing mandatory
would help resolve that problem.