Eclipse Foundation Project Handbook

The Open Source Rules of Engagement lie at the heart of the EDP:

The Open Source Rules of Engagement define a foundation for vendor neutral open source development. Vendor-neutrality is concerned with maintaining a level playing field that is open to all comers: no vendor is permitted to dominate a project, and nobody can be excluded from participating in a project based on their employment status.

Quality and intellectual property cleanliness are also important principles.

Quality means extensible frameworks and exemplary tools developed in an open, inclusive, and predictable process involving the entire community. From the consumption perspective, Eclipse quality means good for users (exemplary tools are cool/compelling to use, indicative of what is possible) and ready for use by adopters. From the creation perspective, Eclipse quality means working with a transparent and open process, open and welcoming to participation from technical leaders, regardless of affiliation.

Intellectual property (IP) is any artifact that is made available from a Eclipse server (this includes source code management systems, the website, and the downloads server). Artifacts include (but are not limited to) such things as source code, images, XML and configuration files, documentation, and more. Strict rules govern the way that we manage IP and your responsibilities as a committer.

Code produced by an Eclipse project is used by organisations to build products. These adopters of Eclipse technology need to have some assurance that the IP they’re basing their products on is clean: the organisation or individuals who claim copyright of the code are the legitimate copyright holders, and the copyright holders legitimately agree to make the code available under the license(s) that the project works under. As a committer, you must be careful that you do not copy code and inadvertently claim it as your own.

Eclipse open source projects start with a proposal that is made available to the community for review. At the end of the community review period, we engage in a creation review, and then provision the project resources.

A proposal must minimally include a description of the project, a declaration of scope, and a list of initial members (project leads and committers) before we make it accessible to the public for community review.

When you feel that the proposal is ready, send a note to the Eclipse Management Organization (EMO) requesting that the proposal be made available to the public for review. The EMO will review the proposal and may provide feedback before initiating the community review period.

At the beginning of the community review period, the EMO will announce the proposal on several channels (the Project Activity News page, Twitter, blog post, and an email note to the Eclipse Foundation members and committers). The EMO will also open a record in the Eclipse Foundation’s issue tracker — an instance of GitLab — to track the progress of the proposal; the proposal’s author, and project leads will be copied on that record.

A proposal will be open for community review for a minimum of two weeks.

Use the web form to create a new project proposal.

Instructions are provided on the form. All new proposals are created in draft mode, and are accessible only by the original author and anybody designated as a project lead or committer in the proposal. Only those individuals designated as a project lead may edit the proposal.

When making the decision to initiate the creation review that will turn the project proposal into an Eclipse open source project, the EMO will consider the following:

When the project name trademark has been secured and the proposal contents are finalised, the EMO will schedule a creation review.

Following a successful creation review, the EMO will initiate the provisioning process.

Provisioning starts with an email message being sent to each of the committers listed on the project proposal with instructions on how to engage in the committer paperwork process. The exact nature of that paperwork depends on several factors, including the employment status of the individual and the Eclipse Foundation membership status of their employer.

When the paperwork is received and processed for one committer, the Eclipse IT Team will begin the resources provisioning process. When that process is complete, the Eclipse IT Team will provide information regarding the nature and coordinates of the various resources and services available to the project.

Before pushing any code into an official Eclipse project repository, the project team must submit the project’s initial contribution of project code and wait for the Eclipse Intellectual Property (IP) Team to grant checkin of that contribution.

third party content that is required by the project code must also be reviewed by the Eclipse IP Team.

After the project code is pushed into the project repository, the project team can create and distribute milestone builds for the first release. However, all intellectual property must be approved by the Eclipse IP Team before the project team can issue any official releases.

Eclipse projects move through various phases. Projects in active phases (incubation or mature) engage in all the normal sorts of development activities: project committers write code, run builds, release software, court contribution, and seek to convert contributors into committers. All new projects start in the incubation phase. Projects tend to stay in the incubation phase for a few months (varies depending on the nature and composition of the project) and then move into the mature phase.

Key project life cycle events are gated by reviews; moving from the incubation phase to the mature phase must be, for example, preceded by a graduation review.

To highlight that a project is in the incubation phase, it must implement incubation branding. Primarily, this takes the form of displaying the incubation logo in prominent locations, including the project’s major web properties and including the word "incubation" or warning that products shipped as part of a release may include incubating components.

Incubating branding includes:

There are no incubation branding requirements for any user-facing elements.

The incubation mailing list exists to facilitate discussions related to the incubation phase, allowing project committers to ask questions about Eclipse Foundation processes, seek guidance from the Eclipse Architecture Council, Eclipse Management Organization, and connect with other community members involved in projects in the incubation phase.

New committers are encouraged to join the incubation mailing list; this list is a good place to ask questions about process, services available, and other aspects of working as a committer.

New project teams are usually eager to get started generating content. In addition to creating fantastic content, there are a few things to remember:

Essential to the Purposes of the Eclipse Foundation is the development of the three inter-related communities around each Project, and the Incubation Phase is the best time to start forming those communities:

Projects are expected to make substantial progress on establishing these communities during their Incubation Phase.

Incubation Phase projects will eventually graduate, signifying that the project code base has stabilised and that the project team is familiar with the Eclipse Development Process.

Graduation Reviews are generally combined with a release review.

The project checklist provides some general criteria to determine whether or not a project is ready to exit the incubation phase.

The project lead(s) are responsible for requesting a Graduation Review when the project leadership believes the project meets the exit criteria.

For Eclipse projects (and the open source world in general), committers are the ones who hold the keys. Committers are either appointed at the time of project creation, or elected by the existing project team.

Committers decide what code goes into the code base, they decide how a project builds, and they ultimately decide what gets delivered to the adopter community. With awesome power, comes awesome responsibility, and so the Open Source Rules of Engagement described by the Eclipse Foundation Development Process, puts meritocracy on equal footing with transparency and openness: becoming a committer isn’t necessarily hard, but it does require a demonstration of merit.

Committers:

Eclipse projects must have at least one project lead, and may have more than one. The project leads are the primary liaison between the project team and the Eclipse Management Organization(EMO). As the first link in the project leadership chain, project leads have responsibility to ensure that the project team is able to successfully implement the goals of the project in accordance with the Eclipse Foundation Development Process and Eclipse Foundation Intellectual Property Policy.

The EMO considers it a good practice to have more than one person in that role to ensure that there is continuity. There is no artificial maximum number of project leads for an Eclipse project: the main thing that the EMO is concerned with is that project leads are elected in a vendor neutral manner following public demonstrations of leadership (documented as comments on issues, contributions to mailing list discussions, etc.) that are cited in the nomination statement. The EMO specifically watches elections to ensure that vendor neutrality is observed.

Project leads are either appointed at the time of project creation or elected by their committer peers (an individual is generally expected to have served as a committer before being nominated for the project lead role). Project leads must also be committers, but the two roles are distinct.

Project leads are responsible for ensuring that project committers are following the rules. At the most basic level, the rules are the open source rules of engagement defined in the Eclipse Foundation Development Process (openness, transparency, and meritocracy), and we depend on them to make sure that team members understand their obligations under the IP Policy and are correctly implementing the Intellectual Property Due Diligence Process.

Project leads have the ability to retire committers: this is a power that must be used responsibly. A project lead needs to be able to support their decision to retire a committer. As a best practice, the project lead should give committers reasonable opportunity to retrain their status, and — should the decision be made to retire — committer retirements should be announced on the project’s primary communication channels including the dev-list.

When committers are disruptive or otherwise behaving in a manner that is detrimental to the project, the project lead should work with the PMC and the EMO to resolve the issue.

Project leads have some extra privileges on GitLab and GitHub.

The project lead is not the technical lead. So it’s not strictly their responsibility to develop things like coding standards, project policies, and such. They are responsible, however, for making sure that those sorts of things get created and for making sure that the project team is working to complete shared goals.

Any committer can initiate a review with the EMO, but the EMO will always copy the project lead(s) in related communication to ensure that they are aware that the committer is acting as their delegate.

Project leads can also request the EMO to initiate a restructuring review in case a project needs to change the meaning of the scope or make any other significant changes to one or more Projects.

A project management committee (PMC) is responsible for the operation of exactly one top-level project as defined by the Eclipse Foundation Development Process. Per the EDP, top-level projects sit at the top of the open source project hierarchy.

The PMC’s role is, fundamentally, to maintain the overall vision and operation of the top level project and all of the projects that fall within their purview. Very often (though it really depends on the nature of the top level project), the PMC will take a very active role in determining how their projects fit together, and how they communicate and interoperate. In pragmatic terms, the PMC ensures that projects are following the rules, set the standards over and above the basic requirements for releases and corresponding documentation, approves intellectual property contributions, and approves committer and project lead elections.

Top-level projects do not generally maintain open source content of their own, but rather provide oversight and guidance to those open source projects that fall under them in the project hierarchy. All projects that fall under a particular top-level project must fit within the mission and scope defined by the top-level project’s charter. In addition to mission and scope, the charter may further define other requirements or establish guidelines for practices by the project that fall under its purview.

The primary role of the PMC is to ensure that project teams are implementing the EDP and operating within the terms outlined by the top-level project’s charter. In particular, the PMC monitors project activity to ensure that project teams are operating in an open and transparent manner.

The PMC is responsible for defining and managing the structure of the top level project and the organisation of the open source (software and specification) projects contained within.

The PMC provides other oversight regarding the operation of open source projects. They review and approve progress reviews, and facilitate cross-project communication within the top level project.

The Eclipse Architecture Council serves the community by identifying and tackling any issues that hinder Eclipse’s continued technological success and innovation, widespread adoption, and future growth. This involves technical architecture as well as open source processes and social aspects. Comprising the finest technical leaders from all community stake holders, it is the council’s goal to keep the projects successful and healthy, the processes simple and smooth, and the communities vibrant and cohesive.

More concretely, the Eclipse Architecture Council serves four basic purposes:

Every PMC may appoint a representative to the Architecture Council to represent the interests of the PMC and corresponding Top-level Project. Every Strategic Member of the Eclipse Foundation may also appoint a representative. Other Architecture Council Members are nominated and voted on by the Architecture Council itself, and appointed by the council by the Eclipse Foundation’s Executive Director. Appointed members serve a two year renewable term.

The Architecture Council interacts primarily via their mailing list. List participation is limited only to Architecture Council members and subscription to the list is automatic. Additionally, the Architecture Council meets (remotely) every month for a one-hour closed discussion (with public minutes).

Committers and Project Leads should connect with the Architecture Council via their PMC.

The Eclipse Management Organization (EMO) consists of the Eclipse Foundation staff, and the Eclipse Architecture Council. The EMO is responsible for providing services to the projects, facilitating project reviews, resolving issues, and more. The EMO is the maintainer of the Eclipse Foundation Development Process. The best method of contact with the EMO is by email (emo@eclipse-foundation.org). If you have a question that cannot be answered by project lead, or PMC, ask the EMO.

While it is natural to have one or more committers become technical leaders in the project team, there is no formal technical lead role defined in the Eclipse Foundation Development Process (EDP). Likewise, while it is natural for certain members of a specification project team to become leaders in the specification process, there is no formal notion of specification lead (or "spec lead") defined in the Eclipse Foundation Specification Process (EFSP). Any de facto technical or specification lead does not have any special authority beyond that which is granted to them by the other project committers.

The committers in a project team have some say over who their leaders are and what powers they grant to those leaders. While the role is not specifically defined for this sort of thing, the project lead role could be granted decision making powers. It is completely reasonable for a project team to decide, for example, that somebody in the project lead role must approve of all commits and anybody with that role can mitigate potential rogue actions by rolling back commits. One of the key benefits of organising in this manner is that project lead is an elected position, so project committers have a build-in process for capturing the decision to grant those extra powers.

For many open source projects, the committers follow the natural leaders. But when a more formal relationship is desired, it must be arrived at by consensus of the project team (via public channels) and documented clearly so that everybody can understand how the project team works (making it very clear how a project team works is a critically important aspect of growing diversity in an open, transparent, and meritocratic open source project team). If the project team decides, for example, that all committers must contribute their updates as pull requests that may only be merged by a project lead, then that must be documented (it’s fairly common for project teams to require that pull requests from one committer be merged by a different committer). When the role is formally defined, it’s also important to document how a committer ascends to into that role (to be clear, in the spirit of vendor neutrality, this criteria cannot be based on employment status).

As discussed in the Eclipse Foundation Development Process and throughout this document, Eclipse open source projects operate in an open, transparent, and meritocratic manner.

In this regard, all project resources are publicly accessible. Put another way, Eclipse open source projects have no private resources. All content repositories, mailing lists, discussion forums, etc. are publicly accessible. Exceptions may be made with the approval of the PMC and EMO; and only when there is some legal reason or technical limitation that requires an exception.

Project resources make use of two sorts of IDs:

For example the "Eclipse Woolsey" project has a short name of "woolsey"; its qualified identifier is "technology.dash.woolsey", indicating that it is a subproject of the an Eclipse Dash Project which is itself a subproject of the Eclipse Technology Top Level Project.

Eclipse projects must maintain project content (source code, documentation, configuration, etc.) in the repositories assigned to the project by the Eclipse Foundation. These official repositories must be the exclusive source of all content delivered via the project’s distribution channels (e.g. the download server).

Git commit records are required to take a specific form. The credentials of the actual author must be used to populate the Author field. The author credentials must specify the author’s actual (legal) name and email address. The email address used must match the email address that the Eclipse Foundation has on file for the author (case-sensitive).

The commit message is divided into three sections:

The summary line is used in many places where Git commits are listed, ensure that this line is sensible by itself. The description area should be used to provide more detail about the commit. The footer area is used for extra fields and values.

If the bug id is included in the summary line (using the form "Bug 12345 - xxx" or "[12345] xxx") Gerrit Code Review will automatically add a link in the corresponding Bugzilla record back to the Gerrit record (this, of course, only applies to commits pushed to Gerrit).

The Change-Id is used by Gerrit Code Review to associate new versions of a change back to its original review. This field need only be specified if the repository is managed by Gerrit.

An Also-by (or Co-authored-by) entry can be added for each additional author of a commit (one committer per entry). This might apply, for example, if a commit has been authored via pair-programming, or the commit is the result of collapsing multiple commits authored by multiple developers. To be considered valid the entry must take the form Also-by: Name <email>.

Authors who are not committers on the project receiving the commit must have an Eclipse Foundation Account and must have a signed Eclipse Contributor Agreement (ECA) on file.

The Eclipse Foundation maintains an instance of GitLab for use by Eclipse open source projects. Project teams may opt to host some or all of their canonical source code repositories on our GitLab instance.

On GitLab, the root group for all Eclipse open source project repositories is eclipse. Under that root, two nesting options are available: an Eclipse open source project’s group can be nested directly under the root, or can be nested in a group corresponding to the Eclipse top-level project. In both nesting options, repositories may be arbitrarily nested in subgroups created under the projects' group to organise the repositories. The custom subgroups are cosmetic only, as the same permissions are applied to the nested groups and do not provide any extra functionality.

Project teams may opt to host some or all of their canonical source code repositories to an organisation on GitHub that is maintained by the Eclipse Foundation. Both GitHub Issues and Wiki may also be used.

Any committer can open a Help Desk issue to request that the Eclipse IT Team create a new repository for their project on, or move an existing repository to, GitHub. A project may have more than one repository on GitHub. When making the request, the committer should describe—​specifically and concisely—​what they want to make happen. Note that the Eclipse IT Team will verify the request with the project leads.

Repositories can be hosted in the default eclipse GitHub organisation, or a dedicated organisation can be created. Dedicated organisations use as their name, the conjunction of eclipse with the project short name (e.g., eclipse-woolsey).

The Eclipse IT Team installs some hooks onto all Eclipse project repositories on GitHub.

The Committers hook grants designated project committers write access to the GitHub-hosted project repositories. Project committers must add their GitHub id to their Eclipse Foundation account, and must use the email address they provide to the Eclipse Foundation as the email address in the author credentials of all commits.

The Eclipse Contributor Agreement (ECA) hook will inspect incoming GitHub pull requests to ensure that the contributor has a valid ECA on file. Project committers should only merge green pull requests:

Since the GitHub API does not provide a way for a Committers hook to absolutely deny a merge by itself, the hook warns committers when the contributors have not signed an ECA.

Click on the Details link for more information. Committers must not merge commits unless they are certain that the contributor does have a valid ECA on file.

It is however possible to set up a Branch Protection Rule for branches to prevent that pull requests which fail the ECA validation are getting merged into them:

Gerrit provides web based code review and repository management for the Git version control system. Many projects use Gerrit to reduce barriers and encourage contribution to the project. As Gerrit is deprecated, we encourage projects to use GitLab or GitHub for code hosting.

If a repository belonging to a project is unmaintained or deprecated and will not receive any further updates, it is good practice to clearly indicate that in the corresponding README.md and SECURITY.md files of the repository with a migration path if applicable.

Committers shall mark a deprecated repository as being archived either by using the Self-Service of GitHub Resources or by opening a Help Desk issue to request assistance from the Eclipse IT Team.

Eclipse projects must use an Eclipse Foundation-provided issue tracker. Project teams may opt to use either the Eclipse Foundation GitLab instance or — for projects that use GitHub — GitHub Issues instances associated with Eclipse Foundation-managed GitHub project repositories.

Eclipse projects have one or more mailing lists.

Mailing lists take the following form: <shortname>-<extension>@eclipse.org, where <shortname> is the project’s short name and <extension> signifies the nature of the list (e.g., woolsey-users@eclipse.org or woolsey-ci@eclipse.org).

With the exception of channels created to discuss security issues while they are in quarantine, there are no private channels for project work. This means that we do not provide private mailing lists for any project activity and that all mailing lists use for project activity are configured to have a public archive.

Mailing list subscriptions are managed via your Eclipse Foundation Account.

All projects are assigned a user forum as a point of contact between the user and adopter communities, and the project developers.

The EMO strongly encourages the use of alternative communication channels for connecting with the community: project teams know their community and how to best connect with them.

Project websites are an excellent way to connect an open source project with the community. Many projects opt to use the Project Management Infrastructure (PMI) project page as their website. PMI-based website URLs take the form of https://projects.eclipse.org/projects/<projectid> (e.g. https://projects.eclipse.org/projects/technology.foo).

Many project teams opt to create a custom main project website: if so-desired, a project may host a website on Eclipse Foundation-hosted servers. Project website URLs generally take the form https://eclipse.dev/<shortname>; (e.g. https://eclipse.dev/foo). Custom project website content is maintained in Git repositories hosted on Eclipse Foundation infrastructure. A background job moves content from the Git repository to the website; content pushed to the repository will appear on the live website within five minutes.

Project websites must implement the branding guidelines for project websites.

The Project Management Infrastructure (PMI) provides the main project website. Website URLs take the form of https://projects.eclipse.org/projects/<projectid> (e.g. https://projects.eclipse.org/projects/technology.foo).

Websites not hosted by the Eclipse Foundation are considered community portals and are subject to the Eclipse Foundation Trademark Usage Guidelines (the Eclipse Foundation asserts ownership of all project name trademarks). Furthermore, projects may be required to comply to specific security guidelines and requirements outlined by the Eclipse Foundation’s Security team.

If your project website or any other property maintained by or on behalf the project team uses Google Analytics or otherwise collects information, there may be privacy and data protection concerns that you’ll need to address. The Data Protection Impact Assessment Guidelines and Eclipse Foundation Hosted Services Privacy and Acceptable Usage Policy describe the Eclipse Foundation’s policy and your obligations.

Organisations who are investing in an open source project may want to provide links on the project website (or in other content related to a project: a README file, for example) to related professional services that they offer.

Including links to vendor-specific services related to an Eclipse open source project is completely consistent with the Eclipse Foundation Development Process.

Vendor-neutrality must be observed. Care needs to be taken to make sure that there is no confusion that the project itself is an Eclipse open source project, and not a Vendor X open source project. In that context, including references and links to vendors who provide services for an open source project is fine, so long as others can participate via the same set of rules.

The rules for inclusion of vendor-specific references need to be captured (even if only informally). A project team might, for example, decide that links to related vendor services are permitted only in cases where the vendor has an active committer on the project.

Vendor-specific links should be a statement of fact without qualification or anything that looks like an advertisement or endorsement (that is, "Vendor X provides services related to this project" is acceptable, but "Vendor X is the preferred services provider for this project" is not). It must be very obvious to users browsing the project content that the links to vendor-specific services lead to content that is separate from the open source project (for example, links to vendor-specific content on a project website must lead to web pages with a distinctive appearance to avoid misleading the user into thinking that the services provider page is part of the open source project’s website).

Links to vendor-specific services must be directly related to the project.

Use of Eclipse Foundation-provided and hosted build services, the so-called Common Build Infrastructure (CBI) is strongly recommended, but not strictly required.

Whether or not a project chooses to make use of provided build resources, it must be possible for members of the community to build project artifacts from source code with reasonable effort.

Where technically sensible, all downloadable artifacts should be signed by an Eclipse Foundation certificate.

The project is allocated space on the Eclipse download and archive servers.

Project artifacts (e.g. downloads) can be distributed via third party services (e.g. Maven Central), but — where technically sensible — the Eclipse Foundation-provided infrastructure must be considered the primary source of project downloads.

Project committers can upload project artifacts to the project’s directory on the download server. The short name is used to denote the area available to the project (e.g. https://downloads.eclipse.org/dash for the technology.dash project) via SFTP or SCP, or from a Eclipse Foundation hosted build infrastructure.

Project teams may use services that are not hosted by the Eclipse Foundation (e.g. GitHub or DockerHub).

The following rules apply:

Even when using services not hosted by the Eclipse Foundation, project teams are required to operate in an open, transparent, meritocratic, and vendor-neutral manner. Use of the service must not add an unreasonable access barrier for contributors, and no single individual or company can exert exclusive control of the service. Administrative level control of the service must be shared by as diverse a subset of the project committers as possible, and a documented policy must be established for managing that control.

All services require that users conform to some sort of terms of use that likely dictate copyright and licensing terms. Project leads must take care to ensure that those terms of use are not at odds with the project license or impact the copyright ownership of project contributions.

External resources can be used for:

This list is not exhaustive. Project leads should work with their Project Management Committee (PMC) and the EMO to determine the terms and conditions for an external resource are compatible with the project license(s), the Eclipse IP Policy, and Eclipse Foundation Development Process.

The chat service is a great way for projects to communicate and to connect with the community, provide real-time support, and to discuss project-related topics.

Eclipse project committers can request rooms/spaces for their project on the chat service. By default, the channel name is of the form #<shortname> where <shortname> is the project’s short name identifier (e.g. #dash for the technology.dash project) and located by default in the #eclipse-projects:matrix.eclipse.org space.

Custom rooms/spaces organisation can be requested, see the following examples:

All requests for new rooms/spaces have to be made by opening a Help Desk issue.

The chat service can be accessed via the web client at chat.eclipse.org or by using a Matrix client (e.g. Element, NeoChat, or any other Matrix client) via the matrix.eclipse.org server.

For more information, please see the documentation here:

The Eclipse Foundation Security Team provides help and advice to Eclipse projects on security issues and is the first point of contact for handling security vulnerabilities. Members of the Security Team are selected from the Eclipse Foundation staff.

You can contact the Eclipse Foundation Security Team by sending email to security@eclipse-foundation.org or by open an issue in the general vulnerability issue tracker.

All project contributors are responsible for ensuring best security practices and following of the Eclipse Foundation Vulnerability Reporting Policy. However, a specific group called the Project’s Security Team is responsible for handling undisclosed vulnerabilities. It is up to the project and project’s leadership chain to organise the Project’s Security Team. In the absence of other decisions, the Project’s Security Team includes all committers.

The project might decide to include a subset of the committers in the team, for example based on their security experience. Any project committer can propose a creation of a separate Project’s Security Team. This is discussed by the project leadership and might be submitted to a vote of all committers. The same procedure applies to bringing the responsibility back to the complete group of committers.

The project must provide a security contact to the Eclipse Foundation Security Team and should communicate that contact information to potential reporters (like security researchers).

The following resources are recommended for each project’s security team:

The Project’s Security Team members might grant access to specific issues to people outside of the team. Such rules should be defined by the Project’s Security Team and the PMC in advance.

Project Leads can define Project Security Team via PMI, in the Security section of the Edit tab (see screenshot below).

The default project setup is to use general Eclipse Foundation reporting (see below). The strong recommendation is to list reporting methods clearly inside a SECURITY.md file in the main repository (also in other repositories if it makes sense) to help security researchers to communicate with the project in a secure way. Similar information should be available in the project’s documentation.

If the project decides to activate reporting via confidential issues (GitLab) or private security advisories (GitHub), please make a request via the Help Desk. The Eclipse Foundation Security team can train the project in using those means. When new reporting methods are set up, update your SECURITY.md accordingly.

In order to be able to set up, monitor, and also help projects dealing with security settings, new project are set up with members of the Eclipse Foundation Security team. Also, in GitHub repositories, if self-management is enabled, the project will include .eclipsefdn repository. Please refer to the documentation for more information.

Vulnerabilities can be reported via a project-specific security tracker, or via general Eclipse Foundation means: an email to security@eclipse-foundation.org or an issue in the general vulnerability issue tracker.

The general security team email address can be used to report vulnerabilities in any Eclipse Foundation project. Members of the Eclipse Foundation Security Team will receive messages sent to this address. This address should be used only for reporting undisclosed vulnerabilities; regular issue reports and questions unrelated to vulnerabilities in Eclipse Foundation project software will be ignored. Note that this email address is not encrypted.

The community is encouraged to report vulnerabilities using the standard project-specific issue tracker. The appropriate link should be available in the project’s SECURITY.md file. In case of a doubt, use the general vulnerability issue tracker.

Disclosure is initially limited to the reporter, the project team and the Eclipse Foundation Security Team, but is expanded to include other individuals, and the general public. The timing and manner of disclosure is governed by the Eclipse Foundation Vulnerability Reporting Policy.

Publicly disclosed issues are listed on the Known Eclipse Security Vulnerabilities page.

The Eclipse Foundation is a Common Vulnerabilities and Exposures (CVE) Numbering Authority and does assign CVE numbers to projects hosted by the Foundation.

A unique vulnerability number like a CVE allows developers, distributions and security researchers to talk about the same issue using a common name. It also helps the project documentation.

The project team can ask for a number when they learn about the vulnerability: by receiving a report or simply by discovering it. They can request the number before the fix is ready, as the request will be confidential until the project tells the Eclipse Foundation Security Team to publish it.

Project can request CVE numbers in different ways depending on the project setup.

If the reporter requests a CVE number, the Eclipse Foundation Security team will assign one if there is a reasonable probability of a real Vulnerability.

+ It’s a bit of a rite of passage for an open source project to disclose their first vulnerability. If in doubt, ask the Eclipse Foundation Security Team for guidance.

It might be that the previous CNA is more appropriate for releasing the CVE.

Anybody can be a contributor. To be a contributor, you just need to contribute. Contributions typically take the form of code or documentation submitted to the project’s source code repository, but may also take the form of answering questions in project and community forums, and more.

For contributions that contain intellectual property (e.g., source code or documentation), some formal documentation is required to ensure that the rights associated with the intellectual property are properly managed and licensed.

To contribute to an Eclipse open source project, a contributor must:

Contributors retain ownership of their contributions; the ECA, for example, states in part:

That is, the contributor owns their contributions, but grants a license to the Eclipse Foundation and downstream consumers to use them under the terms of the project license.

After establishing a pattern of contributing high quality contributions a contributor may be invited to join the project as a committer; an existing project committer will nominate a contributor to be a committer via committer election.

For Eclipse projects (and the open source world in general), committers are the ones who hold the keys. Committers decide what code goes into the code base, they decide how a project builds, and they ultimately decide what gets delivered to the adopter community. With awesome power, comes awesome responsibility, and so the Open Source Rules of Engagement described by the Eclipse Foundation Development Process, puts meritocracy on equal footing with transparency and openness: becoming a committer isn’t necessarily hard, but it does require a demonstration of merit.

In practical terms, there are two ways to become an Eclipse Committer.

The first way is to be listed as an initial committer on a new project proposal. When projects come to the Eclipse Foundation we need them to actually start with committers, and so we include this as part of the bootstrapping. As part of the process of community vetting a new project proposal, the committers listed are themselves vetted by the community. In effect, the project proposal process also acts as a committer election that’s open to the entire community.

The second way to become a committer is to get voted in via committer election. After an individual has made a small number of high quality contributions that demonstrate that they understand how the project works, understand the Eclipse Foundation Development Process and are prepared to implement the Eclipse Foundation Intellectual Property Due Diligence Process, a committer will invite them to join the team and initiate the election. Committer elections start with a nomination by an existing committer that includes a statement of merit that usually takes the form of a list various contributions that the individual has made to the project. What constitutes a sufficient demonstration of merit varies by project team.

When a contributor becomes a committer, they must be covered by a committer agreement (either a Member Committer and Contributor Agreement (MCCA) or an Individual Committer Agreement (ICA). Committers on specification projects must be covered by additional agreements. As the last step in the committer election process, the Eclipse Foundation systems will determine which agreement applies and engage a committer paperwork workflow with the new committer to ensure that everything is in place.

Eclipse Foundation project resources are accessible without an account. That is, members of the community may browse code, documentation, issues, help, etc. without creating an Eclipse Foundation Account.

Those members of the community that wish to contribute code patches, open issues, add content to wikis, etc. must create an Eclipse Foundation Account.

For contributors and committers, their Eclipse Foundation account is their primary portal into their relationship with the Eclipse Foundation. From their account page, individuals can sign the Eclipse Contributor Agreement, manage their mailing list subscriptions, access build resources, and more.

The purpose of the Eclipse Contributor Agreement (ECA) is to provide a written record that contributors have agreed to provide their contributions of code and documentation under the licenses used by the Eclipse project(s) they’re contributing to. It also makes it clear that contributors are promising that what they are contributing to Eclipse is code that they wrote, and that they have the necessary rights to contribute it to Eclipse projects. And finally, it documents a commitment from the contributor that their open source contributions will be permanently on the public record.

All contributors, who are not committers on the Eclipse project, must sign the Eclipse Contributor Agreements (ECA) to ensure that the necessary intellectual property (IP) rights to the contribution are granted.

Contributors who are already covered by a committer agreement (either an MCCA or ICA) are not required to also sign the ECA.

Committers do not require an ECA to contribute to a project on which they have committer status.

The Generative Artificial Intelligence Usage Guidelines for Eclipse Committers provides valuable information regarding the use of generative AI (GPT, LLM) to create project content.

Contributors who have the trust of the project’s committers can, through election, be promoted to committer status for that project. The breadth of a committer’s influence corresponds to the breadth of their contribution. A development team’s contributors and committers may (and should) come from a diverse set of organisations. A committer gains voting rights allowing them to affect the future of the project. Becoming a committer is a privilege that is earned by contributing and showing discipline and good judgement. It is a responsibility that should be neither given nor taken lightly, nor is it a right based on employment by an Eclipse Foundation member company or any company employing existing committers.

Being a Eclipse committer is more than just having write-access to the project resources: there are specific IP due diligence and record keeping activities that committers must follow. New committers must ensure that they are familiar with the Committer Due Diligence Guidelines.

New committers should be encouraged to join the incubation mailing list; this list is a good place to ask questions about process, services available, and other aspects of working as a committer.

Similar to a committer election, a project lead election starts with a statement of merit. The merit statement should, rather than focus on specific code contributions, focus instead on the leadership qualities expressed by the individual.

Project leads are normally also committers. A project may have more than one project lead (so-called co-leads).

Use the Committer Tools › Nominate a Project Lead link on the corresponding project page to start a project lead election.

Only project committers can nominate a new project lead or vote in a project lead election. To be successful, a project lead election must receive a minimum of three positive +1 votes. Any committer can veto the election by casting a -1 vote. For projects with three or fewer committers all committers must vote. Committer elections run for one week, but will end prematurely if all project committers vote +1.

Following a successful committer vote, the project’s PMC will review the election results and then either approve or veto the election. A PMC-approved election will be referred to the EMO/ED as a recommendation for appointment. The final decision rests with the EMO/ED.

Project Management Committee (PMC) members are elected by the existing PMC leads and members, and approved by the EMO/ED. The criteria by which a PMC Member is selected varies by PMC. Some PMCs are set up to have a representative from each of the projects in the top-level project. Other PMCs are more exclusive and require a demonstration of merit.

In all cases, the PMC Lead makes a recommendation to the EMO/ED to appoint a PMC Member. The final decision rests with the EMO/ED.

Project Management Committee (PMC) Leads are not elected. They are vetted by the EMO, approved by the Eclipse Board of Directors, and appointed by the EMO/ED.

A committer can retire themselves from a project. Retirement cannot be undone: to rejoin a project as a committer after being retired, a contributor must again be nominated and elected into the role.

A project lead may also retire a committer. A project lead might, for example, retire a committer that has been inactive for an extended period of time (e.g., longer than a year). Before retiring a committer, the project’s community should be informed of the change and the committer must be given a chance to defend retaining their status via the project’s dev-list.

Retired committers are listed as Historic Committers on a project’s Who’s Involved page. To restore an historic committer to committer status, they must be re-elected into the role.

There is no means by which a committer can be forced out of a project if they have not done anything wrong (there is no notion of "voting a committer out" of a project). Leaving the company that sponsors the project, for example, is not a valid reason for retirement. On the other hand, that a committer has changed jobs or roles and can no longer continue to contribute the project is a completely valid reason for retirement.

A project lead can retire themselves from a project. Prior to retiring, a project lead should work with the project team to ensure the continuity of the role (e.g., in the case where a project’s sole project lead plans retirement, they should engage with the team to identify and elect a replacement). In the spirit of open source transparency, a retiring project lead should announce their retirement on the project’s dev-list.

Connect with the PMC or EMO for assistance.

In the case where the project is dysfunctional (e.g., there is no active project lead and an insufficient number of active committers to offset inactive committers), options are available to the PMC to add and/or remove committers.

The Committer Questionnaire is an online form that must be completed by all new committers. This form offers two separate paths: one for committers who work for a member company that has provided a signed Member Committer and Contributor Agreement (MCCA), and one for everyone else.

The Committer Questionnaire is accessible only after an individual has been elected into the role of a committer on a project (note that all committer relationships are between an individual and a specific project), either as an initial committer on a new project, or via Committer Election on an existing project. New committers will be sent a link to the questionnaire via email.

The specific agreements required depends on the nature of the project and the employment status of the individual. For committers on an open source software project (i.e., most Eclipse projects), the agreements described below are required. For committers on an open source specification project, additional working group agreements are required.

The new committer must download and print the documents, complete and sign them, and then provide them to the EMO Records Team. The Committer Agreement Workflow provides a means of uploading these documents; alternatively, the team may ask you to provide them via email.

After all required documents have been received, the EMO Records Team will review them, contact the committer to resolve any issues that need to be addressed, and send a request to the Eclipse IT Team to provision a committer account.

Questions regarding this process should be addressed to the EMO Records Team.

The EDP defines a number of life cycle reviews for Eclipse projects. All projects start with a creation review, but the most common type is the release review. In addition to those reviews defined by the EDP, the EFSP further defines plan reviews.

Specification project teams engage in reviews in the same manner as all Eclipse projects, with a few differences:

Supermajority approval of a particular review is obtained via a ballot that is initiated and tallied by the specification committee (typically by the specification committee chair or their designate).

The process described in the Progress Reviews (which are the same as release reviews) section is the same for specification projects.

An important part of the specification process is the management of intellectual property flow, patent grants in particular.

Patent grants flow into a specification process through the committers. That is, the project committers (or, more likely, their employers) grant a patent license for any committed essential claim as described in the Eclipse IP Policy. Those patent grants are “locked in” whenever a specification project engages in a successful progress or release review. So, by virtue of holding committer status on a specification project at the time of successful completion of a progress or release review, license grants for those patents represented by the committer are locked into the specification project.

Those grants flow out of the project to a compatible implementation through the ratified final specification (as defined by the EFSP). That is, when an implementation of a specification is based on a final specification (i.e., the implementation implements all non-optional elements of the final specification, does not extend the API, and fulfils all the requirements of the corresponding TCK), those committed patent grants flow to the implementer.

To be clear, a compatible implementation must be based on a final specification (not, for example, the specification document source or a milestone build).

All participant members of the working group that do not already have committer representation on a specification project may appoint one. The intent behind the notion of a participant representative is to ensure continuity of the flow of intellectual property grants when an participating organisation is found to be without representation.

Following their appointment, participant representatives become indistinguishable from other committers on a specification project. As such, following appointment, participant representative committers are subject to the same rules as any other committer: they do not hold any special status or formal role beyond that of committer once appointed, and they retain their committer status if they change employers.

An organisation’s specification committee representative may send a note to EMO with a request to appoint a participant representative.

Anybody that contributes to an Eclipse specification project is a contributor. Contributors make pull requests against project repositories. Pull requests must be reviewed and merged by a committer.

To become a contributor, an individual must:

Regular contributors of high quality content should be invited to join the specification project team as a committer (via committer election).

Committers are developers who have the ability to directly push (i.e., they have write access) their own contributions to the project’s Git repositories, and have the responsibility to review and merge the contributions of others. Committers are responsible for implementing the Eclipse Foundation Development Process and abiding by the Eclipse Intellectual Property Due Diligence Process.

Committer status is assigned on a project-by-project basis. That is, individuals have committer rights only on those projects for which they hold committer status. For all other projects, they are contributors.

The Eclipse Foundation takes copyright ownership of the specification document of every ratified Final Specification. By asserting copyright ownership on the specification documents, the Eclipse Foundation has the ability to protect the specifications in the event that a third party fails to follow the terms of the Eclipse Foundation Specification License.

The Eclipse Foundation Specification License is applied to the specification documents for all ratified final specifications. This action ensures that derivative works of those specification documents cannot be created, thus preventing their use as the basis for incompatible implementations.

Like regular Eclipse open source projects, a specification project starts life as a proposal with a description, scope, list of committers, and more; goes through an iterative development cycle that produces one or more milestone builds; and then engages in a release process.

At least one compatible implementation of a specification version under one of the designated open source licenses before it can be ratified as a final specification. Other compatible implementations may be created from the final specification and distributed under other licensing terms (as determined by respective vendors).

Compatible Implementations may only claim compatibility with a final specification. The intellectual property rights required to build a compatible implementation flow from the final specification. That is, in order to be considered a compatible implementation and benefit from the intellectual property protections provided by the Eclipse Foundation Specification Agreement, an implementation must be based on a final specification. No claims regarding compatibility may be made for an implementation milestone build or unratified specification version.

The Eclipse Foundation has a well-defined IP Policy, corresponding IP Due Diligence Process, and an IP Team of dedicated professional IP specialists who perform the heavy lifting in the due diligence process.

Committers, the software developers who decide what will become project content and how an Eclipse open source project will leverage third party content, are responsible for bringing IP issues to the attention of the IP Team.

The Eclipse Dash License Database (or, more simply, the Dash Database) is a database that contains the license information collected via the Eclipse Foundation Intellectual Property Due Diligence Process. It contains license information gathered and curated by the Eclipse Foundation’s IP Team. The Dash Database is accessed via API only; the Eclipse Dash License Tool is the primary means of accessing this resource.

ClearlyDefined is an OSI project that combines automated harvesting of copyright and license information from software repositories and curation thereof by trusted members of the community to produce a massive database of information about content. The Eclipse Foundation’s IP Team works with the ClearlyDefined team, providing input into their processes and helping to curate their data.

In rough terms, if the license information for third party content can be validated by the Eclipse Foundation’s due diligence process using ClearlyDefined data, then no further action is required. The Eclipse Dash License Tool uses ClearlyDefined as a source of license information (and is the easiest way for Eclipse committers to leverage ClearlyDefined).

When an existing project migrates to the Eclipse Foundation, we refer to the existing code (when one exists) as the Eclipse open source project’s initial contribution. An initial contribution is basically the first set of project code contributions to the new Eclipse project. An initial contribution typically takes the form of an entire existing source code repository or some snapshot of an existing code base.

In the case of an existing repository, the project team has some choices:

Move the existing repository. At the project team’s request, the Eclipse IT Team can move existing source code repositories on GitHub into an organisation managed by the Eclipse Foundation. This is the best option when a project team wants to preserve their repository’s status with existing forks, retain existing issues, stars, etc. If the repository is private, it must be made public before the move. Note that GitHub does a good job of setting up redirects that will ensure that the project’s existing community can find them.

Push to a new repository. At the project team’s request, the Eclipse IT Team can create new source code repositories on either GitLab or GitHub into which the project team can push existing content. This option is best in the case that there is good reason to leave an existing repository in place, or when a project team needs to move an existing private repository into the open. The project team can decide whether or not to push the entire history or just a snapshot from the existing repository. As a best practice, an existing repository that gets "left behind" should be updated to include a pointer to the new repository and marked as archived.

Combinations are also possible. As part of the Eclipse open source project creation process, the EMO asks the project team to capture their requirements and will facilitate discussion between the project team and the Eclipse IT Team to implement those requirements.

The short version of the process is this:

As a general rule third party content should not be included in project repositories. Typically, third party content is pulled in by some form of build process after developers have cloned the repository (for example, developers might pull in required NPM modules via a package-lock.json file).

In the case where third party content must be represented in a project repository, we would consider that a project code. Whether or not the content is modified, it would effectively be considered a fork.

A project cannot make a release until the due diligence on the IP contained in that release—​including project content contributions and third party content--is complete.

Project content is content that is managed by the project team. This includes content that is produced by project committers, along with content that is contributed to the project by outside contributors. Essentially, all content that is contained in a source code repository that is owned and managed by the Eclipse Foundation on behalf of an Eclipse open source project team is considered project content. We use "content" in a general sense, independent of any particular technology or means of delivery; code, scripts, documentation, and configuration files are all (non-exhaustive) examples of content.

Contributions made by Eclipse committers do not require review by the Eclipse IP Team and can be pushed directly into a project repository. Notwithstanding project-specific rules, project committers can push their own content directly into project repositories. While content produced by other Eclipse committers does not require review by the Eclipse IP Team, it must still be accepted by project committers. Project committers should engage the Eclipse IP Team if they have concerns regarding the provenance of any contribution.

Contributions by others (i.e., developers who are not committers) must be received via an Eclipse Foundation channel (e.g., GitHub pull request, GitLab merge request, Gerrit review, or attachment on an issue).

All contributors must sign the Eclipse Contributor Agreement (ECA).

Further investigation is required when any of the following conditions are met:

When further investigation is required, a project committer must engage with the IP Team to request their review before the contribution is pushed/merged.

Any project committer can engage with the IP Team to review a project content contribution. A project cannot make a release that includes the content under review until the due diligence process ​is complete and the content has been approved.

The term third party content refers to any content that is leveraged by the Eclipse project that is not produced and/or maintained as an asset of the project. This includes content from other Eclipse projects.

This includes (for example):

This is list is not exhaustive. The exact nature of the dependencies and how they are specified varies from technology to technology.

The set of dependencies also includes third party content that is referenced by third party content, whether or not it is directly referenced by the Eclipse project content. That is, the dependencies of an Eclipse project includes the entire transitive closure of the immediate dependencies.

The pedantic reader will observe that one can follow the chain of dependencies all the way down to silicon.

We cut the dependency graph off at the platform. The definition of platform varies by technology and intention. In general, we regard the platform as the layer(s) that adopters of the Eclipse software install independently as a foundation for the project software.

For example:

This is list is not exhaustive.

If you’re not sure ask the IP Team for assistance.

Perhaps the most challenging aspect of intellectual property due diligence is determining whether or not content distributed under one license may consume content distributed under a different license. All too often, the answer is: "it depends".

Our approved licenses page lists licenses that we believe are generally compatible with most Eclipse project licenses. As stated on the page, "licenses on this list are not necessarily compatible with every Eclipse Foundation project license, or with each other."

Licenses that are not included on this list are not necessary prohibited. Rather, they may require more thought and careful review.

When in doubt, check with the EMO IP Team.

If your project leverages build technology that pulls third party content from well-defined software repositories (e.g., Apache Maven pulling from Maven Central, a yarn.lock or package-lock.json file), consider using the Eclipse Dash License Tool to automatically create IPLab issues for you.

If you cannot use the Eclipse Dash License Tool, you can manually create a request:

Project Content is any content that will be maintained by the project team. Basically anything that a contributor or committer will put into a project’s source code repository (generally in source form) is project content. This includes content that the project team forks (the premise being that forked content effectively becomes indistinguishable, at least conceptually, from project content).

Note our careful use of the term content. This includes source code, documentation, configuration, etc.

Third party Content is defined as content that is leveraged or otherwise referenced by project code. Third party content is typically (although not necessarily) acquired from software repositories (e.g., Maven Central or NPMJS) during builds.

When creating a review request issue, please provide as much information as you can. If information is missing, or you are not certain how information should be provided, provide what you can and the IP Team will work with you to sort it out.

GitLab issue use Markdown, so use Markdown syntax when specifying information. Our scanners parse information out of the issue description, and so are most likely to be successful (and require less time-consuming manual intervention) if you stick to the format specified.

The Eclipse Dash License Tool takes a list of dependencies as input, matches content to license information obtained from trusted sources, and identifies the content that needs further scrutiny (i.e., it lists all content for which license information cannot be found in one of the approved sources). It is available as both a command-line interface and a Maven plugin.

What the License Tool does is relatively simple:

The License Tool lists all content that ended up marked as restricted as requiring further scrutiny.

Eclipse open source projects are required to track their intellectual property contributions, as well as their use of third party content. We rely on the Git log to track contributors and contributions.

Eclipse open source projects are required to maintain a software bill of materials (SBOM). "About" files (about.html) 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.

OpenChain ISO/IEC 5230:2020 defines the key requirements of a quality open source license compliance program. The Eclipse Foundation IP Due Diligence Process is self-certified as OpenChain ISO/IEC 5230:2020 conformant.

As part of a progress or release review, the EMO validates that the project is correctly implementing the Eclipse Foundation intellectual property due diligence process. Upon successful completion of the review, the project can claim OpenChain conformance for a year (after which the project team need to engage with in another review).

The Eclipse Foundation’s Board of Directors has approved various updates to the Eclipse Foundation’s IP Policy over the years that have introduced significant changes in our IP due diligence process. In this section, we highlight some of them.

Eclipse projects may have one or more source code repositories. Since it is possible for source code repositories to be cloned and rehosted, it is important that legal information is captured directly in the root of every repository.

As described below, legal and other metadata files must be included in the root of every source code repository.

The distribution form of software artifacts (often in a compiled form) generated from a project’s source code repositories must also include legal information.

License and notice files, as described below, must be included in the root of every unit-level distribution artifact (e.g. JAR file). In the most general case, these files will appear in the root of distribution unit, but the exact location varies by technology type.

For content delivered as Java archive (JAR) files, for example, the legal files should be placed in the META-INF directory.

When the unit level of distribution is an individual file (e.g. JavaScript), the file must contain a header with copyright and license information, and the best effort must be undertaken to associate the file with the notices (e.g. a link to the source repository in the header).

Project teams should consult with their Project Management Committee (PMC) for input and advice regarding alternate names and locations for legal documentation.

All products delivered by the project—including executables, websites, documentation, and help must include certain notices. An executable might, for example, provide this information in an About Dialog; documentation might include a notice in either the pre- or post-amble, or a website might provide this information in a common footer, or a dedicated page.

The notices must include one or more copyright statement, the assertion of trademarks owned by the Eclipse Foundation on behalf of the project, indication of third party trademarks in use, and — when applicable — a cryptography notice.

Where possible, all source code, property files, and metadata files (including application, test, and generated source code as well as other types of files such as XML, HTML, etc.) should contain appropriate copyright and license notices as well as information on each contribution.

Copyright holders are legal entities: either individuals or companies. Note that employment contracts very often stipulate that the intellectual property developed by an employee is the property of the company (in this case, the company should be listed as the copyright holder, not the individual; the individual should still be listed as an author).

Copyright statements take the form Copyright (c) {year} {owner}.

The {year} is the year in which the content was created (e.g. “2004”).

The {owner} is the name of the copyright holder. If the content is subsequently modified and appended to by other copyright owners, the words "and others" are typically appended. So for example: "XYZ Corp." or "XYZ Corp. and others". The words "and others" are used to avoid having to list every copyright owner and because often, most of the content in the file was contributed by the initial copyright owner with subsequent modifications by others being smaller. However, especially if the number of copyright owners is small (e.g. two), they may all be listed in a single copyright statement (for example: "XYZ Corp., John Smith, and ABC Enterprises."). Alternatively, additional copyright holders may be added by including multiple copyright statements.

Copyright headers can take one of two forms. In the traditional form, the identities of the copyright holders must be indicated in the copyright statement on the first line of the header.

Contributors should be consistent when expressing copyright on a particular file. In some legal circles, the exact form of the copyright message must be used in summaries, including punctuation (e.g. the "Copyright (c) 2017 My Company, Inc" and "Copyright (c) 2017 My Company, Inc." may be considered different and distinct because of the period).

Alternatively, project teams can adopt a more generic copyright header for each file and include the identities of the copyright holders in the notice file.

Incorporating the SPDX-License-Identifier tag in the header makes it easy for automated tools to discover and report the license of the content. More usefully, the SPDX expression syntax can be used to make it very explicit to automated tools how multiple licenses are combined.

In SPDX, disjunction is used to express dual licensing and conjunction is used to express that the content contains content that is distributed simultaneously under multiple licenses. For example, EPL-2.0 OR MIT expresses that the consumer may choose to accept the content under one of the licenses listed; and EPL-2.0 AND MIT indicates that the consumer must accept the content under both licenses (it may be the case that parts of the content are under one license and other parts are under the other).

The license file contains the exact text of the project’s declared licenses in human readable form. The declared licenses are those that the project team’s content is distributed under. This does not, for example, include the licenses of third party content or incidental fragments of code that is incorporated into the project content (the license of any such content should be indicated in the source file itself and the notice file that accompanies it).

If the project code is distributed under multiple licenses then the text of those licenses must be included. The file should start with a short paragraph that describes how the licenses are combined. This statement should in most cases, be exactly the same as the license statement in the file copyright and license headers (see the example below).

Use inclusive disjunction (OR) when talking about dual licenses (e.g. "choose one or the other (or both)").

The license file must be expressed in a human readable (plaintext) form; human readable markup languages may be used. The file is conventionally named LICENSE and may include a suffix (e.g. LICENSE.md).

Notice files are expressed in human-readable plain text format; human readable markup languages may be used. The file is conventionally named NOTICE and may include a suffix (e.g. NOTICE.md).

The notice file must include basic project metadata, an expression of the declared project licenses, information regarding the licensing of any third party content, and a statement regarding the use of cryptography in cases where either the project code or third party content implements cryptography.

Project metadata provides the identity of the originating project, along with pointers to the project’s website and canonical source code repositories.

The declared licenses statement should in most case, be exactly the same as the license statement in the file copyright and license headers.

If cryptography is included with the content, then the following statement must be included in a comment in the notice file:

Other information, as deemed necessary by the project team may also be included.

While not strictly legal documentation, having concise and clear information how to get involved in a project is very important for building the community around a project. Therefore, to simplify adoption and encourage contributions it is recommended that projects maintain a Contributor Guide. The file is conventionally named CONTRIBUTING (or README) and may include a suffix (e.g. CONTRIBUTING.md).

Like legal documentation, a CONTRIBUTING file should be placed in the root of each repository. Keep the guide as concise as possible: it should contain a few words and a link to other documents for details and more information. Use plain text that can be easily consumed without being formally rendered.

Minimally, the CONTRIBUTING file should include:

Additionally, the guide might include:

The SECURITY file describes products and product versions that for which security updates may be applied and the means by which vulnerabilities are reported. The SECURITY file may have an extension, and should be placed in the root of all project repositories.

It should:

The Eclipse Security Team provides a template (that you must modify).

The CODE_OF_CONDUCT file should provide a copy of the Eclipse Foundation’s Community Code of Conduct. The CODE_OF_CONDUCT file may have an extension, and should be placed in the root of all project repositories.

The Community Code of Conduct is provided in (markdown) format.

The top-level umbrella agreement is the Eclipse Foundation Software User Agreement (SUA). The SUA is not actually a license: it does not grant any rights to use the software and that is why it must reference other legal notices and agreements. The main purpose of the SUA is to describe the potential layout of the legal documentation in the accompanying content.

The most important wording is that which says that the Eclipse Public License (EPL) applies to all the content unless otherwise indicated.

The rest of the text describes the other kinds of notices or licenses that may be found in the content. There is also a short paragraph under the heading Cryptography which lets consumers know that the content may contain cryptography.

The SUA usually appears in place of an actual license in the metadata for features.

Any directory containing content that is licensed under different terms than the project license(s), should be detailed in a file named about.html. We call these files Abouts. Abouts usually contain licensing terms as well as other information such as whether content contains cryptographic functionality that may be subject to export controls.

Most plug-ins will contain a default About that simply confirms that all the content in that plug-in is made available under the project license, typically the Eclipse Public License (EPL). There are other plug-ins, however, that will contain content licensed under licenses other than or in addition to the EPL and/or third party content provided under other licenses. If you are the maintainer of a plug-in for an Eclipse project, please see the About templates for plug-ins.

Since most plug-ins do not contain specially-licensed content, most plug-ins will contain only the default About. The plug-ins with the special Abouts are the interesting ones that most users will want to read.

Although Abouts may be found potentially in any directory, they should always be found in plug-ins and fragments. Previously, plug-ins and fragments were usually packaged as sub-directories of a directory named plugins. Currently, plug-ins and fragments may also be packaged as JAR files (Java™ ARchives). For JAR’ed plug-ins, any local files linked from an About such as copies of licenses, must be located in a directory called about_files. The contents of the about_files directory are handled specially so that links resolve correctly when the About in a JAR’ed plug-in is viewed in an external browser spawned from the About dialog.

Users looking for legal documentation may find the Abouts by browsing the directory structure of an Eclipse installation; but the files are also viewable from the About plug-ins dialog in the Eclipse workbench. To view the Abouts, go to the menu item Help › About Eclipse Platform, click on the Plug-in Details button, select a plug-in, and click on the More Info button.

A feature is a set of one or more related plug-ins and/or fragments that can be installed and upgraded together. There are three important legal documentation files for features, the Feature License (license.html), the Feature Update License (the license property in feature.properties) and the Feature Blurb (the blurb property in about.properties).

Each feature has a file named license.html, called a Feature License, that contains the text of the SUA in HTML format. Each feature includes additional files containing the actual text of the project license(s) in HTML format (e.g. the Eclipse Public License 2.0 in file named epl-2.0.html).

Each feature has a file named feature.properties. In that file is a property named license, which is known as the Feature Update License. The Feature Update License must contain a copy of SUA in plaintext format.

Each feature has at least one plug-in associated with it which is the feature plug-in for that feature. Not surprisingly, this plug-in usually has the same name as the feature. The property named blurb contains text that appears in the About features dialog in the Eclipse workbench. This is known as a Feature Blurb. Blurbs often contain copyright notices and any other statements of attribution that may be required by licenses.

All features must contain a Feature License and a Feature Update License in the directory for that feature. The feature’s plug-in must contain a Feature Blurb.

The Feature License is found in the feature directory which is usually a sub-directory of the directory named features. Any referenced files (for example, the EPL) are located in the same location.

The Feature Update License is found in the feature directory which is usually a sub-directory of the directory named features. Any referenced files (for example, the EPL) are located in the same location.

The Feature Blurb resides in the plugins directory as either a sub-directory or a JAR. In the feature plug-in there is a file named about.properties., the Feature Blurb is the property named blurb. To view the blurb for each installed feature, go to the menu item Help › About Eclipse Platform › Feature Details and then select a feature. The blurb will appear in the bottom half of the dialog.

Where practical, all source code (which includes Java source as well other types of files such as XML, HTML, etc.) should contain appropriate copyright and license notices as well information on each contribution.

If the source is to be licensed under a license other than or in addition to the EPL, you must ensure that the Eclipse Foundation has approved the notice.

The Legal page has a copyright notice and a link to the About in the plug-in that contains the book.

Documentation books usually contain a Legal page as the last page in the book.

See About File Templates.

Releases are formal for Eclipse projects.

Releases are broadly categorised as:

Eclipse projects are expected to engage in an iterative release process.

Every release cycle starts with a plan that is created in an open and transparent manner and made available the community both for review and to solicit input. The development process must be iterative, with the regular delivery of milestone builds to solicit feedback. The release cycle ends with the delivery of a final release candidate, and general availability of the products of the release.

Only project teams that are in good standing can produce official major or minor releases. A project is considered to be in good standing when they have engaged in a progress review within the last year. Put another way, a project team may declare official major or minor releases and distribute associated products for up to one year following a successful progress review. Reviews are not required for service releases that are based on an official major or minor release.

A project plan is required for each major and minor project release. The plan should lay out in broad terms what the goals are for the release. As plans are a valuable means for the community to get involved with your project, the plan should be created at the beginning of the release cycle. By establishing the plan early, you give prospective contributors help in determining how they can most usefully contribute, and adopters can prepare their own development schedule and themes. Plans can change during the release cycle.

A plan can be formal or informal. It’s completely reasonable to set up a project board, or tag issues and call that the plan. What is critical is that the plan be communicated via standard project channels (e.g., the project’s dev-list) in a manner that allows community members to be aware of the project team’s priorities for the and how they can best contribute to the success of the release.

All aspects of a plan can change during the release cycle (including the date). If you do change the plan, make sure that the change is communicated via your project’s communication channels.

Producing regular builds is an important part of the release cycle. Builds are an important means of engaging with the community: adopters can help you test your code and test their own so that they can be ready for the eventual release. Project teams should plan to produce at least one milestone build (more are better, depending on the length of your release cycle), and capture the planned date for that milestone in the release record. It is also common practice to generate nightly and weekly integration builds. Project teams must ensure that their project’s downloads page provides the information required for the community to obtain builds.

Project committers and project leads are responsible for maintaining their project’s metadata. This information is an important part of being an Eclipse project.

Project metadata is:

Project Management Committee (PMC) members and the Eclipse Foundation staff also have the ability to make changes on behalf of a project.

The complete listing of all current Eclipse projects provides one starting point for viewing projects. From here, you can link directly to a project page. Navigation options are provided to help you move from one project to another.

The PMI provides a website for every project based on the project metadata. This website includes an Overview page that shows basic information about the project, a Downloads page that provides links to downloads, a Developer Resources page that includes links to source code repositories, and more.

An example project page is shown below. The Overview page includes the name and description of the project, list of project licenses, a table of recent releases, and various charts and other information (note that more charts are displayed on the Who’s Involved page. The website also includes links to project-specific commands and tools when the user is logged in as a project committer.

A logged in committer can access commands and tools from the Committer Tools block on the right side of the project page; they can also edit project metadata by clicking the Edit link at the far right of the tab list.

The URL for a project page takes the form https://projects.eclipse.org/projects/<projectid> (e.g. https://projects.eclipse.org/projects/technology.foo), where <projectid> is the qualified identifier for the project.

Committers have access to several committer-specific commands and tools in the Committer Tools block on the right side of project pages. The selection of commands available are context sensitive; only those commands that make sense for the logged in user are shown.

Committers have the ability to edit the information managed and displayed on the project page. There are several sections on the page. When you switch the page into Edit mode, you will be provided with lots of help regarding the contents of each of the fields (note that the help text is currently rendered below the fields).

To set the edit project metadata:

If you require assistance editing the project metadata, contact the EMO.

Some of the fields are described below.

Projects, Releases, and Reviews are presented as separate records. Each project record, obviously, represents information about a project. A project may have multiple releases; information about the release is represented in a release record. The release record also contains some review information. This information is included here, because all releases do not necessarily have a review (a project can opt to provide some review type information as part of a release record. A project can have multiple review records; as release reviews are the most common form of review, most review records will be joined to a release record.

A review record, however, does not require a release association. Some reviews are associated with proposals. Other have no other association (e.g. termination reviews).

Each release has its own record in the database. Records are connected directly to a single specific project; a subset of release records associated with a project are displayed on the project page. An existing release can be edited in much the same was as a project. Any logged in project member (committer or project lead) can switch to the Edit tab.

Create a single record for each release. Do not create release records for milestone builds. You may optionally enter milestone information in the Plan information of a release record.

A simultaneous release (also referred to as a coordinated release or release train) is a means of grouping together projects that are coordinating their respective releases and need a means of representing the aggregation. Simultaneous releases must themselves coordinated and managed by supervising body (e.g., a PMC or working group specification committee). The rules for joining and participating in a simultaneous release are defined by the supervising body.

To create a simultaneous release record and update its contents, the supervising body must connect with the EMO.

To join a simultaneous release, an Eclipse project committer must

The Eclipse Foundation supports multiple brands (e.g., Eclipse, Jakarta, and LocationTech). All Eclipse open source projects are associated with a top-level brand.

All Eclipse open source projects may use the Eclipse brand. Other brands are managed by working groups and so whether or not the brand can be used with your project is at the corresponding working group’s discretion.

The formal name of all Eclipse open source projects starts with a brand. The brand should not generally be concatenated with any other words (there are some historical exceptions).

Naming and branding are important issues for project teams to consider: both for the project’s future success as well as to help support and share the good values from the brand itself. Not only can a memorable name help new users and contributors find a project, having a distinctive and unique name makes the Trademark much stronger and enforceable, and ensures that third parties will respect it.

To ensure that future trademarks conflicts don’t arise, all Eclipse Foundation trademarks go through a rigorous search and clearance procedure before they are approved for use. The Eclipse Foundation values its intellectual property rights and the rights of others and these procedures are followed to ensure that there are no infringement allegations.

All Eclipse projects and corresponding software products are trademarks of the Eclipse Foundation. As a legal entity, the Eclipse Foundation owns all open source project and corresponding product trademarks on behalf of the Eclipse community. The EMO initiates a trademark search and clearance review as part of the project creation or renaming process. Existing project name trademarks must be transferred to the Eclipse Foundation. The transfer of names applies to both registered and unregistered trademarks that have been previously used (please see the Trademark Transfer Agreement).

Who needs these requirements?

All project and product names must be vetted and approved by the EMO.

A project, as defined by the Eclipse Foundation Development Process, is the main operational unit; all open source software development at Eclipse occurs within the context of a project. The Eclipse Foundation holds the trademark for all Eclipse Projects.

All project names must be approved by the Eclipse Management Organization (EMO) either before a project is created or before an existing project is renamed.

All Eclipse projects require a description. The project description must include a brief sentence or short paragraph (no bullets) that explains the primary function of the software deliverables provided. For example:

The complete description can certainly include much more information, but starting with a short paragraph is a great service for new readers to the project’s website, and is important for the Eclipse Foundation to maintain an overall list of project trademarks for software products. While this trademark description style may sometimes seem clumsy in technical documentation, it is a critical way that the Eclipse Foundation enforces trademarks.

Project teams may seek guidance from the PMC and EMO to ensure that the text is a proper trademark goods description; i.e. one that describes the specific functionality of the software available for download and use.

The official project website is the primary means of learning about the project and getting involved: people who are interested in contributing to the project come here to learn about technical details, and to observe the project’s development process.

Eclipse projects must host all project content on an Eclipse Foundation provided domain,especially the official/primary website for project-related information, communications, access to source code, and downloads. This both ensures that the Eclipse IT Team can maintain the services, and informs consumers that the content comes from an Eclipse project, and not a third party. This further ensures that the project remains independent of any specific vendor or single individual.

All primary links to the project (including, for example, the project’s contribution guide) must point directly to the official website, and not to external sites or domains.

Where applicable and supported by the programming languages and style used by the project, code namespaces must include the project’s short name.

In Java, for example, package names must start with org.eclipse and use their short name in the third-segment  (that is, follow the pattern org.eclipse.<shortname>.<component>), for example org.eclipse.foo.core, org.eclipse.foo.ui, and org.eclipse.foo.connector. Component names are left to the discretion of the project team.

Per Maven naming conventions, the Maven groupId must follow the standard reverse DNS naming convention, qualified with the project’s short name by following the pattern org.org.eclipse.<shortname>. The use of a more specific groupId extended with a component identifier is also possible by following the pattern org.org.eclipse.<shortname>.<component>.*.

The project team must get approval for exceptions from their PMC.

The use of Eclipse Foundation trademarks outside of the immediate scope of the open source project, including the use of project names, is subject to the terms of the Eclipse Foundation Trademark Usage Guidelines. This includes third party websites, books, publications, conferences, events, and more.

Nothing in this Eclipse Foundation document shall be interpreted to allow any third party to claim any association with the Eclipse Foundation or any of its projects or to imply any approval or support by the Eclipse Foundation for any third party products, services, or events, unless specifically covered by an Eclipse Membership agreement.

Questions? Project participants who have questions about Eclipse Foundation trademarks either used here or at third party sites should contact the EMO. Other organisations looking for information on how to use or refer to any Eclipse Foundation project trademarks or logos should see the Eclipse Foundation Trademark Usage Guidelines.

Thanks and credit to the Apache Software Foundation’s Project Branding Requirements (licensed under the Apache License, v2.0) for parts of this trademark section.

Community development is an important part of life as an Eclipse open source project. Project teams must plan to spend some significant amount of their time courting and informing the community. At least part of that effort involves keeping the project website up-to-date.

Some projects are luckier than others: sometimes a technology is just so compelling that minimal effort returns huge dividends. More often, the overnight success of an open source project comes after weeks, months, and years of a combination of long work and hard work.

It takes effort to get your message out; and if you want to develop a community around your open source project, you have to get the message out. To cultivate a vibrant community of users, adopters, and committers, a project has to have somebody who is responsible for community development. Somebody has to own it. Everybody on the project team has to dedicate some significant amount of their time to community development, but one person on the team has to be responsible for it. For some projects, this may be a full time job; for others, it may be a huge part of one. In fact, many open source projects have more than one full time person working on community development. In some circles, this role might be called the project’s evangelist, or maybe it’s the project lead that manages community development. Whatever the title, the role should be that of making everybody else successful in community development activities.

Minimally, there are valuable activities that the project member responsible for community development can do for those lucky people who actually find your project:

Being responsive for people who find your project is important. But is only effective when people actually find your project. There are many things that you can do to generate buzz and grow your community. Blogging, social media, attending and speaking at conferences, podcasts, and just simply speaking to everybody who will listen through all available media are important activities.

Here are some things to think about:

Know what kind of community you want to build. Tailor your efforts to address that community through native channels. Know where the type of people who should be part of your community hang out. Find out where they get their information and take the necessary steps to get your voice heard on those forums.

Develop an elevator pitch for your project. An elevator pitch is a thirty second to two-minute “sound bite” that describes your project in a way that be understood by a layperson. When done well, an elevator pitch motivates the listener to spend more time investigating your project. Make sure your developers can recite it. Make sure that the the project provides a means for the listener to go and find more information (e.g., a website).

Establish drum beat of outward communication Identify team members who can regularly blog, podcast, host webinars, and otherwise provide outward communication. Coordinate their efforts so that communication is regular: daily, weekly, or monthly. It’s hard to ignore regular communication.

Leverage the existing community. Leverage services provided by the Eclipse Foundation, like the Planet Eclipse blog aggregator which provides a window into the world, work, and lives of Eclipse committers and contributors.

Present and represent. Engage in demo camps, user groups, and other local networking opportunities on behalf of your project.

Make community development a part of your project’s regular work. Interacting with and growing the community is every bit as important as writing the actual code. Make sure that all of your developers understand that community development is important and encourage them all to participate. Assume that it’s going to take a while. You’ll know that you’ve been successful when it starts to take on a life of it’s own (e.g. when people from your community start writing articles, blog posts, doing talks about your project at conferences, .,.).

While the reviews and processes described by the EDP may seem onerous, they are a necessary part of community development. You should anticipate spending a significant amount of time responding to questions posed in various forums (community forums, mailing lists, and other places where your community gathers. You should plan on attending conferences, presenting webinars, writing papers, and more to support your project.