Re: MPL Upgrade for the Mozilla Project
Johnathan Nightingale
First, Gerv, I just wanted to say that this process note and the FAQ with more detail is written brilliantly. Clear, well motivated, anticipated questions I did actually have (despite tracking the process as closely as I could) and answered them well. I feel better informed and more supportive of the process because of your writing.
Second, on a very mechanical note, you list mozilla-inbound and tracemonkey on the merge list even though they are just feeders for mozilla-central. I think I would have expected mozilla-central to be enough, and the feeder repos to implicitly face a giant-but-uneventful merge. If that's not the case for some reason, then we probably want the fx-team repo on there too but, again, I think it would be fine to declare a relicensing day and have the feeder repos do a one time re-merge.
In any event, thank you all for the work you've done on this important project.
J
On 2011-08-18, at 8:09 AM, Gervase Markham wrote:
> Mozilla is on the verge of completing an 18-month process to revise the
> Mozilla Public License (MPL), the licence it has used for most new code
> since the original release of the source code in 1998. MPL 2 is about
> half the length of MPL 1.1, has many provisions removed which have
> become onerous to comply with, and has better compatibility with other
> licences.
>
> Many in the Mozilla community, including the project leadership, have
> reviewed drafts of the upcoming version and are eager to adopt it, in
> place of the tri-licensing scheme we currently use. (The MPL 2 is
> compatible with the LGPL and GPL, like the tri-licence.) We'd like to
> make sure all of the Mozilla community is aware that a decision on
> upgrading our code to the MPL 2 will be made shortly, and if there are
> any issues with doing so, we'd like to know about them before the
> licence is finalized.
>
> We invite project participants to review the licence and raise any
> issues or questions they may have.
>
> http://mpl.mozilla.org/participate/rc/
>
> There is a document about the upgrade process, which explains how we
> would go about it. Feedback on the proposals therein - both in mechanism
> and scope - is also very welcome.
>
> https://wiki.mozilla.org/MPL_Upgrade
>
> Feedback can be sent to the mozilla.governance discussion forum. Please
> respect Followup-To/Reply-To.
>
> Gerv
>
> _______________________________________________
> governance mailing list
> gover...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/governance
---
Johnathan Nightingale
Director of Firefox Engineering
joh...@mozilla.com
Benjamin Smedberg
> There is a document about the upgrade process, which explains how we
> would go about it. Feedback on the proposals therein - both in mechanism
> and scope - is also very welcome.
>
> https://wiki.mozilla.org/MPL_Upgrade
> More specifically, we would write (or repurpose) a script to replace
> existing tri-licence blocks with the MPL 2 boilerplate (which is only
> 3 lines long). We would run it against the following repositories:
>
> * mozilla-central / mozilla-inbound
> * comm-central
> * tamarin-redux
> * camino
> * tracemonkey
> * dom-inspector
> * venkman
> * chatzilla
> * l10n-central
> * Any active labs projects using the MPL
> * NSS trunk (which is still in CVS)
>
> /If you feel this list is incorrect by omission or commission, please
> let us know./
>
> Some repositories such as release repositories are effectively forks
> of some of the above code from earlier points in time. We would not
> plan to upgrade the licence on those repositories, but just let them
> fall out of use naturally.
>
> Merges from other repositories into mozilla-central would need to have
> the license upgraded before the merge was permitted.
>
On a technical note, we need to tread carefully when dealing with
project/integration repositories which feed into mozilla-central. I do
not think that we should run the licensing script on these other repos
at the same time as mozilla-central, because you will be making changes
in two different trees which can confuse history or cause merge issues.
Instead, we should make the big change in mozilla-central, and then
merge m-c into the project repos, which may also need to make changes to
newly-added files before merging back.
--BDS
Axel Hecht
That said, you're listing l10n-central.
l10n-central is not worked on by all contributors today, I think that
going to releases/l10n/mozilla-aurora is more like it. We should
carefully schedule this and message it. Schedule should likely include a
careful synchronization with the release cycle, of which I don't yet
know which is best. Also, we want to make sure that the majority of our
localizers and their mentors are back from vacation, and not on vacation
again yet.
Axel
Ehsan Akhgari
> On 8/18/2011 11:09 AM, Gervase Markham wrote:
>> There is a document about the upgrade process, which explains how we
>> would go about it. Feedback on the proposals therein - both in mechanism
>> and scope - is also very welcome.
>>
>> https://wiki.mozilla.org/MPL_Upgrade
>
As far as I know, this should work just fine, and the merge is going to
be able to figure this out correctly.
> Instead, we should make the big change in mozilla-central, and then
> merge m-c into the project repos, which may also need to make changes to
> newly-added files before merging back.
That definitely makes more sense to me, though.
At any rate, I would be happy to act as the mercurial bot for this
project. :-)
Ehsan
Gervase Markham
newsgroup.]
Mozilla is on the verge of completing an 18-month process to revise the
Mozilla Public License (MPL), the licence it has used for most new code
since the original release of the source code in 1998. MPL 2 is about
half the length of MPL 1.1, has many provisions removed which have
become onerous to comply with, and has better compatibility with other
licences.
Many in the Mozilla community, including the project leadership, have
reviewed drafts of the upcoming version and are eager to adopt it, in
place of the tri-licensing scheme we currently use. (The MPL 2 is
compatible with the LGPL and GPL, like the tri-licence.) We'd like to
make sure all of the Mozilla community is aware that a decision on
upgrading our code to the MPL 2 will be made shortly, and if there are
any issues with doing so, we'd like to know about them before the
licence is finalized.
We invite project participants to review the licence and raise any
issues or questions they may have.
http://mpl.mozilla.org/participate/rc/
There is a document about the upgrade process, which explains how we
would go about it. Feedback on the proposals therein - both in mechanism
and scope - is also very welcome.
https://wiki.mozilla.org/MPL_Upgrade
Feedback can be sent to the mozilla.governance discussion forum. Please
respect Followup-To/Reply-To.
Gerv
Gervase Markham
> Distraction 1, I can't find the original post on news.m.o :-/
Yes, nor me. I'm not sure what has happened there.
> That said, you're listing l10n-central.
>
> l10n-central is not worked on by all contributors today, I think that
> going to releases/l10n/mozilla-aurora is more like it. We should
> carefully schedule this and message it. Schedule should likely include a
> careful synchronization with the release cycle, of which I don't yet
> know which is best. Also, we want to make sure that the majority of our
> localizers and their mentors are back from vacation, and not on vacation
> again yet.
I'm very happy to take direction from you on how exactly we manage this
for the l10n repos. Just tell me what to write :-)
If we upgrade releases/l10n/mozilla-aurora, is that the highest
upstream? If not, will people "merging downwards" end up de-upgrading
the licence?
I agree we need to pick the right moment, and I don't know exactly when
that is yet. It depends on how long this discussion goes on for, and if
problems are raised.
I don't think it particularly requires people being back from vacation -
in fact, if they are on vacation, that means they will not be trying to
check in while we are doing the upgrade :-) They can just come back and
hg pull -u.
Gerv
Gervase Markham
> Instead, we should make the big change in mozilla-central, and then
> merge m-c into the project repos, which may also need to make changes to
> newly-added files before merging back.
You and johnath makes a quorum, so I will update the wiki page accordingly.
Gerv
Gervase Markham
> merge m-c into the project repos, which may also need to make changes to
> newly-added files before merging back.
You and johnath makes a quorum, so I will update the wiki page accordingly.
Gerv
Justin Wood (Callek)
My very simple comment to this relates to the boilerplate you plan to
use, specifically:
#1 - adjusting to be https://mozilla.org/MPL/2.0/ gives an invalid cert
warning, (cert only valid for *.mozilla.org)
#2 - Accepting the invalid cert for https://mozilla.org/MPL/2.0/ redirs
to *http*://mozilla.org/MPL/2.0/
#3 - I feel we *should* serve that as https, so specifically
https://www.mozilla.org/MPL/2.0/
If we do serve by https by default, we should of course, not obscure the
http:// accessible version.
I of course, don't have any strong data saying we should do this, more
just a strong opinion.
--
~Justin Wood (Callek)
Gervase Markham
> #3 - I feel we *should* serve that as https, so specifically
> https://www.mozilla.org/MPL/2.0/
This is the heart of your comment. Why should we serve the licence as HTTPS?
At the moment, given the way our webserver is configured, that makes the
URL 5 chars longer. This could tip it over from N to N+1 lines of
comment in thousands of files. What's the benefit? :-) I believe the web
should use HTTPS much more than it does, but I'm not seeing the use case
here.
Gerv
Justin Wood (Callek)
Could or Does, the distinction I think is relevant here.
If in *our* code it does then lets stick with the current, if it does
NOT then the point is moot, imo. and we should use the https:// (imo).
--
~Justin Wood (Callek)
Mounir Lamouri
> There is a document about the upgrade process, which explains how we
> would go about it. Feedback on the proposals therein - both in mechanism
> and scope - is also very welcome.
>
> https://wiki.mozilla.org/MPL_Upgrade
(CC-ing dev-planning because some dev-planning readers could be interested)
I see in the document that you plan to keep the per-file list of
contributors. I wonder if we shouldn't use the change of MPL boiler
plate to get ride of this list.
I don't know the real reasons why this list has been added first but I
can imagine three reasons:
1. licensing: having the list of contributors to ask if we want to
re-license the file. Though, the list is far from exhaustive and hg
blame would be much more useful (even if not perfect given that a few
commits don't carry the correct author and some file would require cvs
blame too);
2. who knows about this code: when I began to hack into the Mozilla code
base, I was trying to reach people in this list and I quickly realized
that was a waste of time: some people appearing here knew the code 10
years ago, some just wrote a one-line patch and some did a major rewrite
but do not appear. It happens that the list is seriously misleading for
a new contributor;
3. pride: if we look carefully, we can see that some contributors put
themselves in the list as soon as they write a change and some do not
seem to care that much.
So, instead of a per-file list of contributors, I would like to propose
to have a per-repository list of contributor. IOW, instead of having one
list at the top of each file, we would have a file named CONTRIBS (or
CONTRIBUTORS, or anything...) at the root of the repository, with the
list of all contributors who did contribute to source code in the
repository.
I think this solution doesn't make the first point really harder (though
not easier) but re-licensing would probably be as painful as unrealistic
anyway. It would fix the second point without decreasing too much the
last. That means contributors will still have their name somewhere but
not everywhere. Actually, we could make this a policy and ask all
contributors to add themselves to the list with their first patch. We
could even use this list to add entries to about:contribs.
Hope this proposition makes sense.
Thanks,
--
Mounir
Mike Hommey
Note that we did have such a list in the tree, in
browser/base/content/credits.xhtml, and it wasn't updated frequently.
It was moved outside the tree, to http://www.mozilla.org/credits/,
which about:credits now directs to.
Mike
beltzner
dev-planning, but it's not on topic here.
cheers,
mike
Gervase Markham
> I see in the document that you plan to keep the per-file list of
> contributors. I wonder if we shouldn't use the change of MPL boiler
> plate to get ride of this list.
There are an unknown number (>= 1) of Mozilla contributors who feel
strongly it should be kept. I would be interested in knowing whether
there are people in the community who feel that we shouldn't bother
keeping it.
> I don't know the real reasons why this list has been added first
The list is there because the MPL requires it. :-) Why the MPL requires
it, you would need to ask Mitchell, but it could have been any
combination of the 3 possibilities you list, with perhaps reason 1)
being foremost.
> 1. licensing: having the list of contributors to ask if we want to
> re-license the file. Though, the list is far from exhaustive and hg
> blame would be much more useful (even if not perfect given that a few
> commits don't carry the correct author and some file would require cvs
> blame too);
I can testify that the list is not useful from this point of view.
> 2. who knows about this code: when I began to hack into the Mozilla code
> base, I was trying to reach people in this list and I quickly realized
> that was a waste of time: some people appearing here knew the code 10
> years ago, some just wrote a one-line patch and some did a major rewrite
> but do not appear. It happens that the list is seriously misleading for
> a new contributor;
I also think the list is not useful from this point of view - and we now
have better tools (DVCSes; ways of separating patch author from person
who checked it in) than a manual list.
> 3. pride: if we look carefully, we can see that some contributors put
> themselves in the list as soon as they write a change and some do not
> seem to care that much.
"Credit" (a nicer word than 'pride' :-) seems to me to be the only
reason we would consider keeping it.
> So, instead of a per-file list of contributors, I would like to propose
> to have a per-repository list of contributor.
Well, we already have a list for the entire project - see about:credits.
Keeping lists of credits is a difficult enough process politically
(witness the time consumed by maintaining the now-defunct per-release
list of credits in the Firefox 'About' window) that I would not want to
institute new ones without very good reason.
People can already ask to get added to about:credits, and it doesn't
matter what sort of contribution you made (i.e. it's not restricted only
to code contributions) - which is good.
Gerv
Gervase Markham
> Note that we did have such a list in the tree, in
> browser/base/content/credits.xhtml, and it wasn't updated frequently.
> It was moved outside the tree, to http://www.mozilla.org/credits/,
> which about:credits now directs to.
The history here is not quite correct :-)
about:credits has redirected to the URL you give above since the very
first release of a Mozilla project browser; that has never changed.
Between about 2004 and 2010 there was also an additional
Firefox-specific credits list which appeared in the Firefox 'About'
window, stored at the repository location given above. The intention was
that it was a list of people who had made a particular contribution to
that particular release of Firefox. But it has now been discontinued,
and we just use the main project credits list at about:credits.
Gerv
Benjamin Smedberg
> On 19/08/11 23:48, Mounir Lamouri wrote:
>> I see in the document that you plan to keep the per-file list of
>> contributors. I wonder if we shouldn't use the change of MPL boiler
>> plate to get ride of this list.
> There are an unknown number (>= 1) of Mozilla contributors who feel
> strongly it should be kept. I would be interested in knowing whether
> there are people in the community who feel that we shouldn't bother
> keeping it.
understand that the list of contributors is intended to be a list of
people who hold copyright in the file, instead of a list of people who
want to be given credit for the file. If people actually kept it up to
date, it would be a persistent source of merge conflicts; so in most
cases it is not altered even when people land patches.
--BDS
Mounir Lamouri
> On 19/08/11 23:48, Mounir Lamouri wrote:
>> contributors. I wonder if we shouldn't use the change of MPL boiler
>> plate to get ride of this list.
>
> strongly it should be kept. I would be interested in knowing whether
> there are people in the community who feel that we shouldn't bother
> keeping it.
I would be interested to know who wants to keep the per-file list of
contributor and why. I hope they will speak up.
>> So, instead of a per-file list of contributors, I would like to propose
>> to have a per-repository list of contributor.
>
> Well, we already have a list for the entire project - see about:credits.
> Keeping lists of credits is a difficult enough process politically
> (witness the time consumed by maintaining the now-defunct per-release
> list of credits in the Firefox 'About' window) that I would not want to
> institute new ones without very good reason.
>
> People can already ask to get added to about:credits, and it doesn't
> matter what sort of contribution you made (i.e. it's not restricted only
> to code contributions) - which is good.
about:credits and this list would be two different things. This list
would be the list of patch authors and about:credits is the list of all
kind of contributions to Mozilla. Just to make it clear, I don't think
we should merge it.
Actually, I'm not a big fan of the "ask to get added" process and I'm
pretty sure we could do something more automatized, at least for the
code contributions.
For example, we could do like some FLOSS projects and make it mandatory
to add yourself in the list when you contribute for the first time.
Alternatively, we could have a script that would get all commit authors
every week (or so) and add them to the list if they are not (that might
create duplicate entries in the sense of someone might commit with
different email addresses). As I said in a previous email, about:credits
could use that list which would, I believe, reduce the burden of the
maintenance.
Anyway, whether we create a per-repository list or not, I strongly
believe we should get ride of the per-file list.
Thanks,
--
Mounir
Boris Zbarsky
> There are an unknown number (>= 1) of Mozilla contributors who feel
> strongly it should be kept. I would be interested in knowing whether
> there are people in the community who feel that we shouldn't bother
> keeping it.
In my experience, the list is pretty useless, except maybe for the
"initial developer" bit. And even that is not that useful as long as
people don't screw up their file manipulations in the version control
system.
So I would be fine with getting rid of it.
>> 3. pride: if we look carefully, we can see that some contributors put
>> themselves in the list as soon as they write a change and some do not
>> seem to care that much.
>
> "Credit" (a nicer word than 'pride' :-) seems to me to be the only
> reason we would consider keeping it.
Yep. If we do, we should consider changing the wording to make it clear
that the list is very much non-exhaustive....
-Boris
Gervase Markham
> I think the list of contributors is generally useless. I don't bother
> adding myself to the list in existing files. I only put myself in the
> list when I'm adding a new file.
beltzner says "back to governance"...
But it turns out the guy who I thought supported this doesn't actually
care too much (he has a different, related issue), so, given the
feedback here, I'm going to change the plan to drop this list instead of
retaining it.
Gerv
Gervase Markham
> Actually, I'm not a big fan of the "ask to get added" process and I'm
> pretty sure we could do something more automatized, at least for the
> code contributions.
>
> For example, we could do like some FLOSS projects and make it mandatory
> to add yourself in the list when you contribute for the first time.
That assumes that everyone who contributes wants to be added. Some
people do not.
Gerv
Dan Mosedale
> On 2011-08-22 2:14 AM, Gervase Markham wrote:
>> There are an unknown number (>= 1) of Mozilla contributors who feel
>> strongly it should be kept. I would be interested in knowing whether
>> there are people in the community who feel that we shouldn't bother
>> keeping it.
> it takes time to (spottily) maintain without returning a tangible
> benefit, which makes it detrimental. We should drop it from the new
> license.
I agree. It's not really possible to have any confidence that the list
on a given file is anywhere close to right.
Dan
Gervase Markham
> Some people think it's useless, but I think that's a charitable view: it
> takes time to (spottily) maintain without returning a tangible benefit,
> which makes it detrimental. We should drop it from the new license.
Nit: it's not in the new licence; we were considering retaining it by
policy.
That position has now changed - we will not be retaining it.
Gerv
Mounir Lamouri
> On 22/08/11 14:45, Mounir Lamouri wrote:
>> pretty sure we could do something more automatized, at least for the
>> code contributions.
>>
>> For example, we could do like some FLOSS projects and make it mandatory
>> to add yourself in the list when you contribute for the first time.
>
> people do not.
I thought of that but I wasn't able to find any reason why someone
wouldn't want to be added to a contributor list while she/he would
already be in the commit logs. We do not require real names and someone
can just hide behind a pseudonym. If I use services like ohloh.net, I
think I can find very easily if X is crontibuting to project Y just with
the commit logs.
In addition, today, it seems that someone can ask to have someone else
to be added to about:credits, how would that be different from being
automatically added? It seems even worse from being automatically added.
Anyway, if there are real situations where someone might be okay with
contributing but wouldn't want to be added to a contributor list, we
could just let them opt-out.
--
Mounir
Gervase Markham
> Many in the Mozilla community, including the project leadership, have
> reviewed drafts of the upcoming version and are eager to adopt it, in
> place of the tri-licensing scheme we currently use. (The MPL 2 is
> compatible with the LGPL and GPL, like the tri-licence.) We'd like to
> make sure all of the Mozilla community is aware that a decision on
> upgrading our code to the MPL 2 will be made shortly, and if there are
> any issues with doing so, we'd like to know about them before the
> licence is finalized.
Some useful comments on the text of the licence itself have been brought
up in mozilla.governance.mpl-update, and these are being worked on by
the MPL 2 team. There has also been useful feedback here on Mozilla's
particular implementation, and the plan has been updated to reflect
that. The precise implementation details will continue to be refined and
clarified as we work on it.
However, none of the issues raised seem to be show-stoppers, and so we
will be moving the Mozilla project to the MPL 2 once the final version
is released.
Gerv
Frédéric Buclin
> will be moving the Mozilla project to the MPL 2 once the final version
> is released.
Gervase Markham
Gerv