The default bug view has changed. See this FAQ.

MPL compliance: *ongoing* Initial Developers credits

RESOLVED WONTFIX

Status

()

Core
General
RESOLVED WONTFIX
10 years ago
5 years ago

People

(Reporter: philor, Assigned: gerv)

Tracking

({fixed1.8.1.5})

Trunk
fixed1.8.1.5
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

10 years ago
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.
(Assignee)

Comment 1

10 years ago
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
Assignee: hecker → gerv
(Reporter)

Comment 2

10 years ago
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.
(Assignee)

Comment 3

10 years ago
-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
(Assignee)

Comment 4

10 years ago
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.
(Assignee)

Updated

10 years ago
Attachment #266638 - Attachment is patch: true
Attachment #266638 - Attachment mime type: text/x-patch → text/plain
(Assignee)

Comment 5

10 years ago
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
(Assignee)

Comment 6

10 years ago
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
(Assignee)

Comment 7

10 years ago
Now we need to move products so we can have access to the right approval flags...

Gerv
Status: NEW → ASSIGNED
Component: Licensing → General
Product: mozilla.org → Core
Version: other → 1.8 Branch
(Assignee)

Comment 8

10 years ago
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
Attachment #266643 - Flags: approval1.8.1.5?
(Reporter)

Comment 9

10 years ago
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.
(Assignee)

Comment 10

10 years ago
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 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?
(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.
(Assignee)

Comment 13

10 years ago
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 on attachment 266643 [details] [diff] [review]
Patch v.1 for 1.8 branch

approved for 1.8.1.5, a=dveditz for release-drivers
Attachment #266643 - Flags: approval1.8.1.5? → approval1.8.1.5+
(Assignee)

Comment 15

10 years ago
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
Keywords: fixed1.8.1.5
QA Contact: gerv → general
Summary: MPL compliance: *ongoing* Intial Developers credits → MPL compliance: *ongoing* Initial Developers credits
(Assignee)

Comment 16

9 years ago
Just as a note: the list was updated again for Firefox 3 in bug 414025.

Gerv
Depends on: 414025, 523051, 497103, 511322
Version: 1.8 Branch → Trunk
(Assignee)

Comment 17

5 years ago
MPL 2 has no requirement for this. Wahey :-)

Gerv
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.