Updates to the Eclipse IP Due Diligence Process 2022

The 2022 update to the Eclipse Foundation’s IP Policy, approved by the Board of Directors in June 2022, resulted in the following changes:

The Eclipse Public License is no longer special. The Eclipse Foundation was originally conceived as a single-license foundation, but that hasn’t been true for a very long time. With this change, we acknowledge that our open source projects leverage a variety of licenses and that no single one among them is special (but we still love and highly recommend the Eclipse Public License). All language and provisions that positioned the Eclipse Public License as being in any way special have been removed from the IP Policy.

Focus on License Compliance. With this change we’ve switched to focus entirely on license compliance. Specifically, our IP Due Diligence focuses on ensuring that the licenses involved (both project and third-party) are co-compatible (that is, do the licenses actually work together) rather than conforming to a list of licenses that have been deemed acceptable. The IP due diligence process still reviews content to ensure that we understand the state of the content licenses, and continues to rely on existing sources of license information in the reviewing process.

With this change, we can no longer assume that Eclipse open source projects can just use the products of other Eclipse open source projects without license compatibility checks. Due to the fact that our projects have been using a variety of licenses for some time, this isn’t actually new, but we’ve highlighted it here to draw attention to the fact that we are putting additional focus into reviewing license compatibility, and this extends to Eclipse open source projects using other Eclipse open source projects.

License approval processes are managed by the EMO without requirement for Board approvals. We are no longer required to go to the Board of Directors to get approval for our open source projects to use content under licenses that we haven’t encountered. We no longer have a strict “approved licenses” list. There are still restrictions on what licenses can be used, but these restrictions are based on whether or not the licenses actually work together and whether or not license terms align with our open source rules of engagement (e.g., licenses do not restrict fundamental freedoms).

The Guidelines for the Review of Third-Party Dependencies as been revoked. This is related to our focus on license compliance. The Guidelines for the Review of Third-Party Dependencies described notions of prerequisite, works with, and exempt prerequisite dependencies which provided different mechanisms by which third-party content could be consumed by Eclipse open source projects (works with and exempt prerequisite in particular described means by which we could short circuit the due diligence process for content under licenses that might otherwise not be supported by the then-IP Policy). WIth our focus on license compliance, these considerations are no longer necessary.

IPLab replaces IPZilla. We announced the retirement of IPZilla in September 2022 and moved aggressively to retire it completely by the end of December 2022. IPZilla was the tool that we used to request and track the progress of intellectual property reviews. With this update to our process, we now use IPLab, an issue tracker and repository on our GitLab infrastructure that we use to request and track intellectual property reviews. The Eclipse Dash License Tool integrates with IPLab to automate much of the process of requesting reviews (which required significant manual work with IPZilla).

No more Contribution Questionnaires. With the retirement of IPZilla, we also retired the term contribution questionnaire along with its acronym, CQ. You can call the issues on IPLab whatever you want: issues, IP review requests,

SBOMs replace IPLogs. Eclipse open source projects are no longer required to submit an IP Log as part of a progress or release review. Instead, we rely on the Git log to track contributions to a project along with a Software Bill of Materials (SBOM). At the time of this writing, SBOMs take several different forms. For our immediate purposes, about.html files serve this purpose in Eclipse Platform plug-ins, and NOTICE files or summary files generated using the Eclipse Dash License Tool serve as SBOMs. In the future, the EMO will work with projects to leverage standard SBOM formats such as SPDX or CycloneDX.

Automate everything that can be automated. We’ve implemented some tools, starting with the Eclipse Dash License Tool to automate as much of the process as possible. We continue to investigate options that improve the quality of our results while reducing the amount of investment required by committers and the EMO.