Development Resources/Automatic IP Log
The Foundation is working on an automatic IP Log (bug 220977) for each project with the goal of reducing the overhead on each project team. This page is currently a placeholder but will eventually contain the documentation about how the automatic IP Log is generated (by the system) and maintained (by the project team) and processed (by Eclipse Legal). To see this log in action (as it evolves), go here: IP Log for technology.dash.
- 1 Correcting Errors In General
- 2 Third-Party Code
- 3 Unused Third-Party Code
- 4 Works With and Pre-Req Dependencies
- 5 Pending Contribution Questionnaires
- 6 Committers
- 7 Contributors
- 8 Choosing the Set of Projects
- 9 Submitting the IP Log to Eclipse Legal
Correcting Errors In General
In order to correct errors in the IP Log, you must:
- Be a committer on the project
- Be looking at an IP Log for a single project (because if there are multiple projects, we can't figure out where to record the corrections)
- Be logged in to the Eclipse website. The login mechanism uses the Friends of Eclipse login, so when you click "login" in the left menu, you will be taken to the Friends of Eclipse login. Use your bugzilla login.
- Have the same email address for your Foundation email and your bugzilla email.
When all of that is true, extra correction form fields will appear on the page along with a "Make These Corrections" submit button at the bottom. Like any html form, fill it out and press the button to save the corrections.
The Third-Party Code section of the IP Log shows the approved Contribution Questionnaires from ipzilla. The CQs listed in this table are those that are:
- state=approved, or
- RESOLVED/FIXED or CLOSED/FIXED (regardless of state)
- Missing CQ. If a CQ is missing from this list, check its status, resolution, and state: make sure that they match one of the above cases. If not, contact Eclipse Legal.
- Extra CQ. If a CQ is listed but does not belong to this project, then contact Eclipse Legal to have the ipzilla database corrected.
- Missing or Incorrect License. If a CQ is missing the license information, contact Eclipse Legal to have the correct license information added to the database.
Unused Third-Party Code
If the project has CQs that approve the use of certain third-party code, but that code is not currently being used for this release, it is listed in the separate Unused Third-Party Code table. The CQs listed in this table are those that have one of the following keywords:
- obsolete - this third-party code was used in previous releases, but it has been superseded or is obsolete and thus is no longer being used in this release and there is no plan to use it in a future release.
- unused - the project requested approval of this third-party code in anticipation of using this code, but at this time the project is not using this code in this release. The project reserves the right to use the code in a future release.
- withdrawn - the project requested approval of this third-code code but subsequent to receiving approval and prior to using the code, decided not to use said code. This code has not been used in any release, is not being used in this release, and there is no plan to use it in a future release.
- CQ Is Being Used. If a CQ is listed as unused but is actually being used, contact Eclipse Legal to have its state changed.
- CQ Should Be Unused. If a CQ should be in the unused list instead of one of the other lists, contact Eclipse Legal to have its state changed.
Works With and Pre-Req Dependencies
If the project has Works With, Pre-Req, or Exempt Pre-Req Dependencies, these will be listed in a separate table. These are also Contribution Questionnaires from ipzilla. These CQs are:
- Missing Pre-Req. If an pre-req is missing from this list, first check that to see if there is a CQ for it. If there is no CQ, submit one (using the portal). If there is a CQ, check that its state is "workswith", "prereq", or "exempt_prereq" - if not, contact Eclipse Legal.
Pending Contribution Questionnaires
If the project has any pending and not yet approved or rejected Contribution Questionnaires, these are listed in a separate table. These represent potential IP issues and thus must be considered carefully during a Release Review.
- Unneeded CQ. If the code represented by a pending CQ is no longer needed by the project, use ipzilla to withdraw the CQ.
The Committers section of the IP Log uses two information sources to generate the two lists:
- The list of all committers who have committed code to any of the source repositories from the Commits Explorer. This is the basis of the "Past and Present" list. The commits explorer list is driven by the project meta data
- The list of all past and present committers from the Foundation's internal database of committers and projects. Committers here but not in in the "Past and Present" list are put on the "Never Active" list.
- Should Be Active. If a committer is listed as "Never Active" but should be listed in the active "Past and Present" table, then you should check the project meta data via the portal - there are directories missing from the "source repository" item. If the project meta data is correct, you can use the "make active" checkbox to submit a correction.
- Question Mark. If a "xxx???" person is listed as a committer, that means that the unix login "xxx" committed code to the source code repository, but there is no record of "xxx" as having been a committer on the project. This is a potential IP cleanliness problem, so contact the EMO to resolve it (do not just use the "exclude" checkbox correction without understanding why the data is incorrect).
- Extra Committer. If someone is listed as a "Never Active" committer, but you know that they were never even a committer at all, then there is an incorrect record in the Foundation database - contact the EMO. On the other hand, if someone is listed as a "Past and Present" committer, but you know that they were never a committer, then something larger is awry because there are source code check-ins by that person. Use the commits explorer to determine what check-ins they made and contact the EMO if there are any errors. In both cases, after resolving the issue with the EMO, use the "exclude" checkbox to correct the IP log.
- Missing Committer. If someone who is/was a committer with a unix account and is missing from both the "Past and Present" and the "Never Active" tables, then something is very wrong with the code that generates this page - contact the EMO.
The Contributors section of the IP Log uses one information source:
- Everyone who has attached a non-obsolete patch to a RESOLVED/FIXED, VERIFIED/FIXED, or CLOSED/FIXED bug in bugzilla. The bugzilla searches are driven by the project meta data
- No Name. If the contributor record for person X shows an email address but no name, then person X has not entered a name in bugzilla. Have X go to bugzilla Preferences and enter their correct name.
- Error Messages. If the tentative IP log shows errors (red error messages) in product name or component name, then the team should check their project meta data via the portal - the product name and (optional) component names must be an exact match with bugzilla, capitalization and all.
- Extra Contributor. If a person (person X) is listed as a Contributor but the team knows that their patch was never used, their patch should be marked obsolete in bugzilla.
- Missing Contributor. If person X should be listed as a Contributor but is not, then be sure that person X has attached a patch to a fixed bug. All external code contributions should come through bugzilla patches, so if a code contribution first comes through email, the contribution must also add a patch. Note that person X must add the patch because if person Y adds the patch for person X, then person Y will be listed as the contributor.
- Committer is Listed. If committer X is listed as a Contributor, check for two things:
- Check that person X was a Committer when that patch was filed in bugzilla. If they were not a committer at that time, then X is considered a Contributor for that patch.
- Check that person X's email address in bugzilla matches any one of their email addresses on file with the Foundation. Have person X use the the portal to check to verify their email addresses.
Choosing the Set of Projects
The simplest case is an IP Log for a single project. However, many project teams work together to create a unified release across a set of project. In this case, the IP Log must also be an aggregated/unified IP Log across the same set of projects. At the bottom left of the IP Log page is a "adjust the set of projects" link. That link leads to the selector page. Use the checkboxes to select a set of projects and generate a unified IP Log for all of those projects.
Submitting the IP Log to Eclipse Legal
Single or unified-multi-project, either way the IP Log can be submitted to Eclipse Legal for review using the link at bottom center of the page. This link will take you to the portal using a special url which defines which IP Log you want to send. In the portal, you will find a "[submit] IP log to Eclipse Legal" section in the appropriate project specific portal box. Click that, fill out the reason, and voila, the a frozen copy of the log is sent to Legal.