Eclipse Foundation Project Handbook
- Starting an Open Source Project at the Eclipse Foundation
- Project Resources and Services
- Managing and Reporting Vulnerabilities
- Contributing to an Eclipse Project
- Committer Paperwork
- Intellectual Property
- Legal Documentation Requirements
- Project Management Infrastructure (PMI)
- Project Branding
- Promoting your Project
- Project Checklist
- Getting Help
- Legal Documentation for Eclipse Platform Plug-ins and Fragments
- Eclipse Development Process
- Data Protection Impact Assessment Guidelines
Copyright © 2015, 2022 Eclipse Foundation, Inc. and others.
Made available under the Eclipse Public License v 2.0.
This document includes content originally authored on the Eclipsepedia wiki by Wayne Beaton, Fabian Steeg, Denis Roy, Dave Carver, Ed Merks, Bjorn Freeman-Benson, Anne Jacko, Ian Skerrett, Mike Milinkovich, and John Arthorne.
This document provides you with the information that you need to create a new Eclipse open source project or become a committer on an existing one.
The Eclipse Foundation Development Process (EDP) is the foundational document for Eclipse projects and committers. It describes the manner in which we do open source software. The EDP does not prescribe any particular development methodology; it is more concerned with the larger-scale aspects of open source project lifecycle, including such things as reviews, processes for running votes and elections, bringing new committers onto a project, etc. This document elaborates on some key points of the EDP.
Four basic principles lie at the heart of the EDP:
We refer to the first three as the "open source rules of engagement".
To operate with transparency, a project’s discussions, minutes, deliberations, project plans, plans for new features, and other artifacts are open, public, and easily accessible.
Openness at Eclipse means quite a lot more than "open book" (which is really a synonym for transparent). The project is open to all; Eclipse provides the same opportunity to all. Everyone participates with the same rules; there are no rules to exclude any potential contributors which include, of course, direct competitors in the marketplace.
Eclipse is a meritocracy. The more that somebody contributes, the more responsibility they will earn. A pattern of quality contribution to a project may lead to an invitation to join the project as a committer. Leadership roles in Eclipse are also merit-based and earned by peer acclaim. Merit must be demonstrated in publicly-accessible forums. Committers and project leads are added to a project via election.
Employment status has no bearing at whether or not somebody can participate in an open source project at Eclipse. Employment does not guarantee committer status; committer status must be earned by everybody.
Vendor-neutrality is similar to openness in that it’s concerned with maintaining a level playing field. No vendor is permitted to dominate a project, and nobody can be excluded from participating in a project based on their employment status. While project resources will contain copyright statements that assert ownership of various assets by individual vendors, the project itself must remain vendor-neutral.
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 organizations 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 organization 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.
Before getting started, it’s important to know what is required of an Eclipse project. The Eclipse Foundation will take ownership of many aspects of the project to ensure that the project and its assets are managed in an open and vendor-neutral manner. This takes the form, for example, of the Eclipse Foundation retaining ownership of the project’s trademarks on behalf of the community, and carefully managing who has write access on project resources such as source code repositories and distribution channels. Eclipse projects are obligated to use certain resources assigned to the project by the Eclipse Foundation and conform to logo and trademark guidelines. New project sponsors must engage in the process of transitioning an existing project with the intent to continue development of the project code and growth of the community and ecosystem around the project.
It’s also important to know what new projects don’t give up. The project team retains control of the project’s direction by virtue of regular contribution to the project. The contributors to the project retain ownership of their contributions (those contributions are used under license by the project). Project leads are required to ensure that other individuals who present themselves to the project are given uniform opportunity to participate, but the project team gets to establish the rules for participation (within certain parameters). The project team is responsible for determining development methodology, establishing plans, etc. Existing owners of the project code retain their ownership.
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.
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.
Keep track of the URL of the proposal. The website does not provide public links to the document until after the proposal is opened for community review. If you do lose trck of the URL, ask the EMO for assistance.
A proposal must minimally include a description of the project, a declaration of scope, and a list of prospective 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, project leads, and mentors will be copied on that record.
A proposal will be open for community review for a minimum of two weeks.
The Eclipse Foundation holds the trademark for all Eclipse projects. Trademark assignment is undertaken prior to the creation of any new project. If you already have a trademark on your project name, that trademark must be assigned to the Eclipse Foundation. Be advised that trademark assignment can be a time-consuming process (it can take hours, days, or weeks depending on the circumstances surrounding the name). If you currently hold the trademark, you will be asked to complete a Trademark Transfer Agreement.
The proposal must list at least one mentor from the Eclipse Architecture Council. Members of the Eclipse Architecture Council have considerable experience with Eclipse Foundation practices, and the Eclipse Foundation Development Process. The EMO will engage directly with the Architecture Council to identify mentors as necessary. Mentors are assigned to the project through the incubation phase; they are released from their duties when the project graduates.
When the project name trademark has been secured, a mentor has been identified, and the proposal contents are finalized, the EMO will schedule a creation review. Reviews — which run for a minimum of one week — are scheduled twice a month, generally concluding on the first and third Wednesday of each month. The creation review may overlap with the community review period.
Creation reviews tend to always be successful. They should be considered low stress as the hard work has already been done in advance of the start of the 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.
The provisioning process will not start until after the paperwork for at least one project committer is received and processed by the EMO Records Team. If you can be ready with the paperwork in time for the completion of the creation review, then we can move quickly through the provisioning process.
When we initiate provisioning, committers will be sent an email with instructions; please don’t send any paperwork in until after you receive those instructions.
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 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.
Project teams interact with the Eclipse IP Team via the IPZilla system using Contribution Questionnaires (CQs). Those members of the project team that are included in the CQ’s CC list will be informed of progress via email.
The IP Team will indicate check-in permission by adding the
Third-party content that is required by the project code must also be reviewed by the Eclipse IP Team. Project teams that are new to the process should start by raising no more than three CQs for third-party content in order to gain an understanding of the third-party review process before proceeding to enter all requests.
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 activies: 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 lifeycle events are gated by reviews; moving from the incubation phase to the mature phase must be, for example, preceded by a graduation review.
A project in the incubation phase is said to be incubating.
The classification of a project in the incubation phase is not a statement about the quality of the project’s code; rather, the incubation phase is more about the project team’s progress in practicing the open and transparent processes described by the Eclipse Foundation Development Process to establish the three communities (developers, adopters, and users) around the project.
Incubating projects are encouraged to produce milestone builds, make releases, and grow their community.
When the project code is ready (e.g. stable APIs) and the project team has learned to operate as an open source project according to the Eclipse Foundation Development Process, the project may opt to graduate (via graduation review into the mature phase.
In order to alert potential consumers of the incubating nature, projects in the incubation phase must include incubation branding.
The project team must:
Display the incubation logo on their project web page (if they have one);
Display the incubation logo on their project’s primary download page;
Include the word "incubation" in the filename of all downloadable files (when technically feasible) for builds and milestones; and
When technically feasible, include the word "incubation" in features (e.g. about dialogs, feature lists, and installers).
There are no incubation branding requirements for general user interface elements.
For projects that produce OSGi artifacts, include the word "incubation" in the Bundle-Name, feature names, and p2 repositories. The word "incubation" should not be included in technical namespaces (especially when it may result in confusion when the project leaves incubation). e.g. an OSGi bundle’s Bundle-SymbolicName, or a Java package name.
Most of the lifetime of an Eclipse project is spent in the mature phase. A mature project is one that:
Is a good open source citizen with open, transparent, and meritocratic behavior;
Regularly and predictably releases IP clean extensible frameworks and exemplary tools; and
Actively nurtures the three communities: developers, adopters, and users.
When a project has reached its logical conclusion, its resources are archived. Transition in the Archived (phase) is preceded by a termination review.
Why are some committer (but not all) names rendered as links on project proposal pages?
When the list of committers provided for a new project proposal are rendered, a link to more information for each individual committer will be included when possible. The link will render, for example, when an individual already has a role on another existing Eclipse open source project (e.g. is a committer, project lead, PMC member, etc.). No link indicates that no existing project relationships exist for that individual.
How do I find Eclipse Architecture Council mentors?
You don’t have to find them yourself. Focus on the content of the proposal. We can solicit mentors from the Eclipse Architecture Council after the proposal has been opened for community review.
What license(s) can I use for my project?
Eclipse top level projects define the standard licensing for their projects. When a project has nonstandard licensing requirements, they may need to make an appeal to the Eclipse board of directors to request their approval. Connect with EMO for assistance.
Can I change the proposal after it is posted?
Yes. The proposal can be changed any time before the start of the creation review.
When do I submit my code for review by the IP team?
Submit your code (initial contribution) for review after the project has been provisioned. The EMO will let you know when provisioning is complete.
Does the new project have to use Git?
Yes. Git is the only source code management system that is currently permitted for new projects.
Can I host my project code on GitHub?
Eclipse projects can make use of GitHub. Official project repositories must be hosted under an Eclipse Foundation-managed organization at GitHub. Official repositories are subject to the same intellectual property due diligence rules and processes that all Eclipse project repositories must follow.
How long should I let my project incubate?
It depends. Community expectations are one factor. Team experience with open source is another. If your team is new to open source, it may make sense to stay in incubation a little longer than a seasoned team with a mature code base might. As a general rule, though, projects should plan to leave incubation within a year.
Does the mature project code that I’m bring to Eclipse need to incubate?
Yes. All new projects start in the incubation phase. Remember that incubation is as much about the project team learning about how to operate as an open source project as it is about the project code. Project teams that "get it" can opt to exit incubation quickly (e.g. with their first release) if that makes sense for the team and the community.
What do all these terms (e.g. EMO) mean?
Please see the glossary.
Open source projects at the Eclipse Foundation are required to make use of certain Eclipse Foundation services:
All project issues must be tracked in the issue tracker assigned to the project;
All third-party content used by the project must be vetted;
Downloads (when provided) must be distributed via an Eclipse downloads server;
Developer (committer) communication must occur in the dev-list provided to the project by the Eclipse Foundation; and
Projects must keep their Project Metadata up-to-date.
Project resources make use of two sorts of ids:
- Short name
The short name is used in various parts of Eclipse Foundation infrastructure (e.g. the name of the project’s directory on the downloads and Git servers, and the URL for the project website). The short name may contain lowercase alphanumeric characters, dashes, and underlines; but does not contain periods.
- Qualified identifier
The project’s short name is joined with the short name of the parent project(s) to form a qualified identifier (project id) for the project that is used as a key on services generated and/or maintained for the project by the Eclipse Foundation.
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.
We tend to incorrectly refer to all project content as source code. As a general rule, when we refer to source code, we mean all content (including documentation, configuration, image files, etc.) that is maintained in a source code repository (e.g., Git).
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).
In order for the project to operate in an open manner, it must be possible for potential contributors to have access to the code base in its most current form, so all ongoing development must be regularly pushed to these canonical repositories.
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:
One line (max 72 characters) summary;
commit d6cf52411377a039fc2906378711091a26e932cb Author: Some Body <firstname.lastname@example.org> Date: Wed May 29 16:17:36 2013 +0200 Bug 350686 - Hide unwanted action bar items This change hides unwanted 'Link with Editor' and 'Customize View...' items from the local toolbar and the view menu. Change-Id: Ia2bd5091303d1b0a738157effc24e4dac5a7d0c7 Also-by: Some Bodyelse <email@example.com>
|The email address of the author must match the email address on the Eclipse Foundation Account, the name "Some Body" must be replaced by the real name of the person.|
|Best practice: include the bug id in the commit message summary.|
|Additional authors can be added using
The name used in the
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 " 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).
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.
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.
Some of the terms used by GitLab — project in particular — have different meanings from those in the Eclipse Foundation Development Process (EDP). In order to make our meaning as clear as possible, we refer to GitLab projects as repositories and to Eclipse projects as Eclipse open source projects or (in the case where we mean a top-level project) Eclipse top-level projects.
Any committer can create a Help Desk issue to request that the Eclipse IT Team create a new repository on, or move an existing repository to, the GitLab instance for their project. Note that the IT Team will verify the request with the project leads.
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.
A group can be configured as the immediate descendant of the root group, using the Eclipse open source project’s short name.
eclipse ├── <short name A> │ ├── <repository 1> │ ├── <repository 2> │ └── ... ├── <short name B> │ ├── <repository 1> │ ├── <repository 2> │ └── ... └── ...
For example, the Eclipse Dash project (short name:
dash) has a group of
eclipse/dash that might have repositories with the following URLs (note that these URLs are provided as examples and may not actually be real):
A group can be configured as a descendant of the Eclipse open source project’s corresponding Eclipse top-level project’s group, which itself is an immediate descendant of the root group, using the short names. Configuring the Eclipse open source project’s GitLab group in this manner enables aggregation features such as the ability to list and search issues across related Eclipse open source project groups and repositories.
Configuring GitLab in this manner requires approval from the corresponding Eclipse top-level project’s Project Management Committee (PMC).
eclipse ├── <top-level project short name> | ├── <short name A> | │ ├── <repository 1> | │ ├── <repository 2> | │ └── ... | ├── <short name B> | │ ├── <repository 1> | │ ├── <repository 2> | │ └── ... │ └── ... └── ...
For example, the Eclipse Dash project which is an Eclipse Technology (short name:
technology) subproject could have a group of
eclipse/technology/dash that might have repositories with the following URLs (note that these URLs are provided as examples and may not actually be real):
Project leads, committers, and contributors for each project are granted access to their project group according to their role within the project.
For information regarding the privileges available to each of the Maintainer, Developer, and Reporter roles indicated below, consult the GitLab Documentation.
- Project Leads
All project leads are automatically granted the Maintainer role on their project resources hosted on GitLab. When an individual is elected into the role of project lead, they are automatically granted these permissions within the group. When a project lead is retired, they are automatically removed from the group.
With the Maintainer role, project leads have significant privileges on GitLab repositories. Project leads must not manipulate the configuration of GitLab groups and repositories in a manner that would violate the Eclipse Foundation Development Process or the Eclipse Foundation Intellectual Property Policy.
All committers are automatically granted the Developer role on their Eclipse open source project resources hosted on GitLab. When an individual is elected into the role of committer, they are automatically added to the as a Developer to the Eclipse open source project’s group. When a project lead is retired, they are automatically removed from the group.
All contributors are automatically granted Reporter level access to Eclipse open source project resources hosted on GitLab. When an individual is added to the contributors list, they are automatically added as a Reporter in the Eclipse open source project’s group. When they are removed from the contributors list, they are automatically removed from the group.
The Eclipse Contributor Agreement (ECA) hook inspects incoming merge requests to ensure that the contributor has a valid ECA on file, and flags those that do not. Eclipse open source project committers should only accept merge requests that pass this validation.
To assist with CI/CD operations, bots with CI/CD access can be requested by making a request within the Eclipse Foundation Helpdesk by either a project lead, or a committer with approval from a project lead. These bots may be added directly to repositories or to groups depending on the requirements.
Project teams may opt to host some or all of their canonical source code repositories to an organization 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 IT Team will verify the request with the project leads.
Repositories can be hosted in the default
eclipse GitHub organization, or a dedicated organization can be created. Dedicated organizations use as their name, the conjunction of
eclipse with the project short name (e.g.,
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 means of absolutely denying a merge, the hook warns committers when the contributors have not signed a 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.
Eclipse Foundation scripts build and maintain a collection of GitHub Teams, each with permissions appropriate to the corresponding Eclipse project roles (project lead, committer, and contributor).
The scripts require knowledge of the GitHub Id in order to add any individual to any of the teams. Be sure to include your GitHub Id in your Eclipse Foundation Account.
- Project Leads Team
All project leads are automatically added to the project leads team. All members of the project leads team are granted the Maintain role on their project’s GitHub repositories. When an individual is elected into the role of project lead, they are automatically added to the project leads team. When a project lead is retired, they are automatically removed from the team.
A project lead may request temporary Admin level access to their project’s repositories by creating a Help Desk issue with their request. The issue must describe what will be done using this new level of access and how long it will be needed.
With the Maintain role, project leads have significant privileges on GitHub repositories. Project leads must not manipulate the configuration of GitHub organizations and repositories in a manner that would violate the Eclipse Foundation Development Process or the Eclipse Foundation Intellectual Property Policy.
Project leads must provide their GitHub Id in their Eclipse Foundation Account.
- Committers Team
All committers are automatically added to the committers team. All members of the committers team are granted the Write role on their project resources hosted on GitHub. When an individual is elected into the role of committer, they are automatically added to the committers team. When a project lead is retired, they are automatically removed from the team.
Committers must provide their GitHub Id in their Eclipse Foundation Account.
- Contributors Team
All contributors are automatically added to the contributors team. All members of the contributors team are granted Triage level access to project resources hosted on GitHub. When an individual is added to the project’s Contributors list, they are automatically added to the contributors team. When they are removed from the Contributors list, they are automatically removed from the team.
Contributors must provide their GitHub Id in their Eclipse Foundation Account.
The Eclipse Contributor Agreement (ECA) hook inspects incoming pull requests to ensure that the contributor has a valid ECA on file, and flags those that do not. Project committers should only merge pull requests that pass this validation.
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. Open an issue to request that the Eclipse IT Team configure your Git repository for Gerrit.
Commits may be pushed directly to the Git repository through Gerrit by a project committer (e.g. to the
Anybody can push to a
refs/for/* branch for review in a Gerrit repository. A push that includes commits that do not conform to the required form will be rejected. Commits intended for review should have a
Change-Id. The Eclipse Contributor Agreement (ECA) hook will inspect incoming Gerrit review requests to ensure that the contributor has a valid ECA on file; attempts to push will fail in the case where the author credentials cannot be matched to an Eclipse Foundation account with a signed ECA.
You can browse Eclipse repositories directly on the Gerrit server.
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 webite. PMI-based website URLs take the form of
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://www.eclipse.org/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.
If a project website has not already been created for your project, open a Help Desk issue to request that the Eclipse IT Team create one.
Project websites must implement the branding guidelines for project websites.
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.
Organizations 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.
It is inappropriate to provide vendor-specific references and links for services in technical documentation.
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.
The following rules apply:
The Eclipse Foundation’s branding rules must be observed;
External services must not add legal terms or conditions that invalidate the project licenses or copyrights;
One or more project committers must have ownership rights; and
The usual level playing field must be observed.
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.
External resources can be used for:
This list is not exhaustive. Project leads should work with their 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.
For more information, please see CBI/DockerHub in the Eclipse wiki.
Content distributed via official Eclipse Foundation channels must be complete enough that a consumer can (with reasonable effort) use it without needing the DockerHub distribution. That is, the DockerHub distribution needs to be considered a convenient way to leverage the content, not the only way. Please make sure that you treat any links or related discussion that you have on an Eclipse Foundation property about images distributed via DockerHub as an unofficial channel.
Subject to the rules for the use of external resources, a project team can create and maintain their own organization on DockerHub. The organization name must follow the pattern
eclipse-woolsey) or some variation (e.g.
eclipsewoolsey). As indicated in the rules, ownership of the organization must be shared by a subset of project committers and the project must have a documented policy regarding how access to that organization is managed.
Additionally, a PMC may decide to create and manage an organization for the Top-Level Project. The PMC may have their own policy regarding the use of DockerHub. Project teams should consult with their PMC to determine which approach is best suited for the project.
The Eclipse Foundation has no formal relationship with Maven Central or staging providers like OSSRH. Eclipse project teams are, however, welcome to use these services as a distribution channel.
By convention, the
groupid should be of the form
org.eclipse.dash for the
technology.dash project). Project teams should work with their PMC if some exception to this convention is required (and take care to avoid infringing on the namespaces of other projects). The form of the
artifactid should be determined by the project team. The version number should follow the standard Semantic Versioning pattern. All pre-release builds must be appropriately labeled (e.g.
1.0M3 for pre-release builds of version
Project teams must engage in the Releases process before labeling any software as a release version.
The Eclipse Release Engineering Team has provided some help regarding the use of Maven Central in the Eclipsepedia Wiki.
Can a project use the gh-pages support from GitHub to host at
The project’s primary website must be hosted on Eclipse Foundation infrastructure. GitHub’s gh-pages support can be used to host supplementary content only as a Community Portal (and is subject to the branding requirements).
Can we use GitHub for our project website?
The process that publishes website content pulls from the project’s designated website repository on
git.eclipse.org. A project team can put website source in a GitHub repository, but in order to actually get it on the website, some sort of process must set something up to push it to the website repository. Build infrastructure can be used for this.
Do we have to use the Eclipse Foundation-provided download server?
If you provide content to your community via any form of click-to-download notion, then the Eclipse Foundation-provided download server must be the primary source of that content. If, however, the concept of a download doesn’t make sense for the sort of content that your project provides (e.g. your community consumes your context exclusively through Maven Central, or if source code is the only content delivered by the project), then you aren’t required to provide that content via the download server.
Can we host pre-release software (e.g. milestone builds) on Maven Central?
Reasonable steps must be taken to ensure that the consumer understands the pre-release nature of software. At a minimum, pre-release software must be labeled as such. A milestone build for version 1.0, for example, must be labeled as "1.0M1" (or similar). Pre-release software can be pushed to Maven Central, but due to the permanent nature of content that is pushed there, it will persist there indefinitely. Whether or not this is desirable is a decision that the project team should make with help from their PMC.
Can we use external services like OSSRH to stage pre-release builds?
Can an an Eclipse project accept anonymous code contributions?
No. All contributions must be associated with their author using their legal name and a real email address. In pragmatic terms, the contributor must provide their legal name and email address in the Git commit’s
Authorfield; the contributor must also have electronically signed the ECA using those same credentials.
The Eclipse Security Policy contains information regarding obligations and specific practices regarding the reporting and disclosure of vulnerabilities.
The Eclipse 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 committers on Eclipse Projects and members of the Eclipse Architecture Council.
Vulnerabilities can be reported either via email to firstname.lastname@example.org or directly with a project via the Eclipse Foundation’s Bugzilla instance.
The general security team email address can also be used to report vulnerabilities. Members of the Eclipse 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 project software will be ignored. Note that this email address is not encrypted.
The community is encouraged to report vulnerabilities using the standard Eclipse Bugzilla instance in a project-specific product and component. If the project teams does not have a Bugzilla product of their own, or if a reporter is unable to determine an appropriate product and component, the reporter may use Community/Vulnerability Reports product/component. Issue reports related to vulnerabilities must be marked with the
committers-only flag, either by the reporter, or by a committer during the triage process.
Bugzilla Records marked with the
Bugzilla sends out emails as issues are modified. Email is inherently insecure.
The Eclipse IP Team will give priority to contribution questionnaires (CQs) required to resolve vulnerabilities.
Disclosure is initially limited to the reporter and all Eclipse Committers, but is expanded to include other individuals, and the general public. The timing and manner of disclosure is governed by the Eclipse Security Policy.
Knowledge of a vulnerability can be easily extended to individuals by adding them to the
Contacts added to an unresolved vulnerability must be individuals. Groups (e.g. mailing lists with open subscription and public archives) — with the exception of the Security Team email address — should never be copied on a vulnerability issue.
Publicly disclosed issues are listed on the Known Eclipse Security Vulnerabilities page.
The Eclipse Foundation is a Common Vulnerabilities and Exposures (CVE) Numbering Authority.
If you’re not sure whether or not a CVE is required, err on the side of caution and request one.
Think of a first CVE for your open source project as a rite of passage. Alerting your adopters of a vulnerability is a signal of maturity and responsibility to the open source community.
Any project committer can request a CVE assignment, by creating a CVE Request issue. Upon creation, the request issue will be marked as confidential.
Project committers should only request a CVE when the timing for disclosure is imminent. Due to the nature by which CVEs are allocated to the Eclipse Foundation, there is some risk that reserving a CVE for a protracted period of time may block other CVE assignment requests. Plan to disclose the CVE within two days of the CVE being assigned by the EMO.
The request must provide:
The name of the impacted project and product;
A description of the versions impacted (which may include ranges);
A Common Weakness Enumeration (CWE) code;
A one or two sentence summary of the issue which clearly identifies the Eclipse project/product and impacted versions; and
A pointer (URL) to the issue used to track mitigation of the vulnerability.
The request may optionally include additional information, such as a Common Vulnerability Scoring System (CVSS) code.
Project name: Eclipse Vert.x Project id: rt.vertx Versions affected: [3.0, 3.5.1] Common Weakness Enumeration: - CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') Summary: In Eclipse Vert.x version 3.0 to 3.5.1, the HttpServer response headers and HttpClient request headers do not filter carriage return and line feed characters from the header value. This allow unfiltered values to inject a new header in the client request or server response. Links: - https://bugs.eclipse.org/123456
The Tracking section of the request issue includes some checkboxes for the project team and for the EMO. The EMO will assign the CVE upon receipt of the request, but will not escalate (that is, they will not report the assignment of the CVE to the central authority) until after a project committer clicks the first checkbox indicating that they are ready to disclose the vulnerability.
Click the first checkbox when you’re ready for the EMO to submit the request to the central authority (that is, when you’re ready for the issue to be disclosed publicly).
If the project is using a GitHub Security Advisory to track mitigation of the vulnerability, EMO intervention will likely be required to submit the advisory. Click the second checkbox to indicate that you’re ready for the EMO to submit the advisory on the project team’s behalf.
In what form should a disclosure be published? Is publishing the bug on the Known Vulnerabilities page enough?
Publishing on the Known Vulnerabilities page will happen automatically. This is mimimal disclosure. Whether or not you should do more is a project team decision. If you need help with that decision, connect with your PMC or the Security Team.
If the vulnerability real and is in release software (i.e., it’s likely to have been adopted), you should request a CVE.
You should let your community know about the vulnerability though your usual communication channels.
Who can/will update Known Vulnerabilities page and when?
When a Eclipse Bugzilla record has the "committers-only" flag turned off, includes the
securitykeyword, is in the
CLOSEDstate, and is resolved
FIXED, it will appear on this page.
Can I already commit the fixes to our repository and provide a service release, or shall I wait for some part of the disclosure process first?
In general, you should fix the issue first.
Whether or not we disclose in advance of making the fix available is a judgement call. When there is a real risk that somebody may exploit the vulnerability, you generally want to inform your adopters as quicky and discretely as possible so that they can prepare themselves.
If the issue is particularly sensitive and you need to make that fix in a private repository and coordinate disclosure, connect with EMO and we’ll help. Very few projects actually need to go to this extreme.
Is there something specific I should add (or something I should avoid mentioning) in the commit message?
That depends. In general, you should avoid adding anything that calls particular attention to the vulnerability. Just state what the commit contains.
Do we need a CVE?
It’s up to the project team. We need the project team to engage with the process of gathering the information required to report the vulnerability to the central authority; the first step in that process is deciding whether or not a CVE is desired/required.
The general rule is that a CVE is required when a vulnerability impacts release software. The Eclipse Security Team has given this advice (paraphrased):
If someone can download compiled (e.g., JAR) files and use them without any sort of compilation process then we are inclined to say that there exists a tangible risk to consumers and so a CVE should be requested. That is, unless that version string specifically says alpha or beta, or the content has otherwise clear warnings to not use it in a production context, then we should — as good citizens — create a CVE. Merely being versioned 0.x instead of 1.x doesn’t absolve the situation.
If you’re not sure, check with your PMC or the Security Team.
It’s a bit of a rite of passage for an open source project to disclose their first vulnerability.
Do we need a CVE for versions of software that we released before moving our project to the Eclipse Foundation?
The answer to this is not obvious, but as a general rule… no. The answer is not obvious because the continuity of the source of affected products may not be obvious (or relevant) to consumers, and it is not strictly wrong for a CVE Numbering Authority to create a CVE for a version of a product not immediately in their purview.
Ultimately, whether or not we should create a CVE is the project team’s call.
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:
Create an Eclipse Foundation Account;
Sign the Eclipse Contributor Agreement;
Read the project’s contribution guide to learn about coding style and other guidelines for contributions (contribution guidelines are typically found a
READMEfile in the root of every source code repository);
Create a commit:
Ensure that the author credentials on the commit record match the email address associated with their Eclipse Foundation Account
Create a pull request (GitHub), merge request (GitLab), or submit a review (Gerrit); and
Work with the project team to merge the contribution.
Contributors retain ownership of their contributions; the ECA, for example, states in part:
This ECA, and the license(s) associated with the particular Eclipse Foundation projects You are contributing to, provides a license to Your Contributions to the Eclipse Foundation and downstream consumers, but You still own Your Contributions, and except for the licenses provided for in this ECA, You reserve all right, title and interest in Your Contributions.
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.
In order to grant the ability to assign issues and merge/pull requests to a non-committer contributor on repositories that are hosted either on GitLab or GitHub, a committer must designate the individual as a contributor by providing their email address in the Contributors field in the project’s metadata (PMI).
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.
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.
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. For those members of the community that wish to contribute code patches, open issues, add content to wikis, etc., an Eclipse Foundation Account is required.
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.
If you’re working with projects that use GitHub, be sure to add your GitHub Id to your Eclipse Foundation Account so that our scripts can add you to the GitHub Teams that we use to manage access to Eclipse Foundation repositories hosted on GitHub. When you become a committer on an Eclipse project that hosts their source code repositories on GitHub, you will be sent an invitation to join the GitHub Team associated with that project.
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.
You can determine your ECA status from your Eclipse Foundation Account page. Your ECA status is shown in the top-right corner.
Committers do not require an ECA to contribute to a project on which they have committer status.
Is there any requirement on what is necessary for committers/project leads to consider when dealing with contributions from someone from the same company?
No requirement. Getting reviews/approvals from any committer on your project is sufficient, whether they are from the same company or different.
Project teams may establish their own rules regarding how contributions are accepted. These rules range from allowing any committer to approve a contribution, to requiring that contributions from a committer be approved by another committer, to requiring that all contributions be approved by a project lead. Whatever the case, it should be documented (typically captured in a
It is generally considered good practice (or a nice-to-have) to request a review from an "outsider", especially if the proposed change might be considered complex or controversial. It’s always good to get outside viewpoints. But the specific rules are left for the project team to decide.
Do I need to sign the Eclipse Contributor Agreement (ECA)?
If you are not a committer on a particular Eclipse open source project, to contribute (e.g., make pull requests) to that project, you need to be covered by an ECA. If you are already a committer on any Eclipse open source project, then you are already covered by an ECA through your committer agreement and do not need to sign the ECA separately. If your employer has signed the Member Committer and Contributor Agreement, then you are already covered by an ECA and you do not need to sign the ECA separately.
If you are a committer on a project you do not need an ECA to contribute to that project.
Assuming that you are empowered to do so, you can individually sign the ECA even if you are already covered by another agreement.
How do I know if I’m covered by an Eclipse Contributor Agreement?
Visit your Eclipse Account page. Your Eclipse Contributor Agreement (ECA) status is shown in the top-right corner.
For example, this contributor is covered by the ECA (and is a committer on one or more Eclipse Foundation open source projects).
How do I know if somebody else is covered by an Eclipse Contributor Agreement (ECA)?
Visit your Eclipse Foundation Account page and click on "Eclipse Contributor Agreement" in the Status block. Use the ECA Validation Tool on My Eclipse Contributor Agreement page to verify the ECA status of an individual using their email address.
How do I know if my employer is a member of the Eclipse Foundation?
If your employer is a member of the Eclipse Foundation, they will be listed on the Explore Our Members page.
How do I know if my employer has signed the Member Committer and Contributor Agreement (MCCA)?
Check with your manager. If your manager doesn’t know, you can contact the EMO Records Team for assistance.
I know that my employer has signed the Member Committer and Contributor Agreement (MCCA), but my account page shows that I am not covered by the ECA. What should I do?
It’s likely that you haven’t provided us with employer information. In order for our systems to know that you are affiliated with a particular organization, you must specify your employer in your Eclipse Foundation Account.
I am a committer on a project, but I cannot push to that project’s GitHub repositories. What should I do?
It’s likely that you haven’t provided us with your GitHub Id. Our systems manage the composition of the GitHub teams that have the necessary privileges on project repositories. For that, we need your GitHub Id, which you must provide us with in your Eclipse Foundation Account.
Roles in a project are assigned based on merit demonstrated in a publicly-accessible forum, in the form of an election. Elections start with a nomination that contains a statement of merit. The nature of a statement of merit varies widely, but is generally expected to to concisely state the impact that the nominee has had on the project.
Employment status has no bearing at whether or not somebody can participate in an open source project at Eclipse. Employment does not, for example, guarantee committer status; committer status must be earned by everybody.
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 organizations. 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 judgment. 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.
There are only three requirements around nominating and electing new committers (note that there are additional committer paperwork requirements for the new committer):
Maintain vendor/employer neutrality; and
Operate transparently (public and archived election).
Each project is entitled to define how it evaluates "[people] who have the trust of the Project’s Committers … [through] contributing and showing discipline and good judgment". This definition needs to be a transparent and public document on the project’s website (the top-level project charter may provide this). It is extremely important to publish these criteria to avoid any issues around cliques or "the in-crowd" preventing others from joining a project.
There must not be any hint of "we (company W) hired person X to work on project Y thus person X should elected a committer". Committer status is independent of employment; thereare well-supported mechanisms for contributors without commit-rights and thus committer status is not required for a team member to be effective. Additionally, the team will want to make sure that they have confidence in the candidate irrespective of employment and management because the committer status will continue even after moves to another job.
The nomination and election process for a new committer is for more than just the project team - it is also for the entire Eclipse community, current and future. The larger community uses the artifacts of elections as (one of many pieces of) evidence about the maturity of the project team, and thus quality of the frameworks.
Nominations such as "we all know Bob, vote for him" may work within the team, but actually harm the project’s reputation in the larger Eclipse community: that larger community does not know Bob and does not understand why the project team trusts him with the source code.
A committer nomination should explain the candidate’s contributions to the project and thus why they should be elected as a committer. Cite the issues they have fixed via patches; cite the community forum postings they have answered; cite the dev-list design discussions to which they have contributed; etc. In all cases, provide urls to source material.
Use the project page and follow the workflow to start a committer election.link on the corresponding
Project committers will be notified to participate in the election via the project’s dev-list.
Your project must have a dev-list specified in the project’s metadata and existing project team members must be subscribed to the list.
An election starts with a nomination by an existing committer.
Only project committers may nominate a new committer or vote in a committer election. To be successful, the election must receive a minimum of three positive
+1 votes. Any committer can veto the election by casting a
-1 vote, or indicate their participation in the process but with no opinion with a
+0 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
Committers can change their vote while the election is in progress. Committers may post questions about the committer or ask for clarification of the merit statement in the project’s dev-list, and change their vote based on what they discover. The merit statement itself cannot be changed after the election has started.
Following a successful committer vote, the project’s PMC will review the election results and then either approve or veto the election. An election may be vetoed, for example, if the PMC feels that the merit statement is not strong enough.
The paperwork process will automatically be initiated following PMC approval of an election.
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.
Robert Smith has been part of the Eclipse Dash development since before the initial contribution. He played an important role ever since, as he is one of the key developers. With regards to the number of commits Robert is currently the top committer of Eclipse Dash:
Apart from that Robert took care of the project page and the build. He also handed the governance aspects of the 0.6 release.
Finally I would like to mention a blog post he did at thecure.com:
Project leads are normally also committers. A project may have more than one project lead (so-called co-leads).
Use the project page to start a project lead election.link on the corresponding
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
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.
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.
No specific infrastructure is exists for PMC Member elections. PMCs must use their PMC mailing list to nominate and elect new members, and report the results to the EMO. The EMO will get approval from the EMO/ED and make the appointment.
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.
To retire from a project, navigate to the project page, open the Who’s Involved tab, and click on your image in the committer list. Then, in the "Retire Committer Status" box on the on the project role page, check the checkbox and click the Submit button.
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.
A common practice is for the project lead to use the project’s dev-list to announce generically that they’re going to retire committers that have been inactive for some designated period of time and give the committers a chance to speak up before a deadline.
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 replacment). In the spirit of open source transparency, a retiring project lead should announce their retirement on the project’s dev-list.
To retire from a project, navigate to the project page, open the Who’s Involved tab, and click on your image in the project lead list. Then, in the "Retire Project Lead Status" box on the on the project role page, check the checkbox and click the Submit button.
Do we really need to do this?
Can I still be a committer if I change employers?
Yes. Your status as a committer is not tied to your employment status. You may, however, require Committer Paperwork from your new employer (or if you become self-employed). If you change employers, please contact the EMO Records Team for help regarding paperwork requirements.
What happens if committers don’t vote?
If a project has three or fewer committers, then all committers must vote. If even one out of the three does not vote, then the election will end in failure. If the non-voting committer is also not active, then they can, perhaps, be retired by the project lead.
Can we change a merit statement?
The election infrastructure doesn’t permit changing a merit statement after an election has begun (the principle being that changing the question after you start a vote is considered bad form).
In cases where the merit statement is omitted or considered inadequate, or committers have additional questions about a candidate, it’s completely reasonable to discuss it on the mailing list, and for committers to then use that discussion as the basis for their vote. Committers who have already voted, you can return to the election record and change their vote.
Can a committer change their vote on an election?
How do we transfer committers from one project to another?
Short answer: you don’t
We have no concept of transferring committers. if committers need to move from one project to another, then they must be elected as committers to the new project and retire themselves from the old one.
Can a project lead retire a disruptive committer?
The EDP allows a project lead to retire a disruptive committer. This is basically the "nuclear" option and so should be used sparingly; we have only retired a few committers in this manner. Should a project lead decide to take this step, they should be prepared to provide evidence to back up the claim of disruption. The project lead should work with the PMC and EMO to determine how (or if) that evidence is tracked and disseminated.
The Eclipse Foundation needs to ensure that all committers with write access to the code, websites, and issue tracking systems understand their role in the intellectual property process. The Eclipse Foundation also needs to ensure that we have accurate records of the people who are acting as change agents on the projects. To ensure that committers understand their role, and that the Eclipse Foundation has accurate records, committers must provide documentation asserting that they have read, understood, and will follow the committer guidelines. Committers must also gain their employers consent to their participation in Eclipse Foundation open source projects.
All committers must complete the Committer Agreement Workflow, which includes the Committer Questionnaire and documentation as described below.
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.
If you indicate that you are employed, you will be asked to identify your employer. Only member companies that have provided a signed MCCA will be listed as member companies in the Committer Questionnaire. If you work for a company that is not an Eclipse Foundation Member Company, or your employer has not provided the Eclipse Foundation with a MCCA you must list your employer as "Other".
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 Member Committer and Contributor Agreement (MCCA) is used by organizations that are members of the Eclipse Foundation to cover all of their employees who participate in Eclipse Foundation projects as committers.
If your employer is a member of the Eclipse Foundation and has not already provided an MCCA, consult with your management team to determine who has the necessary authority to sign it on your company’s behalf. Provide the MCCA in advance of the completion of your committer election or new project creation to streamline the committer provisioning process. If you and your management team are not sure whether or not your employer has an MCCA, ask the EMO Records Team.
If the committer’s employer is a member of the Eclipse Foundation that cannot provide a signed MCCA, then the committer will have to complete an Individual Committer Agreement.
An ICA is required when:
The committer works for a company that is not a member of the Eclipse Foundation;
The committer works for member company that has not signed a MCCA;
The committer is self employed or not employed; or
The committer is a student.
If the individual is already a committer on an existing Eclipse Foundation project then additional agreements may or may not be necessary. The EMO Records Team will ask for additional documentation if required.
What is the difference between an Individual Committer Agreement, the Member Committer and Contributor Agreement, and the Eclipse Contributor Agreement?
The Individual Committer Agreement (ICA) is for committers whose employers are either not members of the Eclipse Foundation or are members that have not signed the Member Committer and Contributor Agreement.
The Member Committer and Contributor Agreement (MCCA) is used by organizations that are members of the Eclipse Foundation to cover all of their employees who participate in Eclipse Foundation open source projects as committers.
The Eclipse Contributor Agreement (ECA) is for everybody else. The ECA covers contributors who are not otherwise covered for their contributions by an ICA or MCCA.
What happens if I do not fill out the agreements?
If you do not fill out the agreements, then you do not get your credentials for write-access to the source code repository(s) and other project resources.
Where can I get help to discuss these documents with my management team?
The EMO can talk to your management and senior executives about these (and other) legal documents to help them understand why these documents are the best risk reduction solution for everyone involved. Contact us at email@example.com.
What formats can be used to submit paper documentation?
The EMO Records Team prefers a scanned document delivered via email. The documents may also be provided by fax or by post (the fax number and postal address are captured in the documents).
What Email address should I use to send completed documents?
What if a I change employers?
Edit your Eclipse Account Profile to update your employment status.
The Eclipse Foundation Specification Process (EFSP) defines a means of creating specifications in open source. The EFSP defines specifications as a “… collection of Application Programming Interface (API) definitions, descriptions of semantic behavior, data formats, protocols, and/or other referenced specifications, along with its TCK, intended to enable the development and testing of independent Compatible Implementations.”
Under the EFSP, all specification work must be done in a designated specification project. Specification projects operate according to the Eclipse Foundation Development Process (EDP), just like "regular" Eclipse open source projects, but with special consideration for the intellectual property management differences that are inherent in specification development. Specifically, the flow of intellectual property license grants is a critical difference between open source software development and open source specification development that is addressed by the EFSP. Due to these differences in the intellectual property license grants, specification project committers must be covered by additional legal agreements and must engage in additional governance steps.
Unlike Eclipse open source software projects which have no formal association with Eclipse Foundation Working Groups (“working groups”), every specification project is aligned directly with an Eclipse Foundation working group and operates under the purview of that working group’s specification committee.
Individual working groups may add requirements for specification projects over and above what is outlined in the EFSP. Many working groups, for example, extend the default period of time required for reviews.
The EDP defines a number of lifecycle 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:
Prior to starting the release cycle, a specification team must engage in a successful plan review;
Specification project teams must engage in a release review prior to every release (including service releases);
Following a successful plan review, the project team must engage in either a release review or a progress review within one year; and
All creation, plan, release, and progress reviews require super-majority approval from the corresponding working group’s specification committee.
Individual working groups may have additional requirements for some lifecycle events, and guidance for engaging in working group-specific processes. Those additional requirements will be captured and disseminated by the working group.
Super-majority 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 and Release Reviews section is the same for specification projects.
In the lead up to a review, it is in the best interests of a specification project team to engage with the specification committee in their designated community/public channel to socialize plans and expectations. You must get super-majority approval from the specification committee before you can make an official release of your specification, so giving them every opportunity to understand and provide feedback on what they’ll be voting on is in your best interests. Besides, operating in an open and transparent manner is a critical success criteria for all open source 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 fulfills 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 organization is found to be without representation.
There is no specific rule in this regard, but it considered good form to inform the working group’s specification committee about the appointment.
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 organization’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:
If you are already a committer, your committer agreement includes an ECA; so you’re already covered. If your employer is a member of the Eclipse Foundation and your employer has signed the Member Committer and Contributor Agreement (MCCA), then you’re already covered. You can check your status on the Eclipse Foundation account page (your ECA status is in the top-right corner). If you’re not sure contact EMO Records for assistance.
Regular contributors of high quality content shoul 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.
In order to get committer rights on project repositories hosted on GitHub, you need to set your GitHub Id in your Eclipse Foundation account.
Due to the nature of specification project work, the committer agreements need to be augmented. For Eclipse open source software projects (i.e., those projects not engaged in specification development) the committer agreements (Member Committer and Contributor Agreement and Individual Committer Agreement) are sufficient. The complete set of required agreements are described below.
Specific agreements need only be signed once. If you’ve already signed the agreement, you’re good-to-go.
A committer who is self-employed, unemployed, or a student needs:
Individual Working Group Participation Agreement (IWGPA), which includes:
Membership Agreement as a Committer Member, no dues
Individual Committer Agreement
A committer whose employer is either not an Eclipse Foundation Member; or is an Eclipse Foundation Member that is not a participant in the working group needs the following agreements:
Individual Working Group Participation Agreement (IWGPA), which includes:
Membership Agreement as a Committer Member, no dues
Individual Committer Agreement
Employer Consent Agreement for Eclipse Specification Projects (“Consent Agreement”)
A committer who works for an Eclipse Foundation Member that is a working group participant needs:
No additional agreements are required.
The Eclipse Foundation’s committer provisioning process is automated. As a new committer, you will—following your successful election—be contacted by the EMO Records team by email to engage in our agreement workflow which guides you through signing those agreements that you need. These agreements are all available for your review on our Legal Resources page. The working group-specific agreements are on our Explore our Working Groups page.
A Working Group Participation Agreement (WGPA) is signed by an organization that wishes to participate in a particular working group. By signing the Working Group Participation Agreement (WGPA), an organization agrees to become a participant of the working group and to adhere to the terms outlined in by the working group’s charter.
WGPAs are working group specific; signing the agreement for a particular working group covers the employees of the organization operating in a committer role on one or more specification projects operating under the purview of that working group’s specification committee.
Participation in a working group requires that the organization commit to being a member of the Eclipse Foundation (at a level defined by the working group’s charter) and to commit to the terms of the Member Committer and Contributor Agreement (MCCA). Both of these commitments are explicitly made as part of the organization signing the WGPA.
An Individual Working Group Participation Agreement (IWGPA) is signed by an individual that wishes to participate in a particular working group when their employer is not themselves a participant in the working group. By signing the IWGPA, an individual agrees to become a participant of the working group and to adhere to the terms outlined in by the working group’s charter.
Like WGPAs, IWGPAs are working group specific; signing the agreement for a particular working group covers the individual to operate in a committer role on one or more specification projects that operate under the purview of that working group’s specification committee.
Participation in a working group requires that the individual commit to being a committer member (there are no fees associated with being a committer member) of the Eclipse Foundation and to commit to the terms of the Individual Committer Agreement (ICA). Both of these commitments are explicitly made as part of the individual signing the IWGPA.
The Employer Consent Agreement for Eclipse Foundation Specification Projects ("Employer Consent Agreement" or "Consent Agreement) is required for committers who work for a company that is not a participant in the working group. This agreement must be signed by the employer; that is, it must be signed by somebody with authority to enter the agreement on behalf of the committer’s employer.
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.
Unlike a "regular" Eclipse open source project, a specification project must be aligned with exactly one working group. Each working group designates a specification committee that maintains and manages the specification process on the working group’s behalf. A specification project must get approval from the corresponding specification committee to pass key project lifecycle events.
The specification committee is responsible for ensuring that the specification teams keep within their defined scope, and generally ensure that the specification versions created by the specification project are implementable and serve the purposes of the working group.
The specification committee is required to engage in a formal ballot to approve key milestones in the lifecycle of their specification projects. The exact means by which ballots are run varies by working group. The following lifecycle events require the approval of the working group’s specification committee:
Specification project creation;
Revision to the scope;
Progress and release reviews;
Service releases; and
Designation of a profile or platform.
By default all ballots require seven days. Some specification committees may increase the length of time for some or all ballots, or add additional constraints.
To succeed, a vote requires positive responses from a super-majority (defined as two-thirds) of the members of the specification committee. Votes to designate a specification as a profile or platform require positive responses from a super-majority of the specification committee members who represent the interests of Strategic Members of the Eclipse Foundation. It’s worth noting that there is no veto.
The criteria by which representatives decide how they’re going to vote varies by individual and according to the values of the individual and the organization that they represent (if applicable). Minimally, the specification committee is expected to use their vote to ensure that specification projects stay within scope. In the case of a progress review, the voters will need to consider whether or not the project is progressing in a manner that will eventually result in a successful vote on the eventual release review that gates the ratification of the final specification.
In the event of a failure, the specification committee will provide feedback regarding the reason for the failure to the project team, who will work to mitigate issues and then re-engage.
Creation reviews give the community a last opportunity to review and comment on a new project proposal before it is created.
The specification committee needs to approve of the creation of a specification project from a proposal by taking a role in the creation review. The expectation is that the specification committee members will consider the details of a proposed specification project (with particular focus on the scope) before making their decision. In addition to the requirements defined by the Eclipse Foundation Development Process (EDP), a super-majority ballot of the entire specification committee is required to approve a creation review.
Contact the EMO to initiate a creation review.
Following successful creation and provisioning of project resources, a specification project team begins development.
During the development cycle, the project team will produce one or more milestone builds to provide a means for the community to provide feedback.
A milestone build must never be used to claim compatibility with a specification. An implementation of a specification may only be considered compatible when it is based on a final specification.
For a progress review, the Project Management Committee (PMC), and Eclipse Management Organization (EMO) validate that the specification project team is following the EDP and EFSP, and that the Eclipse Foundation’s Intellectual Property Policy is being correctly implemented. The EFSP requires that the specification committee approve a progress review by super-majority ballot.
The intent of the progress review is to ensure that the specification project is progressing in a manner that will ultimately result in a successful release. A specification committee or project leadership may compel a specification project to engage in additional progress reviews.
A specification project team must engage in a release review for every release (major, minor, and service).
At the end of every development cycle, the project team must produce a release candidate build that is designated as a specification version and then engage in a release review. For a release review, the PMC, EMO, and specification committee all engage in the same sorts of activities that they do for a progress review, but with the understanding that approval results in the ratification of the specification and promotion to an official status. The EFSP requires that the specification committee approve a release review by super-majority ballot.
To engage in a release review, create a release record (if one has not already been created as part of the planning process) and contact the EMO to schedule the review. Your PMC and specification committee may provide additional requirements and documentation that must be met to get their approval of the review.
Following a successful first release (and every subsequent release thereafter), and before engaging in any further development of the specification, the project team must assemble and present their Plan for review by the Specification Committee via Plan Review. The notion of a Plan Review is specific to the EFSP (since Plan Reviews are not part of the EDP, no formal involvement from the PMC is required). A Plan Review provides the Specification Committee with an opportunity to ensure that the plan for the next Specification Version is in-scope, fits within the overall vision of the Working Group, and is otherwise charting a path to eventual ratification and release. The EFSP requires that the Specification Committee approve a Plan Review by Super-majority vote.
The plan itself must be in-scope (i.e. all new work must fall within the bounds defined by the specification project’s scope) and must be developed in consideration of the concerns of stakeholders. It must, for example, take plans of the PMC or associated working group into consideration . The concerns of the project team must also be taken into consideration when creating a plan.
After the Plan is approved, the Project Team engages in Development as before.
Following a successful release review, the final release version of the specification artifacts are considered ratified and transmogrifies into what the EFSP refers to as a final specification. It is the final specification that must be used to build compatible implementations.
All versions of specifications that are referenced by a ratified final specification must themselves be ratified. The release review for related specification versions may be run concurrently.
Final Specifications and their associated artifacts are distributed under specific licenses. The specification document for the final specification must be distributed as read-only text (e.g., PDF) under the Eclipse Foundation Specification License. The ratified TCK in composite is distributed under the Eclipse Foundation TCK License. Other technical artifacts must be distributed under an open source license (normally the specification project’s license).
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.
How do I tell whether or not a project is a specification project?
The best way to know, frankly, is it communicate with the project team. Specification project teams should make the nature of the project clear in the
READMEfiles in their repositories.
We do track this in metadata, which we expose in a number of different locations including the PMI project page. For example:
Do we need to engage in a release review for a service release?
Yes, the specification project team must engage in a successful release review prior to issuing a release of any kind; this includes service releases.
Can the specification committee block/veto a release?
Yes. The specification committee’s super-majority approval of the release is an absolute requirement. Without their approval, there can be no ratification of the final specification, so there can be no release.
Can you provide more information regarding why these agreements are necessary?
Explaining these documents would be a form of legal advice, and we simply cannot provide that. The short version is that we need these agreements and if you want somebody to explain them to you, you’ll need to consult with your lawyer.
Do I need to arrange for my employer to sign the Employer Consent Agreement for Eclipse Specification Projects?
You do not need to arrange for your employer to sign the Employer Consent Agreement for Eclipse Specification Projects if you are unemployed, self-employed, or are a student.
If, however, you are employed, and your employer is not a member of the working group, then you must arrange for your employer to sign the Employer Consent Agreement for Eclipse Specification Projects.
Do I need to sign the Eclipse Contributor Agreement?
If you are not a committer on an Eclipse open source project, to contribute (e.g., make pull requests) to that project, you need to be covered by an Eclipse Contributor Agreement (ECA). If you are already a committer on any Eclipse open source project, then you are already covered by an ECA through your committer agreement and do not need to sign the ECA separately. If your employer has signed the Member Committer and Contributor Agreement, then you are already covered by an ECA and you do not need to sign the ECA separately.
If you are a committer on a project you do not need an ECA to contribute to that project.
How do I know if I’m covered by an Eclipse Contributor Agreement?
Visit your Eclipse Account page. Your Eclipse Contributor Agreement (ECA) status is shown in the top-right corner.
For example, this contributor is covered by the ECA (and is a committer on one or more Eclipse Foundation open source projects).
How do I know if my employer is a member of the Eclipse Foundation?
If your employer is a member of the Eclipse Foundation, they will be listed on the Eclipse Foundation Membership page.
How do I know if my employer has signed the Member Committer and Contributor Agreement (MCCA)?
If your employer is a participant in the working group, then they must have signed the Working Group Participation Agreement, which includes the Member Committer and Contributor Agreement.
If you are unsure whether or not your employer has signed a particular document, please contact the EMO Records Team.
What happens when I change employers?
Your status as a committer is not tied to your employment status. Your committer status will not be revoked when you change employers, but it may be suspended while we resolve the legal status of your ability to contribute to Eclipse open source project. You may, for example, require new committer paperwork to reflect your new employment status. If you change employers, please contact the EMO Records Team for help regarding paperwork requirements.
What if my employer will not sign the Employer Consent Agreement?
If your employer is not a participant of the working group, your employer must sign the Employer Consent Agreement to provide the necessary legal coverage for you to be a committer on a specification project operating under the purview of that working group. Without this agreement, you cannot have a committer role on a specification project. You may, however, continue to operate as a (non-committer) contributor on specification projects. You may also assume a committer role on Eclipse open source projects that are not engaged in specification development.
Creating a new Top Level Project (TLP) at the Eclipse Foundation usually happens when a group of projects gather some momentum. A new TPL usually has a strategic member sponsor, but it’s not a hard requirement.
A TLP is defined through a charter. There is not a dedicated web form, or any special file format for TPL charters. All charters start from the standard charter and extend it with information specific to the particular top level project, e.g. a TLP charter can specify what kind of merit a contributor needs to be elected.
Top level projects don’t have mentors, instead they have a Project Management Committee (PMC) which usually includes the participation of an EDP expert to help with the bootstrapping and then drops off once the project is up and running
In order to be created, a TLP needs the Eclipse Foundation’s Board of Directors approval. For this, it’s necessary to have both the charter and the names of the PMC Lead and Members defined.
If you are interested in creating a TLP please contact the EMO.
The term intellectual property (IP) refers to any sort of creative work, be it literature, art, or software. In the realm of open source software, artifacts like source code, documentation, and images are considered intellectual property. Unless otherwise stated, intellectual property is the property of its creator, who may grant permission for others to use that intellectual property by providing a license.
The ease with which software can be copied and combined makes it challenging to know with confidence if content can be used without running into legal issues. Any sort of serious software development effort must be accompanied by a well-defined IP due diligence process that can ferret out issues and mitigate the risk of leveraging the work of others. IP due diligence is a time consuming process that requires specialized skills and a keen eye for detail.
In October 2019, The Eclipse Foundation’s Board of Directors approved an update to the IP Policy that introduces several significant changes in our IP due diligence process.
License certification only for third-party content. This change removes the requirement to perform deep copyright, provenance and scanning of anomalies for third-party content unless it is being modified and/or if there are special considerations regarding the content. Instead, the focus for third-party content is on license compatibility only, which had previously been referred to as Type A due diligence.
Leverage other sources of license information for third-party content. With this change to license certification only for third-party content, we are able to leverage existing sources of information license information. That is, the requirement that the IP Team personally review every bit of third-party content has been removed and we can now leverage other trusted sources.
ClearlyDefined is a trusted source of license information. We currently have two trusted sources of license information: The Eclipse Foundation’s IPZilla and ClearlyDefined. The IPZilla database has been painstakingly built over most of the lifespan of the Eclipse Foundation; it contains a vast wealth of deeply vetted information about many versions of many third-party libraries. ClearlyDefined is an OSI project that combines automated harvesting of software repositories and curation by trusted members of the community to produce a massive database of license (and other) information about content.
Piggyback CQs are no longer required. CQs had previously been used for tracking both the vetting process and the use of third-party content. With the changes, we are no longer required track the use of third-party content using CQs, so piggyback CQs are no longer necessary.
Parallel IP is used in all cases. Previously, our so-called Parallel IP process, the means by which project teams could leverage content during development while the IP Team completed their due diligence review was available only to projects in the incubation phase and only for content with specific conditions. This is no longer the case: full vetting is now always applied in parallel in all cases.
CQs are not required for third-party content in all cases. In the case of third-party content due diligence, CQs are now only used to track the vetting process.
CQs are no longer required before third-party content is introduced. Previously, the IP Policy required that all third-party content must be vetted by the IP Team before it can be used by an Eclipse Project. The IP Policy updates turn this around. Eclipse project teams may now introduce new third-party content during a development cycle without first checking with the IP Team. That is, a project team may commit build scripts, code references, etc. to third-party content to their source code repository without first creating a CQ to request IP Team review and approval of the third-party content. At least during the development period between releases, the onus is on the project team to — with reasonable confidence — ensure any third-party content that they introduce is license compatible with the project’s license. Before any content may be included in any formal release the project team must engage in the due diligence process to validate that the third-party content licenses are compatible with the project license.
History may be retained when an existing project moves to the Eclipse Foundation. We had previously required that the commit history for a project moving to the Eclipse Foundation be squashed and that the initial contribution be the very first commit in the repository. This is no longer the case; existing projects are now encouraged (but not required) to retain their commit history. The initial contribution must still be provided to the IP Team via CQ as a snapshot of the
HEADstate of the existing repository (if any).
The due diligence process for project content is unchanged.
We are in the process of updating this documentation to reflect these changes. All historical information is technically correct, but may no longer be required. If something appears confusing, please connect with EMO for assistance.
There are different kinds of content (e.g., source code, documentation, and images) to consider. Project content is content (typically source code) that is produced and maintained by the open source project committers and contributors. Third-party content generally takes the form of libraries (e.g. modules, or components), source files, images, or other forms of IP that are produced and maintained outside of the scope of the open source project. To mitigate the risk associated with adopting open source in products, the project content and the third-party content that it leverages need to be vetted to ensure that the copyrights expressed are correct, licensing is valid and compatible, and that other issues have been uncovered and properly investigated.
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.
Most of the project content produced by committers can be pushed into a project repository without any sort of legal review. However, at least in some cases, the IP Team needs to be engaged to review project content that comes from contributors (who are not committers); and there are some cases where even the work of committers needs to be reviewed.
The IP Due Diligence Process focuses on source content. For the purposes of the IP Due Diligence Process, the term source code (or source content) refers to the pre-compiled content, including programming language source, configuration and property files, as well as binary things that don’t have a pre-compiled form like icons. The IP Due Diligence Process is concerned with reviewing the IP that is either consumed (third-party content) or produced (project content) by the Eclipse open source project. The process doesn’t generally focus on compiled content (e.g., the IP Team looks at source code, not JAR files).
The IP Due Diligence Process does not dictate how source code repositories are structured. When the IP Team signals that content can be used, the project team can put content into their repositories in whatever structure makes the most sense. Similarly, the IP Due Diligence Process is not concerned with how third-party content is represented (e.g. how it is integrated into builds) or how it is disseminated.
The Eclipse Foundation Development Process does restrict how content can be disseminated based on the state of the IP review. A Project team can create and distribute milestone builds of any content that has been granted check-in from the IP Team. All content must be approved by the IP Team before the project can engage in a formal release.
The entry point into the IP Due Diligence Process is the Contribution Questionnaire, or CQ. Project teams should create a single CQ for the initial contribution of project content. The initial contribution is a special type of project content contribution in the sense that it is the first thing that the IP Team will review on behalf of the project 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 via IPLab and IPZilla. The Dash Database is accessed via API only; the Eclipse Dash License Tool is the primary means of accessing this resource.
IPLab is a repository on the Eclipse Foundation’s GitLab infrastructure that is dedicated to tracking the due diligence review process and conclusions for Eclipse project and third-party content. Issues on that repository are used to request reviews, and track the review process and results.
IPLab is being phased in through 2022 as a replacement for IPZilla.
IPZilla is a modified instance of Bugzilla that tracks the progress of the IP due diligence review and approval process. It is the main interaction point between committers and the IP Team. IPZilla is accessible only by committers, Eclipse Foundation member company representatives, and other specifically-designated individuals. Authorized users can review both completed and ongoing reviews via IPZilla.
IPZilla was marked deprecated in April 2022, and is scheduled for retirement at the end of 2022.
ClearlyDefined is an OSI project that combines automated harvesting of software repositories and curation by trusted members of the community to produce a massive database of license (and other) information about content. The Eclipse Foundation’s IP Team works closely 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 (i.e., no CQ is required).
In order to facilitate the use of automation in the IP due diligence process, the Eclipse Foundation has adopted ClearlyDefined identifiers to identify content.
The notion of an identifier for content is pretty natural for developers who are familiar with technologies like Apache Maven which has well defined means of uniquely identifying content in a well-defined software repository. Maven coordinates — which combine
version (often referred to as a “GAV”) — identify a very specific bit of content (especially when combined with a specific source, e.g. Maven Central). For example,
org.junit.jupiter:junit-jupiter:5.5.2 unambiguously identifies content on Maven Central that is known to be under the Eclipse Public License version 2.0 (EPL-2.0). Other systems use different means of identifying content:
node.js, for example, uses a pURL-like identifier for content in the NPM repository (e.g.,
To bridge the gap between the different means of identifying content (and fill in some of the blanks), we’ve adopted the ClearlyDefined project’s five part identifiers which includes the type of content, its software repository source, its name space and name, and version. ClearlyDefined coordinates are roughly analogous to Maven coordinates, but — by including the type and source — provide a greater degree of precision. ClearlyDefined uses slashes to separate the parts of the identifier, so the Maven GAV
org.junit.jupiter:junit-jupiter:5.5.2 maps to
maven/mavencentral/org.junit.jupiter/junit-jupiter/5.5.2 and the NPM identifier
@firstname.lastname@example.org maps to
ClearlyDefined is used as part of the overall due diligence process for third-party prerequisites. The Dash Database is the primary source of information regarding third-party licensing for Eclipse projects. In cases where the Dash Database and ClearlyDefined results differ, the Dash Database results take precedence.
Don’t use ClearlyDefined directly. Instead, use the Eclipse Dash License Tool.
When content is known to ClearlyDefined and has a Licensed score of at least 60, the declared and all discovered licenses are on the Eclipse Foundation’s approved licenses list, and all of the licenses are mutually consistent, then the content can be used without further action.
Note that when the ClearlyDefined record shows any of the following, a project committer must engage with the IP Team to review the content:
NOASSERTIONappearing as a declared license;
NOASSERTIONappearing as a discovered license;
No declared license; or
A License score of less than 60.
A Contribution Questionnaire (CQ) is the main interface between Eclipse committers and the IP Team. CQs are used to engage the IP Team in a review of intellectual property when their assistance is required.
A CQ is started when a committer completes a questionnaire regarding a project content contribution or third-party content. In literal terms, a CQ is a record in IPZilla that tracks the progress of the approval process. The CQ record is the primary communication channel between the submitting committer and the IP Team. CQ records persist indefinitely.
All significant contributions of content to be maintained by an Eclipse project (project content) require a CQ. Projects further may also require a CQ for some pieces of third-party content that project content makes direct use of (regardless of whether or not the content is directly distributed by the project.
CQs are not generally required for ongoing work done by project committers.
Code provenance tracking is critical (the source of all code that ends up in Eclipse Foundation repositories must be well known). To that end, all new projects are required to make an initial contribution before any code is committed to a project’s source code repository.
Following a successful Creation Review, the EMO will initiate the provisioning process (Committers provide required paperwork and the IT Team creates project resources (Git, downloads, website, etc.);
The initial contribution is a snapshot of the existing code base. The initial contribution, like any other project content contribution, should contain only project content. Any third-party content that might be included in the existing source tree should be excluded from the initial contribution and treated as third-party content. The initial contribution is just a snapshot in time: the IP Team does not review history.
Any project committer can start the initial contribution review process by creating a CQ. The IP Team will review the initial contribution to ensure that it hasn’t been copied inappropriately, that licenses are being used correctly, and so forth. As part of this process, the IP Team will research the source of all code; depending on the size of the contribution, this can be a time-consuming process.
Because a full review can be time-consuming, the IP Team will in most cases start with a cursory review of the content, and — assuming that no significant issues are uncovered by that cursory review — will grant check-in indicating that the project team can push/merge the initial contribution into their Git repository (or initiate the transfer of their existing repository) and start working with the code while the IP team continues their review in parallel (they will add completing the review to their work queue and address it in turn).
After check-in has been granted for the initial contribution, the project team should start the due diligence process for their third-party content.
Eclipse Foundation systems use email to inform and remind interested parties of the various steps in this process. Only the committer who creates a CQ is notified by default, but other committers can be added to a CQ’s CC list to be included in the communication.
The email address that is associated with your Eclipse Foundation account is used; be sure to check spam filters to ensure that these messages are not missed. Send a note to EMO if you are concerned that you are not receiving these notification.
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).
Historically, the IP due diligence process treated committers from other projects as complete strangers. That is, historically, a contribution to a project by an Eclipse committer from a different project were treated as though they came from a contributor. This is no longer the case: contributions authored by Eclipse committers who are not project committers (that is, they are committers on one or more other Eclipse projects) do not require a CQ.
When the contributor has signed the Eclipse Contributor Agreement (ECA) and the following conditions are met, a CQ is not required:
Was developed from scratch; written 100% by submitting contributor;
Was submitted under the terms of the project license;
Contains no cryptography; and
Is contains fewer than 1,000 lines of code, configuration files, and other forms of source code.
If all of these conditions have not been met, then a project committer must open a CQ to request review by the IP Team before the contribution is pushed/merged.
If you’re not sure whether or not a CQ is required, or are otherwise concerned that there may be issues with a contribution, create a CQ.
All contributions of project content must be tracked in the project’s IP Log. This is done automatically when the author information is correctly specified in Git commit records (e.g., the content creator’s credentials are correctly recorded in the
author field of Git commit records).
Any project committer can create a CQ to submit a project content contribution for review by the IP Team. The project content must be attached to the CQ in source form. A full review can be time-consuming; the IP Team will start with a cursory review of the content, and—assuming that no significant issues are uncovered by that cursory review—will grant check-in indicating that the project team can push/merge the initial contribution into their Git repository and start working on it while the IP team continues their review in parallel. 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 author of a contribution (or their employer) retains copyright of the intellectual property contained in the contribution. As part of the contribution process, the contributor licenses their contribution under the applicable license(s).
The applicable license is typically the project license. Contributions may, however, be received and distributed under different licenses in some circumstances. If you need to accept content under a license that is not the project license, engage with the IP Team for assistance (create a CQ).
In the case where review by the IP Team is required, a project committer must create a CQ.
Creating a CQ for a project content contribution requires two steps. In the first step, a committer must create the CQ record by providing basic information about the content. In the second step, the committer must then attach the source code for the content to the newly created CQ. When all information and the source code has been collected, the workflow will connect with the PMC for their approval.
When engaged in the workflow to create a CQ for a project content contribution, indicate that the CQ is for "Project Content" on the first page of the wizard and provide the information requested on the following page. Set the value of the "Contribution Record" to some publicly accessible link. This could be a link to a pull request, or — in the case of an initial contribution — a link to the proposal tracking bug.
After creating the CQ, the committer will be sent an email with instructions to attach the corresponding source code. Bundle the
Be sure to click Issues addressed, return CQ to IP Team to release the CQ back to the workflow.
The IP Team will engage in two phases. In the first phase, they will perform a rudimentary license check. If the licenses represented in the content are found to be compatible with the project license, the project team will grant check-in meaning that the project team may add the content to a project repository (or engage with the Eclipse IT Team to move an existing repository). The IP Team will add the CQ to their queue for further detailed analysis. When that analysis is complete, the IP Team will mark the CQ as
approved, indicating that the content is fully vetted for use and may be included in a project Releases.
The IP team may require assistance from the project team as it analyzes content. Once that analysis is complete and the IP Team has made a decision, they will outline the next steps directly on the CQ.
Be advised that this process may take a while. The actual amount of time that it takes to process a CQ depends on numerous factors including the size of the IP Team’s work queue, and the nature and size of the contribution.
The sort of effort that the IP Team brings to bear on third-party content varies depending on the type. The Guidelines for the Review of Third-party Dependencies defines three different types: Prerequisite, Exempt Prerequisite, and Works With Dependency.
The term contribution questionnaire is a bit misleading when it comes to third-party content. Third-party content is not really a contribution to the project, but since the requirements for tracking project content and third-party content is very similar, the same mechanism is used for both.
The simplest form of third-party content is the prerequisite (which is frequently referred to as a prereq). Prerequisites are required by the Eclipse project content to provide core functionality (i.e., adopters of Eclipse project content are compelled to adopt the prerequisite content). Prerequisite content is not generally stored in an Eclipse project’s source code repositories, but is likely included in build scripts and referenced as runtime dependencies. The entire transitive closure of a prerequisite’s dependencies are themselves prerequisites (the dependencies of a prerequisite are themselves prerequisites, recursively).
Examples of Prerequisite dependencies:
The Java/OSGi manifest for one of the project bundles makes a direct reference to third-party content (either a bundle or package);
The project content includes an import statement for a package from third-party content;
The project content imports a third-party library’s header file;
The project content references NPM modules via a
The project’s Maven-based build lists a module as a
The project content uses reflection or other means to reference APIs and implementation;
The project content uses OSGi Services to make a reference to a specific implementation of a service; or
The project content invokes a command line interface (this may actually be an exempt prerequisite).
This list is not intended to be exhaustive, but rather to provide common examples. Fundamentally, when project content makes some kind of use of third-party content, then that content is likely a Prerequisite. Under certain conditions, the content may also be classified as an exempt prerequisite or a works with dependency.
In the case where an Eclipse project references code from another Eclipse project that itself references prerequisites, no further review of that chain of prerequisites is required. Eclipse project teams must only reference release versions of other Eclipse projects in their own releases to ensure that the IP Due Diligence Process has been completed.
The following snippet from a Maven
pom.xml file includes a single dependency that itself has dependencies.
... <dependencies> <dependency> <groupId>commons-httpclient</groupId> <artifactId>commons-httpclient</artifactId> <version>3.1</version> </dependency> </dependencies> ...
When Maven resolves the dependencies, it must also resolve dependencies of dependencies recursively. The
dependency:tree plug-in generates a graph of the entire dependency tree (note that the example is abridged).
$ mvn dependency:tree ... [INFO] org.eclipse.dash:good-stuff:jar:0.0.1-SNAPSHOT [INFO] \- commons-httpclient:commons-httpclient:jar:3.1:compile [INFO] +- commons-logging:commons-logging:jar:1.0.4:compile [INFO] \- commons-codec:commons-codec:jar:1.2:compile ...
Every library in the entire transitive closure of the dependency graph is a prerequisite.
In this example,
commons-codec:commons-codec:1.2 must all be vetted for license compatibility.
Prerequisites are version specific. Since it is possible that problematic intellectual property may be added in a new version of a prerequisite, every version of a prerequisite is treated as distinct content. In practical terms, this means that project teams are required to engage the due diligence process with each separate version of Prerequisite content they require.
This applies specifically to major and minor versions of prerequisites.
Project teams are not required to engage with the IP Team to review service releases for third-party content, provided that the service release is based on a release that has either been vetted by the due diligence process. A service release is defined as a release that is backwards compatible and contains only bug fixes. If a project team isn’t sure whether or not a particular release is a service release, they should submit the content for review by the IP Team.
All prerequisites must be available under a license that is on the Eclipse Foundation’s list of approved licenses for third-party content. Further, the nature of the license must be verified by a trusted source. When the license for content can be verified by a trusted source of license information, no further action is required (there is no need to seek approval from the IP Team); if there is any question regarding the nature of the license, then project team should create a CQ to request that the IP Team perform the necessary due diligence on the content.
Content that claims to be distributed under a particular license may in fact include content that is distributed under alternative licenses, meaning that the licensing of a particular piece of content may be more complex than even the content authors know.
The Eclipse Foundation has two trusted sources of license information: IPZilla and ClearlyDefined. IPZilla is the primary source of information regarding third-party licensing for Eclipse projects. In cases where results differ, those from the IPZilla take precedence.
Use the Eclipse Dash License Tool to determine whether or not third-party content has been approved for use.
IPZilla contains the accumulated knowledge of the Eclipse Foundation’s IP Team; it is the primary source of license information for third-party content. When an IPZilla record (CQ) for third-party content is marked as
license_certified, then that content can be used without further action. If, however, third-party content is otherwise marked (e.g.,
rejected), then the project team must engage with the IP Team via CQ to get approval to use the content.
If third-party content is not known to IPZilla, then ClearlyDefined can be used. When an entry is known to ClearlyDefined and has a Licensed score of at least 60 and all discovered licenses are on the Eclipse Foundation’s approved licenses list, then the content can be used without further action (for more information see Using ClearlyDefined).
When content fails to meet these requirements, the project team must engage with the IP Team via CQ to get approval to use the content.
When in doubt, committers should check with the EMO IP Team.
The workflow for creating a CQ for a prerequisite starts with a search of existing CQs. If an existing CQ, marked as either approved or license_certified, can be found that is concerned with the same content and version, then no further action is required. That is, committers should not create an additional CQ for any content that is already approved; if the content is already approved by an existing CQ, then it can be used without additional due diligence (notwithstanding any caveats or limitations outlined on the CQ).
Creating a CQ for a prerequisite requires two steps. In the first step, a committer must create the CQ record by providing basic information about the content. In the second step, the committer must then attach the source code for the content to the newly created CQ.
When all information and the source code has been collected, the workflow will connect with the PMC for their approval. The PMC’s role is to engage in a technical assessment to ensure that the information provided makes sense from a technical perspective; with their approval, the IP Team will engage in their review.
When engaged in the workflow to create a CQ for a prerequisite:
After creating the CQ, the committer will be sent an email with instructions to attach the corresponding source code. Bundle the source code into a ZIP file for the attachment.
Be sure to click Issues addressed, return CQ to IP Team to release the CQ back to the workflow.
The IP Team may require assistance from the project team as it analyzes content. Once that analysis is complete and the IP Team has made a decision, they will outline the next steps. These next steps may — in the event that the content is rejected — require that the content be removed from the project’s source code repository, or that some part be removed. Most often, the content is approved and the CQ is marked as such.
Be advised that this process may take a while. The actual amount of time that it takes to process a CQ depends on numerous factors including the size of the IP Team’s work queue, and the nature and size of the contribution.
When one follows a dependency graph all the way to the bottom, the entire runtime environment including virtual machines and the operating system are included in the transitive closure of dependencies. Clearly, having the IP team review virtual machines and operating systems is not a great use of time, and — in the case of closed source operating systems — just not be possible.
The Eclipse IP Due Diligence Process guidelines provide for a notion of Exempt Prerequisite dependencies, which are not subject to review. According to the guide, content may be considered exempt if it "is pervasive in nature, expected to be already on the user’s machine, and/or an IP review would be either impossible, impractical, or inadvisable." The IP Team does not review the source code associated with an Exempt Prerequisite.
One of the key aspects of an Exempt Prerequisite is that the user or adopter is typically the one that actually installs the software and so is the one who must agree to the licensing terms. Content that is declared an Exempt Prerequisite should never be directly distributed by an Eclipse project or otherwise made available without some explicit action from the consumer.
Any project committer can create a CQ to submit an Exempt Prerequisite for review by the IP Team. Exempt Prerequisites must be approved by the Eclipse Foundation’s Executive Director.
The Eclipse IP Due Diligence Process guidelines also define the notion of a Works With Dependency (commonly referred to simply as a Works With) that applies in two different cases. Third-party content may be declared a Works With Dependency when:
the functionality of Eclipse project content is enhanced by the presence of the software, but is otherwise functional and useful without it; or
there are multiple choices and reviewing all of them is impractical or impossible.
A Works With Dependency is, literally, a dependency that the Eclipse project content will work with when it is available. The fundamental requirement is the Eclipse project content must be useful and adoptable without the Works With Dependency. That is, either the project content provides useful functionality without the Works With Dependency or the Works With Dependency is a suitable alternative for a Prerequisite.
As with an Exempt Prerequisite, a Works With Dependency should never be directly distributed or otherwise made available without some explicit action from the consumer. The consumer is responsible for making the Works With Dependency content available and otherwise agreeing to the terms for that content.
It’s enough to just create a CQ to register the use of Works With Dependency without seeking IP Team approval for its dependencies. Works With Dependencies must be approved by the Eclipse project’s PMC.
Test and Build Dependencies are also categorized as works-with dependencies.
This document applies specifically to open-source libraries and tools only; it does not apply to the use of proprietary tools. Use of proprietary tools is covered by the Using Proprietary Tools Eclipse Board resolution.
Test and build dependencies are those third-party libraries and tools that are considered non-distribution contributions. That is, these libraries are not actively distributed by the project via any generally-accessible
eclipse.org property. These libraries and tools may, for example, persist on the build server which is accessible only to Eclipse committers; they may not, for example, persist on the
eclipse.org download or archive servers, web server, or any source code repository. Eclipse project content (e.g., build scripts) distributed via
eclipse.org source code repositories may contain references to these libraries and tools (but not the libraries/tools themselves). Project documentation should list these dependencies, how they are obtained (either manually or automatically via scripts), and other issues (especially licensing).
This applies to third-party content that is required exclusively to facilitate build and test. Any dependencies that are required by downstream consumers of the Eclipse software are prerequisites as defined by the Guidelines for the Review of Third-party Software) and must be taken through the due diligence process as such.
To declare build and test test dependencies, create a CQ:
Enter a title containing the terms "test-only dependencies", "build-only dependencies", or "build- and test-only dependencies" (or similar);
Enter a description that indicates that the CQ is for test/build-only dependencies, and set the CQ type to "works with"; and
Enter "various" in the license field and "binary" in the ;
List all the third-party dependencies — one on each line — along with version information.
This is an umbrella CQ for all dependencies of the Eclipse Tycho project which are only needed to compile and execute unit and integration tests for Tycho. These artifacts are *not* redistributed by the Tycho project and are strictly only needed to compile and run tests for tycho itself. The following bundles from orbit are required by Tycho as test-only dependencies: Bundle-SymbolicName : Bundle-Version ============================================= com.ibm.icu:4.2.1.v20100412 javax.xml:1.3.4.v201005080400 org.apache.ant:1.7.1.v20090120-1145 org.junit:3.8.2.v20080602-1318 org.junit:3.8.2.v20090203-1005
When the list of build and test dependencies is long, it might be easier to include it in a comment after the CQ is created.
Project teams may create multiple test and build CQs.
You will need PMC approval. You may be able to hasten approval if you work with your PMC prior to creating the CQ to ensure that they understand your requirements.
If you have any questions or concerns, please contact EMO.
Piggyback CQs are not longer required or supported.
IP Team review or approval is not required for an Eclipse open source project to use released content from another Eclipse open source project as part of a release (a project may use unreleased content from another project in milestone builds). A release of one project should never include unreleased content from another project.
When an Eclipse projects makes direct use of third-party content inherited by consuming another Eclipse open source project, that content must be treated as a prerequisite dependency.
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.
The Eclipse Dash License Tool is intended to assist with the process of determining the licenses of third-party content and help committers identify intellectual property that require further scrutiny. The tool, like any tool, is only as good as the input provided. The License Tool’s documentation provides examples of how dependency lists can be generated; these examples should be regarded as such: examples of how to construct a dependency list. Ultimately, is the responsibility of committers to understand the nature of their project and the third-party content it requires.
What the License Tool does is relatively simple:
it first queries the Eclipse Foundation’s license information database;
if an entry has been vetted by the IP Team and has been approved for use, then it is marked as
if an entry has been vetted by the IP Team and flagged as somehow problematic, it will be marked as
it then sends the content that has not been flagged as either
ClearlyDefined matches are marked as
Everything else is marked
The License Tool lists all content that ended up marked as
restricted as requiring further scrutiny.