Closed Bug 578857 Opened 10 years ago Closed 9 years ago
update Committer Agreement to better address copying of third-party code
Gerv and I met today to discuss the Contributor Agreement for an hour; we agreed to discuss in more depth the issue of third-party code which is acceptably licensed but potentially of under-documented provenance. Github and potential license compatibility will accelerate this issue, as the engineers will be more eager to incorporate such code. Luis has consulted with SFLC on this issue; once SFLC responds the next step will be to take it to the Harmony project and see what their thoughts are on the general case. --- First Response: --- First Response Timeframe: Few weeks --- Business Objective: --- Other Party:
10 years ago
Assignee: nobody → lvilla
Status: NEW → ASSIGNED
Priority: -- → P3
Whiteboard: needinfo: response from SFLC
Retitling to be more correct.
Summary: consider relationship of third-party code and the Contributor Agreement → consider relationship of third-party code and the Committer Agreement
Continuing to discuss with SFLC; their model agreement does not cover this situation so I've proposed some ideas to them and Gerv to see what they think.
SFLC's response is essentially 'we do this on a case-by-case basis'; they have no specific advice on this situation. My current thinking on the issue is: We currently ask our CA signers to vouch that third party code that they copy into the Mozilla tree meets the terms of our CA. The CA does not specify what mechanisms the CA signers should use for this- e.g., contacting the author, inspecting licenses, etc. As I understand it, the purpose of this language is to protect against something like a SCO-like attack, where code of unknown authorship or unclear licensing enters the tree, and is later uncovered by the 'real' author, leading to questions about our code's provenance. We should consider addressing this problem by requiring documentation of the source of third-party code, rather than the current practice of requiring verification of the licensing and ownership of the sourcing. e.g., in the version of the file that resides in our tree, the person who copied the file into our tree would be required to include a link to the public repository where the code was found, and a link to the license or project licensing policy which made the copier believe that the code was appropriate. More ambitiously, we could try to archive the license statement. This is not a perfect solution to a SCO-like attack, but it seems to me to be a good first step- if someone accuses us, we can immediately know where the code in question came from, and have documentation of the license we thought it was under.
Summary: consider relationship of third-party code and the Committer Agreement → update Committer Agreement to better address copying of third-party code
Whiteboard: needinfo: response from SFLC → needs to be considered as part of other CA changes
Unfortunately, it does not appear that Project Harmony will issue something we can use in the near future, so we should probably revisit this and other CA issues. For this particular issue, I propose making the following change. Current language: ===== 4. Committing Code Created by Others You may check in Code to a Mozilla Foundation repository that was not written by You, provided that: a) The checkin comment contains information (or references to information) sufficient to identify the author of the Code, including at minimum an email address; and b) You make all reasonable and appropriate efforts to ensure that such Code conforms to the terms of this agreement. ===== Proposed language (change is all in 4(a)) ===== 4. Committing Code Created by Others You may check in Code to a Mozilla Foundation repository that was not written by You, provided that: a) The checkin comment contains information (or references to information) sufficient to identify the author and the license of the Code, and a link to a public source repository if one is available; and b) You make all reasonable and appropriate efforts to ensure that such Code conforms to the terms of this agreement. ===== This wouldn't perfectly resolve the issue but it would at least give us the tools to understand where code had come from in case of a problem. In at least one case this year, similar checkin information did help clarify a licensing situation, so we know that in practice it is helpful.
Harvey: Luis' suggestion looks good to me. Unless you object, I'll set about making an update. Gerv
I have updated all three copies of the Committer's Agreement (.odt, .pdf, .txt) on the website with the new text from Luis, and bumped the version number to 2.0.1. Erica: you can accept version 2.0 for a couple of months, but after that please ask people who use the old version to resubmit with the current one. Thanks :-) Gerv
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
I don't think this bug needs to be confidential and it concerns a matter of interest to the whole community so, to open it up, I plan to move it to mozilla.org/Governance. Anyone who objects, speak now :-) Gerv
Assignee: villalu → gerv
Component: Licensing → Governance
Product: Legal → mozilla.org
QA Contact: handerson → governance
Version: unspecified → other
You need to log in before you can comment on or make changes to this bug.