The global landscape of open source development is increasingly defined by the need for transparency, trust, and a rigorous approach to supply chain security. As organisations integrate thousands of third-party components into their proprietary stacks, the burden of ensuring that every piece of software is legally clean and properly licensed has grown considerably. In this context, the Eclipse Foundation has long distinguished itself through a governance model that prioritises intellectual property (IP) due diligence. The emergence of formal standards like ISO/IEC 5230—better known as the OpenChain specification—provides an internationally recognised benchmark for licence compliance.
By aligning the Eclipse Foundation’s established processes with the OpenChain standard, Eclipse open source projects can provide downstream adopters and consumers with a high degree of confidence. While many projects at the Eclipse Foundation naturally follow these rigorous paths, specific criteria must be met before a project can formally claim to be OpenChain compliant. This alignment is not merely a bureaucratic exercise; it is a fundamental part of the Foundation’s mission to foster a commercially friendly ecosystem.
The Life cycle of an Eclipse Project
To understand how compliance is achieved, one must first understand the life cycle of an Eclipse open source project as defined by the Eclipse Foundation Development Process (along with the practical guidance provided by the Eclipse Project Handbook). Every Eclipse open source project begins its journey in the incubation phase. This is an onboarding period where the project team learns the “rules of the road”, adopting the core principles of openness, transparency, and meritocracy. During incubation, the primary focus is on establishing a functioning community and integrating with the Eclipse Foundation’s governance, practices and processes (including the IP due diligence process).
Graduation is a significant milestone. A project in the mature phase has demonstrated to the community that they are working in a vendor-neutral manner and are faithfully engaging in the IP due diligence process. Graduation is a formal recognition of process adoption. For the purposes of OpenChain compliance, being in the mature phase is a prerequisite. It signals to the community that the project is no longer “learning the ropes” but is instead operating at a level of professional governance expected by adopters.
An Eclipse open source project moves from the incubation phase into the mature phase by engaging in a graduation review; graduation reviews are combined with a progress review. Following a successful graduation review and graduation into the mature phase, an Eclipse open source project will engage in periodic progress reviews.
The Role of Progress Reviews and IP Due Diligence
Conducted by the Eclipse Management Organization (EMO) and the Eclipse open source project’s Project Management Committee (PMC), a progress review is an annual check-in to ensure the project continues to align with the Eclipse Foundation’s practices and processes. For a project to claim OpenChain compliance, it must have successfully completed a progress review while already in the mature phase.
A critical component of a progress review is the validation of the open source projects’ continued faithful implementation of the Eclipse Foundation IP due diligence process. The IP due diligence process requires that all content—whether it be original code or third-party libraries—be scrutinised for legal cleanliness. Committers are responsible for ensuring that every contributor has a valid contributor agreement on file and that the provenance of all code is documented. During a progress review, the EMO validates that these practices are being implemented correctly.
While an Eclipse open source project must produce a Software Bill of Materials (SBOM) in a standard format to claim OpenChain compliance, the Foundation does not currently require the creation of an SBOM as a condition for passing a standard progress review. The review focuses on the integrity of the IP process itself, whereas the SBOM is the outward-facing documentation of that integrity.
Implementing the OpenChain Requirements
The OpenChain specification (ISO/IEC 5230) is structured around several key goals, ranging from establishing a programme foundation to managing the delivery of compliance artifacts. Through its governance model, the Eclipse Foundation addresses these requirements as a service to its projects. The following breakdown highlights how the Foundation’s practices, processes, and policies, as detailed (in part) in the Eclipse Project Handbook, map to the high-level requirements of the OpenChain standard.
Programme Foundation and Awareness
The first pillar of OpenChain compliance is the establishment of a documented policy. The Eclipse Foundation fulfills this through our Intellectual Property Policy and the corresponding sections of the Eclipse Project Handbook. These documents provide the legal and procedural baseline for all activity within the ecosystem. Awareness is fostered through the Committer Due Diligence Guidelines, to which all elected committers must agree. These guidelines explicitly detail the expectations regarding code provenance and the use of third-party software.
The Eclipse Foundation provides multiple training modules, including specific education on IP due diligence, for Eclipse committers.
Roles, Responsibilities, and Staffing
OpenChain requires that an organisation identify the roles responsible for the compliance programme and ensure they are appropriately staffed. At the Eclipse Foundation, these roles are clearly delineated between the committers, the PMCs, and the professional staff of the EMO. Specifically, the responsibility for receiving and responding to external compliance inquiries is held by the Eclipse Foundation’s IP Team.
The IP Team handles inquiries from the committer community and does all of the hard work involved in IP due diligence. This centralised function ensures consistency across hundreds of projects. The Eclipse IP Team is staffed by professionals with backgrounds in IP risk management and data analysis ensuring that the competency requirement of ISO/IEC 5230 is met with a high degree of rigour.
Review and Remediation Processes
A core requirement of any compliance programme is a process for identifying and reviewing the obligations of open source licences. The Eclipse Foundation addresses this through a combination of automated scanning and manual review.
Every third-party library or contribution that is not original code from a committer is vetted via the IP due diligence process. The IP Team uses a variety of scanning tools to identify the licences involved and check for compatibility with the project’s own licence. When a non-compliant case or a problematic licence is identified, the Foundation has documented procedures for remediation. This might involve working with the project team to replace a dependency or identify a different version. This systematic approach ensures that by the time an Eclipse open source project reaches its release, the licence obligations mentioned in OpenChain have been thoroughly vetted.
Compliance Artifacts and Delivery
OpenChain focuses on the delivery of compliance artifacts. This includes ensuring that the software distribution is accompanied by the necessary licence texts and notices. The Eclipse Project Handbook mandates that all projects include standard legal files and proper copyright headers.
The introduction of the SBOM requirement for OpenChain-compliant projects is the final piece of this puzzle. By requiring a standard-format SBOM, the Eclipse Foundation ensures that downstream adopters and consumers receive a comprehensive inventory of the software. This inventory allows adopters to perform their own risk assessments and ensures that the transparency promised by the Eclipse process is accessible in an automated, industry-standard way.
The Value of Standardised Compliance
The alignment of Eclipse projects with ISO/IEC 5230 is more than a branding exercise; it is a response to the needs of the global software industry. As regulations like the Cyber Resilience Act in Europe and various executive orders in the United States place more pressure on software producers to vouch for their supply chains, having a known-good process is essential.
The Eclipse Foundation’s model is particularly powerful because it relieves individual project teams of much of the administrative burden. By providing the policy framework, the legal expertise, the scanning infrastructure, and the liaison functions, the Foundation allows developers to focus on innovation while remaining within the guardrails of legal safety. When a project lead at the Eclipse Foundation asserts that their project is OpenChain compliant, they are not just making a promise; they are pointing to a verified history of graduation, successful mature-phase progress reviews, and a machine-readable SBOM.
Conclusion
In the world of open source, trust is the ultimate currency. For decades, the Eclipse Foundation has built that trust through a meticulous, hands-on approach to intellectual property. By embracing the OpenChain specification, the Foundation has provided its projects with a way to translate that internal rigour into a globally recognised standard of excellence.
The path to compliance is clear: a project must graduate into maturity, maintain its standards through regular progress reviews, and provide the community with an SBOM. This journey, guided by the Eclipse Project Handbook and supported by a dedicated team of experts, ensures that Eclipse projects remain at the forefront of the professional open source movement. As organisations look for certainty in their software supply chains, the combination of Eclipse governance and OpenChain compliance provides a robust, scalable, and dependable solution for the future of digital innovation.
Please also see:
We’ve created this issue as place to post comments and discuss this article. If you have questions about Eclipse Project Governance, contact emo@eclipse-foundation.org.
