The Eclipse Foundation Explained: Governance, Projects and the CRA

The Eclipse Foundation is an international non-profit association registered in Brussels under Belgian law that hosts more than 450 open source projects, including Jakarta EE, the Adoptium Temurin Java runtimes and the Eclipse IDE. Members fund it and sit on its board, while a written development process, an IP policy and a security policy govern every project. Under the EU Cyber Resilience Act (CRA), it is the kind of organisation the law calls an open source software steward.

This guide goes one level deeper than our posts comparing open source foundation governance models and the Linux Foundation and Apache governance approaches. We read the Eclipse Foundation's own governance documents (the bylaws, version 1.1.1 dated 17 December 2025; the Eclipse Foundation Development Process, version 1.12 effective 1 July 2026; the Intellectual Property Policy, version 8.0.1 effective 18 March 2026; and the Security Policy, version 1.2 of 20 November 2024), the Eclipse Dash License Tool documentation, the Open Regulatory Compliance working group site, the European Commission's CRA pages and the text of Regulation (EU) 2024/2847. Every rule, threshold and date below comes from those sources.

Key takeaways

• The Eclipse Foundation AISBL is a Belgian international non-profit association with its registered office in Brussels. Its General Assembly of members is the supreme body; a Board of Directors runs the foundation day to day, and an Executive Director leads the Eclipse Management Organization (EMO), the staff arm that runs IP review, security and project lifecycle work.
• There are four membership classes: Strategic, Contributing, Committer and Associate. Each Strategic Member nominates a director; Contributing and Committer Members each elect at least one director, plus one more for every five Strategic seats beyond the first.
• Every new project starts in incubation, passes a Creation Review, should graduate in roughly three to six months, and can only ship releases for one calendar year after a successful Progress or Release Review. Reviews run for at least one week, usually no more than two.
• The IP Policy requires the EMO to approve every piece of third party content before a project distributes it. The Eclipse Dash License Tool automates the check against ClearlyDefined and the foundation's own license data, and can open review requests with the IP team.
• The Eclipse Foundation runs a PSIRT that acts as a CVE Numbering Authority. The Security Policy asks projects to fix a vulnerability in no more than three months and says all vulnerabilities must eventually be disclosed.
• The CRA's open source steward role (Article 24) asks for a cybersecurity policy, cooperation with market surveillance authorities and reporting of actively exploited vulnerabilities and severe incidents to the extent the steward is involved. Manufacturers have had to report since 11 September 2026, but the Commission says steward reporting under Article 24(3) applies from 11 December 2027, the same date as the main obligations. Stewards are not subject to administrative fines.
• The Open Regulatory Compliance working group (ORC WG), hosted by the Eclipse Foundation, brings industry, SMEs, research institutions, foundations and maintainers together to work on CRA compliance for open source. The Commission's open source CRA page lists it as a community resource.
• A foundation does not make you compliant. If you ship a product that includes Eclipse code, you are the manufacturer under the CRA, and the due diligence on that component is yours.

What is the Eclipse Foundation?

The foundation describes itself as an international non-profit association that gives individuals and organisations "a business-friendly environment for open source software collaboration and innovation." Its about page says it hosts Adoptium, Software Defined Vehicle, Jakarta EE, the Eclipse IDE and more than 450 open source projects spanning runtimes, tools, specifications and frameworks for enterprise, cloud, edge, automotive, AI, embedded, IoT, systems engineering and open processor designs. It reports support from more than 300 member organisations.

Where did it come from?

The same page gives the short history. The Eclipse Project was created in November 2001 by a single company and supported by a consortium of software vendors. The Eclipse Foundation was created in January 2004 as an independent not-for-profit corporation "to act as the steward of the Eclipse community," so that a vendor neutral, open and transparent community could grow around the platform. That origin explains a lot about how the foundation still works: it was built as a place where competing companies could share a platform (originally an IDE and its plug-in framework) under rules that no single vendor controlled.

Why is it registered in Brussels?

Today the legal entity is the Eclipse Foundation AISBL. The bylaws describe it as "a Belgian incorporated international not-for-profit association" with its registered office at Rond Point Schuman 11, 1040 Brussels, enterprise number 0760.624.114, under the French-speaking Enterprise Court of Brussels. AISBL is the Belgian legal form for international non-profit associations. The bylaws state that the association has legal personality and is governed by Belgian law, and that the registered office can only move within Belgium by a Board decision.

The foundation's own Europe page gives its reasons. It calls itself "a Belgian-based AISBL operating under European law" and lists regulatory readiness, "such as the Cyber Resilience Act (CRA)", global policy insight and trusted governance as member benefits. The same page ties the Open Regulatory Compliance working group, security audits, supply chain safeguards and CVE management to its privacy and security work, and cites figures of more than 450 projects, more than 300 members and more than 20 collaborations.

For a European regulation like the CRA, that matters in a practical way. A steward that is itself an EU legal person can talk to national market surveillance authorities inside their own legal frame and answer questions about EU law as a party subject to it. The Commission's open source CRA page notes that representatives of free and open source software sit on the CRA Expert Group. None of the governance documents we read dates the transition itself, so we do not give one here.

How is the Eclipse Foundation governed?

Governance is split across four layers, each set out in a document you can read: the bylaws (who controls the association), the membership and working group agreements (who pays and who votes on what), the development process (how projects run) and the policies (IP, security, antitrust, code of conduct).

General Assembly

Article 17 of the bylaws makes the General Assembly "the supreme body of the Eclipse Foundation." It holds the powers reserved to it by Belgian law and the bylaws, including approving changes to the foundation's name, approving or amending the membership agreement and amending the bylaws. Changes of that kind need qualified majorities: the bylaws refer to two thirds majorities of votes cast for several decisions, and certain provisions protecting Strategic Members can only change with the unanimous consent of the Strategic Members.

Membership classes

The bylaws define four classes:

The bylaws also require at least three members other than Associate Members. A committer employed by a member company is deemed a Committer Member through that company's membership agreement; a committer whose employer is not a member signs the membership agreement personally to get Committer Member rights. Associate Members may attend and speak at the General Assembly but cannot vote there and have no board seat.

Board of Directors and how seats are counted

Article 23 sets the board's composition, and the formula is worth reading closely because it ties community seats to corporate seats:

• Each Strategic Member nominates one director, who must be an employee, officer, director or consultant of that member. If the membership ends, the director is deemed to have resigned with immediate effect.
• Contributing Members as a class get at least one seat, plus one more for every five Strategic seats beyond the first, counted each year as of 1 February. The bylaws give the arithmetic: sixteen Strategic Members means four Contributing seats; fifteen means three. No Contributing Member may hold more than one Contributing seat.
• Committer Members as a class get seats on the same formula. No more than half the candidates in a given Committer election may come from the same legal entity and its affiliates.
• Contributing and Committer directors are chosen in annual at-large elections using Single Transferable Vote, then formally appointed by the General Assembly.

The board holds residual powers: anything not reserved to the General Assembly. Under the development process, it also approves the charter of every Top-Level Project and approves PMC Leads.

Executive Director, EMO and the Technical Advisory Council

Article 16 makes the Executive Director responsible for forming the Eclipse Management Organization. The development process describes the EMO as "the operational arm of the Eclipse Foundation," responsible for IP due diligence, security audits and project lifecycle management, and as a neutral mediator between companies. The EMO in turn establishes the Eclipse Technical Advisory Council, which guides the conventions, standards and architectures used by projects and advises the Executive Director on matters important to developers, including proposed changes to the development process.

Older Eclipse documents and many blog posts describe separate Architecture and Planning Councils. The current bylaws name a single Technical Advisory Council; if you read older material, check the version date.

Working groups and interest groups

A working group, in the bylaws' words, is "a collection of Eclipse Foundation Members" that collaborate under a charter and a Working Group Participation Agreement, with their own fees. The foundation's collaboration page lists the services a working group gets: vendor neutral governance, ecosystem development and marketing, collaboration management, specification development, and branding and compatibility programs. Jakarta EE, Adoptium, Software Defined Vehicle and the Open Regulatory Compliance group are all organised this way.

The split is the key to understanding Eclipse: projects write code under the development process and are open to any contributor, while working groups are member organisations funding and steering a domain (marketing, compatibility programs, specification ballots) around those projects.

Which major projects does the Eclipse Foundation host?

The foundation's own about page lists Adoptium, Software Defined Vehicle, Jakarta EE and the Eclipse IDE as headline technologies, alongside more than 450 projects. A few matter to most software supply chains.

Jakarta EE

Jakarta EE is the open, vendor neutral successor to Java EE, developed as a set of specifications with compatibility test kits (TCKs). The Jakarta EE site lists the Platform, Web Profile and Core Profile, individual specifications, released versions 8 through 11 and Jakarta EE 12 as work in progress.

Specifications follow a second rulebook, the Eclipse Foundation Specification Process (EFSP), version 1.4.1 dated 1 July 2026. The EFSP says that while much of the day to day work happens in projects under the development process, the process and the Final Specifications it produces "are to be managed by Working Groups" through Specification Committees, which may tailor the process with EMO approval. It defines a Compatible Implementation as one that fulfils every requirement of a Final Specification "as demonstrated by fulfilling all requirements of the associated TCK," and patent grants flow to implementers under the licences defined in the IP Policy. If your application server, servlet container or persistence library says it implements Jakarta EE, the specification and its TCK live at Eclipse even when the implementation lives elsewhere.

Eclipse Adoptium and Temurin

The Adoptium site says the mission of the Eclipse Adoptium Top-Level Project is "to produce high-quality runtimes and associated technology for use within the Java ecosystem." Its Temurin builds are OpenJDK based runtime binaries described as TCK tested and compliant. Adoptium also publishes build scripts, a test farm and quality assurance tests that other runtime builders can use, plus infrastructure for running Java SE TCKs. For a security team, Temurin is often the single most widely deployed piece of Eclipse hosted software in the estate, because it sits under every Java service and build agent. Its trust store, update cadence and end of life dates are therefore operational facts, as our posts on checking Java cacerts after the eMudhra incident and updating JDK vendor builds show.

Eclipse IDE, Theia and developer tools

The Eclipse IDE is where the foundation started and remains a flagship technology, and Eclipse Theia is a framework for building cloud and desktop IDEs. The Dash License Tool README uses Theia's project identifier (ecd.theia) in its review example: tool projects go through the same IP checks as runtimes.

Automotive, IoT and edge

The Software Defined Vehicle working group gathers automotive projects, and IoT and edge is one of the foundation's main technology areas. These projects often end up in products with long field lives, where the CRA's support period and vulnerability handling duties bite hardest.

Other components you probably already run

Eclipse projects show up deep in dependency trees: the Jetty web server and servlet container, the Paho MQTT clients, Vert.x, the Eclipse Collections library, EclipseLink, Mosquitto and others. Our Eclipse Jetty patching guide covers one of these in detail. Project homes and repositories move over time, so look up the current project page before you script against a URL.

How does the Eclipse Development Process work?

The Eclipse Foundation Development Process (EDP) is the rulebook every project follows. Version 1.12 took effect on 1 July 2026. It opens with principles (the "Open Source Rules of Engagement": openness, transparency and meritocracy) and three communities a project must serve: developers, users and adopters. It is explicit that use inside contributing companies is "necessary, but not sufficient" to prove an adopter community.

Project structure

Projects are hierarchical. A Top-Level Project has a charter approved by the Board and is run by a Project Management Committee (PMC) with one or more PMC Leads (approved by the Board) and PMC Members (elected by the PMC and approved by the Executive Director). Each project below it has one or more Project Leads, committers and contributors. Subprojects operate under the charter of their Top-Level Project, and a project's scope must be a subset of its parent's.

The "Project Leadership Chain" runs from Project Lead, through parent project leadership and the PMC, to the EMO and the Executive Director. In exceptional cases (zero active committers, disruptive committers, no effective lead) that chain can add or remove committers and leads.

Becoming a committer

The election rules are concrete:

1. An existing committer on the project nominates the contributor.
2. The project's committers vote for at least one week.
3. At least three positive votes and no negative votes are required. On projects with three or fewer committers, all committers must vote yes.
4. The PMC approves.
5. The contributor signs the committer legal agreements, including the committer due diligence guidelines, and gets write access.

Committers inactive for "more than six months" can have commit rights removed by unanimous consent of the Project Leads.

Lifecycle phases

Two details are easy to miss. All projects except Top-Level Projects start in incubation "independent of code maturity or developer skill," so the label describes process alignment, not code quality. And a Permanent Incubator subproject (with "Incubator" in its name) never graduates and never releases, though it may publish builds.

Reviews

Every review follows the same process: the team completes IP due diligence first, assembles documentation, gets PMC approval, asks the EMO to schedule it, and the EMO publishes it to members and then approves or fails it. A review period is "open for no less than one week and usually no more than two weeks."

Releases

The EDP defines a release as anything distributed beyond the project's committers: "If consumers are being directed to download a build, then that build has been released." Before any release, the Project Lead must assert that the IP Policy was followed and approvals received. And a project "can make Releases for one calendar year following a successful Progress Review or Release Review." That annual check is one of the most useful signals an adopter can look at, because a project that has not passed a review in over a year should not be shipping official releases.

Grievances and EMO authority

Members with a concern escalate up the leadership chain, then to the EMO, the Executive Director and finally the Board. The EMO can suspend access, add or remove committers and leads, and in extreme cases terminate a project, including for failing to implement the Security Policy or IP Policy. When it acts, it must disclose its reasons publicly within one week.

How does the Eclipse Foundation handle IP due diligence and licences?

The IP Policy (version 8.0.1, effective 18 March 2026) distinguishes three kinds of content:

• Project Content: code developed or modified by Eclipse projects, whatever its licence.
• Third Party Content: everything else, such as libraries a project depends on and redistributes.
• Hosted Content: content in repositories that are not subject to the full due diligence and record keeping rules, which the Board must approve.

Project licences and EPL-2.0

The bylaws define "EPL" as the latest version of the Eclipse Public License approved by the board, and the IP Policy requires each project's licences to be on a Board approved list and consistent with each other. EPL-2.0 is the default licence for many Eclipse projects. It is a weak copyleft scoped by what the licence calls Modified Works: additions, deletions or modifications to the Program's contents, including any new source file that contains Program contents. The text excludes files that only declare interfaces, types or classes "in order to link to, bind by name, or subclass the Program." When you distribute EPL code in object form, you must make the source available under the EPL and tell recipients how to get it. EPL-2.0 also defines a Secondary License as GPL-2.0 or later, with any exceptions the initial contributor names (GPL-2.0 with the Classpath Exception is common in Java projects). The secondary option only applies if the initial contributor attached the Exhibit A notice; the licence says copying the agreement alone "is not sufficient." Many Eclipse projects are dual or multi licensed (for example EPL-2.0 alongside Apache-2.0 or a GPL variant), so read the LICENSE and NOTICE files in the specific release you consume.

Third party content

The IP Policy is strict about what a project may redistribute:

• Third party content can only be used where the EMO has determined it is important to the project's goals and that its licence is not inconsistent with the project's licences.
• Third party content "shall only be Distributed when it has been approved by the EMO after its completion of the due diligence and record keeping requirements."
• Projects may keep bug fixes or derivative works of third party content as project content where the original developers are unable or unwilling to provide the fix. That clause is the IP basis for an Eclipse project patching a dependency it cannot wait on.

The Eclipse Dash License Tool

Running a manual review for every transitive dependency would be impossible, so the foundation built the Eclipse Dash License Tool. Its README is clear about scope: the tool "does not identify dependencies"; your build tool does that. Dash takes the list and, for each item, identifies it by its ClearlyDefined id (for example maven/mavencentral/org.apache.commons/commons-csv/1.8), then checks two sources: an Eclipse Foundation service built from data the IP team has collected over the years, and ClearlyDefined. Each item comes back as approved or restricted; restricted means the IP team needs to look at it.

It accepts a flat file of ClearlyDefined ids, Maven coordinates or npm ids, plus package-lock.json, pnpm-lock.yaml and yarn.lock. The -summary <file> option writes a CSV line per input item with its licence and status. With -review and a GitLab token, it opens review requests in the IP team's IPLab repository on the foundation's own code hosting. The executable jar is published to the Eclipse Maven repository, and there is also a Maven plugin that works directly against a Maven build. We walk through the command line version below.

Why this matters outside Eclipse

The IP process checks licences, not vulnerabilities. But its discipline (a complete dependency list per release, recorded approvals, a named person asserting compliance before shipping) is the evidence habit the CRA expects, and a project that already keeps a full third party inventory is close to producing an SBOM.

What does the Eclipse Foundation's security team do?

The foundation's security page says its Project Security Incident Response Team (PSIRT) "manages vulnerability reporting, triage, disclosure, and remediation, while also acting as a CVE Numbering Authority (CNA)." It also lists project security support, repository management best practices, developer training, self service tools and security advocacy as services. Reports go to security@eclipse-foundation.org or through a project's own channel.

Who fixes what

The Security Policy (version 1.2, 20 November 2024) splits responsibility:

• The EF Security Team is part of the EMO and is "the first line of defense." It triages reports and routes them to the right project. It "does not resolve Vulnerabilities."
• Each project's Security Team (by default, its committers) coordinates the fix. Projects must tell the EF Security Team how to reach their security contacts and keep that current.
• When the reporter, the project and the EF Security Team disagree on whether something is a vulnerability, the EF Security Team gives the final classification.
• The EMO will provide a confidential channel for undisclosed vulnerabilities on request.

Disclosure timing

Timing is at the discretion of the Project Leadership Chain, with recommended defaults:

• Resolved vulnerabilities are disclosed immediately after a release with the fix is available.
• Projects are expected to resolve a vulnerability in no more than three months; the leadership chain and EF Security Team can extend that.
• The leadership chain, with the EF Security Team, may disclose earlier if needed.
• All vulnerabilities must eventually be disclosed.

The policy also defines quiet disclosure (for issues wrongly marked as vulnerabilities, or low severity ones where exploitation is highly unlikely), progressive disclosure to specific experts before public release, and full disclosure through the foundation's channels. A project may also report to an external authority, and the EF Security Team decides how to engage with reporting authorities, which is the hook for CRA reporting.

What adopters get from this

Because the foundation is a CNA, CVEs for Eclipse projects are usually assigned by the organisation that hosts the code, and the security page links a known vulnerabilities list and advisories. You can usually trace an Eclipse CVE to a project, a fix release and an advisory without guessing which upstream owns it.

What is the Open Regulatory Compliance working group?

The ORC WG site describes the group as bringing together "key stakeholders from industry, small and medium enterprises (SMEs), research institutions, open source foundations, maintainers and contributors" to support compliance with government regulations while keeping open source usable through the software supply chain. It says the group will work with governmental bodies to help industry meet regulatory requirements, and help open source projects address industry's needs as rules change.

It is a working group, so it follows the same model as Jakarta EE or Adoptium: member organisations sign a participation agreement under a charter. Treat what it publishes as community guidance, not legal advice and not a certification. The European Commission's open source CRA page lists "The Open Regulatory Compliance Working Group (ORC WG) on the CRA" among private community resources, alongside an OpenChain CRA checklist, Open Source Initiative work on harmonised standards and an OpenSSF course. The Commission adds that it does not endorse those initiatives or check their accuracy.

What does the CRA's open source steward role require?

The definition

The Commission's page explains that the CRA covers free and open source software only when it is made available on the market, meaning supplied in the course of a commercial activity. FOSS that is not monetised by its manufacturer is not considered a commercial activity, and the CRA does not apply to developers contributing code to projects that are not under their responsibility.

Between those two poles, the CRA creates "the novel legal category of open-source software stewards." In the Commission's words, a steward is a legal person that does not place the software on the market but "provides systematic support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities, and ensures the viability of those products." The Commission calls the resulting regime "light-touch and tailor-made."

A foundation that hosts projects, runs their infrastructure, provides security and IP services and keeps them viable through funded working groups is the model the definition was written around. Whether a particular entity meets the definition for a particular project is a legal question that depends on facts, and we are not claiming the foundation has made any specific determination.

The obligations in Article 24

The Commission summarises Article 24 as:

1. Putting in place a cybersecurity policy to foster secure development and handling of vulnerabilities.
2. Cooperating with market surveillance authorities.
3. Reporting actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements, to the extent the steward is involved.

The Commission's summary of the legal text words the reporting duty more narrowly: actively exploited vulnerabilities "to the extent that they are involved in the development" of the product, and severe incidents to the extent they affect network and information systems the steward provides for development. Under Article 64(10), stewards are not subject to administrative fines for infringing the CRA.

How reporting works

The reporting mechanics are the same for manufacturers and stewards. The Commission's reporting page says notifications go through the CRA Single Reporting Platform (SRP), which ENISA runs and which has been operational since 11 September 2026. A notification goes to the CSIRT of the Member State where the reporter has its main establishment and, outside exceptional circumstances, is made available to ENISA at the same time. For manufacturers, the deadlines are an early warning within 24 hours of becoming aware, a full notification within 72 hours, and a final report no later than 14 days after a corrective measure is available for an actively exploited vulnerability (or within a month of the 72 hour notification for a severe incident). On 11 December 2025, the Commission adopted a delegated act on when a CSIRT may delay passing a notification to other CSIRTs on cybersecurity grounds.

Dates

The Commission's CRA page gives the headline timeline: the regulation entered into force on 10 December 2024; reporting obligations apply from 11 September 2026; the main obligations apply from 11 December 2027. Its reporting page adds a detail that matters for foundations: "In accordance with Article 71(2) of the CRA, open-source software stewards are subject to reporting obligations (Article 24(3)) from 11 December 2027." On 27 July 2026, the Commission published practical guidance for manufacturers and businesses, and its open source page points to Section 3 of that guidance for FOSS questions.

How Eclipse's existing machinery maps to Article 24

The mapping shows why the foundation model fits the steward role, and why the role is still real work.

What the CRA does not shift to the steward

The steward regime does not make anything compliant on a manufacturer's behalf. If you put a product with digital elements on the EU market and it contains Jakarta EE APIs, Temurin, Jetty or any other Eclipse component, you are the manufacturer. The Commission's page is explicit that a manufacturer placing FOSS on the market is subject to manufacturer obligations. You still have to do your own due diligence on that component, handle vulnerabilities in it for your support period and report actively exploited vulnerabilities in your product. Our post on running an OSPO as an open source steward under the CRA covers the in-house side.

How does Eclipse compare with the Linux Foundation and the Apache Software Foundation?

All three are large open source foundations built on different legal and governance models. This is a structural comparison, not a ranking.

The Eclipse model is the most centralised of the three on IP intake: no third party content ships until the EMO has approved it. The Apache model leans hardest on individual merit and board elected by individual members. The Linux Foundation model is the most federated, with each fund setting much of its own process. Each shapes what an adopter can assume. For a deeper look at how the other two handle supply chain controls, see our comparison of Linux Foundation and Apache governance and what CNCF maturity levels mean for security.

How should a company check an Eclipse hosted component before adopting it?

Foundation hosting is a good sign, not a guarantee. These steps use public data and work for any Eclipse project.

Step 1: Find every Eclipse component you already ship

Start from your builds, not from memory. For Maven:

# List every dependency whose groupId starts with org.eclipse or jakarta
mvn -q dependency:list -DincludeScope=runtime -DoutputFile=deps.txt
grep -E "org\.eclipse|jakarta\." deps.txt | sort -u

For Gradle:

./gradlew dependencies --configuration runtimeClasspath | grep -E "org\.eclipse|jakarta\."

For the Java runtime itself:

java -XshowSettings:properties -version 2>&1 | grep -E "java\.vendor|java\.runtime\.version|java\.vm\.version"

In containers, check the base image too, because many images bundle a Temurin runtime.

Step 2: Check the project's lifecycle phase and last review

Open the project page on projects.eclipse.org and look for the phase (incubating or mature), the list of reviews and the date of the last successful Progress or Release Review. Under the EDP, a project can make releases for one calendar year after such a review. An incubating project is not necessarily lower quality, but it may not yet implement every policy, and its releases must carry incubation branding.

The same data is available as JSON from the projects API, which is easier to put in a script. The example below uses the Dash project's identifier (technology.dash); substitute the identifier from the project page you care about.

P=technology.dash

# Phase, licences, top-level project, security team settings and SLSA build level
curl -s "https://projects.eclipse.org/api/projects/$P" \
  | jq '.[0] // . | {project_id, state, licenses: [.licenses[].short_name], top_level_project, security_team, slsa}'

# Reviews with dates and outcomes, newest first
curl -s "https://projects.eclipse.org/api/projects/$P/reviews" \
  | jq -r '.reviews | sort_by(.date) | reverse | .[] | "\(.date) \(.review_name) \(.status)"' | head

# Releases with dates
curl -s "https://projects.eclipse.org/api/projects/$P/releases" \
  | jq -r '.releases | sort_by(.date) | reverse | .[] | "\(.date) \(.name)"' | head

When we ran this on 23 October 2026 (the reviews list can include scheduled reviews with a future date and no outcome yet), the API reported the Dash project's state as Regular (the API's label for a project that is not incubating), its licence as EPL-2.0, its project security team as the committers, and a Creation Review dated 9 December 2005. Field names can change, so check the raw JSON once before you rely on a script.

Step 3: Check release cadence and support

Look at the release history in the project's repository:

# Last ten tags and dates from a cloned repository
git -C path/to/project tag --sort=-creatordate \
  --format='%(creatordate:short) %(refname:short)' | head -10

For Temurin, the Adoptium API reports which feature releases are available and which are long term support:

curl -s https://api.adoptium.net/v3/info/available_releases | jq '{available_lts_releases, most_recent_lts, most_recent_feature_release}'

Compare the support window against your own product's support period. Under the CRA, the manufacturer has to handle vulnerabilities for the period it declares, so a component with a shorter maintenance window becomes your problem to cover.

Step 4: Check security response

Check the project's security contact and advisories (the foundation security page links its known vulnerabilities list), and query an open vulnerability database for the exact version you use:

curl -s https://api.osv.dev/v1/query -d '{
  "package": {"name": "org.eclipse.jetty:jetty-server", "ecosystem": "Maven"},
  "version": "12.0.0"
}' | jq '.vulns[]? | {id, summary}'

Look for how long past fixes took between report and release, whether advisories name fixed versions clearly, and whether older branches got backports. The Security Policy's three month expectation gives you a baseline to compare against.

Step 5: Check licences the way the project does

You can run the same Dash License Tool the projects use. It needs Java and the jar from the Eclipse Maven repository (the README links the latest download):

# Build a dependency list in ClearlyDefined-compatible Maven coordinates
mvn -q dependency:list -DoutputFile=deps.txt -DappendOutput=false
grep -Eo '[a-zA-Z0-9_.-]+:[a-zA-Z0-9_.-]+:jar:[a-zA-Z0-9_.-]+' deps.txt \
  | awk -F: '{print $1":"$2":"$4}' | sort -u > deps-gav.txt

# Check licences; write a CSV summary
java -jar org.eclipse.dash.licenses-<version>.jar -summary DEPENDENCIES deps-gav.txt

For JavaScript projects, point it at the lockfile:

java -jar org.eclipse.dash.licenses-<version>.jar package-lock.json

The summary file maps each package to a licence and marks it approved or restricted. For your own product, restricted is not a ban; it means nobody has vetted that item against Eclipse's licence policy yet, so check it against your own policy. Only Eclipse committers working on Eclipse projects should use -review to open IP team requests.

Step 6: Record what you found

Put the component, version, licence, lifecycle phase, last review date, support window and security contact into your SBOM or component inventory. Under the CRA that record is part of the due diligence you will need to show for third party components.

Common mistakes

• Treating "Eclipse" as a warranty. The foundation provides governance and process; it does not take on your manufacturer obligations or support your product.
• Reading incubation as low quality, or mature as maintained. Incubation is about process alignment. A mature project can still be thinly staffed; check recent commits, releases and reviews.
• Assuming an approved Dash result means safe. It is a licence and provenance check. It does not look at vulnerabilities.
• Missing the runtime. Teams scan application dependencies and forget the JDK in the base image, which is often Temurin and has its own update cadence and trust store.
• Assuming the CRA steward role covers you. Stewards have light duties for the projects they support. Manufacturers placing products on the market keep full obligations.
• Mixing up the reporting dates. Manufacturers have had to report actively exploited vulnerabilities since 11 September 2026. The 11 December 2027 date for stewards does not delay a manufacturer's own duty to report on its product.
• Scripting against moved repositories. Eclipse projects change hosting over time. Use the project page or projects API as the source of truth.

FAQ

Is the Eclipse Foundation a European organisation?

Yes. Its bylaws describe the Eclipse Foundation AISBL as a Belgian international non-profit association with its registered office in Brussels, governed by Belgian law.

Who controls the Eclipse Foundation?

The members' General Assembly is the supreme body. A board of Strategic Member nominees plus elected Contributing and Committer directors runs the foundation, and an Executive Director leads the EMO staff.

What licence do Eclipse projects use?

Many use EPL-2.0, sometimes with a GPL secondary licence or alongside another licence. Each project's licences must be on a Board approved list, so check the licence files in the release you use.

What does incubating mean for an Eclipse project?

It means the project is still aligning its process, community and policies with the Eclipse Development Process. All new projects except Top-Level Projects start there, whatever their code maturity. The guideline is three to six months, and releases must carry incubation branding.

Is the Eclipse Foundation a CVE Numbering Authority?

Yes. Its security page says the Eclipse Foundation PSIRT acts as a CNA, alongside handling reporting, triage, disclosure and remediation coordination.

How fast do Eclipse projects fix vulnerabilities?

The Security Policy recommends that projects resolve a vulnerability in no more than three months, with extensions possible, and disclose immediately after a fixed release ships. Actual timing varies by project.

What is an open source software steward under the CRA?

A legal person that does not place software on the market but systematically supports the development of specific FOSS products intended for commercial use and ensures their viability. Stewards must have a cybersecurity policy, cooperate with authorities and report actively exploited vulnerabilities and severe incidents (from 11 December 2027, according to the Commission), and are not subject to administrative fines.

Does using Eclipse software make my product CRA compliant?

No. If you place a product on the EU market that includes Eclipse components, you are the manufacturer and carry the manufacturer obligations, including due diligence on those components and vulnerability handling for your support period.

What is the Open Regulatory Compliance working group?

An Eclipse hosted working group of industry, SMEs, researchers, foundations and maintainers working on open source compliance with rules such as the CRA. The Commission lists it as a community resource without endorsing it.

What is the Eclipse Dash License Tool?

A command line tool and Maven plugin that checks a dependency list or lockfile against Eclipse IP data and ClearlyDefined, marking each item approved or restricted.

Where Safeguard fits

Safeguard is not a licence clearance service, and it does not stand in for a foundation's IP team or a steward's CRA processes. The fit is on the adopter side. The Eclipse components you ship (Temurin in base images, Jakarta EE APIs, Jetty, Paho and the rest) are ordinary dependencies in ordinary repositories and container images. Safeguard can scan those with safeguard scan --dir ., --image <name> for a container image or --sbom <file> for an SBOM you already have, writing JSON results under ./output, and the platform shows which projects contain a given component and version. Vulnerability matching, reachability analysis and policy gates then apply to Eclipse components the same way they apply to any others.

Foundations like Eclipse make upstream better governed, but the CRA still puts the manufacturer on the hook for the components in its product and for every month of its declared support period. Keeping those components patched in your own builds is the part no steward can do for you.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. After install, safeguard opens the interactive terminal, you ask it to fix the lodash CVE in a repository, and it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. It ends with /permissions, /model and /scan. The demo uses an npm project, but the same ask, approve and test loop applies when the dependency to move is a Jetty or Jakarta EE artifact in a Maven build.

Click through it at your own pace, or open it full screen.

Build agents and release machines that assemble Java products are often kept on internal networks. The local runner demo shows how to set up the runner on your own machine, approve it with its device code, and then scan from the terminal, so the repositories and images on that host can be checked where they live.

Click through it at your own pace, or open it full screen.

If your team uses Claude, the third demo shows how to connect Claude to the Safeguard MCP server with OAuth and choose which tools Claude can use. A compliance lead preparing CRA due diligence notes could then ask which projects carry a given Eclipse component version, using only the tools you allowed.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Eclipse Foundation AISBL Bylaws, version 1.1.1 (17 December 2025)
• Eclipse Foundation Development Process, version 1.12
• Eclipse Foundation Intellectual Property Policy, version 8.0.1
• Eclipse Foundation Security Policy
• Eclipse Foundation Security
• About the Eclipse Foundation
• Eclipse Foundation working groups and collaborations
• Eclipse Dash License Tool README
• Open Regulatory Compliance Working Group
• About Eclipse Adoptium
• About Jakarta EE
• Eclipse Foundation Specification Process, version 1.4.1
• Eclipse Public License 2.0 text (SPDX license list data)
• Eclipse Foundation: European roots
• Eclipse projects API, Dash project record
• Adoptium API: available releases
• Apache Software Foundation: how it works
• Linux Foundation: about
• European Commission: Cyber Resilience Act
• European Commission: Cyber Resilience Act and open source
• European Commission: summary of the CRA legal text
• European Commission: CRA reporting obligations

Last reviewed: 23 October 2026. Eclipse governance documents and Commission CRA guidance are revised over time; check the version and date of each document before relying on a specific rule.