Project IP Log
| See "Section IV" of the Eclipse IP Policy. |
...the applicable Committer, with the assistance of the EMO, shall conduct the following activities prior to uploading any Content into the repository or otherwise making the Content available for distribution: ... (2)The Committer(s) shall document all information gathered pursuant to (1) above in a form to be provided by the Eclipse Foundation and provide such completed form to the EMO.The Eclipse IP Policy requires certain due diligence and record keeping. Small contributions in the form of Bugzilla patches and the like can be committed directly to the code base (after the appropriate contributor information is recorded). Medium, large, and all third-party (non-EPL licensed) contributions require the Code Contribution Questionnaire and additional record keeping. Maintaining a current and accurate Project Log is the best way to keep this information up-to-date.
The Project Log is a file containing the following sections. The file can be in these formats: (The goal is to have the log in a universally readable file format, thus proprietary formats, such as Microsoft Word or Excel, are not allowed.)
- HTML
- CSV (a spreadsheet saved in the open Comma Separated Value file format)
- text
Section 1 (Committers)
A list of all the Committers, past and present, whose contribution is still active in the repository. A Committer whose code has been entirely removed from the active branches does not need to be listed. The columns for this section are:
- dev.eclipse.org unix login name
Section 2 (Developers)
A list of all the non-Committers whose contribution is still active in the repository. The columns for this section are:
- component (CVS directory)
- bug #
- contributor's name (see Additional Information below)
- contribution size (LOC or "small" where small is defined as "less than 100 LOC")
- committer who committed this contribution
- description if there is no bug # or if there are multiple bug #s
Note that it behooves the Project to use the full capabilities of Bugzilla to assist with generating this report. If the Project uses the following features, then simple queries will generate most of section 2:
- All code changes (100% of them) refer to a Bugzilla entry
- All commit messages include the corresponding bug numbers.
- VERIFY and CLOSE all RESOLVED bugs when closing out a release.
- Target milestones for "fixed in version"
Section 3 (Third Party Software)
A list of the non-Eclipse third party software included in the Project. The columns for this section are:
- name including version
- IPzilla # of entry providing legal clearance for inclusion
- directory location or jar file
- license name and version (including any licenses related to embedded third party software)
- usage (e.g. modified/unmodified, source, object, derivative work, entire package or which subset)
Additional Information
The Foundation needs to maintain contact information for all Contributors; however, the Foundation also needs to abide by its Privacy Policy. The Project handles these two requirements by maintaining an internal, non-public database (list) of contact information for all Project Contributors, including the Contributor's name, email address, mailing address, and phone number. Committers are stored in the Foundation database under their dev.eclipse.org unix login name, thus the only requirement for section 1 is that login name. Contributors are stored by the Project in private, in a text file, a spreadsheet, an HTML table, a small database, or whatever the Project chooses. Section 2 uses the Contributor names as keys into that information to avoid having to list Contributors' email addresses or mailing addresses in the Project IP log. The Project sends the contact information to the Foundation as part of the process of a Release Review.
All of this is a long way of saying that the Project leadership and/or PMC must keep track of the Contributors' contact information in private and send that private list to the EMO at the Release Review.