Last Comment Bug 380017 - MPL compliance: *ongoing* Initial Developers credits
: MPL compliance: *ongoing* Initial Developers credits
Status: RESOLVED WONTFIX
: fixed1.8.1.5
Product: Core
Classification: Components
Component: General (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: Gervase Markham [:gerv]
:
:
Mentors:
http://lxr.mozilla.org/seamonkey/sour...
Depends on: 414025 497103 511322 523051
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-07 20:56 PDT by Phil Ringnalda (:philor)
Modified: 2012-05-28 06:45 PDT (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch v.1 (29.84 KB, patch)
2007-05-30 11:39 PDT, Gervase Markham [:gerv]
no flags Details | Diff | Splinter Review
Patch v.1 for 1.8 branch (12.73 KB, patch)
2007-05-30 12:07 PDT, Gervase Markham [:gerv]
dveditz: approval1.8.1.5+
Details | Diff | Splinter Review

Description Phil Ringnalda (:philor) 2007-05-07 20:56:57 PDT
In bug 331136, MPL section 3.3 ("You must include a prominent statement that the Modification is derived, directly or indirectly, from Original Code provided by the Initial Developer and including the name of the Initial Developer in (a) the Source Code, and (b) in any notice in an Executable version or related documentation in which You describe the origin or ownership of the Covered Code.") was met for mozilla.org releases by including a section in /toolkit/content/license.html listing the names of all the Intial Developers in the whole tree, as of some time in the neighborhood of 2006-03-30.

Considering how many releases our various products have had in that year-plus, bug 331136 comment 9 ("I'll rerun the script which generates it every so often, and paste the result into the page") clearly isn't a workable plan for ongoing compliance, unless Gerv becomes part of the Build & Release team, or at least a checkbox for them.

The three solutions that occur to me are:

1. Fix the script (or land the fixed version - the last time I tried using the version of relic in the tree, it choked on file after file after file) so that it can be run as a part of every release, reflecting the actual Initial Developers at the time of release.

2. Loudly order anyone contributing a new file to add themselves to license.html#initial-developers at the time they contribute their first new file.

3. Decide that MPL 3.3 doesn't actually apply to us, since we aren't distributing modified versions of Covered Code except when Thunderbird copies a Firefox file and files off a few of the serial numbers, in which case compliance probably consists of maintaining the original Initial Developer.
Comment 1 Gervase Markham [:gerv] 2007-05-17 06:33:11 PDT
It's a fair cop.

1. relic does run fine on the tree; there's an option (-f) to keep going after errors.

2. Less reliable even than the current solution IMO.

3. 3.3 definitely applies to us.

Release time is too late to redo this, IMO. So having it as part of the build and release process won't work.

To begin with, I will regenerate the list. The fact that there are now N copies of license.html in the tree doesn't help, though :-| What progress on plans to reunify them?

Gerv
Comment 2 Phil Ringnalda (:philor) 2007-05-17 21:09:53 PDT
Does -f log all the errors, in a way that you can diff one run's errors against the next? If 3.3 applies to us, it probably doesn't only apply to those Initial Developers who land license blocks that don't choke relic, so you would need a way of telling known errors from new.

If release time is too late, I'm not quite sure what time is right, since I don't see a way of reading 3.3 as saying "except for minor products that pick a bad time to release, and except for files that are added at the last minute." I'd say having a box equivalent to egg, that continuously checks out every active branch, runs relic, and checks in anything new it finds, would be the ideal solution, since the Goatbird project might snapshot a stable branch at any time, and think that what they get complies with the MPL. However, I doubt we'll get that, and without that, the only way to ensure we don't violate our own license is to update the list after the last checkin, and whether it's the build team or the product team doing it, I don't know how to describe that as anything other than part of the build & release process.

As to making license.html unforkable, if you can make me a toolkit peer, I'll let you steal my patch, and then I'll review it.
Comment 3 Gervase Markham [:gerv] 2007-05-21 06:39:42 PDT
-f sends text relating to all errors to stdout. But you can't really diff the runs, because it also outputs a list of files, and that changes often. (Arguably, this verbosity should be more configurable.)

I regularly fix things so there are no errors; however, without a tinderbox test (bug 372447), they keep regressing.

I agree there's a balance to be struck here. We should at least do it when we branch for a release, and then perhaps monitor if more change is required and deal with it on a case-by-case basis. I would note in this connection that until recently, every single person I know of using the MPL ignored this requirement - not just the Mozilla project. Now, everyone does except for us. I am attempting to respect it more, but I do think some slack could be cut.

Sadly, I can't make you a toolkit peer :-( Keep trying with your patch...

Gerv
Comment 4 Gervase Markham [:gerv] 2007-05-30 11:39:22 PDT
Created attachment 266638 [details] [diff] [review]
Patch v.1

This patch updates the trunk list to be current, and also syncs up the different copies of license.html so they all have the bug fixes, the spelling correction script, and the license for Growl.
Comment 5 Gervase Markham [:gerv] 2007-05-30 11:52:58 PDT
Trunk checkin:

Checking in ./mail/license.html;
/cvsroot/mozilla/mail/license.html,v  <--  license.html
new revision: 1.2; previous revision: 1.1
done
Checking in ./toolkit/content/license.html;
/cvsroot/mozilla/toolkit/content/license.html,v  <--  license.html
new revision: 1.10; previous revision: 1.9
done
Checking in ./xpfe/global/resources/content/license.html;
/cvsroot/mozilla/xpfe/global/resources/content/license.html,v  <--  license.html
new revision: 1.10; previous revision: 1.9
done

Gerv
Comment 6 Gervase Markham [:gerv] 2007-05-30 12:07:13 PDT
Created attachment 266643 [details] [diff] [review]
Patch v.1 for 1.8 branch

This is a minimal patch for the branch to update the list of Initial Developers only.

Gerv
Comment 7 Gervase Markham [:gerv] 2007-05-30 12:08:29 PDT
Now we need to move products so we can have access to the right approval flags...

Gerv
Comment 8 Gervase Markham [:gerv] 2007-05-30 12:10:11 PDT
Comment on attachment 266643 [details] [diff] [review]
Patch v.1 for 1.8 branch

Requesting 1.8.1.5 approval, as bsmedberg said on IRC. This is a license compliance patch which makes textual changes to an HTML page shipped with the product.

Gerv
Comment 9 Phil Ringnalda (:philor) 2007-05-30 12:18:27 PDT
Comment on attachment 266638 [details] [diff] [review]
Patch v.1

>    - The Initial Developer of the Original Code is
>-   - the person recorded in the version control logs.
>+   - Gervase Markham.

>-Gervase Markham,

I don't see any individual opt-out clause in 3.3.
Comment 10 Gervase Markham [:gerv] 2007-05-30 12:43:30 PDT
Yeah, sorry, that's an out-of-sync error. I added myself to the headers for these files after I generated the list which I used to make the patch. After that, I realised that there was an anomaly and added myself in. The checked-in version does not remove my name from the list. (I also fixed the spelling of Simon Bunzli's name.)

Gerv
Comment 11 Smokey Ardisson (offline for a while; not following bugs - do not email) 2007-05-30 14:12:04 PDT
Comment on attachment 266638 [details] [diff] [review]
Patch v.1

>+    <span class="path">toolkit/components/alers/src/mac/growl/</span>.  (This

Surely this is supposed to be "alerts" in both instances?
Comment 12 Smokey Ardisson (offline for a while; not following bugs - do not email) 2007-05-30 14:20:03 PDT
(In reply to comment #3)
> I agree there's a balance to be struck here. We should at least do it when we
> branch for a release, and then perhaps monitor if more change is required and
> deal with it on a case-by-case basis. 

I'd argue it should be done at the last Gecko beta freeze or l10n freeze point (instead, or as well), which should cover the vast majority of new files in the tree, though it may still miss files added to non-Firefox products which are still developing their respective releases after the Firefox release.  Still, that would be better than where we've been until now.
Comment 13 Gervase Markham [:gerv] 2007-05-31 03:01:19 PDT
Yes, it should be "alerts"; this bug was present in the original copy. I noticed that, but forgot to fix it. Never mind.

Yes, the last beta freeze point would be a good time to do it. And then again perhaps after the release, in good time for X.0.0.1. As it's only text changes, it's very low risk.

Gerv
Comment 14 Daniel Veditz [:dveditz] 2007-06-25 11:29:40 PDT
Comment on attachment 266643 [details] [diff] [review]
Patch v.1 for 1.8 branch

approved for 1.8.1.5, a=dveditz for release-drivers
Comment 15 Gervase Markham [:gerv] 2007-06-26 03:13:32 PDT
Checked in on the branch.

Checking in ./mail/license.html;
/cvsroot/mozilla/mail/license.html,v  <--  license.html
new revision: 1.1.2.2; previous revision: 1.1.2.1
done
Checking in ./toolkit/content/license.html;
/cvsroot/mozilla/toolkit/content/license.html,v  <--  license.html
new revision: 1.1.2.7; previous revision: 1.1.2.6
done
Checking in ./xpfe/global/resources/content/license.html;
/cvsroot/mozilla/xpfe/global/resources/content/license.html,v  <--  license.html
new revision: 1.1.2.8; previous revision: 1.1.2.7
done

Gerv
Comment 16 Gervase Markham [:gerv] 2008-01-26 04:39:35 PST
Just as a note: the list was updated again for Firefox 3 in bug 414025.

Gerv
Comment 17 Gervase Markham [:gerv] 2012-05-28 06:45:46 PDT
MPL 2 has no requirement for this. Wahey :-)

Gerv

Note You need to log in before you can comment on or make changes to this bug.