Revise and update the Eclipse Foundation IP Policy and Due Diligence Process
We've only just started work on this effort and will fill in more details over the coming days.
On April 28/2022, @mmilinkovich delivered a presentation to the members and committers, titled "IP Due Diligence: Modernizing Our Processes".
The main points are that we will evolve the IP Policy and corresponding IP Due Diligence Processes further to:
- The EPL is no longer special in the IP Policy or elsewhere (But we still love and highly recommend the EPL-2.0)
- Focus our energies on license compliance
- License approval processes managed by the EMO without requirement for Board approvals
- Focus on project-level license compatibility
- Eliminate manual record keeping requirements for dependencies
- Revoke the existing policy on third party dependencies
- Deprecate IPzilla and CQs (contribution questionnaires)
- Only track what is distributed by our projects
- To the degree that any manual record keeping is still required, use public Gitlab to support
- Eliminate the requirement for IP Logs
- Rely entirely on SBOMs and git logs for communicating the provenance of our code
- Implement build-time license compliance tools such as ORT
- Automate license compliance checking of all third party dependencies
- Automate creation of machine-readable SBOMs
Themes and Issues
Note: this is a work in progress; please be patient.
Licenses
With the anticipated changes in the IP Policy, the Eclipse Public License (EPL) will cease to be special and so the processes and infrastructure that we've created to make the EPL special will need to be reworked. Maintaining a list of board approved licenses, for example, will no longer make sense as we focus instead on license compatibility. It's worth noting that the approved license list includes licenses that we believe are generally compatible with the EPL; it has never been our intention to make any claims regarding whether or not licenses on the approved list are compatible with other project licenses (e.g. the Apache-2.0
).
This will make explicit something that's always been implicit: our IP due diligence process is not intended to make any sort of legal statement regarding whether or not certain combinations of licenses are compatible. That is, it is (and always has been) the domain of the consumer (presumably in conjunction with their respective legal counsel) to make decisions regarding whether or not combinations of licenses work together; and our role is to ensure that reasonable effort has been undertaken to correctly identify the licenses. Having said all that, we do have a role to play in working with project teams to ensure that licenses leveraged by the content they produce and the third-party content they leverage are generally considered to be compatible. In that regard, we are investigating the work of OSADL (specifically their Open Source License Checklists and the potential in their compatibility matrix) and others.
- #1313 (moved) Revise how we capture and track project licenses
Retire IPZilla
Our current thinking is that we will replace IPZilla with GitLab issues via IPLab. As part of retiring IPZilla, we will also retire the terms "contribution questionnaire" and "CQ".
Work items that need to be tracked (that is, we need to create issues to track these):
- #1369 (closed) Create a template to receive contribution review requests via IPLab
- TBD Retire IPZilla
Timeline:
- Prepare IPLab and deprecate IPZilla (2022Q2)
- Deprecate IPZilla (September 30/2022)
- Retire IPZilla (December 22/2022)
Bring IPLab Mainstream
To take IPZilla’s place, we’ve introduced IPLab which is a GitLab project on the Eclipse Foundation’s GitLab instance. There are templates that committers can use to create review requests on IPLab, or use the automation that we’ve put in place and instead use the Eclipse Dash License Tool to automatically initiate review requests. IPLab exists today, and the Eclipse Dash License Tool – which has already been adopted by multiple Eclipse open source project teams and even incorporated into automated builds – works. Further, the EMO team has already successfully tested the Eclipse Dash License Tool on many existing Eclipse Project repositories (mostly Eclipse projects that have engaged in a release or progress review in the last year).
ORT
We are investigating the use of OSS Review Toolkit (ORT) to automate the review of Eclipse Project content. ORT "digs into" third party dependencies referenced by numerous popular module system (e.g. Maven) and leverages scanners and sources of curated copyright and license information to review and report on the intellectual property state. Our intention/hope is to have ORT continuously review project repositories, and automatically engage the Eclipse Foundation's IP Team to review issues that cannot be resolved via automation (and feed the results of their reviews back into the system to improve the quality of subsequent runs).
Our work with ORT is being tracked here: https://gitlab.eclipse.org/eclipsefdn/emo-team/eclipsefdn-ort
Eclipse Dash License Tool
In parallel to our work with ORT, we've also invested in the Eclipse Dash License Tool which is capable of determining the license of third-party content based on multiple trusted sources of information and can automate creating requests for review of content by the Eclipse IP Team.
SBOMs
In place of the IP Log generator, we'll leverage SBOMs. We're investigating what form this will take. In the meantime, the Eclipse Dash License Tool is capable of generating a form of SBOM (for third party content), and we've had some success using ORT to completely automate the generation of SBOMs for Eclipse project repositories. Other technologies, such as REUSE may play a role in this.
Whatever form SBOMs end up taking, our belief is that they should be kept with the code. That is, SBOMs should be represented directly in the Git repository rather than stored elsewhere. The basic idea is that there is an increasing expectation by the community in general and adopters of open source technology in particular, that all information related to a project be kept as close as possible to the actual code/content.
A possible exception to this may be the SBOMs generated by ORT which will be centrally located, but may also be copied into a repository.
- #1078 (closed) Retire the IP Log Generator
Documentation
The handbook has a full chapter decided to intellectual property due diligence that makes several references to IPZilla and CQs. These references will need to be updated to point to IPLab.
PMI
The PMI makes several references to IPZilla. We will retire this references and replace them with pointers to IPLab.
Information Sessions
- Eclipse IP Policy and Due Diligence Process AMA
- September 29/2022 at 9am ET.
- All committers are invited to join in for a very short presentation followed by a question and answer session.
- https://eclipse.zoom.us/j/86102590354
- Meeting ID: 861 0259 0354
- EclipseCon talk: Revising the Eclipse Foundation's Intellectual Property Due Diligence Process