Skip to main content

Eclipse Foundation Project Handbook

Table of Contents

Current as of 2024-01-31.

Notices

Copyright © 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.

Overview

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.

While this document is focused on Eclipse, it makes several "Eclipse" references, including the Eclipse Foundation, Eclipse Foundation Development Process, and Eclipse Management Organisation. The Eclipse Foundation is the legal entity that manages the operations of the Eclipse working group, software development forge, and community.Many of the provided services and contacts are so-named on that basis.

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 life cycle, 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.

Principles

Four basic principles lie at the heart of the EDP:

  • Transparency;

  • Openness;

  • Meritocracy; and

  • Vendor-neutrality

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.

Note

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

Starting an Open Source Project at the Eclipse Foundation

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.

Project Proposal

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.

starting overview
An overview of the Project Creation Process

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 Organisation (EMO) requesting that the proposal be made available to the public for review. The EMO will review the proposal and may provide feedback before initiating the community review period.

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

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

Project Proposal Document

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.

Note

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 track of the URL, ask EMO for assistance.

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

Scope

Does the project have a technology scope and focus which will have a reasonable likelihood of success? Projects that are too big will definitely fail; projects that are too small are unlikely to be interesting.

Clear and Concise Description

If the community found any aspects of the proposal confusing, unclear, or using unfamiliar jargon, those areas must be clarified. This is a hard and fast requirement: because the Eclipse community must be able to evaluate the proposal. To do that, they must be able to understand the proposal and thus it must be clear and straightforward and free of marketing-speak.

Committers

The creation review serves as the new committer election for the initial Committers and thus the proposal must contain the same level of nomination justification and background as an election would. The committer biographies don’t have to be long or involved, but they should describe each committer’s relationship to and history with the incoming code, and/or involvement with the area or technologies covered by the proposal.

The project must have sufficient committed developers to achieve its goals. The Eclipse Foundation is not a place to "abandon in public" code; rather, the Eclipse Foundation strives to have active projects with active communities and thus enough developers to move the project along.

Communities

Does the project have a community of contributors and users, outside the core developers, who are willing to work towards making this a success? This is a bit of a Catch-22 situation because it is sometimes hard to attract a community before any milestones or releases, but it is also true that projects with limited developers and even fewer users tend not to have much technical impact.

Collaborations

Successful Eclipse projects are those that collaborate with existing Eclipse, or other open source, projects. Again, it can be hard to start a collaboration before demonstrating the technology, but at the same time it is never too early to start discussing collaborations with other projects. Additionally, it never hurts to join and help an existing project to start establishing those social networks that will make future collaborations on the new project possible.

Sufficient Time for the Community

Project proposals are held in community review for a minimum of two weeks. Anything less than two weeks of general accepted business days does not give the Eclipse membership sufficient notice of new initiatives.

Diversity

Is this a single company project or a multi-organization effort? If all the committers and contributors are in the same organisation or have financial ties to the same organisation, the project is at a greater risk of being de-staffed. Brand new projects are not required to be diverse, but projects cannot graduate from incubation without appropriate diversity.

Trademarks

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.

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

Note

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.

Provisioning

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.

Note

The provisioning process will not start until after the committer agreement 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.

After Provisioning

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

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

post creation
Post creation activities

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.

Project Phases

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

phases
An overview of the Project life cycle Phases

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

Incubation Phase

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 practising 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.

Incubation branding
incubating

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.

Note

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.

Mature Phase

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 behaviour;

  • Regularly and predictably releases IP clean extensible frameworks and exemplary tools; and

  • Actively nurtures the three communities: developers, adopters, and users.

Archived

When a project has reached its logical conclusion, its resources are archived. Transition in the Archived (phase) is preceded by a termination review.

Frequently Asked Questions

  1. Can we keep the project proposal in draft form (private) until a certain date?

    Yes. You can ask the EMO to keep a proposal private until you a ready.

  2. Can we create the project right now? Do we have to wait?

    Our process requires that a proposal be made available for community review (and review by our members) for a minimum of two weeks. The required creation review requires one full week. In exceptional circumstances, we can overlap the community review and creation review, meaning that the best we can do for project creation is two weeks. Timely responses to our queries will help: we cannot for example, create a project until after we have transferred applicable trademarks and domains.

  3. Can we delay the creation review?

    Our practice is to move as quickly as we can, so the EMO will do its best to schedule a creation review as quickly as possible. We can, however, hold off scheduling a creation review until you and the community are ready.

  4. Do I have to create an entirely new project? Can I extend an existing project?

    If new functionality falls within the scope of an existing project, then it may make sense to instead create a component within the project. Components are an informal concept for Eclipse open source projects; the notion of a component generally manifests as a separate Git repository with access to that repository managed via social convention.

    All project committers have uniform write access to all project resources, which means that when a new component is added to a project everybody who already has push access to the Git repositories already in that project can also push to the new component’s Git repository.

    Different components within a project can be built separately, but they generally release on a shared schedule with shared release reviews (although there is some precedent for projects releasing different components separately).

    A component may be the right choice if the new functionality:

    • Is within the scope of the project;

    • Shares the same licensing of the project;

    • Can reasonably share the development schedule of the project; and/or

    • Will be delivered alongside other project functionality.

    You might instead choose to create a new project if the new functionality:

    • Does not reasonably fall within the scope of an existing project (and an existing scope cannot be reasonably changed to accommodate);

    • Absolutely must be delivered on a separate schedule;

    • Must be delivered independently (i.e. a completely separate downloads area is required);

    • Has different licensing requirements; and/or

    • Would benefit from separate branding.

  5. 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, Project Management Committee (PMC) member, etc.). No link indicates that no existing project relationships exist for that individual.

  6. 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.

  7. Can I change the proposal after it is posted?

    Yes. The proposal can be changed any time before the start of the creation review.

  8. 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.

  9. Does the new project have to use Git?

    Yes. Git is the only source code management system that is currently permitted for new projects.

  10. 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 organisation at GitHub. Official repositories are subject to the same intellectual property due diligence rules and processes that all Eclipse project repositories must follow.

  11. 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.

  12. 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.

  13. What do all these terms (e.g. EMO) mean?

    Please see the glossary.

Project Roles

The Eclipse Foundation Development Process defines multiple formal open source project roles. Primary among the roles are those of Committer, Project Lead, and Project Management Committee.

Committers

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

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

Committers:

  • Operate in an open, transparent, and meritocratic manner;

  • Write code (and other project content) and push it directly into the project’s source code repository;

  • Review contributions (merge and pull requests) from contributors;

  • Engage in the Intellectual Property Due Diligence Process;

  • Vote in committer and project lead elections;

  • Engage in the project planning process; and

  • Otherwise represent the interests of the open source project.

Project Lead

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

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

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

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

Tip

Project leads should seek help/advice from the Project Management Committee and Eclipse Management Organisation when they need assistance.

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

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

Tip

The six months of inactivity is more of a suggested period of time for considering retirement of committers; we defer to the judgement of the project lead to determine when and if somebody who is inactive should be retired.

Project leads have some extra privileges on GitLab and GitHub.

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

Note

A project lead is not necessary a technical lead. We have no formal designation of technical lead; this tends to occur organically.

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

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

Project Management Committee

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

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

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

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

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

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

Composition

A PMC has one or more PMC leads and zero or more PMC Members.

The PMC Lead is appointed by the Eclipse Foundation’s Board of Directors. When an existing PMC Lead retires, the EMO will work with the PMC to identify a replacement and then with the EMO(ED) to have that individual ratified by the board of directors.

PMC Members are appointed by the EMO(ED). The criteria by which PMC members are identified varies by PMC, but is generally by nomination and election within the existing PMC. Some PMCs are designed to be composed of representatives from some subset of the projects that operate under their purview. In such a case, the means of identifying members should be documented in the corresponding top-level project charter.

In the unlikely event that a member of the PMC becomes disruptive to the process or ceases to contribute for an extended period, the member may be removed by the unanimous vote of the remaining PMC members, subject to approval by the EMO. Removal of a PMC Lead requires approval of the Board.

PMC Role in the Intellectual Property Due Diligence Process

The Eclipse IP Team has limited technical knowledge and so relies on the PMC to use their relationship with the open source projects operating under their purview, their knowledge and experience with the community and related technology to provide technical insight. Specifically, the IP Team depends on the PMC to use their knowledge and experience with their community and technology to flag any potential issues that may not be obvious.

The PMC might, for example, know that the license for some content had been, at some point in the past, changed; or that some particular piece of content links in some non-obvious manner to other intellectual property that should also be vetted.

Tip

The PMC should not perform any detailed intellectual property analysis of content. The IP Team will engage in detailed analysis, identify license compatibility issues, and determine whether or not license headers have been appropriately applied, for example.

The IP Team will connect with the PMC when their assistance is required.

PMC Role in Elections

The PMC reviews and approves (or vetoes) committer and project lead elections. The role of the PMC is validate that the election was run according to the open source rules of engagement and election process described in the Eclipse Foundation Development Process, and consistent with the Top-Level Project Charter.

In practical terms, the EMO depends on the PMC to validate that elections provide (either via the nomination statement, or by statements made by committers during the voting period) a transparent record of relevant contribution by the nominee and maintain vendor/employer neutrality.

From the EMO’s perspective, any single PMC member can review the election and — if they feel that the election was correctly run — approve it. Any single member can do this on behalf of the PMC. PMCs tend to do this opportunistically: the first PMC member who receives notice of the completed election does a quick review and approves (or not). In the general case, a PMC member will independently review and approve an election; in specific individual cases, the PMC member may decide that further investigation is required and engage with the rest of the PMC for guidance.

Note

The PMC may, at its discretion, add requirements for elections involving projects that operate under its purview. The PMC must capture additional requirements (ideally in the Top-Level Project Charter or in a companion document) and apply them consistently.

The PMC list is notified when elections require the PMC’s attention. Alternatively, PMC members can review elections that require their attention on the Notifications page.

Tip

Click the drop-down next to "Welcome, <name>" to access the Notifications page.

notifications

PMC Role in Reviews

As part of the project leadership chain, the PMC is tasked with approving progress, release, and graduation reviews.

The criteria by which the PMC determines whether or not to approve a review, and the process that they follow to grant approval varies by PMC. In general, with this request for approval, the EMO seeks the advice of the PMC regarding whether or not projects under its purview are operating according to the open source rules of engagement. That is, the EMO expects that the PMC has some insight into the operation of the projects operating under their purview, and know whether or not project teams have what they need to be successful.

A project lead or committer must request PMC approval via email to the PMC’s mailing list. Any member of the PMC may approve the review by responding directly to the request with a +1 (that is, the EMO will interpret any single PMC member’s +1 as the PMC’s affirmative response).

Note

The EMO monitors all PMC mailing lists and so will likely observe the PMC’s approval response. The EMO will acknowledge the approval via the issue being used to track the review.

Since any single member of the PMC may approve a review on behalf of the entire PMC, the EMO purposely delays recording the approval in order to give other PMC members an opportunity to challenge their colleague.

PMC Role in Grievance Handling

The PMC is a link in the project leadership chain. As such, the PMC has a role in the grievance handling process: they identify and document project dysfunction (with the responsibility to remove or replace disruptive committers).

The PMC is an important link in the project leadership chain, which is composed of the project’s project lead(s), the leadership of the parent project (if any), the PMC leads and PMC members, the EMO, and the Executive Director of the Eclipse Foundation. In exceptional situations—such as projects with zero active committers, disruptive committers, or no effective project leads—the project leadership chain has the authority to make changes (add, remove) to the set of committers and/or project leads of that project, and otherwise act on behalf of the project lead.

PMC Representation

Every PMC is entitled to appoint one representative to the Eclipse Architecture Council.

Eclipse Architecture Council

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

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

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

Tip

In practice, the two year renewable term for appointed members of the Architecture Council are automatically renewed with no formal ceremony.

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

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

Eclipse Management Organisation (EMO)

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

Frequently Asked Questions

  1. Is the Project Lead a super-committer?

    A project lead is not a super committer. In fact, the project lead role does not automatically grant the individual committer privileges. The roles are different and an individual must be elected into both of them separately (though it is common that an individual is elected into the project lead role after demonstrating merit while working in the committer role).

Committer Badges

The Committer Badge

The role of a committer is one of great responsibility within open source communities. Committers are individuals who have demonstrated their expertise, commitment, and contribution to a project or community and have earned the trust of the existing committers or project maintainers.

Committers have write access to the source code repositories. They have the authority to directly contribute changes to the codebase and have their contributions integrated into the project. This role often involves reviewing and merging code submissions from other contributors, ensuring that the code meets the project’s standards and maintaining the stability and quality of the codebase.

Being a committer requires technical skills, knowledge of the project’s codebase and development practices, and a strong understanding of the project’s goals and objectives. Committers are responsible for making important decisions related to the project’s direction, resolving conflicts, and ensuring that the project evolves according to its roadmap.

The role of a committer comes with a set of obligations and responsibilities, such as actively participating in discussions, providing guidance and support to other contributors, and upholding the project’s values and standards. Committers play a crucial role in shaping the project, maintaining its integrity, and fostering a collaborative and inclusive community.

Becoming an Eclipse committer is a significant accomplishment, reflecting the continuous dedication, contribution, and earned trust of the community.

The Eclipse Foundation awards this badge to certify developers who have attained committer status within the Eclipse Foundation’s Community.

Who is Entitled to Receive the Badge?

Everybody who has committer status on one or more Eclipse Projects is eligible to receive the badge.

How Do I Get the Badge?

Roll out starts after EclipseCon 2023 (November 2023). From that point forward, we will offer the badge to all new committers when we have their fully executed committer agreement.

Tip

If you work for a member company, then we most likely already have a Member Committer and Contributor Agreement on file for you; we might otherwise require that you complete an Individual Committer Agreement. The EMO Records Team will help you sort this out.

Roll out to existing committers will occur in stages with anticipated completion in early 2024.

Former committers can request the badge by sending a note to EMO Records Team.

Frequently Asked Questions

  1. Do I have to accept the Committer badge?

    No.

  2. Do I have to be an Eclipse Committer to receive the badge?

    Yes.

  3. How do I become an Eclipse Committer?

    The most common way for somebody to join an Eclipse Foundation open source project as a committer is to be elected to an active project. All Eclipse open source projects operate in an open, transparent, and meritocratic manner, so the path to becoming a committer starts with participation: clone the repository, make some changes, and contribute those changes as a merge/pull request. Then do it again.

    After you have demonstrated, through a pattern of high quality contributions, that you understand how the open source project works, and that you understand the Eclipse Foundation Development Process and are prepared to implement the Eclipse IP Policy, an existing committer will invite you to join the team and initiate an 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 of the various contributions that the individual has made to the project.

    What constitutes a sufficient demonstration of merit varies by project team.

    For more information, please see Committers.

  4. Do I have to make a specific number of contributions to receive the badge?

    No. The role of Eclipse committer is awarded to individuals who have already demonstrated to the project team and community that they understand the responsibilities inherent in the role. If the contributions that you’ve made are sufficient enough for the project team to elect you into the role, then you’re eligible to receive the badge.

  5. How do I request the Committer badge?

    Current and former committers can send a note to EMO Records Team to request the badge.

  6. I’m a committer on multiple Eclipse open source projects, do I get multiple badges?

    No. You get one. Don’t be greedy.

  7. I was an Eclipse committer in the past, but no longer have committer status; am I entitled to the badge?

    Yes. Send a note to EMO Records Team to request the badge.

  8. What can I do with the badge?

    You can add the badge to your professional profiles, such as LinkedIn, to highlight your expertise and stand out to potential employers or clients. By sharing your badge on social media platforms, you can increase your visibility and attract the attention of potential employers, colleagues, or collaborators. It serves as a powerful endorsement of your skills and can lead to networking opportunities.

    Show it to your mom.

  9. What is Credly?

    Credly is a digital credentialing platform that allows individuals and organisations to create, issue, and manage digital badges.

  10. Do I need an account with Credly to accept the badge?

    Yes. You have the option to create an account or you can sign into Credly using your existing Google or Apple account.

    Note

    You will have to agree to Credly’s privacy policy and terms of use in order to access the badge.

Project Resources and Services

Open source projects at the Eclipse Foundation are required to make use of certain Eclipse Foundation services:

The Eclipse Foundation provides the following services (high level) for Eclipse open source projects:

Open, Transparent, and Meritocratic

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

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

Identifiers

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.

Source Code Management

Tip

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).

Note

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

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:

  1. One line (max 72 characters) summary;

  2. Description; and

  3. Footer.

Example Git Commit Record
commit d6cf52411377a039fc2906378711091a26e932cb
Author: Some Body <somebody@somewhere.com> 1
Date:   Wed May 29 16:17:36 2013 +0200

    Bug 350686 - Hide unwanted action bar items 2

    This change hides unwanted 'Link with Editor' and
    'Customize View...' items from the local toolbar
    and the view menu.

    Change-Id: Ia2bd5091303d1b0a738157effc24e4dac5a7d0c7 3
    Also-by: Some Bodyelse <somebodyelse@nowhere.com> 4
1 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.
2 Best practice: include the bug id in the commit message summary.
3 Gerrit Change-Id (only when pushing to Gerrit for review).
4 Additional authors can be added using Also-by or Co-authored-by entries, by replacing the name "Some Bodyelse" by the real name of the person (use one entry per person).
Important

The name used in the Author field (and, when required, in the Also-by/Co-authored-by entries) must be the legal name of the contributor; the email address must be valid and real.

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

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

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

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

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

GitLab

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.

Tip

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.

Tip

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. In both nesting options, repositories may be arbitrarily nested in subgroups created under the projects' group to organise the repositories. The custom subgroups are cosmetic only, as the same permissions are applied to the nested groups and do not provide any extra functionality.

Project Group

A group can be configured as the immediate descendant of the root group, using the Eclipse open source project’s short name.

Project short name as the root
eclipse
 ├── <short name A>
 │   ├── <repository 1>
 │   ├── <repository 2>
 │   └── ...
 ├── <short name B>
 │   ├── <repository 1>
 │   ├── <repository 2>
 │   ├── <custom group 1>
 │   │   ├── <repository 3>
 │   └── ...
 └── ...

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):

  • https://gitlab.eclipse.org/eclipse/dash/handbook

  • https://gitlab.eclipse.org/eclipse/dash/license-tool

Top-level Project Group

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.

Tip

Configuring GitLab in this manner requires approval from the corresponding Eclipse top-level project’s Project Management Committee (PMC).

Top-level project short name as the root
eclipse
 ├── <top-level project short name>
 |   ├── <short name A>
 |   │   ├── <repository 1>
 |   │   ├── <repository 2>
 |   │   └── ...
 |   ├── <short name B>
 |   │   ├── <repository 1>
 |   │   ├── <repository 2>
 │   │   ├── <custom group 1>
 │   │   │   ├── <repository 3>
 |   │   └── ...
 │   └── ...
 └── ...

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):

  • https://gitlab.eclipse.org/eclipse/technology/dash/handbook

  • https://gitlab.eclipse.org/eclipse/technology/dash/license-tool

Access to GitLab Repositories

Project leads, committers, and contributors for each project are granted access to their project group according to their role within the project.

Tip

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.

Warning

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.

For example, project leads must not manipulate privileges and must specifically not add or remove developers directly. See Committer Elections for information on how to add developers to a project, and Committers Retirement for information on how to remove developers from a project.

Project leads must also not use their privileges to create private repositories, as this would violate the open source rules of engagement.

Committers

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.

Contributors

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.

Bot Users

To assist with CI/CD operations, bots with CI/CD access can be requested by making a request within the help desk 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.

Excluded Subgroups

Excluded Subgroups have been added to Project Management Infrastructure (PMI) project page to better support cases where third-party non-project code needs to exist within a project group for stability, such as forks and mirrors. Once configured, these subgroups within the project groups to exclude from automated tooling such as the ECA checks. The excluded subgroups follow the standard access permissions and Project Leads can request updates to this field through the help desk.

GitHub

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., eclipse-woolsey).

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

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

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

Github cla success
Notification that the commit is properly structured and permissions are in place.

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

Github cla failure
Notification that there is something wrong with the commit.

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

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

Github branch protection rule
Setup of a Branch Protection Rule with require ECA validation status checks.

Access to GitHub Repositories

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).

Tip

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.

GitHub’s Repository roles for an organization document describes the permissions granted for each of the roles (Maintain, Write, and Triage) described below.

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.

Warning

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.

For example, project leads must not manipulate teams or privileges and must specifically not add or remove developers directly. See Committer Elections for information on how to add developers to a project, and Committers Retirement for information on how to remove developers from a project.

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.

Self-Service of GitHub Resources

The Eclipse Foundation offers self-service of GitHub resources via a tool named Otterdog.

Upon opting-in, a new repository .eclipsefdn will be created that hosts the GitHub configuration as code.

Example Otterdog configuration
orgs.newOrg('adoptium') {
    settings+: {
      blog: "https://adoptium.net",
      default_repository_permission: "none",
      default_workflow_permissions: "write",
      description: "The Adoptium Working Group promotes and supports high-quality runtimes and associated technology for use across the Java ecosystem",
      members_can_change_project_visibility: true,
      members_can_change_repo_visibility: true,
      members_can_delete_repositories: true,
      name: "Eclipse Adoptium",
      readers_can_create_discussions: true,
      security_managers+: [
        "adoptium-project-leads",
      ],
      twitter_username: "adoptium",
      web_commit_signoff_required: false,
    },
   ...
}

The following resource configurations are available:

  • Organization Settings

  • Organization Webhooks

  • Repositories and their settings

  • Branch Protection Rules

Committers can create pull requests for this repository with suggested changes. A workflow will automatically run, validate and highlight the changes:

Github self service pull request comment
Validation of suggested configuration changes.

The pull request needs to be approved by an Eclipse Foundation staff member and once its merged, the changes will get applied to GitHub.

The baseline configuration used by the Eclipse Foundation can be accessed here.

Gerrit Code Review

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

Issue Trackers

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

Mailing Lists

Eclipse projects have one or more mailing lists.

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

Tip

To create additional mailing lists for a project, a project leads should make the request by opening a Help Desk request.

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

Mailing list subscriptions are managed via your Eclipse Foundation Account.

Project Dev Lists

All projects are assigned a development list or dev-list that takes the form <shortname>-dev@eclipse.org (e.g., woolsey-dev@eclipse.org).

All project committers must subscribe to the list. The dev-list should be the primary means of communication between project committers and is the means through which the EMO and the Eclipse Foundation’s automated systems communicate with the project team.

PMC Lists

Every Project Management Committee (PMC) is assigned a PMC list that takes the form <shortname>-pmc@eclipse.org where <shortname> is the short name of the corresponding top-level project (e.g., technology-pmc@eclipse.org).

All PMC members must subscribe to this list. Project leads and committers from open source projects operating under the purview of the PMC may also subscribe to the list to monitor the activities of the PMC and interact as necessary (it’s common that project teams will designate one or more representatives to the PMC who will subscribe to the PMC list).

The PMC list should be the primary means of communication between PMC members and is the means through which the EMO and the Eclipse Foundation’s automated systems communicate with the PMC.

Committers Mailing List

All committers are automatically subscribed to the eclipse.org-committers@eclipse.org mailing list. This list is used primarily as a means for the EMO and the Eclipse Foundation IT Team to communicate important information to all committers. We use this list sparingly.

Tip

Subscription to the committers mailing list is an obligation that comes with having committer status on an Eclipse open source project. The only way to remove yourself from this list is to retire yourself as a committer.

Forums and Outbound Communication

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

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

Many project teams opt to create a custom main project website: if so-desired, a project may host a website on Eclipse Foundation-hosted servers. Project website URLs generally take the form https://www.eclipse.org/<shortname> (e.g. 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.

Note

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.

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

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

Analytics and Data Collection

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.

Vendor-Specific Links

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.

Note

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.

Builds

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.

Signed Artifacts

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

Downloads

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.

External Resources

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

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.

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

Warning

Source code, documentation, issues/tickets/bug reports must all be maintained using resources that are provided and managed by the Eclipse Foundation.

External resources can be used for:

  • User forum discussions (e.g, Slack);

  • Builds and alternative sources for downloads;

  • Container image management (e.g., DockerHub); and

  • Examples, presentations, blogs, social media handles.

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

External resources must, where possible, include links to:

These links can be provided in a field, a README, or on directly accessible (i.e., linked) web page.

DockerHub

The Eclipse Foundation owns several organizations on DockerHub, including eclipse, locationtech, and polarsys, but does not formally support or strictly manage the use of these organizations.

For more information, please see CBI/DockerHub in the Eclipse wiki.

Note

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-<shortname> (e.g. 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.

Maven Central

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.<shortname> (e.g. 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 labelled (e.g. 1.0M3 for pre-release builds of version 1.0).

Project teams must engage in the Project Releases and Reviews process before labelling 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.

Frequently Asked Questions

  1. How do I get write access to a particular GitLab/GitHub project?

    Only committers have the ability to write to GitLab/GitHub projects that are managed by the Eclipse Foundation on behalf of Eclipse open source project repositories.

    In order to get write access, you must be elected as a committer on the corresponding Eclipse by an existing committer. In order to get access to a GitHub project, you must also provide your GitHub Id in your Eclipse Foundation Account.

  2. Can we connect service X to an Eclipse project’s GitHub Repositories?

    Our primary concern is that all decision making and planning (and related discussion) for the Eclipse open source project must be done in a manner consistent with the Open Source Rules of Engagement (open, transparent, and meritocratic) defined in the Eclipse Foundation Development Process.

    Growing a community and diversifying the project committers is a goal of every Eclipse open source project. Nothing quite kills a community’s enthusiasm like pointers to related issues that they don’t have access to, hints that there is a higher level of planning that they do not have access to, or otherwise suggest that the project is not being run in an entirely vendor-neutral manner.

    Care must be taken to ensure that all decisions regarding the direction taken by the project are being driven the committers.

    If you believe that the Eclipse project can be run as independent vendor neutral open source with the service attached, that is transparent and open to all comers and that there is a level playing field with a path that community members can follow to demonstrate merit and earn equal access to all project planning (that is, become committers), then you can request that the service be attached by creating a Help Desk issue.

  3. Can a project use the gh-pages support from GitHub to host at <project>.github.io?

    Yes.

  4. Can we use a GitHub repository for our project website source?

    Yes. Create a Help Desk issue to request support.

  5. 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.

  6. 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 labelled as such. A milestone build for version 1.0, for example, must be labelled 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.

  7. Can we use external services like OSSRH to stage pre-release builds?

    Yes.

  8. 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 Author field; the contributor must also have electronically signed the ECA using those same credentials.

Managing and Reporting Vulnerabilities

The Eclipse Foundation Vulnerability Reporting Policy contains information regarding obligations and specific practices regarding the reporting and disclosure of vulnerabilities.

Eclipse Foundation Security Team

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

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

Project Setup for Vulnerability Reporting

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

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

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

Reporting

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

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

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

Note

Security vulnerabilities should be reported as confidential issues (on GitLab), private security advisories (GitHub) or other confidential means. If unsure, use the general vulnerability issue tracker with the default template.

Disclosure

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

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

Common Vulnerabilities and Exposure (CVE)

The Eclipse Foundation is a Common Vulnerabilities and Exposures (CVE) Numbering Authority.

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

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

Tip

If you’re not sure whether or not a CVE is required, err on the side of caution and request one.

A CVE number related to a bugfix release gives users a clear sign that an update is strongly recommended.

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.

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

General case

For most projects the process looks as follows:

  • Request the number: When you know that there is a security issue (the fix is not yet needed at this point), go to the CVE Request form and fill it. Make sure to keep the issue confidential for now. If you want to make the issue visible to multiple project members, add them as assignees when creating the ticket (it will be hard later on).

  • Receive the number: The Eclipse Foundation Security Team will come back to you with the assigned number. You can start using it internally when preparing documentation of the release containing the fix.

  • Prepare the fix (with backports to all supported branches) and the release: The common practice is to avoid using the CVE number in the fix commit message or the fix itself. Use generic terms instead. The goal is to allow time for all users to upgrade without giving potential attackers too much information. See also the next step (you can do them in parallel).

  • Ask for publication of the issue: When you have the fix ready and published, update the ticket. Make sure that you specify the version (or versions) where the bug is fixed, including all stable branches. Fill in the description of the issue. You may also consider removing some of the comments (for example containing sensitive or incorrect information). At this stage you may decide to publish only partial information (for example without the link to the commit with the fix). Then ask the security team to make the CVE and the discussion of the CVE assignment public. Ideally your release and the publication happen at the same time. You can ask for a publication at your specific date, for example at your planned release date.

  • See it publicly: The ticket becomes public and the Eclipse Foundation Security Team publishes the CVE entry.

  • (Optional, a few days later) Update the entry with all additional information that might be helpful. That includes, for example, the link to the fix commit.

Note

Project committers should make it clear if their request is a reservation of a CVE number, or a publication.

Tip

When working with GitLab confidential issues, be careful. Only the author of the ticket, all committers in the project containing the issue tracker, and assigned people will see the issue and receive notifications.

Adding new assignees who are not members of the project has no effect when the issue is already confidential. When in doubt, verify with the concerned person if they receive notifications by other communication means.

The Tracking section of the request issue includes some checkboxes for the project team and for the Security Team. The Security Team 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 clearly indicates that they are ready to disclose the vulnerability.

…​

This section will completed by the project team.

  • ❏ Reserve an entry only

  • ❏ We’re ready for this issue to be reported to the central authority (i.e., make this public now)

  • ❏ (when applicable) The GitHub Security Advisory is ready to be published now

…​

Check the second checkbox when you’re ready for the Eclipse Foundation Security Team 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, the Security Team intervention will likely be required to submit the advisory. Click the second checkbox to indicate that you’re ready for the Security Team to submit the advisory on the project team’s behalf.

Projects Using Exclusively GitHub Security Advisories

If the project receives reports exclusively by private reporting with GitHub Security Advisories, the procedure is as follows:

  • Prepare the initial data: The project receives initial data in the report and assesses that it is a real vulnerability.

  • Request the number: When you know that there is a security issue (the fix is not yet needed at this point), contact the Eclipse Foundation Security Team to request the number.

  • Receive the number: The Eclipse Foundation Security Team will request a number and GitHub will assign one (or ask for more information in the report). You can start using it internally when preparing documentation of the release containing the fix.

  • Prepare the fix (with backports to all supported branches) and the release: The common practice is to avoid using the CVE number in the fix commit message or the fix itself. Use generic terms instead. The goal is to allow time for all users to upgrade without giving potential attackers too much information. See also the next step (you can do them in parallel).

  • Ask for publication of the issue: When you have the fix ready and published, as the Eclipse Foundation Security team to publish the advisory. Make sure that you specify the version (or versions) where the bug is fixed, including all stable branches. Fill in the description of the issue. You may also consider removing some of the comments (for example containing sensitive or incorrect information). At this stage you may decide to publish only partial information (for example without the link to the commit with the fix). Ideally your release happens earlier or at the same time as the publication. You can ask for a publication at your specific date, for example at your planned release date.

  • See it publicly: The advisory becomes public, so is the CVE entry.

  • (Optional, a few days later) Update the entry with all additional information that might be helpful. That includes, for example, the link to the fix commit.

Required Information

For all types of request, the project needs to prepare information about the vulnerability.

The request for a publication 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, a link to the commit fixing the issue etc.

Example CVE Report data
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://gitlab.eclipse.org/eclipse/myproject/-/issues/12345

If unsure on how to fill the form, ask the Eclipse Foundation Security Team for assistance.

Frequently Asked Questions

  1. 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 minimal disclosure. Whether or not you should do more is a project team decision. If you need help with that decision, connect with your Project Management Committee (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.

  2. 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 and prepare a bugfix release.

    Whether or not we disclose in advance of making the fix available is a judgement call. Many projects notify of a date of an imminent security bugfix release in advance, without releasing the details. Users can then plan their update. When there is a real risk that somebody may exploit the vulnerability, you generally want to inform your adopters as quickly 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 Security Team and we’ll help. Very few projects actually need to go to this extreme.

  3. 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. Especially avoid expressions like vulnerability or using a reserved CVE number.

  4. 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 Foundation 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. If in doubt, ask the Eclipse Foundation Security Team for guidance.

  5. 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.

  6. I think that my project hasn’t received all notifications about security issues?

    In this case, please contact the Security Team. Please note that the Eclipse Foundation Security Team notifies project leads by default.

  7. I can’t see a confidential issue in the Eclipse Foundation GitLab instance

    If you have received a notification of a confidential issue by email, make sure to log in to the Eclipse Foundation instance of GitLab first, before following the link. Otherwise you will get a 404 error page.

    If you are following a link, verify with the person managing the issue (for example the reporter) if you have been added to the issue. Currently, in the general issue tracker, each person needs to be added manually. In case of difficulties, ask the Eclipse Foundation Security team for assistance.

    Also please note that we need an activated GitLab account to add a user to a confidential issue. In practice, the user needs to log in into the Eclipse Foundation GitLab instance at least once.

  8. Confidential issues are not visible to all committers

    Currently, in the general issue tracker, each person needs to be added manually. In case of difficulties, ask the Eclipse Foundation Security team for assistance.

  9. I can see .eclipsefdn repository in my project. What is this?

    This repository is used to keep project management data. See the related documentation or ask the Eclipse Foundation staff for help.

Contributing to an Eclipse Project

Contributors

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:

  1. Create an Eclipse Foundation Account;

  2. Sign the Eclipse Contributor Agreement;

  3. Read the project’s contribution guide to learn about coding style and other guidelines for contributions (contribution guidelines are typically found a CONTRIBUTING or README file in the root of every source code repository);

  4. Create a commit:

    • Ensure that the author credentials on the commit record match the email address associated with their Eclipse Foundation Account

  5. Create a pull request (GitHub), merge request (GitLab), or submit a review (Gerrit); and

  6. 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.

contributor contributors
Becoming a contributor
Note

Eclipse committers must engage with the EMO Intellectual Property Team to review your project code contributions, or third-party content that your contributions leverage. The committers will take are of this, but may need your help as part of the process.

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.

Note

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).

Committers

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.

Note

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 Account

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

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

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

Tip

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.

Employed by a Member Company

If you are employed by an Eclipse Foundation Member Company when you create your Eclipse Foundation Account, you must align your account with your employer.

In the field where it asks "What is your employment status?":

  • Highlight "Work for an Eclipse Member Organisation"; and

  • Pick your employer from the list.

organization selection
Specify that you work for a member organisation.
Tip

Specifying your employer information in this manner will ensure that your contributions can be traced back to your employer and we can, for example, correctly display company logos based on your contributions. This will also ensure that you are automatically covered by the ECA in the case where your employer has already signed the agreement on behalf of their employees.

If your employer is not listed and you believe that this is an error, contact EMO for assistance.

If you change employers, contact the EMO Records Team to request that they update your employment status information.

Eclipse Contributor Agreement

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.

Tip

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.

Frequently Asked Questions

  1. 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 CONTRIBUTING file).

    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.

  2. 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.

  3. 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).

    accounts status
  4. 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.

    eca validation tool
  5. 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.

  6. 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.

  7. 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.

  8. 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.

Elections

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.

Note

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.

Committer Elections

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

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

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

What are the Requirements?

There are only three requirements around nominating and electing new committers (note that there are additional committer paperwork requirements for the new committer):

  • Define trust;

  • 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 judgement". This definition must be consistent with the top-level project charter, and must be transparent and public document on the project’s website. 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; there are 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.

Note

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.

What Should a Nomination Look Like?

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.

How does an Election work?

Use the Committer Tools  Nominate a Committer link on the corresponding project page and follow the workflow to start a committer election.

committer election2
The New Committer Nomination Form

Project committers will be notified to participate in the election via the project’s dev-list.

Note

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.

elections overview
An overview of the Election Process

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 +1.

Tip

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 Project Management Committee (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.

Project Lead Elections

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.

Example 1. Project Lead merit statement

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:

https://github.com/eclipse/dash-licenses/commits?author=RobertSmith

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:

https://thecure.com/dash

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

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

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

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

PMC Member Elections

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

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

Tip

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 Lead Appointments

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

Committer Retirement

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.

Tip

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.

elections retire self

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.

Note

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.

Project Lead Retirement

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

Tip

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.

elections retire pl

Retiring Other Roles

Connect with the PMC or EMO for assistance.

Troubleshooting

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

Tip

If you believe that a project is in a dysfunctional state, contact the PMC via their mailing list to request assistance.

Frequently Asked Questions

  1. Do we really need to do this?

    Yes.

  2. 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.

  3. 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.

  4. 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, can return to the election record and change their vote.

    Committers can also add information via the comment that accompanies their vote on an election.

  5. Can a committer change their vote on an election?

    Yes. A committer can change their vote while an election is still in progress.

  6. 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.

  7. 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.

Committer Paperwork

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.

Committer Questionnaire

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.

committer questionnaire
The Committer Agreement Workflow starts by asking for employment status.

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.

Note

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".

Documents

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.

paperwork
What 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.

committer questionnaire2
Upload the ICA directly into the form

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.

Member Committer and Contributor Agreement

The Member Committer and Contributor Agreement (MCCA) is used by organisations that are members of the Eclipse Foundation to cover all of their employees who participate in Eclipse Foundation projects as committers.

Note

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.

Individual Committer Agreement

The Individual Committer Agreement (ICA) is used by committers who are not covered by a MCCA.

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.

Existing Committer

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.

Not Employed or Student

If the committer is not employed or is a student, they must send a note to the EMO Records Team explaining their status.

Frequently Asked Questions

  1. 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 organisations 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.

  2. 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.

  3. 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 license@eclipse-foundation.org.

  4. 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).

  5. What Email address should I use to send completed documents?

    emo-records@eclipse-foundation.org

  6. What if a I change employers?

    Edit your Eclipse Account Profile to update your employment status.

Specifications

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 behaviour, 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.

Note

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.

Specification Project Reviews

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

spec release review
Release review work flow

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 supermajority approval from the corresponding working group’s specification committee.

Note

Individual working groups may have additional requirements for some life cycle events, and guidance for engaging in working group-specific processes. Those additional requirements will be captured and disseminated by the working group.

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

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

Tip

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 socialise plans and expectations. You must get supermajority 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.

Intellectual Property Flow

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

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

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

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

Participant Representative Committers

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

Tip

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 organisation’s specification committee representative may send a note to EMO with a request to appoint a participant representative.

Contributors

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.

specification contributors
How to become a contributor

To become a contributor, an individual must:

  1. Create an Eclipse Foundation account;

  2. Sign the Eclipse Contributor Agreement (ECA);

  3. Contribute! (submit a pull request)

Note

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 the EMO Records Team for assistance.

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

Committers

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.

Tip

In order to get committer rights on project repositories hosted on GitHub, you need to set your GitHub Id in your Eclipse Foundation account.

Specification Development Agreements

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.

Note

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:

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:

A committer who works for an Eclipse Foundation Member that is a working group participant needs:

  • No additional agreements are required.

Note

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.

Working Group Participation Agreement

A Working Group Participation Agreement (WGPA) is signed by an organisation that wishes to participate in a particular working group. By signing the Working Group Participation Agreement (WGPA), an organisation 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 organisation 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 organisation 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 organisation signing the WGPA.

Individual Working Group Participation Agreement

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.

Eclipse Foundation Specification License

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.

Specification Project Life Cycle

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.

specifications life cycle
An overview of the Eclipse Foundation Specification Process

Specification Committee

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 life cycle 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.

Specification Committee Ballots

The specification committee is required to engage in a formal ballot to approve key milestones in the life cycle of their specification projects. The exact means by which ballots are run varies by working group. The following life cycle events require the approval of the working group’s specification committee:

  • Specification project creation;

  • Release plan;

  • 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 supermajority (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 supermajority 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 organisation 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 Review

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 supermajority ballot of the entire specification committee is required to approve a creation review.

Tip

Contact the EMO to initiate a creation review.

Following successful creation and provisioning of project resources, a specification project team begins development.

Specification 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.

Warning

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.

A development cycle begins when a either a creation review or a plan review is declared successful. A specification project team must engage in a progress review when a development cycle exceeds one year in duration.

Progress Review

For a progress review, the Project Management Committee (PMC) and Eclipse Management Organisation (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 supermajority ballot.

Note

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.

Release Review

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 supermajority ballot.

Tip

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.

Plan 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 supermajority 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.

Tip

To engage in a plan review, create a release record and contact the EMO to schedule a review.

After the Plan is approved, the Project Team engages in Development as before.

Final Specification

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).

Compatible Implementations

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.

Frequently Asked Questions

  1. 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 README files 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:

    specification project
  2. 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.

  3. Can the specification committee block/veto a release?

    Yes. The specification committee’s supermajority 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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).

    accounts status
  8. 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.

  9. 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.

  10. 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.

  11. 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.

Intellectual Property

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 identify issues and mitigate the risk of leveraging the work of others. IP due diligence is a time consuming process that requires specialised skills and a keen eye for detail.

Warning

The Eclipse Foundation’s IP Team does not (and cannot) give legal advice. Rather, the team leverages their experience, along with various resources, to identify licenses in content, and make judgement calls as to whether or not licenses be being used in a consistent and compatible manner.

There are different kinds of content (e.g., source code, documentation, and images) to consider. For the purposes of the Eclipse Foundation’s IP Due Diligence Process, we consider all types of content, not just code, to be intellectual property that is subject to the process (even when we say code--especially in the context of IP due diligence—​you should assume that we mean content).

Project content is content (typically source code) that is produced and maintained by the open source project committers and contributors. 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.

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.

Warning

If you’ve been around for a while, you may be looking for things that no longer exist. We’ve retired IPZilla along with the term Contribution Questionnaire, we’re now able to leverage a wider variety of open source licenses, and we lean much more heavily on automation than ever before. There’s more information about these changes in the History section of this chapter.

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 images or 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. Project teams should organise content in their source code 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.

Note

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 their content before it is fully vetted by the IP Due Diligence Process, but all content must be fully vetted before the project can engage in a formal release.

The means for committers to engage in the IP Due Diligence Process is by creating a review request issue.

Eclipse Foundation IP Team

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.

Eclipse Dash License Database

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

IPLab

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.

Data collected in IPLab is used as a source for the Eclipse Dash License Database.

ClearlyDefined

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

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

ClearlyDefined Identifiers

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 groupid, artifactid, and 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., @babel/generator@7.62).

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 namespace and name, and version/revision. 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 @babel/generator@7.62 maps to npm/npmjs/@babel/generator/7.6.2.

Using ClearlyDefined

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.

Tip

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 (use the Eclipse Dash License Tool):

  • NOASSERTION appearing as a declared license;

  • NOASSERTION appearing as a discovered license;

  • No declared license; or

  • A License score of less than 60.

Initial Contribution

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

Warning

All Eclipse open source project content must be kept in source code repositories that are managed by the Eclipse Foundation IT Team. Our current options are GitLab or GitHub.

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

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

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

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

Note

We must complete the open source project creation process before we move any existing source code repositories or create new ones. Following a successful Creation Review, the EMO will initiate the provisioning process. It is during the provisioning process that we activate project committers, move/create source code repositories, and create other project resources.

The short version of the process is this:

  • Complete the proposal process and creation review;

  • Project team and EMO works with Eclipse Foundation IT Team to set up source code repositories;

  • The EMO initiates the intellectual property review of the default branch of all repositories; and

  • The EMO IP Team will inform the EMO when the reviews are complete

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

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

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

Project Content

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).

When the contributor has signed the Eclipse Contributor Agreement (ECA) and the following conditions are met, further investigation 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 engage with the IP Team to request review by the IP Team before the contribution is pushed/merged.

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

Copyright

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).

Tip

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 to request assistance.

Third Party Content

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

This includes (for example):

  • References in a Java®/OSGi manifest that makes a direct reference to third party content (either a bundle or package);

  • Imports of packages in Java source;

  • Includes of header files in C/C++;

  • References to NPM modules via a package.json, package-lock.json, or yarn.lock file;

  • References to Go modules via a go.sum file;

  • Entries in the dependencies section of a Maven pom.xml file;

  • Use of reflection or other means to reference APIs and implementation;

  • Use of OSGi Services to make a reference to a specific implementation of a service; and

  • Invocation of a command line interface.

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

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

prereq dependencies
Eclipse Project Dependencies

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

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

For example:

  • For a Java-based application, the Java runtime would be the platform;

  • For an application based on Jakarta EE technology, the application server would be the platform;

  • For an NPM application, node would be the platform; and

  • For a native application, a Linux based operating system, Windows, or MacOS would be the platform.

This is list is not exhaustive.

Note

We regard the platform as something that the adopter installs and agrees to the licensing terms independently from the project content. If you’re bundling the platform with your project’s binaries, for example, then the platform is a dependency. If a layer of software is installed as part of installing your project’s artifacts (e.g., via Maven), then that layer of software is a dependency.

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

Maven Example

The following snippet from a Maven pom.xml file includes a single dependency that itself has dependencies.

Snippet from an example Maven pom.xml file
...
<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).

Dependency graph generated by Maven
$ 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.

mvn example dependencies
Visualisation of the dependency graph (the Maven type and scope have been removed for brevity)

In this example, commons-httpclient:commons-httpclient:3.1, commons-logging:commons-logging:1.0.4, and commons-codec:commons-codec:1.2 must all be vetted for license compatibility.

Versions of Dependencies

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.

Test and Build Dependencies

Warning

This section 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).

If you have any questions or concerns, please contact EMO.

License Compatibility

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

Warning

Our goal is to provide as much information as possible so that, ultimately, the adopters of Eclipse project code (with assistance from their own legal counsel) can decide whether or not licenses are consistent and compatible.

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

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

When in doubt, check with the EMO IP Team.

Requesting a Review

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

Note

Note that the Eclipse Dash License Tool is only capable of creating issues for content that it either discovers from your build or that you feed to it. It will not, for example, find third party content that is buried in your code. If you’ve, for example, added some JavaScript library in a lib directory or similar, then you may have to manually create a request to vet that content and manually track your project’s use of that library.

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

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

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

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

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

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

Instructions

Set the title to a valid ClearlyDefined id

Set the title of the issue to the ClearlyDefined id, type/source/namespace/name/version for the content. If you’re not sure, do your best and the IP Team will assist.

e.g., maven/mavencentral/org.apache.maven.enforcer/enforcer-api/3.1.0

Issues that have a valid ClearlyDefined identifier for a title and source pointer (see below) will be automatically processed and so will likely be resolved quickly.

Identify the Eclipse open source project

We need you to identify the Eclipse open source project that is accepting this contribution. Note that we need you to specify an Eclipse open source project, not a GitLab or GitHub project (provide that in the Git repository field).

In the template replace <project name> with the name of your Eclipse project (e.g., Eclipse Dash) and <project id> with the project’s id (e.g., technology.dash):

Project: [Eclipse Dash](https://projects.eclipse.org/projects/technology.dash)

Provide Basic Information

In the Basic Information section, provide as much information as you can, including the license of the content as you understand it as an SPDX identifier, and URLs that points to the binary and sources of the content.

Provide a Pointer to Source

The Source field is the important one. The scanner looks for content of the form:

[Source](<url>)

We need pointers to specific versions of content, ideally in an archive format (e.g. a ZIP file). That is, please do not provide a pointer to a repository on GitHub; rather, provide a pointer to a specific downloadable ZIP archive associated with the particular release.

For example:

[Source](https://github.com/kataras/iris/archive/refs/tags/v12.1.8.zip)

Note

We need to have a source pointer. If you cannot (or do not) provide it, processing will be delayed while we hunt it down.

The source must be one of the following:

  • A URL pointing to an archive (e.g., .zip, .tar.gz)

  • An attachment;

  • The URL for an Eclipse GitLab merge request (e.g., https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/merge_requests/1); or

  • The URL for a GitHub pull request, (e.g. https://github.com/eclipse/dash-licenses/pull/278).

Provide additional Information

Please provide any additional information that you think might be useful to assist the IP Team in resolving this issue in free form text after the basic information.

Don’t Apply Any Labels

The scanner will only automatically scan issues under the following conditions:

  1. The issue is open;

  2. The issue has a valid ClearlyDefined id; and

  3. The issue either has no labels or has the Review Needed label applied.

Issues that do not meet these criteria are ignored.

Scanning Attachments

If you’re only pulling in a subset of the source code and have the means to bundle that up into a ZIP file, you can use that ZIP file as an attachment.

When you drop an attachment on the GitLab issue, you’ll see something like this in the text:

[built-in-extensions-1.64.2.tar.gz](/uploads/9d97a24028eb76fab91a139945d1e005/built-in-extensions-1.64.2.tar.gz)

The scanner will know what to do if you change it to:

[Source](/uploads/9d97a24028eb76fab91a139945d1e005/built-in-extensions-1.64.2.tar.gz)

FWIW, it also handles the case when just drop the attachment as the URL (this is not supported by Markdown, so it may not render as expected, but the tool can deal with it):

[Source]([built-in-extensions-1.64.2.tar.gz](/uploads/9d97a24028eb76fab91a139945d1e005/built-in-extensions-1.64.2.tar.gz))

Eclipse Dash License Tool

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.

Warning

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 Dash Database;

    • if an entry has been vetted by the IP Team and has been approved for use, then it is marked as approved;

    • if an entry has been vetted by the IP Team and flagged as somehow problematic, it will be marked as restricted

  • it then sends the content that has not already been flagged as either approved or restricted to ClearlyDefined

    • ClearlyDefined matches are marked as approved;

  • Everything else is marked restricted.

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

Maven Plugin

An Maven plugin is provided that can be used by project teams that leverage Maven pom.xml files for build.

licenseTool mvn
The Eclipse Dash License Tool’s Maven plugin in action

Command-line Interface

A CLI interface is also provided. For many build technologies, it is relatively easy to generate lists of dependencies directly (e.g., the Maven Dependencies plugin). There are some specific examples in the Eclipse Dash License Tool’s README (e.g., Gradle-, NPM-, and Yarn-based systems). Project teams that use technologies that do not provide easily parsed/converted dependency lists can manually generate a list and feed that to the tool.

Automatic IP Team Review Requests

The Eclipse Dash License Tool can create issue against IPLab for content that any content that the tool determines requires further review by the IP Team.

To use this feature, you must:

  • have committer status on an Eclipse project; and

  • get an authentication token (scope: api) from gitlab.eclipse.org;

When using the command-line version of the tool:

  • include the -review option;

  • pass the token via the -token option; and

  • pass the project id via the -project option.

When using the Maven plugin:

  • pass the token via the -Ddash.iplab.token=<token> option; and

  • pass the project id via the -Ddash.projectId=<project> option.

For example:

$ mvn org.eclipse.dash:license-tool-plugin:license-check -Ddash.projectId=technology.dash -Ddash.iplab.token=...
Warning

Do not share your access token.

Software Bill of Materials

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

Warning

IP Logs are no longer required in the form previously described in this document. The IP Log Generator has been deprecated and will be retired.

This section is under construction.

Eclipse open source projects are required to maintain a software bill of materials (SBOM). "About" files (about.html) serve this purpose in Eclipse Platform plug-ins, and NOTICE files or summary files generated using the Eclipse Dash License Tool serve as SBOMs. In the future, the EMO will work with projects to leverage standard SBOM formats such as SPDX or CycloneDX.

Tip

Please ensure that any merge/pull requests that come to you project correctly identify the contributor and that the contributor is covered by the Eclipse Contributor Agreement. Further, ensure that your project’s third party content is accounted for in either a notice file (consider using the summary output from the Eclipse Dash License Tool to generate this).

Changes in the IP Policy

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

2022

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

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

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

Note

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

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

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

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

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

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

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

2019

The 2019 update to the Eclipse Foundation’s IP Policy, approved by the Board of Directors in October 2019, makes the following changes:

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 Dash Database and ClearlyDefined. The Dash Database has been painstakingly built over most of the life span 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 HEAD state of the existing repository (if any).

The due diligence process for project content is unchanged.

Frequently Asked Questions

  1. Can third party content be included in an Eclipse project’s source code repository?

    Yes. Third party content can be included in binary form (e.g. source and binary JAR files) in a project’s source code repository if that makes technical sense for the project.

    Third party content that is stored in the project repository as source code is effectively a fork of that third party content. This is a bit of a grey area in that it is third party content that will be ultimately treated as project content (i.e. contributors may potentially modify it).

    Third party source code must be reviewed by the IP Team (that is, open a Content Review Request) before it may be included in a project repository.

  2. The IP Due Diligence Process says that I need to request a review for project content contributions that exceed 1,000 lines of code; how do I calculate lines of code?

    The short version is that the Eclipse Foundation trusts the judgement of Eclipse committers regarding how lines of code should be calculated. What we’re interested in is net new intellectual property. With this in mind, it’s not generally correct to just add the number of lines added to the lines removed; it’s also not generally correct to use the difference of these numbers to determine the true number of lines in a contribution. Again, as a committer we trust your judgement.

    If a contribution contains significant new functionality, or if you are not certain of the provenance or are otherwise concerned that there may be intellectual property issues with a contribution (of any size), then the IP Team needs to be engaged.

    If you’re not sure, create a Content Review Request.

  3. Can my release use unreleased content from another Eclipse open source project?

    No. A release may only use released content from other projects. A project may disseminate milestone builds that include unreleased content, but the upstream content must be released before a downstream project can include the content in their own release.

  4. Are project websites subject to the IP Due Diligence Process?

    Website content is separate from project content. Project teams are expected to respect licenses for all web site content, but are not required to submit website content (including third party libraries) for review by the IP Team.

  5. What is "Type A" and "Type B" due diligence?

    Versions of the Eclipse Foundation’s Intellectual Property Policy prior to October 2019 referred to two different types of intellectual property due diligence, named Type A and Type B. Project teams were able to choose the type of IP due diligence that they wanted for their project: Type A which was concerned with validating that the licenses of the content were compatible with the project license, and Type B which offered a more thorough check including provenance and other deep analysis. We phased out Type B in October 2019, and now focus solely on license compatibility for third party content.

  6. What is Parallel IP?

    The parallel IP Process allows an Eclipse projects to make use of project code contributions and third party content before they are fully approved by the IP Team. In versions of the IP Policy prior to 2019, projects needed to meet specific requirements to be able to leverage the Parallel IP. This is no longer the case: full vetting is now always applied in parallel in all cases.

  7. Do I have to use the Eclipse Dash License Tool?

    No. The Eclipse Dash License Tool is provided as a convenience. It works with a variety of technologies, but not all.

  8. Can I count on the Eclipse Dash License Tool to detect all of my third party dependencies?

    No. In fact, the Eclipse Dash License Tool doesn’t actually detect any dependencies. The Maven plugin uses the dependency resolution mechanism that is built into Maven, so the Maven plugin only knows what Maven knows. If your Maven-based build does funky things like grab code from random URLs, the tool won’t detect that. For other technologies, the command-line version of the Dash License Tool only knows about the dependencies that you send to it.

  9. What happened to IPZilla and Contribution Questionnaires (CQs)?

    IPZilla was retired in 2022 and replaced with IPLab. We’re all taking steps to purge the term CQ from our brains.

Legal Documentation Requirements

The content developed and maintained by Eclipse Foundation open source projects is distributed via multiple channels, including distributed source code management systems, download servers, and software repositories. Further, open source project content is — by design — integrated into and distributed as part of the products of adopters. The legal obligations of the content must be observed in all forms of which the content is available.

Where possible we adopt standards and conventions in order to be good open source citizens. We use the Software Package Data Exchange® (SPDX®) specification for communicating the licenses associated with software packages.

Note

This document describes a set of general guidelines for legal documentation. Projects that implement Eclipse Platform Plug-ins and Features under the EPL-2.0 should follow the Legal Documentation for Eclipse Platform Plug-ins and Features.

Projects that implement Eclipse Platform Plug-ins and Features under the EPL-1.0 should follow the Guide to the Legal Documentation for Eclipse Plug-ins and Features under the EPL-1.0.

Source Code Repositories

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

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

../project.git
 ├── CODE_OF_CONDUCT.md
 ├── CONTRIBUTING.md
 ├── LICENSE.md
 ├── NOTICE.md
 ├── README.md
 └── ...

Distribution

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

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

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

MyFile.jar
 ├── META-INF
 │   ├── NOTICE
 │   └── LICENSE
 └── ...
Note

This structure need not necessarily be reflected in the source tree. How a project’s build process includes this information is determined by the project team.

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

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

End User Content

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

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

Example website notices

All material on this website is Copyright (c) 2017, Contributors to the Eclipse Foundation

Eclipse Dash and the Eclipse Dash project logo are trademarks of the Eclipse Foundation. Eclipse and the Eclipse logo are registered trademarks of The Eclipse Foundation.

Java and all Java-based trademarks are trademarks of Oracle Corporation in the United States, other countries, or both.

Content may contain encryption software. The country in which you are currently may have restrictions on the import, possession, and use, and/or re-export to another country, of encryption software. BEFORE using any encryption software, please check the country’s laws, regulations and policies concerning the import, possession, or use, and re-export of encryption software, to see if this is permitted.

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

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

Note

An Eclipse Foundation open source project is not a legal entity. Further, the Eclipse Foundation does not assume ownership of contributions (the Eclipse Foundation is only a copyright holder in those cases where an employee of the Eclipse Foundation has authored the contribution).

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

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

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

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

Eclipse Public License 2.0 Copyright and License Header template
/********************************************************************************
 * Copyright (c) {year} {owner}[ and others] 1
 *
 * This program and the accompanying materials are made available under the 2
 * terms of the Eclipse Public License 2.0 which is available at
 * http://www.eclipse.org/legal/epl-2.0.
 *
 * SPDX-License-Identifier: EPL-2.0 3
 *
 * Contributors: 4
 *   {name} - initial API and implementation
 ********************************************************************************/
1 Name of the initial copyright owner (this must be a legal entity); other organisations that have contributed are either listed individually or grouped together by appending "and others". The {year} is the year of the initial creation.
2 Declared project licenses described in human readable form.
3 Declared project licenses indicated using SPDX codes and expressions.
4 The names of the contributors and the nature of their contribution (this section may be excluded).

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

Note

Older versions of this template included the sentence "All rights reserved." It is not wrong for this sentence to be included in the header; it is just not necessary. File headers that include this sentence do not need to be changed.

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

Alternative Eclipse Public License 2.0 Copyright and License Header template
/********************************************************************************
 * Copyright (c) {year} Contributors to the Eclipse Foundation 1
 *
 * See the NOTICE file(s) distributed with this work for additional 2
 * information regarding copyright ownership.
 *
 * This program and the accompanying materials are made available under the 3
 * terms of the Eclipse Public License 2.0 which is available at
 * http://www.eclipse.org/legal/epl-2.0
 *
 * SPDX-License-Identifier: EPL-2.0 4
 ********************************************************************************/
1 The {year} is the year of the initial creation
2 Statement that indicates where the actual copyright information is located.
3 Declared project licenses described in human readable form.
4 Declared project licenses indicated using SPDX codes and expressions.
Note

The border, line breaks, etc. are not mandated in either form.

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

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

Example Copyright and License Header for Dual-licensed Content
/********************************************************************************
 * Copyright (c) {year} {owner}[ and others]
 *
 * This program and the accompanying materials are made available under the
 * terms of the Eclipse Public License 2.0 which is available at
 * http://www.eclipse.org/legal/epl-2.0, or the Apache Software License 2.0
 * which is available at https://www.apache.org/licenses/LICENSE-2.0.
 *
 * SPDX-License-Identifier: EPL-2.0 OR Apache-2.0
 ********************************************************************************/

License File

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

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

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

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

Example License File (dual-licensed EPL-2.0 or Apache-2.0).
This program and the accompanying materials are made available under the
terms of the Eclipse Public License 2.0 which is available at
http://www.eclipse.org/legal/epl-2.0, or the Apache Software License
2.0 which is available at https://www.apache.org/licenses/LICENSE-2.0.

... Text of the Eclipse Public License 2.0 ...

... Text of the Apache Software License 2.0 ...

Notice Files

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

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

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

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

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

Cryptography Statement

Content may contain encryption software. The country in which you are currently may have restrictions on the import, possession, and use, and/or re-export to another country, of encryption software. BEFORE using any encryption software, please check the country’s laws, regulations and policies concerning the import, possession, or use, and re-export of encryption software, to see if this is permitted.

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

Example NOTICE.md file
# Notices for Dash, Tools for Committers

This content is produced and maintained by the Eclipse Dash, Tools for
Committers project.

 * Project home: https://projects.eclipse.org/projects/technology.dash

## Trademarks

Eclipse Dash, Tools for Committers, and Dash, Tools for Committers are
trademarks of the Eclipse Foundation. Eclipse, and the Eclipse Logo are
registered trademarks of the Eclipse Foundation.

## Copyright

All content is the property of the respective authors or their employers.
For more information regarding authorship of content, please consult the
listed source code repository logs.

## Declared Project Licenses

This program and the accompanying materials are made available under the terms
of the Eclipse Public License v. 1.0 which is available at
http://www.eclipse.org/legal/epl-v10.html.

SPDX-License-Identifier: EPL-1.0

## Source Code

The project maintains the following source code repositories:

 * http://git.eclipse.org/c/dash/org.eclipse.dash.dashboard.git
 * http://git.eclipse.org/c/dash/org.eclipse.dash.handbook.git
 * http://git.eclipse.org/c/dash/org.eclipse.dash.m4e.tools.git
 * http://git.eclipse.org/c/dash/org.eclipse.dash.maven.git
 * http://git.eclipse.org/c/dash/org.eclipse.dash.repositories.git
 * http://git.eclipse.org/c/dash/org.eclipse.dash.test.git

## Third-party Content

ckeditor (3.0.1)

 * License: MPL 1.1, BSD
 * Project: http://ckeditor.com/
 * Source: http://ckeditor.com/download

commons-codec-1.3.jar (1.3)

 * License: Apache License, 2.0

commons-net (3.3)

 * License: Apache License, 2.0

commons-vfs2 (2.1)

 * License: Apache License, 2.0

Google Gson (2.2.4)

 * License: Apache License, 2.0

Google Guava (19.0)

 * License: Apache License, 2.0

Services_JSON (1.31)

 * License: Modified BSD
 * Project: http://pear.php.net/pepr/pepr-proposal-show.php?id=198
 * Source: http://mike.teczno.com/JSON/

Yahoo YUI (2.3.1)

 * License: New BSD license

YUI (2.6.0)

 * License: New BSD license

## Cryptography

Content may contain encryption software. The country in which you are currently
may have restrictions on the import, possession, and use, and/or re-export to
another country, of encryption software. BEFORE using any encryption software,
please check the country's laws, regulations and policies concerning the import,
possession, or use, and re-export of encryption software, to see if this is
permitted.
Note

The actual text of the project’s declared licenses should not be included in the notice file (they are provided in the license file). The terms of the other licenses included in the content, including third-party licenses, must be observed (e.g. some licenses require that the text of the license be included with the distribution; in this case, position the license text either in the notice file or as close to the corresponding content as possible).

Contributor Guide

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

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

Minimally, the CONTRIBUTING file should include:

  • The name and brief description of the project;

  • A link to the project’s website and documentation;

  • A pointer to the Eclipse Foundation’s Terms of Use (https://www.eclipse.org/legal/termsofuse.php);

  • A link to the primary Communication channel (how do potential contributors contact the project team?);

  • A pointer to the canonical source code repositories;

  • Mechanics of how to actually contribute (e.g., merge/pull requests);

  • Link to sign the ECA (https://www.eclipse.org/legal/ECA.php)

Additionally, the guide might include:

  • Link to downloads; and

  • Link to a more comprehensive project contribution guide (e.g. a website).

Setting up the Development Environment

The CONTRIBUTING file should make it easy for people who got interested in the project to start working with it. It should include:

  • Instructions for obtaining the sources;

  • Clear instructions for setting up any additional tools needed for the development;

  • A description of the dependencies of the project, or even better how to easily get all the necessary content the project depends on; and

  • A list of necessary steps to build the artifacts of the project (e.g. bundles, features, stand-alone products).

Contributing Code

The CONTRIBUTING file should make it very clear what are the steps a contributor needs to follow, so that their contribution reaches the project and may be accepted.

It should:

  • Include very specific instructions on how contributions are accepted;

  • Describe how to submit contributions (GitHub pull requests, GitLab merge requests, or Gerrit reviews), along with the necessary steps to have the project accept those requests;

  • Describe the legal part of the process for accepting contributions, e.g. point to the the Eclipse Contributor Agreement (ECA) and Developer Certificate of Origin (DCO); and

  • Describe any project specific rules, which the contributors should know, for example:

    • preferences on code quality;

    • code formatting; and

    • processes for code review.

Projects may slightly different rules for contributing to different repositories. Make this clear to the contributors.

Help Wanted

The CONTRIBUTING file can optionally provide guidance for developers who want to help, but don’t have their own agenda. To help these developers, the guide may list ideas for improvements which the team already knows, or areas where help is needed.

Note

Keeping a help-wanted list up-to-date can be challenging. Consider including a query (e.g. for helpwanted issues) rather than (or in addition to) specific work area recommendations.

SECURITY File

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

It should:

  • Provide a pointer to the Eclipse Foundation’s Vulnerability Reporting landing page;

  • Describe supported versions (with regard to security patches); and

  • Provide a communication channel for reporting vulnerabilities.

Example SECURITY.md file
# Security Policy

This project implements the Eclipse Foundation Security Policy

* https://www.eclipse.org/security

## Supported Versions

These versions of Eclipse Dash are currently being supported with security
updates.

| Version      | Released   | Supported          |
| ------------ | ---------- | ------------------ |
| 1.0 Handbook | 2021-10-06 | Yes                |

## Reporting a Vulnerability

Please report vulnerabilities to the Eclipse Foundation Security Team at
security@eclipse.org

Community Code of Conduct

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

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

Frequently Asked Questions

  1. How do file headers change when content is refactored?

    When you split a file during a refactoring exercise, any new files that you create must automatically inherit the header of the original. If even fragment of text from a single line of the original content survives the refactoring (whether generated, rote, or otherwise), then the original copyright statement and author information should be retained.

    Even a refactoring exercise that does not change behaviour, may add intellectual property. When refactoring adds content, copyright statements should be updated to reflect the addition. In concrete terms, you can either add the new copyright holders to the existing copyright statement or append "and others" (especially when the list of copyright holders gets long).

  2. Do we need to specify a range of years in the copyright statement?

    No. In the past, legal advice was that the year of the initial creation of the content and the year of the last change should be reflected in the copyright header. This is no longer the case. Specify the year that the content was initially created in the copyright statement.

  3. Do I need to update the year in the copyright statement when I make changes to the file?

    No. The year in the copyright header should be the year that the content was created.

  4. How does the copyright header change when we accept a change to an existing file?

    You have some options.

    If the current copyright statement indicates copyright of a single entity, and the contribution comes from a different entity, then you can generally append "and others" to the existing copyright statement.

    /********************************************************************************
     * Copyright (c) 2007 Milo Bloom and others
     *
     ...

    Or, you can add a separate line for the new copyright holder (with the year of the new contribution).

    /********************************************************************************
     * Copyright (c) 2007 Milo Bloom
     * Copyright (c) 2023 Mike Binkley
     *
     ...

    Both options are acceptable, so you can pick whichever works best for the situation.

  5. Do the license and notice files need to be named LICENSE and NOTICE?

    No. If there are technical limitations, for example, that require that you select different names, you can do so. But for the sake of consistency for our communities we prefer that this convention be followed. Format-specific file extensions (e.g. .md as in NOTICE.md) can be used.

  6. Can the license and notice files use Markdown?

    Yes. Any human-readable markup format may be used.

  7. Is the cryptography statement required?

    The cryptography statement is only required if the project code includes cryptography algorithms or other cryptographic content.

  8. What licenses should be listed in a build script (e.g. Maven pom.xml file)?

    The license(s) in the build should reflect what is being built, but typically not the license(s) of referenced third-party content. The pom.xml file for project code, for example, should list the project license(s).

  9. In a multiple license scenario, do we use conjunction (AND) or disjunction (OR)?

    We follow the lead of the SPDX community with regard to the way in which we express the combination of licenses, and use inclusive disjunction. In the example of a dual licensing scenario, we make the content available under the terms of licenses A AND B, but the consumer accepts it under the terms of license A OR B or both. Think of it from the perspective of the consumer.

  10. How do I get help?

    If you have any questions or concerns, contact license@eclipse-foundation.org.

Legal Documentation for Eclipse Platform Plug-ins and Fragments

Eclipse Platform Plug-ins and Fragments are highly modularised to facilitate ease of delivery, extensibility, and upgradeability. A typical Eclipse Platform-based product may potentially include plug-ins and features authored and/or distributed by many different parties including Eclipse Foundation open source projects, other open-source organisations, and commercial vendors.

Software User Agreement

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

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

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

Note

You will also often see on many of the download pages at Eclipse.org, text that says: "All downloads are provided under the terms and conditions of the Eclipse Foundation Software User Agreement unless otherwise specified."

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

Plug-ins and About Files

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

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

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

Note

All plug-ins and fragments should contain an About file. All Eclipse project plug-ins and fragments must contain either one of the default Abouts or a special About written and/or approved by the Eclipse Foundation. In JAR’ed plug-ins, any local files linked from the About such as copies of licenses, must be located in a directory called about_files.

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

Example file layout
eclipse
 ├── LICENSE - Text of the project license(s)
 ├── plugins
 │   ├── org.eclipse.core.runtime_3.13.0.v20170207-1030.jar - Plug-in packaged as a JAR
 │   │   ├── about.html - Standard _About_ file
 │   │   └── ...
 │   ├──org.apache.ant_1.10.1.v20170504-0840 - Third-party content packaged as a directory
 │   │   ├── about.html
 │   │   ├── about_files - Licenses and notices related to the content
 │   │   │   ├── DOM-LICENSE.html
 │   │   │   ├── LICENSE
 │   │   │   ├── NOTICE
 │   │   │   ├── SAX-LICENSE.html
 │   │   │   └── APACHE-2.0.txt
 │   │   └── ...
 │   └── ...
 └── ...

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

The Abouts Checklist

  • Every plug-in has an about.html, usually the standard one;

  • Every plug-in with a non-standard about.html contains the additional referenced license files; and

  • Every JAR’ed plug-in stores linked files in about_files.

About plugins dialog

Features Licenses and Feature Update Licenses

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

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

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

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

Note

The difference between the Feature License and Feature Update License is when they are shown to the user. The Feature License is only available once a feature has been installed. The Feature Update License is seen when a user is using the Install Dialog to install or upgrade a feature and must agree to an agreement before proceeding with the installation.

One thing that is important to note is that with the distributed licensing model used by plug-ins, unless a Feature Update License contains an aggregation of all the notices from the plug-ins for a feature, a user will not be able to see these notices before installing the feature. It is for this reason that the maintainer of a feature may choose to have different text for the Feature License and Feature Update License.

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

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

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

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

The Feature Checklist

  • Every feature has the text of the SUA in HTML in license.html;

  • Every feature has the project license(s) in HTML (e.g., typically the EPL in epl-2.0.html);

  • Every feature has the text of the SUA in plaintext in the license section of feature.xml or the license property of feature.properties; and

  • Every feature plug-in has copyright notices, etc. in the blurb property of about.properties

About features dialog
The About Eclipse Platform Features Dialog
An example directory structure corresponding to the above description
eclipse
 ├── features
 │   ├── org.eclipse.rcp_4.7.1.v20171009-0410 - Feature directory
 │   │   ├── license.html - Feature License (SUA)
 │   │   ├── epl-2.0.html - The project’s primary licenses(s) referenced by the SUA/Feature License
 │   │   ├── feature.properties - Feature Update License (SUA) in `license` property
 │   │   └── ...
 │   └── ...
 ├── plugins
 │   ├── org.eclipse.rcp_4.7.1.v20171009-0410.jar - Plug-in packaged as a directory
 │   │   ├── about.properties - Feature Blurb in `blurb` property
 │   │   └── ...
 │   └── ...
 └── ...

Notices in source code

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

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

Notices in documentation

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

Help legal page
Example legal notice in documentation

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

Project Releases and Reviews

Releases and reviews are crucial aspects of the project life cycle within the Eclipse Development Process. Through regular and transparent releases, Eclipse projects ensure that their software remains up-to-date and reliable.

Annually (more frequent for specification projects), Eclipse projects undergo a thorough review process in close collaboration with the Eclipse Management Organisation (EMO) and the Project Management Committee (PMC). This collaborative effort ensures that each project adheres to high-quality standards and follows the best open-source software (OSS) practices and guidelines established by the Eclipse Foundation. Reviews may be associated with a specific release, referred to as a "Release Review", or may not be linked to any particular release, known as a "Progress Review".

Additionally, there are other, less common but equally important types of reviews at the Eclipse Foundation, including Graduation Reviews, Restructuring Reviews, and Termination Reviews. In the following section, we will go into the specifics of these release and review processes.

Releases

Releases are formal for Eclipse projects.

Releases are broadly categorised as:

  • Major releases include API changes (potential for downstream breakage);

  • Minor releases add new functionality, but are API compatible with previous versions; and

  • Service releases include bug fixes only and include no significant new functionality.

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

release cycle
The Release Cycle

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

Warning

Specification projects must engage in a release review for every major or minor release.

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

Warning

Intellectual property must be properly accounted for and tracked at all times. The project team must engage in the Eclipse IP Due Diligence Process on an ongoing basis. The IP review and approval that occurs at the time of a progress review should be regarded as a means of confirming that intellectual property is being properly managed and not as a trigger to engage in a last minute clean up.

Release Plan

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

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

Tip

Release records can be used to capture a project plan. All project leads and committers can use the Create a new release command on their project page to create a new release record.At the start of the release cycle, a plan should minimally include a release number, date, and short description.

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

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

Pre-release Milestone Builds

Milestone builds and release candidates are not themselves official releases. Per the Eclipse Foundation Development Process, milestone and release candidate builds are pre-releases that are intended to be consumed by a limited audience to solicit, gather, and incorporate feedback from leading edge consumers. A predictable schedule for the delivery of milestone builds is especially valuable when the period of time between formal releases spans multiple months.

Project teams should include at least one milestone build during every release cycle. The timing of milestone and release candidate builds should be included in release plans.

Tip

As described in the Eclipse Foundation Development Process, milestones and release candidates are "almost releases", not releases. You’ve likely noticed that we to some lengths to avoid using the word release and instead tend to speak of milestone builds. While the EMO may wince a little when you refer to content as, for example, an alpha release, please feel free to do so if that makes sense to you and your community.

There are no governance requirements to produce and distribute a milestone build. Specifically, the project team does not need to engage in any reviews (for example, release or progress reviews) prior to distributing a milestone build. Milestone builds may include intellectual property that has not been fully vetted; the project team does not need to wait for specific approvals from the Eclipse Foundation’s IP Team to disseminate milestone builds. The project team should, however, take care to ensure that—​to the best of their knowledge and ability—​the licenses of the content included in milestone builds is well-defined and compatible/consistent.

Milestone builds can be hosted wherever the project team hosts downloads. The project team must ensure that milestone builds are clearly described as pre-release software that is intended to engage and prepare consumers, test the build process, and to solicit feedback. Milestone builds can be referred to as alpha, beta, or whatever other terms make sense to the project team and community (the primary concern is that the community understand the nature of the content that they consume).

Tip

Be sure to specify the channels where milestone adopter should provide feedback.

If you have questions regarding the distribution of milestone builds, contact the EMO for assistance.

Reviews

Creation Reviews

The creation review is only part of the overall project creation process which starts with a project proposal and ends with your code being available for distribution. Please see Starting an Open Source Project at the Eclipse Foundation for a discussion of the overall process.

Creation reviews occur over five generally-accepted business days. They are an extension of, and a natural conclusion to, the community review period for your project proposal. As such, your only real commitment during the review is to continue to monitor the proposal’s communication channel and answer any questions related to your project.

At the end of the review period, the EMO will declare the review complete (reviews tend to end successfully).

Note

There are no calls. We used to have a phone call at the end of each review period; we don’t do this anymore.

After the review, the EMO will initiate the provisioning process. As part of the committer provisioning process there will be paperwork requirements initiated via email; please make sure that your project’s committers respond to these email requests in a timely manner as the IT Team cannot provision any project resources until after at least one project committer’s paperwork has been processed.

Prior to scheduling the creation review, the EMO will check for the following things:

  • Proposal document is complete:

    • Top-level project is captured;

    • Project has a well-defined scope;

    • Project leads are identified;

    • The specified email addresses for project committers are correct (note that the proposal document will display warning messages for any committer email addresses that are not already registered to an Eclipse Foundation account); and

    • Biographical information (as it relates to the project) is provided for each initial committer;

  • PMC approval has been obtained;

  • Trademark assignment is complete; and

  • All questions have been satisfactorily answered in the communication channel.

Release and Progress Reviews

Reviews serve as a means for a project to engage in a retrospective of the progress made, discover areas for potential improvement or mitigation, demonstrate that the project is operating according to the open source rules of engagement (open, transparent, and meritocratic), and ensure that the development process and intellectual due diligence processes are being followed.

Reviews within the Eclipse Foundation can be categorised into: Release Reviews, which are associated with specific software releases, and Progress Reviews, which are not tied to any particular release. A Release Review is a type of Progress Review that is aligned directly with a specific Release. A Release Review must be concluded successfully before the corresponding Release is announced to the community.

Following a successful release or progress review, an Eclipse open source project is considered to be in good standing for a year. Only projects in good standing can make official releases. Specification projects must engage in a release review for every major or minor release.

Note

Historically, Eclipse open source projects were required to engage in a release review before publishing an official release. The notion of a release review still exists, but is fundamentally the same as a progress review.

Progress and release reviews differ only in timing. A progress review can be scheduled at any point in a project’s release cycle; a release review tends to be scheduled at the end of the release cycle.

Progress reviews provide a means for the EMO, PMC, and community to provide feedback and input.

progress review
Progress review work flow
Note

A progress review can be initiated by the project team, by the PMC, or by the EMO.

Send an email to EMO to initiate a progress review.

A progress review provides the EMO with an opportunity to review the project team’s practices to make sure that the the team is doing the right sorts of things to grow the project and attract diversity, has the recommended documentation in place, and is correctly implementing the Eclipse Foundation Development Process and intellectual property due diligence process. The project checklist describes the sorts of things that the EMO looks for when they engage in a review. Note that the checklist is used primarily as a means of identifying opportunities for the project to improve their open source practices and that absolute conformity with the list is considered aspirational, not an absolute requirement.

Note

The EMO is using GitLab issues to track the status of project’s reviews, you can see the template for a Project Review here.

Warning

Intellectual property must be properly accounted for and tracked at all times. All intellectual property must be vetted via the Intellectual Property Due Diligence Process before it it can be included any any release.

The PMC’s role in a progress review is to determine whether or not the project is operating within its scope, and within the mission and scope of the top-level project. The EMO also depends on the PMC to have some sense for how well the project is implementing the open source rules of engagement and is otherwise operating in a vendor neutral open source project. To engage the PMC, the project lead or a designated project committer should send an email to the PMC’s mailing list with a request for approval of the progress review. The PMC will respond with feedback or a simple +1 indicating approval.

Finally, a progress review provides the community and the Eclipse Foundation Membership with an opportunity to provide feedback and express concerns about the progress of the project.

Note

Eclipse open source projects don’t operate in a vacuum. While a progress review provides an opportunity for the EMO, PMC, and community to have a look at the project, our expectation is that the open source project is operating as part of the community and that all of these parties will have ongoing opportunities to interact and provide guidance.

Graduation Reviews

The purpose of a graduation review is to confirm that the project has a working and demonstrable code base of sufficiently high quality active and sufficiently diverse communities; has adopters, developers, and users operating fully in the open following the Eclipse Foundation Development Process; and is a credit to Eclipse and is functioning well within the larger Eclipse community

Graduation reviews are generally combined with a progress review (typically, but not necessarily in advance of the open source project’s 1.0 release). Upon successful completion of a graduation review, a project will leave the incubation phase and be designated as a mature project.

For a graduation review, review documentation must be provided by the project team that includes demonstration of:

  • solid working code with stable APIs;

  • an established and growing community around the project;

  • diverse multi-organisation committer/contributor/developer activity; and

  • operation in the open using open source rules of engagement.

The graduation review documentation should demonstrate that members have learned the ropes and logistics of being an Eclipse project. That is, the project "gets the Eclipse way".

Note

Connect with your PMC to discuss whether or not the project is ready for graduation. Contact the EMO to schedule the review.

Restructuring Reviews

A Restructuring review is a type of Review that is used to notify the community of substantial changes to one or more existing project’s structure, governance, or scope.

The purpose of a Restructuring Review is to notify the community of significant changes to one or more Projects. Examples of "significant changes" include: * Movement of significant chunks of functionality from one Project to another. * Modification of the Project structure, e.g. combining multiple Projects into a single Project, or decomposing a single Project into multiple Projects. * Change of Project Scope.

Note

Send an email to EMO to initiate a restructuring review.

Restructuring reviews begin with a formal proposal submitted by project leaders to the EMO. The proposal should outline the rationale for the restructuring and provide a detailed implementation plan (a paragraph with some context is considered formal enough). Once submitted, the project team has the responsibility to inform their community and PMC using the appropriate public channels. The EMO will then schedule a formal restructuring review that will run for at least a week, during which the Eclipse community engages in a thorough evaluation, providing feedback and participating in relevant discussions related to the impact of the restructuring.

The EMO uses this GitLab template as a starting point to track the status of restructuring reviews. Please note that due to the variety of restructuring cases that may arise, the template will be modified to align with the specific review rationale.

Termination Reviews

Initiating a termination review is a crucial step in managing projects that have reached the end of their life cycle or are no longer sustainable. This process is typically initiated when project leaders or stakeholders believe that a project should be retired or terminated.

To kick-start the termination review, a formal proposal is submitted to the EMO and PMC. This proposal should provide a rationale for the termination, outlining the reasons behind it, such as lack of activity or relevance, and the potential implications for the Eclipse community. Once submitted, the EMO schedules a formal review period, during which the Eclipse community can provide feedback and comments on the termination.

Note

Send an email to EMO to initiate a termination review.

Once the termination request is submitted, the EMO will schedule a formal review that will run for at least a week. The project team has the responsibility to inform their community and PMC using the appropriate public channels. During the termination review period the Eclipse community engages in a thorough evaluation, providing feedback and participating in relevant discussions related to the impact of the termination. During this period, there is always the possibility that someone may express interest in taking over the project. In such cases, the termination review is withdrawn, and instead, a restructuring or progress review is scheduled, depending on the specific circumstances.

The EMO uses this GitLab template as a starting point to track the status of termination reviews. The template is always modified to align with the specific review rationale.

Frequently Asked Questions

  1. Can a progress review fail?

    Technically, yes. A release review can fail. In our history, however, this occurs very rarely. We set up release reviews to succeed.

  2. Do we really need to do this?

    Yes.

  3. How often should we do releases?

    This depends very much on the nature of your project and the expectations of your community and stake holders. If you’re not sure, connect with your PMC for guidance.

  4. How much effort should we put into this?

    The amount of effort varies based on the nature of the team, and expectations of the community and stake holders. Generally, though, a project team shouldn’t spend more than a couple of hours working directly on the formal aspects of a progress review. If the amount of effort seems too onerous, you may be trying too hard. Connect with your PMC or the EMO for guidance.

  5. Do I need to engage in a progress review?

    If the the project team wants to issue an official major or minor release and has not engaged in a progress review within a year of the planned release date, then a progress review is required.

  6. What is the difference between a release review and progress review?

    In practice, there is really no difference. The activities involved are the same and a project may create major and minor releases for an entire year following a successful release or progress review.

    Progress reviews were added to the Eclipse Foundation Development Process primarily to support the Eclipse Foundation Specification Process, which requires that specification project teams engage periodic reviews that do not necessarily align with releases.

    In cases where, for example, a project team has gone an extended period of time without having engaged in a review, the project leadership chain may compel the project team to engage in a progress review to ensure that the project team is following the processes and is generally engaging in the sorts of activities required for success.

  7. How do I obtain PMC approval?

    Send the the Project Management Committee (PMC) a note via the top-level project’s PMC mailing list with a link to the release record. Note that the release record page has a handy link labelled Committer Tools  Send Email the PMC.

  8. I need to do a release now. Can you fast-track the review?

    While we do try to be as accommodating as possible, the answer is no. We have a well-defined process with predictable dates. Please plan accordingly.

  9. Can a project in the incubation phase do releases?

    Yes. In fact, we encourage projects to do at least one release while in incubation phase.

  10. What restrictions are placed on version names for incubating projects?

    Projects in the incubation phase generally use version numbers that are less than 1.0. This is, however, a convention not a rule. If it makes sense for you community and adopters to use higher numbers, then do so. If you’re not sure, ask your Project Management Committee (PMC) for advice.

  11. How do I name/number milestone builds?

    Milestone builds must be named in a manner that that conveys the pre-release nature of the content. It is common for project teams to name their milestone builds alpha or beta. Another convention is to use the name/number of the eventual release suffixed with "Mn" (e.g. the second milestone for Eclipse EGit 3.2 may have a file named egit-3.2M2). Projects in the incubation phase may produce milestone builds for their graduation release, e.g myProject-1.0M2.

  12. Can Eclipse open source projects in the incubation phase distribute milestone builds?

    Yes. In fact, the EMO strongly encourages Eclipse open source projects in the incubation phase to create and distribute milestone builds.

  13. How can I get help?

    Post your question on the Incubation Mailing list, or contact your Project Management Committee (PMC) or the EMO.

Project Management Infrastructure (PMI)

The Eclipse Project Management Infrastructure (PMI) consolidates project management activities into a single consistent location and experience.

Project Management Infrastructure themes:

Improved consistency. Configuration/data-driven project web presence, direct linkage between releases, reviews, and plans. Information — including basic project metadata, project plans, and review information — is captured and retained in a consistent (and easily leveraged) data-based format (rather than in multiple documents in arbitrary formats).

All-in-one-place. Project leads and committers are able to edit information in place on the project information pages. Text/information in one place with links in another is eliminated where possible. Comments and discussion related to reviews, elections, etc. are connected directly to the item being discussed.

Get started fast. By default, projects are provided with a data-driven website (a so-called PMI Page) that includes consistent links to project releases, reviews, downloads, etc. With the data-driven website, setting up project presence is a matter of providing metadata. Projects can opt provide their own custom website.

Project Metadata

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

Project metadata is:

  1. Relatively static structural information such as the project description and scope, the names of the project’s mailing lists and forums, pointers to source code repositories and issues, etc.

  2. Historical information such as previous release downloads, review materials, etc.

  3. Status and future looking information such as the project and milestone plans, the features scheduled for the current release, release dates, etc.

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

Viewing

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

Project Pages

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

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

project page
An example project page

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

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

Commands and Tools

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

Create a New Release

A project lead or committer can create a new release record. This opens a dialog requesting that a date and name be specified. Both of these values can be changed later.

To create a new release record:

  1. Log in to the PMI;

  2. Navigate to a project page;

  3. Click Committer Tools  Releases  Create a new release; and

  4. Follow the workflow.

Editing Project Metadata

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

edit project metadata
Editing project metadata.

To set the edit project metadata:

  • Log into the PMI;

  • Navigate to the project page;

  • Click Edit;

  • Expand sections to expose the various topic areas, and edit as required; and

  • Click Save.

Tip

The changes that you make to the project metadata will be reflected immediately on the project information page.

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

Some of the fields are described below.

Description and Scope

The project description is displayed on the Overview page; the scope is displayed on the Governance page.

The description should start with a concise paragraph of three to five sentences (e.g. suitable for display with a collection of other projects). A single paragraph is generally appropriate for the description.

If more than a single simple paragraph is required to fully describe the project, it is possible to set a summary. The summary can be specified by toggling the show summary link to explicitly set a summary apart from the more detailed description, or the top part of the description can be designated as the summary by inserting a Teaser Break into the content.

Note

Providing a summary gives you control over what will get rendered. In views where we are displaying more than one project, the system will artificially cut short descriptions that are too long, potentially resulting in a description that looks weird.

The scope is intended for a more select audience; generally speaking the scope should be taken directly from the project’s proposal.

Warning

Project members have the ability to change the text of the project scope, but should be careful to avoid changing the meaning. If the meaning of the scope needs to change, the Project Management Committee (PMC) must be contacted regarding a potential restructuring review.

To edit the description and/or scope:

  • Log into the PMI;

  • Navigate to the project page;

  • Click Edit;

  • Open the section labelled The Basics;

  • Update the fields as required; and

  • Click Save.

Downloads

You can provide download information for your project in the Downloads section.

The first entry is the main "Downloads URL". This manifests as a Big Button Download on the project page. What you put here is left to the project team to decide. It can be a link to a website, a direct link to a file download, or whatever else makes sense the project and community.

Optional text can be included along with the Big Button Download, as well as links to zero or more Eclipse Marketplace, update/p2 sites, or other downloads. Each of the links can have an optional title (the link itself will be displayed if no title is provided). Note that no validation is done on the links to ensure that they are meaningful.

To edit the download information:

  • Log into the PMI;

  • Navigate to the project page;

  • Click Edit;

  • Open the section labelled Downloads, Software Repositories, and Marketplace;

  • Update the fields as required; and

  • Click Save.

Contributors

The project team can choose to designate specific individuals as official contributors. On GitLab, designated contributors are granted the Reporter role in the project’s repositories. On GitHub, designated contributors are granted the triage permission. Contributors can create merge and pull requests regardless of whether or not they are designated as an official contributor.

Contributors can be designed by adding their email address to the Contributors field. The contributor must have an Eclipse Foundation account using the email. In the case of GitHub, the contributor must also provide their GitHub ID in their Eclipse Foundation Account.

Note

To gain the triage role on an Eclipse project’s GitHub repositories, contributors must provide their GitHub ID in their Eclipse Foundation Account.

Any committer or project lead can add or remove contributors for their own project. To set the add or remove contributors:

  • Log into the PMI;

  • Navigate to the project page;

  • Click Edit;

  • Open the section labelled Source Code and Issues/Bugzilla;

  • Add/remove email addresses to/from the Contributors field;

  • Click Save.

Note

The sync script that propagates contributor information into teams on our GitLab instance or to GitHub runs every two hours. That is, you should expect upwards of two hours of latency between when an individual is added to as a contributor and the corresponding privileges are available to that individual.

Source Repositories

Source repositories are listed on the Developer Resources page.

Metadata regarding source repositories is maintained by EMO staff.

A Contribution Message, which is — when provided — displayed at the top of the Developer Resources page. Arbitrary text is permitted, but we recommend that you limit this content to a single paragraph with a few sentences that include a link to more information.

Tip

It is more likely that potential contributors will find your project’s source code repositories before they find the project page; be sure to provide a Contributor Guide in the root of your project repositories.

To edit information about contribution and provide pointers to information about contributing to your project:

  • Log into the PMI;

  • Navigate to the project page;

  • Click Edit;

  • Open the section labelled Source Code and Issues/Bugzilla;

  • Update the fields as required;

  • Click Save.

Project Logos

Project Logos appear in the right navigation area on the project page. They also appear on summary or list pages (for example, the Project List Page).

Any member of the project team can set the project’s logo. The logo will be resized to a maximum of 200x200 pixels. Project logos are considered trademarks of the Eclipse Foundation (see Logos and Graphics for more information).

Tip

The Eclipse Foundation will use your logo to promote your project. Be sure to create your project logo with a transparent background so that it will display well on arbitrary background colours.

Any committer or project lead can set the logo for their own project. To set the project logo:

  • Log into the PMI;

  • Navigate to the project page;

  • Click Edit;

  • Open the section labelled The Basics;

  • Upload your logo to the Logo field;

  • Click Save.

Note

On a project page, the PMI displays either the project logo or — when the project is in the incubation phase — the incubation logo.

To exit from the incubation phase into a mature project, a project must meet all of the requirements and engage in a graduation review.

Company Logos

Company logos automatically appear on the Overview and Who’s Involved page under the following conditions:

  • The company must be a member of the Eclipse Foundation;

  • The company needs to have their logo uploaded to the Eclipse Foundation Member Portal; and

  • An employee of the company has authored a commit in the last three months that’s been merged into a project repository.

Tip

The display of company logos is entirely automatic based on the criteria listed above.

If all of those conditions are met and the logo is still not showing up, then it’s possible that a gap exists in our data. Contact the EMO for assistance.

Build Technology

Build information appears on the Developer Resources page.

A project can specify a section of text, links, and a selection of the build technologies employed. Specifying this information makes it easier for members from the community to understand your build. Links can include direct links into the CI builds, pages of build instructions, or whatever else the project team feels will help the community build the project.

To set build technology information:

  • Log into the PMI;

  • Navigate to the project page;

  • Click Edit;

  • Open the section labelled Build;

  • Upload your logo to the Logo field;

  • Click Save.

Technology Types

Technology types are displayed in the Tags block in the right navigation area of the project page.

A project can specify the types of technology produced by the project. This is specified in rather broad terms like OSGi or Runtime. The various technology types manifest as checkboxes on the edit screen. This information is used to form connections between projects to assist in navigation and discovery.

Clicking on one of the technology types, will take the user to a page that lists the projects that produce that particular type of technology, along with the summary of their description and project logo (if specified).

To configure technology types:

  • Log into the PMI;

  • Navigate to the project page;

  • Click Edit;

  • Open the section labelled Categorisation, Relationships, and Tags;

  • Select technology types from the list;

  • Click Save.

You can also specify arbitrary tags and related projects (projects that share some link or synergy) in the Categorisation, Relationships, and Tags section.

Releases and Reviews

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

releases and reviews
The relationship between proposals, projects, releases, and reviews.

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

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

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

Tip

Use the Create a new release command on a specific project page in the Project Management Interface (PMI) to create a new release record.

Description

Describe the release in the Description section. The description should generally be a concise paragraph describing the focus of the release (e.g. adding certain functionality, fixing bugs, etc.) in a form that is appropriate in an aggregation (e.g. a page that displays the release information for all projects participating in an instance of the Simultaneous release). The description should provide enough information to encourage the reader to click the find out more link.

Plan

Project plan information belongs in the Plan section. This information should generally be provided early in the development cycle to allow the various communities the ability to understand and participate in the release. It is expected that the plan will evolve over time. Note that all projects are required to provide a plan for each major and minor release (plans are not required service releases).

Review

The release record has a Review section that can be used to provide information for an associated release review. If you provide information in the Review section, the release record itself can be used as review documentation; no further documentation is required.

Each section on the review page includes a little help to describe the sort of information that you should provide.

Note

A review is not necessarily required for every release. A project team may declare official major or minor releases and distribute associated products for up to one year following a successful progress review and reviews are never required for bug-fix/service releases.

If a release requires a review, you can schedule one by clicking the Schedule a review link. The drop-down list above the button contains several options for review dates. Pick the one that works best for you.

Note that this form will not appear if a review has already been scheduled, or the release date does not provide enough time to run a review (or is in the past). If a review has been scheduled, a link to the review will appear.

You can edit the review document, but there’s really not all that much to edit. A free-form text field is available and can be used if there is some need to provide review-specific information that might not otherwise be an appropriate part of the release record.

Note

The free-form text field in the review record is intended for other types of reviews (e.g. restructuring or termination reviews); we decided to leave it available for release reviews for cases in which it might be useful rather than suppress it.

When the review is displayed, it automatically includes the review information from the release record; it shows the review-specific information at the top of the page, and includes the review information from the release as the rest of the page contents.

This can make things a bit confusing when you want to make changes to the metadata for a review record. Just remember that the review information for a release is stored in the release record.

Joining a Simultaneous Release

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

Note

Simultaneous releases are not a formal concept in the EDP. While the supervising body has considerably latitude to define the nature of their simultaneous release, the project teams that opt to participate in a simultaneous release are still individually required to fully meet their obligations under the EDP and the Eclipse IP Policy.

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

Tip

The Eclipse Planning Council manages the Eclipse IDE Simultaneous Release, and maintains the participation rules.

Tip

The Jakarta EE Specification Committee manages the Jakarta EE release.

To join a simultaneous release, an Eclipse project committer must

  1. Meet the requirements defined by the supervising body;

  2. Create a release record:

    • The record must include at least brief description of the release (that can be changed later); and

    • The date of the release should generally match that of the simultaneous release;

  3. The committer must then connect with the supervising body and the EMO to add their release record to the simultaneous release record.

Note

Release records are added to a simultaneous release record by reference. If you change information in the release (including the release name/number), those changes will be automatically reflected.

Frequently Asked Questions

  1. Why doesn’t a committer appear on the project’s Who’s Involved page?

    For a committer to appear on a project’s Who’s Involved page:

    1. The new committer must be elected (or be listed as an initial committer on a project proposal);

    2. The election must complete successfully and be approved by the PMC;

    3. The new committer must provide the required paperwork;

    4. The paperwork must be processed by the EMO Records Team; and

    5. The Eclipse IT Team must create the committer account.

    Each piece takes time. If a committer doesn’t appear some number of days after the successful completion of a committer election, then contact the committer to confirm that they’ve followed the provided instructions and have submitted committer paperwork. Then, connect with EMO for assistance.

    If the new committer will be working with projects that use GitHub, they must be sure to add their GitHub Id to their Eclipse Foundation Account so that our scripts can add them to the GitHub Teams that we use to manage access to Eclipse Foundation repositories hosted on GitHub.

  2. What is the difference between a Committer and an Historic Committer?

    The Who’s Involved page lists committers and (in many cases) historic committers. Committers are those individuals who currently hold committer status (i.e., they can write to project resources). Historic committers are retired former committers. While they hold a special place in our hearts, they have no official status on the project. To turn an historic committer back into a committer, they must be re-elected to the project.

  3. Where did the Issues Tab go?

    This feature was deprecated and removed (see issue #83 for more information).

Project Branding

This section defines how Eclipse projects must use and display all Eclipse Foundation trademarks as well as how they showcase their project’s website within the community and ecosystem. The requirements described here are a complement to the Eclipse Foundation Trademark Usage Guidelines, targeting Eclipse open source project leads and committers specifically.

These requirements are meant to promote and improve the image of all projects that are part of the Eclipse community, as well as to show that all Eclipse projects are part of our community of developers, adopters and users that we believe is an important factor in our mutual success. While every project manages their own development within the broader Eclipse Foundation Development Process, a consistent public branding and web presence that ties all of our projects together benefits all of us.

All projects must conform to these branding requirements before engaging in any release or graduation review.

Brands

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

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

Note

The brand that is associated with a particular project is used on the corresponding project page.

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

Naming and Trademarks

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

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

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

Note

When naming a project, the brand is a consideration. All Eclipse projects are able to use the Eclipse brand. Other brands are managed by working groups and so whether or not the brand can be used with your project is at the corresponding working group’s discretion. For help, please contact EMO.

Who needs these requirements?

  • Project teams that want to name or rename a software product;

  • Project teams that want to rename their project; and

  • Anyone submitting a new project proposal

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

Registered Trademarks

Project teams may request legal trademark registration for their project or product name. Since trademark registration requires a significant investment in time money and ongoing maintenance project teams must work with the EMO to determine whether trademark registration is necessary, determine in which jurisdictions the trademark must be registered, and how that registration will impact the project (e.g. adding registration marks on the website and in products).

Other Organisations' Trademarks

Project teams must ensure that product names that include other organisations’ Trademarks in names must conform to those organisations’ trademark usage guidelines. For example, "Eclipse Foo Perl" is not appropriate, since it improperly uses the trademark "Perl" (which is a trademark of The Perl Foundation); a better project name would likely be "Eclipse Foo for Perl" (assuming that is permitted by the Perl Foundation). Use of another organisation’s trademark should be limited and approved on a case by case basis.

Choosing a Name

Naming and branding are challenging issues that generally require some real investment in time and energy. The best project names are distinctive, unique, and memorable.

Project teams should start the process of securing the trademark for a name as early as is practical. This is required to ensure the EMO has sufficient time to review and approve the name.

A project team should start this process:

  • When they first begin preparing a project proposal;

  • As soon as their project wants to name a new software product; or

  • Before initiating a Restructuring Review to change a project name

Note

Renaming projects (i.e. after a project has been created and provisioned) requires significant work on the part of the infrastructure team, and can be disruptive and confusing for consumers. Project teams should start the process as early as possible once they have a candidate name.

Project Names

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

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

Formal Name

The primary branding for any project name is fully-qualified formal name which includes the brand (typically Eclipse, but projects may leverage other Eclipse Foundation brands) prefix (e.g. Eclipse Woolsey Intellectual Property Tools or Eclipse Woolsey Framework). This ensures that the project is associated with the Eclipse Foundation in the community, ecosystem, and the minds of users and adopters. However, Eclipse projects are oftentimes known by many names: it is common for a project to have both a formal and a nickname or commonly-used acronym.

The formal name may include a brand name and/or a descriptive name.

Distinctive Names

Ideal project names are distinctive and memorable. Woolsey, Apogy, and Whiskers are examples of project names that are distinctive and memorable: they make the project easier to talk and write about than a wordier descriptive name.

Distinctive names don’t tend to convey information about the nature of the project; combining a distinctive name with a descriptive name (e.g. Eclipse Woolsey Intellectual Property Tools) can help in this regard.

Descriptive Names

Descriptive names tend to be challenging to register as a trademark and so are generally discouraged as a project name. That’s not to say that descriptive names are prohibited, but rather that they are more likely to be rejected during the trademark vetting process.

Descriptive names can, however, be helpful as an informal secondary name for a project.

The best names do not include the word Project, and are—​in formal contexts—​prepended by the brand name. Descriptive names may optionally include the words Framework, Platform, or Tools if the project has a specific emphasis on extensible frameworks, a platform, or obvious development tooling technology. Eclipse projects always provide both but may be tailored more toward one or the other. When choosing to use these words, the team should consider that Framework, Platform, and Tools mean different things to different people and are becoming overused.

Nicknames

A project may have a nickname or common name that is a shorter form of the formal name (and will likely be the same as the brand name). The Eclipse Woolsey Intellectual Property Tools project may be referred to as Eclipse Woosley or simply Woolsey. An acronym may be used as a nickname (e.g. ECF and GMF).

Acronyms For Long Names

Most descriptive names are sufficiently long that it can be convenient to abbreviate them in some way.

Note

Acronyms often become brand names.

Existing Software Product Names

To avoid confusion between Eclipse projects and commercial products, Eclipse projects may not be named after commercial products and vice versa. To ensure that users understand the source of software products—​i.e. from an Eclipse project, or from a third-party vendor—​the brand for an Eclipse project must not include or be directly reminiscent of a commercial product.

Short Names and IDs

Projects require a short name; this name is used to as an ID for the project in various parts of Eclipse Foundation infrastructure and should be as reflective of the formal name as possible.  It may, for example, be a lowercase rendering of the brand name, or an acronym of a descriptive name.

The short name may contain lowercase alphanumeric characters, dashes, and underlines. The short name may not contain periods (.). Short names are used in some project URLs, download directories, the build server, and in the technical namespaces of other parts of the supported infrastructure.

The short name is joined with the short name of the parent project(s) to form a qualified identifier for the project that is used as a key on many of the web pages and services generated and/or maintained for the project by the Eclipse Foundation. e.g. the Eclipse Woolsey project has a short name of woolsey; its qualified name 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.

Project names should always be referred to in a consistent casing, and used as an adjective (never as a noun or verb) like any trademark should be used (e.g. "Download Eclipse Woolsey software here", using the Woolsey name as an adjective for software).

Product Names

A product is a specific, downloadable software product that users or consumers might want to use in some way. Most projects release a product with the same name (e.g. the Eclipse Woolsey project releases a software product called Eclipse Woolsey) or some variation of the project name (e.g. Eclipse Woolsey SDK).

Note

Most open source projects produce products that share the project name. There are, however, numerous examples of projects that produce additional products. The Eclipse CDO project, for example, has a product named Dawn; and the Eclipse Graphical Editing Framework project has a product named Zest.

Product names should also be prefixed with an Eclipse Foundation brand when used in any formal context (e.g. Eclipse Widgets).

Project teams should work with their Project Management Committee (PMC) to determine whether or not to pursue assertion of ownership of the trademark for product names. Project teams should work with the Eclipse Management Organisation (EMO) to assert ownership of product trademarks.

Project Descriptions

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

The Eclipse C/C++ Development Tooling™ (CDT) project provides a fully functional C and C++ Integrated Development Environment based on the Eclipse Platform.

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

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

Project Website Branding

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

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

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

Name References

The first reference to a project or product on every web page—​especially in page titles or headers—​must use the formal name and must include the relevant trademark (™) or registered trademark (®) symbol (e.g. Eclipse Woolsey Intellectual Property Tools™). When a web page features an otherwise prominent reference to the project or product (e.g. in a callout), that reference should also use the formal name. Other references may use  the nickname or acronym (e.g. Eclipse Woolsey or Woolsey) as appropriate.

All project web pages must include a footer that prominently displays an approved Eclipse logo, important links back to key pages, and a copyright notice.

Approved Eclipse logos are available on the Eclipse Logos and Artwork page.

The following minimal set of links must be included on the footer of all pages in the official project website:

Note

An appropriate footer is included automatically by the default website infrastructure and the PMI.

Code Namespaces

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

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

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

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

Third-party Use of Trademarks

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

Conferences and Events

Use of the terms Eclipse, EclipseCon, and Eclipse Day are reserved for exclusive use by events authorised by the Eclipse Foundation.

Other Eclipse Foundation trademarks (e.g. project names) may be used in events, but must be approved by the EMO subject to the following considerations:

  • The name of the event must conform to the terms laid out in the Eclipse Foundation Trademark Usage Guidelines;

  • The event must include sessions that focus on content provided by the corresponding open source projects;

  • Representatives from corresponding Eclipse open source projects (e.g. committers, project leads, PMC members) must be directly involved in the event; and

  • Websites, printed materials, and other content associated with the event must provide pointers/links to the project website and trademark attribution.

The trademark should not generally be concatenated with any other words. Exceptions for established conventions (e.g. WoolseyCon) may be granted on a case-by-case basis.

Trademark attribution must indicate that the trademarks are owned and managed by Eclipse Foundation on behalf of the community.

Note

Permission is not required to present a talk on an Eclipse project.

Community Portals

Community portals are generally operated at arms length from the Eclipse open source project. The community portal may help users find information about what the project software does and how to get it, or provide a means for the community to contribute to related side projects that are not part of the Eclipse open source project.

The community portal is not a replacement for a developer portal which takes form in the official project website as described by this document.

A community portal is operated with these considerations:

  • The name of the community portal must conform to the terms laid out in the Eclipse Foundation Trademark Usage Guidelines;

  • The first and most prominent reference to the open source project or corresponding product name on every web page must use the formal name and must include the relevant trademark or registered trademark symbol (subsequent references may use  the nickname or acronym as appropriate);

  • All references to Eclipse open source project names must use the formal name;

  • The website must include trademark attributions for all Eclipse Foundation trademarks used on the site; and

  • Contributors must be directed to the official project website for information regarding contribution or related development activities.

Community portals must include a prominent text paragraph or sidebar that points to the official project website, so that users interested in contributing or otherwise participating in the open source project know where to go.

Note

Naming exceptions may be granted for names that follow established conventions (e.g. Woolsey™ Labs). Contact the EMO to request an exception.

Domains

Websites on external domains that use a project name trademark (e.g. www.mosquitto.com) that point to servers that are not hosted by the Eclipse Foundation, may be employed as community portals. External domains may be appropriate for some forms of documentation, community-generated content, and pointers to community forums.

For domains that leverage Eclipse Foundation trademarks, ownership of the domain name must be transferred to the Eclipse Foundation.

Note

If a project team takes it upon themselves to acquire a domain, they must transfer ownership of that domain to the Eclipse Foundation. The Eclipse Foundation does not generally acquire domains on behalf of projects. Selecting a domain (and how to pay for the initial acquisition of that domain) are matters for the project team to sort out.

The domain must be regarded and used exclusively as a community portal (and not as an official project website).

Trademark Attribution

The external uses of Eclipse Foundation trademarks must include a prominent trademark attribution of all applicable Eclipse Foundation marks.

For example:

Eclipse Woolsey Intellectual Property Tools, Eclipse Woolsey, Woolsey, Eclipse, the Eclipse logo, and the Eclipse Woolsey project logo are Trademarks of The Eclipse Foundation.

Note

As a general rule, you must respect trademark usage guidelines and provide attribution for trademarks held by others.

e.g., "Java is a registered trademark of Oracle. Other names may be trademarks of their respective owners."

Important Notes

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

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

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

Frequently Asked Questions

  1. Can my company use the project name as part of their product name?

    It depends on how the name will be used. Please see the Eclipse Foundation Trademark Usage Guidelines.

Promoting your Project

It’s certainly true that great technology is an important part of what makes Eclipse open source projects great. However, technology alone isn’t enough. Technology needs to have a community. Open source projects need to bring the community together to do great things.

Developing a community is an important part of being an open source project. It is from a community of users, adopters, and contributors that a project draws strength and longevity. Without a community, an open source project is just a bunch of code that might as well buried on a server behind a firewall somewhere in parts unknown.

The Eclipse Foundation Development Process defines three different communities: users, adopters, and developers. Each of these communities has different requirements and expectations from Eclipse.

promotion communities
Three communities

The first community, users, tends to regard open source primarily as consumable technology.

The adopter community contains individuals and organisations that build solutions based on open source technology. This includes those individuals and organisations who base a business on providing development assistance and support for open source technology.

The developer contains that group of individuals who contribute directly to open source projects in the form of patches and/or contributions new functionality. Contributors tend to participate directly in an open source project by providing code, ideas, answers to questions in community forums, and more. Committers are a subset of the contributors with write access to the resources maintained by a project (committer access is provided on a project-by-project basis). The idea is that a contributor is invited to become a committer and elected into that position based on credibility established over a period of time.

Developing a community is an important part of being an Eclipse open source project. In fact, developing community is an integral part of the Eclipse Foundation Development Process: as part of the project review, a project is required to demonstrate their community-building activities, like blogging, speaking opportunities, and more.

Engage the Community

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

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

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

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

  • Co-ordinate responsibility for monitoring the project’s communication channels: project developers can take turns monitoring community forums, and triaging issues;

  • Establish a response policy for responding for questions:

  • How long should somebody expect to wait for a response?

  • Will project committers create issues on behalf of community members, or invite them to open issues themselves?

  • Teach your team members to be courteous and polite in all communication;

  • Make sure that anybody who finds your project has a positive experience;

  • Ensure that the project is operating transparently: decisions regarding project architecture, features, and more should be discussed in transparent forums that invite participation; and

  • Ensure that the project’s website and other sources of information are correct and up-to-date.

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

Here are some things to think about:

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

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

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

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

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

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

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

Promotion Resources

Project Web Site

If your project does not already have an official website, create one.

Web site developers must put themselves into the mindset of the project’s target community. You must plan to iterate; you’re not going to get it right the first time. Too many of our project sites are old, contain stale information, and assume too much prior knowledge to be useful tools for growing a vibrant community of users, adopters, and developers.

Tip

The Eclipse Foundation will use the project logo to promote a project. Project teams should be sure to create their project logo with a transparent background so that it will display well on arbitrary background colours. Square logos are preferred and should be sized to display well at the 200x200 pixels resolution maximum permitted by the project metadata.

Logos are important to recognise as trademarks. For a project’s official logo, the designer must ensure that it includes a small trademark (™) or registered trademark (®) symbol (as appropriate) in the graphic or immediately adjacent to it.

Projects may request to use an Eclipse logo within their project logo, or otherwise create a derivative of the Eclipse logo. However, they must contact the EMO by opening a issue to request the Eclipse Foundation’s Board of Directors' permission to do so.

Note

Add your project logo to your project’s metadata via the PMI.

Crowdsourcing a Project Logo

Projects teams can engage a graphic design crowdsourcing site or similar service to create a logo. The project leader and committers are responsible for setting up the design process and providing the feedback to the graphic designers. Based on past experience, faster and more detailed feedback to the designers yields better results. The Eclipse Foundation will help fund the creation of project logo. A project leader or committer will have to pay for the logo design in advance. Once the logo is created, the project can then send the invoice to the Eclipse Foundation marketing team. The Foundation will reimburse up to €500 for the logo design. Project team members should contact the Eclipse Foundation’s marketing team with any questions regarding logo design.

Adopters Programme

The Eclipse Project Adopters Programme provides a means for projects to highlight the various organisations, groups, and other open source projects that leverage their content.

The Eclipse Project Adopters Programme provides:

  • A means for adopters to upload their logo and information;

  • A standard mechanism for adopters to express their interest in multiple Eclipse open source projects;

  • An API that Eclipse project teams can leverage to display the adopter logos on their project page.

Warning

An important aspect of the Eclipse Project Adopters Programme is that adopter organisations are themselves responsible for providing the Eclipse Foundation with their logos, links, and other information. To avoid confusion and liability, Eclipse project teams should not manage these resources directly.

Eclipse Marketing Team

The Eclipse Foundation has various Marketing Services that they can bring to bear to help you market your project.

Project teams can, for example, request help with:

Community

The Eclipse Foundation Development Process (EDP) is mostly concerned with engaging in activities that grow community involvement. an Eclipse project is considered successful only if a vibrant community develops around it and the project team grows in diversity.

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

Community and ecosystem development are two things that every committer should spend at least some time thinking about, and — hopefully — some time doing something about. Ultimately, it is difficult to call your project a success without these things. It is from the community and ecosystem that you will draw additional contributions and other helpful input to make your open source project a success.

Lower the Barriers

One of the most critical aspects of running an open source project is to grow user and adopter communities, invite contributions, and increase committer diversity. All Eclipse projects must work to lower the barrier of entry.

To attract and support contributors:

  • Make it easy for contributors to find is the code, build it, and run tests;

  • Describe and disseminate the contribution process;

  • Maintain an open and transparent schedule of builds, milestones, releases, etc.;

  • Capture important decisions in public channels and invite participation (be transparent and open); and

  • Consider implementing a weekly phone call where you can discuss the schedule, the on-going work, and also the more complex/controversial technical things which would have not been easy to take care of by email.

When somebody does show up to do some work on your project, help them be successful.

To attract and support users:

  • Maintain a concise and clear description of the project on the website;

  • Provide a five minute tutorial to help users understand what the project does and why they should care;

  • Make sure that they know where they can go to get answers to their questions (e.g. a project forum); and

  • Provide great documentation, with a lot of ready-to-go examples.

Include support for the website, and regular updates to your project documentation and tutorials as part of your project planning.

Forums

It is through Eclipse Forums that adopters tend communicate with a project. Very often, it is the only real support channel provided for those adopters.

Note

Every project should have at least one committer monitor eclipse.newcomer to catch questions posed there and further extend the awareness of the project.

When your community asks questions, answer them as soon as possible. No question should go unanswered. Encourage all of the project committers to monitor the project forum(s), or — at very least — take turns. When sensible, incorporate the answers into the FAQ or some type of wiki recipe. Repeat this process for as many newsgroups as possible, because Eclipse’s overall success will be reflected in your personal success. Your dedication to high-quality service and support is the fuel for your ecosystem and the success of that ecosystem is the most effective way to achieve maximum influence with your limited individual capacity.

Adopter questions posed in developer mailing lists (and other inappropriate forums such as personal e-mail) should be answered politely. It is reasonable to recommend that the question (or future questions) be posed in the forum where it can be viewed by a larger audience as is more likely to receive a timely answer.

Avoid negativity, swearing, belittling, or other disparaging behaviour in your responses.

All of the answers don’t need to necessarily come from project committers: empower your community to answer questions in the newsgroup. When community members do provide answers that require further clarification (either they are not complete, or are not 100% correct), do so politely.

The more welcome you make your community feel, the more likely it is that your project will be successful.

Issues

When your community reports a problem, fix it as soon as possible. Be sure to make a distinction between wish list items ("I want more goodness") and actual defects ("it’s broken because it’s not working the way it was designed to work"). A list of 1,000 issue reports that looks to the community like a list of 1,000 defects rather than like a list of 1,000 wishes is bad publicity. Having no responses in most of those reports, is also bad news. Your community will interpret it as a lack of respect, and no pleas about your lack of resource will help offset that negative perception.

Provide linkage between commits and issue records in the commit comment so that somebody browsing the history of your code can follow the links to find any discussion, or other useful information related to that commit. Consider including issue numbers directly in comments in the source code when the discussion contained in that bug is particularly useful. This will help your community and committers better understand why your code is implemented the way it is and give them a pre-existing place (i.e. the issue report) to pose further questions.

Signs of success

Ultimately, everything above is about making it possible for a community to find out about your project and provide opportunity to get involved. Providing that opportunity is one thing, actually attracting a community is another.

You are successful if (not an exclusive list):

  • A significant number of bugs raised against your project come from non-committers;

  • Non-committers are blogging about your project;

  • Articles, presentations, podcasts, webinars, etc. are being developed and presented by non-committers; and/or

  • You cease to be the centre of the universe for your project.

Project Checklist

This checklist is provided as a convenience and is included primarily as a guideline or tool to ensure that Eclipse projects are doing the right sorts of things to attract community and grow.

Tip

With this checklist, we’ve tried to strike a balance between being concise while being as comprehensive as possible. Many of the entries apply for specific technologies only. If an entry on the list doesn’t make sense for some particular type of technology in your project, skip it (e.g., file headers do not make sense for JSON content).

The EMO and Project Management Committee will use this checklist as part of their evaluation during a Progress Review.

All projects must conform to the branding guidelines before engaging in any release (specific examples are described below).

General

  • Project is operating within the mission and scope defined in its top-level project’s charter;

  • Project is operating within the bounds of its own scope;

  • Project is operating in an open and transparent manner;

  • All distributed third-party content has been approved by the IP Team;

  • Project content correctly uses Eclipse Foundation trademarks; and

  • Project content (code and documentation) does not violate trademarks owned by other organisations.

Code

  • All project code is managed in source code repositories provided by The Eclipse Foundation;

  • Naming conventions followed:

    • e.g. org.eclipse.<shortname>.<component>[.*] for Java packages and OSGi Bundles;

  • Provider information is set to the project’s formal name:

    • e.g. the Bundle-Vendor entry set to "Eclipse Foo" in OSGi Bundles; or

    • e.g. the project and organisation names are set to "Eclipse Foo" in Maven pom.xml files;

  • Legal documentation is provided:

    • All source files include a copyright and license header (when technically feasible);

    • All source code repositories include a LICENSE file (or equivalent) in the root; and

    • All source code repositories include a NOTICES file (or—​for projects that produce Eclipse Platform plug-ins--about.html files as described by the Legal Documentation for Eclipse Platform Plug-ins and Fragments);

  • All source code repositories include a CONTRIBUTING file (or equivalent) in the root; and

  • All feature names and descriptions are captured, are spelled correctly, use proper grammar, and contain content that is actually useful for the intended audience.

Downloads

Many projects provide binary/compiled downloads of their software, intended for consumption by their various communities.

  • All generated artifacts include only intellectual property that has been subject to the IP Due Diligence Process;

  • The project website and project page includes links for artifacts;

  • Incubation branding (when applicable) is included on distributed artifacts;

  • All download artifacts are (if technical feasible) signed; and

  • Subject to limitations of specific technologies, the Semantic Versioning rules are followed.

Project Metadata

Project metadata is specified and maintained using the Project Management Infrastructure.

  • The formal name, e.g. Eclipse Foo, is used in the project title;

  • The formal name including appropriate marks is used in the first mention in the text of the project description, and scope;

  • The project description starts with a single paragraph that can serve as an executive summary;

  • Source code repository references are up-to-date; and

  • Download links and information are up-to-date.

Release Metadata

Release metadata is specified and maintained using the Project Management Infrastructure. Project teams are required to create a metadata entry for every official release (including major, minor, and service releases).

  • At least one release record describes a future release; and

  • The release record includes a description that starts with a single paragraph that can serve as an executive summary.

Tip

Use the Create a new release command on a specific project page in the Project Management Interface (PMI) to create a new release record.

Development Website

  • Is hosted on Eclipse Foundation-provided infrastructure;

  • Uses the formal name including appropriate marks, e.g. Eclipse Foo™, on the page title, first mention in the text, and on all prominent references to the project;

  • Incubation branding (when applicable) is displayed;

  • Includes a concise description of the project (with all necessary marks); and

  • The standard navigation links (e.g. as displayed on https://www.eclipse.org) are included in the website footer.

Logos and graphics

  • Project logo includes the trademark symbol; and

  • Project logo is used consistently.

Company Logos

Company logos may optionally be included on a project website, but only if the following conditions are met.

  • The company is a member of the Eclipse Foundation;

  • At least one project committer is an employee of the company in question; and

  • The committer is active (i.e. they have made at least one commit in the last three months).

Community portals, regardless of who owns and maintains them must conform to the branding guidelines. If you discover a website that does not conform to these guidelines (and it is not within your power to effect the changes yourself), send a note to EMO to request assistance.

  • The formal name including appropriate marks, e.g. Eclipse Foo™, is used on the page title, first mention in the text, and on all prominent references to the project;

  • Attributions are provided for all Eclipse Foundation marks;

  • All references to Eclipse open source projects use the formal name with appropriate marks;

  • Trademark and registered trademark symbols are used appropriately;

  • Developers are directed to the official project website for information regarding contribution or related development activities;

  • Ownership of the domain name (especially if it includes the project name) has been transferred to the Eclipse Foundation; and

  • The domain is regarded and used exclusively as a community portal (i.e. is is not presented as the official project website).

Announcements, News items, Blog posts, …​

All announcements regarding project milestones issued by the project must conform to the branding guidelines.

  • The formal name including appropriate marks, e.g. Eclipse Foo™, is used in the title, first mention in the text, and on all prominent references to the project;

  • Attributions are provided for all Eclipse Foundation marks; and

  • All references to Eclipse open source projects use the formal name with appropriate marks.

Glossary

Architecture Council

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

Board of Directors

The business and technical affairs of the Eclipse Foundation are managed by or under the direction of the Eclipse Board of Directors (or more simply, The Board).

Committer

A committer is a software developer who has the necessary rights to write code into the project’s source code repository. Committers are responsible for ensuring that all code that gets written into the project’s source code repository is of sufficient quality. Further, they must ensure that all code written to an Eclipse source code repository is clean from an intellectual property point of view.

Community

Community is a nebulous sort of term. Community is the group of individuals and organisations that gather around your project. In the case of some projects, the community is enormous. Other projects have smaller communities. Developing a community is a very important part of being an Eclipse project as it is from the community that you get feedback, contributions, fresh ideas, and ultimately new committers to help you implement your shared vision. The Eclipse Community is formed from the union of the communities that grow around individual projects.

Contributor

A contributor is anybody who makes contributions to the project. Contributions generally take the form of code patches, but may take other forms like comments on issues, additions to the documentation, answers to questions in forums, and more. All contributors must sign the Eclipse Contributor Agreement (ECA).

Dash Process

The Dash Process, or simply Dash, is a collection of scripts and processes that harvest project data for dissemination in charts, and various services.

Dev-list

Every project has a development list or dev-list. All project committers must subscribe to the list. The dev-list should be the primary means of communication between project committers and is the means through which the EMO and Eclipse Foundation’s automated systems communicate with the project team.

Ecosystem

A commercial ecosystem is a system in which companies, organisations, and individuals all work together for mutual benefit. There already exists a vast ecosystem of companies that base significant parts of their business on Eclipse technology. This takes the form of including Eclipse code in products, providing support, and other services. You become part of an ecosystem by filling the needs of commercial interests, being open and transparent, and being responsive to feedback. Ultimately, being part of a commercial ecosystem is a great way to ensure the longevity of your project: companies that build their business around your project are very motivated to contribute to your project.

Eclipse

This is a tough one. For a significant number of people in the broader community, Eclipse refers to the Eclipse Java IDE which based on the Java development tools (JDT) project and assembled by the Eclipse Packaging Project. However, the term Eclipse is also used to refer to the Eclipse Foundation, the eclipse.org website, the community, the ecosystem, and — of course — The Eclipse Project (which is just one of the top-level projects hosted by the Eclipse Foundation). Confusing? Yes.

Eclipse Contributor Agreement (ECA)

The purpose of the Eclipse Contributor Agreement (ECA) is to provide a written record that a contributor has agreed to provide their contributions of code and documentation under the licenses used by the Eclipse Project(s) to which they are contributing. All contributors who are not already committers on the Eclipse Project to which they are contributing must digitally sign the ECA.

Eclipse Management Organisation (EMO)

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

EMO Executive Director

The EMO Executive Director (EMO/ED) is the head-honcho at the Eclipse Foundation. The Executive Director is ultimately responsible for all the goings-on at the Eclipse Foundation.

EMO IP Team

The EMO Intellectual Property Team (commonly referred to as the Eclipse IP Team or the IP Team) is responsible for implementing the intellectual property policy of the Eclipse Foundation. Contact the Eclipse IP Team via email (emo-ip-team@eclipse.org).

EMO Records

The EMO Records Team (commonly referred to as EMO Records) is responsible for managing committer paperwork and other records on behalf of the Eclipse Foundation. Contact the EMO Records team via email (emo-records@eclipse-foundation.org).

Genie

Genie is the generic term given to automated processes that perform various functions on behalf of project teams, generally focused around builds. The Eclipse Genie performs various tasks (e.g. automated portions of the IP Due Diligence Process) on behalf of the Eclipse Foundation.

Incubation Phase

The purpose of the incubation phase is to establish a fully-functioning open-source project. In this context, incubation is about developing the process, the community, and the technology. Incubation is a phase rather than a place: new projects may be incubated under any existing project.

IP Due Diligence Process

The Intellectual Property Due Diligence Process defines the process by which intellectual property is added to a project. All Eclipse committers must be familiar with this process.

Member Company

The Eclipse Foundation and Eclipse community is supported by our member organisations. Through this support, the Eclipse Foundation provides the open source community with IT, intellectual property, and marketing services.

Project

Projects are where the real work happens. Each project has code, committers, and resources including a website, source code repositories, space on the build and download server, etc. Projects may act as a parent for one or more child projects. Each child project has its own identity, committers, and resource. Projects may, but do not necessarily, have a dedicated website. Projects are sometimes referred to as subprojects or as components. The Eclipse Foundation Development Process, however, treats the terms project, subproject, and component as equivalent.

Project Lead

The project lead is more of a position of responsibility than one of power. The project lead is immediately responsible for the overall well-being of the project. They own and manage the project’s development process, coordinate development, facilitate discussion among project committers, ensure that the Eclipse IP policy is being observed by the project and more. If you have questions about your project, the Eclipse Foundation Development Process, or anything else, ask your project lead.

Project Management Committee (PMC)

Each top-level project is governed by a Project Management Committee (PMC). The PMC has one or more leads along with several members. The PMC has numerous responsibilities, including the ultimate approval of committer elections, and approval of intellectual property contributions. Effectively, the PMC provides oversight for each of the projects that are part of the top-level project. If you have a question that your project lead cannot answer, ask the PMC.

Project Management Infrastructure (PMI)

The Project Management Infrastructure (PMI) is the system that tracks the state and progress of Eclipse projects. Project committers can modify the the information represented in the PMI, including the project description, and information about project releases. Automated systems use this information to, for example, generate dashboard and chart information for the project, intellectual property logs, etc.

Third-party Content (Dependency)

A Third-party Content is content that is leveraged by a Eclipse project that is not produced and/or maintained as an asset of the project.

Top-Level Project (TLP)

A top-level project (sometimes referred to as a TLP) is effectively a container for projects that do the real work. A top-level project does not generally contain code; rather, a top-level project contains other projects. Each top-level project defines a charter that, among other things defines a scope for the types of projects that it contains. Top-level projects are managed by a Project Management Committee.

Vulnerability

This Eclipse Foundation uses the ISO 27005 definition of vulnerability: "A weakness of an asset or group of assets that can be exploited by one or more threats."

Webmaster

Webmaster is often used as an alternative name for the Eclipse IT Team. The IT team is responsible for maintaining the IT infrastructure of the Eclipse Foundation and the Eclipse forge. You can contact the IT team directly by opening a Help Desk issue or via email (webmaster@eclipse-foundation.org).

Working Group

Eclipse Working Groups provide a vendor-neutral governance structure that allow organisations to freely collaborate on new technology development.

Getting Help

If you have any questions, or are unsure of your responsibilities as a project lead or committer, please contact your Project Management Committee (PMC), or the Eclipse Management Organisation (EMO) at emo@eclipse-foundation.org.

To request assistance with matters related to supported project infrastructure (e.g., Git repositories, mailing lists, builds), open a Help Desk issue.

To report vulnerabilities or report security issues contact security@eclipse-foundation.org. Please see Managing and Reporting Vulnerabilities.

To ask questions about licensing or issues of a legal nature, contact license@eclipse-foundation.org.

If you’re not sure, contact emo@eclipse-foundation.org.

Eclipse Foundation Development Process

Version 1.11. Effective September 1, 2023

1. Purpose

This document describes the development process for the Eclipse Foundation. In particular, it describes how the Membership at Large, the Board of Directors, other constituents of the Ecosystem, and the Eclipse Management Organization (EMO) lead, influence, and collaborate with Eclipse Projects to achieve the Purposes defined in the Bylaws.

This document has the following sections:

  • Principles outlines the basic principles upon which the development process is based.

  • Requirements describes the requirements that the Eclipse community has for its development process.

  • Structure and Organization specifies the structure and organization of the Projects and Project community at Eclipse.

  • Development Process outlines the lifecycle and processes required of all Eclipse Projects.

This document defines terms used elsewhere in Eclipse governance documents. In the event of any conflict between the terms set forth in this document and the terms of the documents listed below, the terms of those documents shall take precedence.

1.2 Terms and Definitions

Adopter

Adopters are the individuals and organizations that adopt Eclipse technology for inclusion in their own products and services.

Architecture Council

The Eclipse Architecture Council (AC) is a council of experienced Eclipse committers responsible for identifying and tackling any issues that hinder continued technological success and innovation, widespread adoption, and future growth of Eclipse technology. The Eclipse Architecture Council is formally defined in section VII of the Bylaws of the Eclipse Foundation.

Board of Directors

The business and technical affairs of the Eclipse Foundation are managed by or under the direction of the Eclipse Board of Directors.

Check Point Review

Check Point Review is a category of Review that includes: Creation Review, Progress Review, Release Review, and Graduation Review.

Committer

A committer is a software developer who has the necessary rights to make decisions regarding a Project.

Contributor

A Contributor is anybody who makes contributions to a Project.

Creation Review

A Creation Review is a type of Review that marks a Project’s transition from the Proposal Phase to the Incubation Phase.

Developer

A Committer or Contributor.

Ecosystem

An Ecosystem is a system in which companies, organizations, and individuals all work together for mutual benefit.

Eclipse Management Organization

The Eclipse Management Organization (EMO) consists of the Eclipse Foundation staff, and the Eclipse Architecture Council.

EMO(ED)

The term EMO(ED) generally refers to the Executive Director of the Eclipse Foundation. When discussing matters pertaining to the Eclipse Foundation Development Process, EMO(ED) refers to the subset of the EMO consisting of the Executive Director and whomever he or she may delegate specific approval authority to.

Graduation Review

A Graduation Review is a type of Review that marks a Project’s transition from the Incubation Phase to the Mature Phase.

Incubation Branding

Incubation Branding is the branding that must be applied to all Projects in the Incubation Phase.

Incubation Phase

The Incubation Phase is a Phase during which the Project Team develops the process, the community, and the technology for a new Project.

Integration Build

An Integration Build is a build of the Project content that is generated periodically and made available to the Developer community for testing purposes.

Major Release

A Major Release is a type of Release that includes either significant new functionality and/or breaking changes.

Mature Phase

The Mature Phase is a Phase during which a Project operates with an open and transparent process, has an actively involved and growing community, and produces Eclipse-quality technology.

Membership at Large

The Membership at Large (or Membership) refers to all members of all types, as defined by the Bylaws of the Eclipse Foundation.

Milestone

A Milestone is a build of the Project content intended for limited distribution to demonstrate progress and solicit feedback.

Minor Release

A Minor Release is a type of Release that includes new features over a Major Release.

Nightly Build

A Nightly Build is a build of the Project content that is generated nightly and made available to the Developer community for testing purposes.

Permanent Incubator

A Permanent Incubator is a Project that is intended to perpetually remain in the Incubation Phase.

Phase

A Phase is a stage in the Project lifecycle. See Pre-proposal Phase, Proposal Phase, Incubation Phase, and Mature Phase.

Pre-proposal Phase

The Pre-proposal Phase is a Phase during which a new Project Proposal is created.

Progress Review

A Progress Review a type of Review that is used by a Project Team to summarize the accomplishments of the Project, verify that the Eclipse Development Process and IP Policy have been followed, and to highlight any remaining quality and/or architectural issues.

Project

A Project is the main operational unit for open source software development at the Eclipse Foundation.

Project Lead

A Project Lead, the first level in the Project Leadership Chain, is responsible for the overall well-being of a specific Project and serves as the primary liaison between that Project and the EMO.

Project Leadership Chain

The Project Leadership Chain is composed of a Project’s Project Lead(s), the leadership of the parent Project (if any), the PMC Leads and PMC Members for the Top-Level Project, the EMO, and the EMO(ED).

Project Management Committee

A Project Management Committee (PMC) is the primary leadership of a Top-Level Project with responsibility to ensure that the Projects within its purview are active and viable.

Project Proposal

A Project Proposal (or just Proposal) is a document that is presented to the PMC, Membership at Large, and EMO to describe a potential new Project.

Project Team

A Project Team is the collective of Committers with responsibilities and privileges on a specific Project.

Proposal Phase

The Proposal Phase is a Phase during which a Project Proposal is presented to the community and Membership at Large to solicit feedback.

Release

A Release is a collection of Project artifacts intended for distribution beyond the Project Developers.

Release Candidate

A Release Candidate is a feature-complete Milestone.

Release Review

A Release Review is a type of Progress Review that is aligned directly with a specific Release.

Restructuring Review

A Restructuring review is a type of Review that is used to notify the community of significant changes to one or more Projects.

Review

A Review is formally designated period of time during which the Project Management Committee, the Membership at Large, and the EMO are given an opportunity to survey the current state of a Project, provide feedback, and validate that the Project is in good standing.

Scope

The Scope is the defined range of activities to be undertaken by a Project. The Project Team must operate within the bounds defined by the Project’s Scope.

Service Release

A Service Release, or Bug-fix Release is a type of Release that includes no significant changes or additions over the base Release.

Subproject

A synonym for Project.

Termination Review

A Termination Review is a type of Review that provides a final opportunity for a Project Team, the Project Leadership Chain, and the Eclipse Membership to consider the proposed archival of a Project.

Top-Level Project

A Top-Level Project is an organizational unit that defines an overall mission and scope for a collection of Projects.

Top-Level Project Charter

A Top-Level Project Charter describes the mission, purpose, scope, and operational rules for a Top-Level Project.

2. Principles

The following describes the guiding principles used in developing this development process.

2.1 Open Source Rules of Engagement

  • Open - Eclipse 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.

  • Transparent - Project discussions, minutes, deliberations, Project plans, plans for new features, and other artifacts are open, public, and easily accessible.

  • Meritocratic - Eclipse is a meritocracy. The more you contribute the more responsibility you will earn. Leadership roles in Eclipse are also merit-based and earned by peer acclaim.

2.2 Eclipse Ecosystem

Eclipse as a brand is the sum of its parts (all of the Projects), and Projects should strive for the highest possible quality in extensible frameworks, exemplary applications, transparent processes, and Project openness.

The Eclipse Foundation has the responsibility to …​cultivate…​an Ecosystem of complementary products, capabilities, and services…​. It is therefore a key principle that the Eclipse Foundation Development Process ensures that the Projects are managed for the benefit of both the open source community and the Ecosystem members. To this end, all Eclipse Projects are required to:

  • communicate their Project plans and plans for new features (major and minor) in a timely, open and transparent manner;

  • create high-quality frameworks capable of supporting the building of commercial grade products on top of them; and

  • ship extensible, exemplary applications which help enable a broad community of users.

2.3 Three Communities

Essential to the Purposes of the Eclipse Foundation is the development of three inter-related communities around each Project:

2.3.1 Developers

A thriving, diverse, and active community of Developers is the key component of any Eclipse Project. Ideally, this community should be an open, transparent, inclusive, and diverse community of Committers and (non-Committer) Contributors. Attracting new Contributors and Committers to an open source Project is time consuming and requires active recruiting, not just passive "openness". The Project Leadership must make reasonable efforts to encourage and nurture promising new Contributors.

2.3.2 Users

An active and engaged user community is proof-positive that the Project’s exemplary applications are useful and needed. Furthermore, a large user community is one of the key factors in creating a viable Ecosystem around an Eclipse Project, thus encouraging additional open source and commercial organizations to participate. Like all good things, a user community takes time and effort to bring to fruition, but once established is typically self-sustaining.

2.3.3 Adopters

An active and engaged Adopter community is the only way to prove that an Eclipse Project is providing extensible frameworks and applications accessible via documented APIs. Reuse of the frameworks within the companies that are contributing to the Project is necessary, but not sufficient to demonstrate an Adopter community. Again, creating, encouraging, and nurturing an Adopter community outside of the Project’s Developers takes time, energy, and creativity by the Project Leadership, but is essential to the Project’s long-term open source success.

The Eclipse community considers the absence of any one or more of these communities as proof that the Project is not sufficiently open, transparent, and inviting, and/or that it has emphasized applications at the expense of extensible frameworks or vice versa.

2.4 Clear, Concise, and Evolving

It is an explicit goal of the development process to be as clear and concise as possible so as to help the Project Teams navigate the complexities, avoid the pitfalls, and become successful as quickly as possible.

This document imposes requirements and constraints on the operation of the Projects, and it does so on behalf of the larger Eclipse community. It is an explicit goal of the development process to provide as much freedom and autonomy to the Projects as possible while ensuring the collective qualities benefit the entire Eclipse community.

Similarly, this document should not place undue constraints on the EMO or the Board of Directors that prevent them from governing the process as necessary. We cannot foresee all circumstances and as such should be cautious of being overly prescriptive and/or requiring certain fixed metrics.

The frameworks, applications, Projects, processes, community, and even the definition of quality continues to, and will continue to, evolve. Creating rules or processes that force a static snapshot of any of these is detrimental to the health, growth, and Ecosystem impact of Eclipse.

Part of the strength of this document is in what it does not say, and thus opens for community definition through convention, guidelines, and public consultation. A document with too much structure becomes too rigid and prevents the kind of innovation and change we desire for Eclipse. In areas where this document is vague, we expect the Projects and members to engage the community-at-large to clarify the current norms and expectations.

2.5 Freedom of Action

Projects are required to engage in practices that ensure the continued viability of the Project, independent from the continued availability of external resources and services, or continued participation on any single individual, organization, or group.

In practical terms, Projects are required to use resources and services approved by the Eclipse Foundation. This includes (but is not limited to) all source code management, distribution channels for artifacts, issue tracking, documentation, and public communication channels.

3. Requirements

This document is entirely composed of requirements. In addition to the requirements specified in this development process, the EMO is instructed to clarify, expand, and extend this process by creating a set of development guidelines to advance the creation, evolution, promotion, and support of the open source Projects; and to cultivate both a community and an Ecosystem of complementary products and services.

3.1 EMO Responsibility

The EMO has the responsibility and authority to mitigate issues that arise when Committers fail to perform the required behaviors or engage in practices that risk harm to Eclipse Projects, the community, and/or Ecosystem. This includes, but is not limited to, issues that arise due to a failure to implement the Eclipse Foundation Vulnerability Reporting Policy, the Eclipse Foundation Intellectual Property Policy, the Eclipse Foundation Community Code of Conduct, or other governance policies of the Eclipse Foundation.

The EMO’s authority includes, but is not limited to, the ability grant specific individuals equivalent to Committer privileges, suspend access to Project resources, add or remove Committers and Project Leads, and—​in extreme cases—​terminate the Project.

The EMO is not permitted to override or ignore the requirements listed in this document without the express written endorsement of the Board of Directors.

The motivation for the EMO to take action along with description of the steps taken as part of the mitigation must be publicly disclosed within one week of action being taken. The Grievance Handling section of this document describes the means by which a Member may respond in the event that they believe that the EMO has overstepped its authority.

4. Project Structure and Organization

A Project is the main operational unit at Eclipse. Specifically, all open source software development at Eclipse occurs within the context of a Project. Projects have leaders, Developers, code, builds, downloads, websites, and more. Projects are more than just the sum of their many parts, they are the means by which open source work is organized when presented to the communities of Developers, Adopters, and users. Projects provide structure that helps Developers expose their hard work to a broad audience of consumers.

Eclipse Projects are organized hierarchically. A special type of Project, Top-Level Projects, sit at the top of the hierarchy. Each Top-Level Project contains one or more Projects. Each Project may itself contain zero or more Projects. A Project that has one or more Projects is said to be the parent of those Projects. A Project that has a parent is oftentimes referred to as a Subproject. The term Project refers to either a Top-Level Project or a Subproject.

The descendants of a Project are the Project itself and transitive closure of its child Projects. The top parent of a Project is the Top-Level Project at the top of the hierarchy.

Projects are the unit entity for:

  • Committers;

  • code and Releases;

  • intellectual property (IP) records; and

  • community awareness

4.1 Committers

Each Project has exactly one set of Committers. Each Project’s set of Committers is distinct from that of any other Project, including Subprojects or parent Projects. All Project Committers have equal rights and responsibilities within the Project. Partitioning of responsibility within a Project is managed using social convention. A Project may, for example, divide itself into logical partitions of functionality; it is social convention that prevents Committers from one logical partition from doing inappropriate work in another. If finer-grained management of Committer responsibilities is required, a Project should consider partitioning (via a Restructuring Review) into two or more Subprojects.

The Committers of a Project have the exclusive right to elect new Committers to their Project; no other group, including a parent Project, can force a Project to accept a new Committer.

There is no roll-up of Committers: the set of Committers on a Project is exactly that set of people who have been explicitly elected into that role for the Project (i.e. being a Committer on a Subproject does not give you any automatic rights on the "parent" Project or any child Project).

In practical terms, each Project has a single UNIX group of its Committers that provides write-access to the Project’s resources. Pictorially below, we see that a Project, in addition to the various resources and Committers it has, can also have zero or more Subprojects. Each of these Subprojects has its own distinct set of Committers and resources.

resources
Project Committers, resources, and Subprojects

4.2 Code and Resources

Each Project owns and maintains a collection of resources.

Resources may include source code, a Project website, space on the downloads server, access to build resources, and other services provided by the Eclipse Foundation infrastructure. The exact infrastructure provided by the Eclipse Foundation varies over time and is defined outside this process document.

A Project is not strictly required to make use of all the resources made available; a Project might, for example, opt to not maintain a source code repository. Such a Project might operate as an organizational unit, or container, for several Subprojects. Similarly, a Project might opt to provide a consolidated website, build and/or download site for its Subprojects (the Subprojects would then not require those resources for themselves).

Namespaces are assigned to a Project by the EMO. All Project source code must be organized in the assigned namespaces and Projects can only Release code under their own namespace (that is, they cannot infringe on another Eclipse Project’s namespace).

4.4 Community Awareness

Projects are the level of communication with the larger Eclipse community and Ecosystem. Projects may either have their own communications (website, mailing lists, forums/newsgroups, etc) or they may be part of a parent Project’s communications (website, mailing list, forums/newsgroups, etc). In either case, the Project is required to maintain an open and public communication channel with the Eclipse community including, but not limited to, Project plans, schedules, and design discussions.

All Projects must make the communication channels easy to find. Projects are further required to make the separate communication channels of their child Projects (if any) easy to find.

Any Project in the Incubation Phase must correctly identify its website and Releases. A Project with at least one descendant Project in Incubation Phase must correctly annotate its own website so as to notify the Eclipse community that incubating Projects exist in its hierarchy. Any Release containing code from an Incubation Phase Project must be correctly labeled, i.e., the Incubation Phase is viral and expands to cover all Releases in which it is included.

4.5 Scope

Each Top-Level Project has a Charter which describes the purpose, Scope, and operational rules for the Top-Level Project. The charter should refer to, and describe any refinements to, the provisions of this development process. The Board of Directors approves the charter of each Top-Level Project.

Subprojects do not have separate charters; Subprojects operate under the charter of their parent Top-Level Project.

All Projects have a defined Scope and all initiatives within that Project are required to reside within that Scope. Initiatives and code that is found to be outside the Scope of a Project may result in the termination of the Project. The Scope of Top-Level Projects is part of the charter, as approved by the Board of Directors of the Eclipse Foundation.

The Scope of a Subproject is defined by the initial Project Proposal as Reviewed and approved by the Project Management Committee (PMC) (as further defined below) of the Project’s top parent and by the EMO. A Project’s Scope must be a subset of its parent’s Scope.

4.6 Leaders

There are two different types of Project Leadership at Eclipse: The Project Management Committee (PMC) and Project Leads. Both forms of leadership are required to:

  • ensure that their Project is operating effectively by guiding the overall direction and by removing obstacles, solving problems, and resolving conflicts;

  • operate using open source rules of engagement: meritocracy, transparency, and open participation; and

  • ensure that the Project and its Subprojects (if any) conform to the Eclipse Foundation IP policy and procedures.

The leadership chain for a Project is composed of the Project’s Project Lead(s), the leadership of the parent Project (if any), the PMC leads and PMC members for the Top-Level Project, the EMO, and the EMO(ED).

In exceptional situations—such as Projects with zero active Committers, disruptive Committers, or no effective Project Leads—the Project Leadership Chain has the authority to make changes (add, remove) to the set of Committers and/or Project Leads of that Project, and otherwise act on behalf of the Project Lead.

4.6.1 Project Management Committee (PMC)

Top-Level Projects are managed by a Project Management Committee (PMC). A PMC has one or more PMC leads and zero or more PMC Members. Together the PMC provides oversight and overall leadership for the Projects that fall under their Top-Level Project. The PMC as a whole, and the PMC leads in particular, are ultimately responsible for ensuring that the Eclipse Foundation Development Process is understood and followed by their Projects. The PMC is additionally responsible for maintaining the Top-Level Project’s charter.

PMC leads are approved by the Board of Directors; PMC members are elected by the existing PMC leads and members, and approved by the EMO(ED).

In the unlikely event that a member of the PMC becomes disruptive to the process or ceases to contribute for an extended period, the member may be removed by the unanimous vote of the remaining PMC members, subject to approval by the EMO. Removal of a PMC Lead requires approval of the Board of Directors.

4.6.2 Project Lead

Eclipse Projects are managed by one or more Project Leads. Project Leads are responsible for ensuring that their Project’s Committers are following the Eclipse Foundation Development Process, and that the Project is engaging in the right sorts of activities to develop vibrant communities of users, Adopters, and Contributors. The initial Project Leads are appointed and approved in the Creation Review. Subsequently, additional Project Leads must be elected by the Project’s Committers, approved by the Project’s PMC, and appointed by the EMO(ED).

To hold a Project Lead role on a Project, an individual must also hold a Committer role on that Project.

In the unlikely event that a Project Lead becomes disruptive to the process or ceases to contribute for an extended period, the individual may be removed by the unanimous vote of the remaining Project Leads (if there are at least two other Project Leads), or unanimous vote of the Project’s PMC.

4.7 Committers and Contributors

Each Project has a development team, led by the Project Leaders. The development team is composed of Committers and Contributors. Contributors are individuals who contribute code, fixes, tests, documentation, or other work that is part of the Project. Committers have write access to the Project’s resources (source code repository, bug tracking system, website, build server, downloads, etc.) and are expected to influence the Project’s development.

Contributors who have the trust of the Project’s Committers can, through election, be promoted Committer 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 member company or any company employing existing Committers.

The election process begins with an existing Committer on the same Project nominating the Contributor. The Project’s Committers will vote for a period of no less than one week. If there are at least three (3) positive votes and no negative votes within the voting period, the Contributor is recommended to the Project’s PMC for commit privileges. If there are three (3) or fewer Committers on the Project, a unanimous positive vote of all Committers is substituted. If the PMC approves, and the Contributor signs the appropriate Committer legal agreements established by the EMO (wherein, at the very least, the Developer agrees to abide by the Eclipse Intellectual Property Policy), the Contributor becomes a Committer and is given write access to the source code for that Project.

At times, Committers may become inactive for a variety of reasons. The decision making process of the Project relies on active Committers who respond to discussions and vote in a constructive and timely manner. The Project Leads are responsible for ensuring the smooth operation of the Project. A Committer who is disruptive, does not participate actively, or has been inactive for an extended period may have his or her commit status revoked by the unanimous consent of the Project Leads. Unless otherwise specified, "an extended period" is defined as "no activity for more than six months".

Active participation in the user communication channels and the appropriate Developer mailing lists is a responsibility of all Committers, and is critical to the success of the Project. Committers are required to monitor and contribute to the user communication channels.

Committers are required to monitor the mailing lists associated with the Project. This is a condition of being granted commit rights to the Project. It is mandatory because Committers must participate in votes (which in some cases require a certain minimum number of votes) and must respond to the mailing list in a timely fashion in order to facilitate the smooth operation of the Project. When a Committer is granted commit rights they will be added to the appropriate mailing lists. A Committer must not be unsubscribed from a Developer mailing list unless their associated commit privileges are also revoked.

Committers are required to track, participate in, and vote on, relevant discussions in their associated Projects. There are three voting responses: +1 (yes), -1 (no, or veto), and 0 (abstain).

Committers are responsible for proactively reporting problems in the bug tracking system, and annotating problem reports with status information, explanations, clarifications, or requests for more information from Contributors. Committers are responsible for updating problem reports when they have done work related to the problem.

Committer, PMC lead or member, Project Lead, and council representative(s) are roles; an individual may take on more than one of these roles simultaneously.

4.9 Permanent Incubator Projects

A Project may designate a Subproject as a "Permanent Incubator". A Permanent Incubator is a Project that is intended to perpetually remain in the Incubation Phase. Permanent Incubators are an excellent place to innovate, test new ideas, grow functionality that may one day be moved into another Project, and develop new Committers.

Permanent Incubator Projects never have Releases. Permanent Incubators may have builds, and downloads. They conform to the standard Incubation Branding requirements and are subject to the IP due diligence rules outlined for incubating Projects. Permanent Incubators do not graduate.

The Scope of a Permanent Incubator Project must fall within the Scope of its parent Project. The Committer group of the Permanent Incubator Project must overlap with that of the parent Project (at least one Committer from the parent Project must be a Committer for the incubator). The parent Project’s Committers are responsible for ensuring that the incubator Project conforms to the rules set forth by the Eclipse Foundation Development Process.

A Permanent Incubator Project must be designated as such by including the word "Incubator" in its name (e.g. "Eclipse Dash Incubator"). To do otherwise is considered exceptional and requires approval from the PMC and EMO(ED).

Only Top-Level Projects and Projects in the Mature Phase may create a Permanent Incubator. Permanent Incubator Projects are created upon request; a Creation Review is not required.

4.10 Project Plans

Projects are required to make a Project plan available to their community at the beginning of the development cycle for each major and Minor Release. The plan may be as simple as a short description and a list of issues, or more detailed and complex. Subprojects may opt to include their plans with those of their parent Project.

Project Plans must be delivered to the community through communication channels approved by the EMO. The exact nature of the Project plan varies depending on numerous variables, including the size and expectations of the communities, and requirements specified by the PMC.

6. Development Process

Projects must work within their Scope. Projects that desire to expand beyond their current Scope must seek an enlargement of their Scope using a public Review as described below. Further, Projects must fit within the Scope defined by their containing Projects and the Scope defined in the charter of their Top-Level Project.

Projects must provide advanced notification of upcoming features via their Project plan.

6.2 Project Lifecycle

Projects go through distinct Phases. The transitions from Phase to Phase are open and transparent public Reviews.

lifecycle
An overview of the Project lifecycle Phases
6.2.1 Pre-Proposal Phase

An individual or group of individuals declares their interest in, and rationale for, establishing a Project. The EMO will assist such groups in the preparation of a Project Proposal.

The Pre-Proposal Phase ends when the proposal is published by EMO and announced to the Membership at Large by the EMO.

6.2.2 Proposal Phase

The proposers, in conjunction with the destination PMC and the community, collaborate in public to enhance, refine, and clarify the proposal.

The Proposal Phase ends with a Creation Review, or withdrawal. The proposal may be withdrawn by the proposers at any point before the start of a Creation Review. The EMO will withdraw a proposal that has been inactive for more than six months.

6.2.3 Incubation Phase

The purpose of the Incubation Phase is to establish a fully-functioning open-source Project. In this context, incubation is about developing the process, the community, and the technology. Incubation is a Phase rather than a place: new Projects may be incubated under any existing Project.

  • A Project in the Incubation Phase can (and should) make Releases;

  • Top-Level Projects skip incubation and are immediately put into the Mature Phase;

  • The Incubation Phase ends with a Graduation Review or a Termination Review.

  • Designated Permanent Incubator Projects remain perpetually in the Incubation Phase; they do not create Releases, so no Reviews are required.

Many Eclipse Projects are proposed and initiated by individuals with extensive and successful software development experience. This document attempts to define a process that is sufficiently flexible to learn from all its participants. At the same time, however, the Incubation Phase is useful for new Projects to learn the community-defined Eclipse-centric open source processes.

6.2.4 Mature Phase

The Project Team has demonstrated that they are an open-source Project with an open and transparent process, an actively involved and growing community, and Eclipse-quality technology. The Project is now a mature member of the Eclipse community.

6.2.6 Archived

Projects that become inactive, either through dwindling resources or by reaching their natural conclusion, are archived. Projects are moved to archived status through a Termination Review.

If there is sufficient community interest in reactivating an archived Project, the Project can start again with a Creation Review. As there must be good reasons to have terminated a Project, the Creation Review provides a sufficiently high bar to prove that those reasons are no longer valid.

6.3 Reviews

The Eclipse Foundation Development Process is predicated on open and transparent behavior. All major changes to Eclipse Projects must be announced and Reviewed by the Membership at Large. Major changes include the Project Phase transitions as well as the introduction or exclusion of significant new technology or capability. It is a clear requirement of this document that members who are monitoring the appropriate media channels not be surprised by the post-facto actions of the Projects.

Projects are responsible for initiating the appropriate Reviews. If it is determined to be necessary, the Project Leadership Chain (e.g. the PMC or EMO) may initiate a Review on the Project’s behalf.

All Reviews have the same general process:

  1. The Project Team will complete all required due diligence under the Eclipse IP Policy prior to initiating the Review.

  2. A Project representative (Project Lead or Committer) assembles Review documentation.

  3. A Project representative presents the Review documentation to the Project’s PMC along with a request to proceed with the Review and for approval of the corresponding documentation.

  4. Upon receiving approval from the PMC, a Project representative makes a request to the EMO to schedule the Review.

  5. The EMO announces the Review schedule and makes the documentation available to the Membership at Large.

  6. The EMO approves or fails the Review based on the feedback, the Scope of the Project, and the Purposes of the Eclipse Foundation as defined in the bylaws.

The Review documentation requirements, and criteria for the successful completion of each type of Review will be documented by the EMO. PMCs may establish additional success criteria.

The Review period is open for no less than one week and usually no more than two weeks. The Review ends with the announcement of the results in the defined Review communication channel.

If any member believes that the EMO has acted incorrectly in approving or failing a Review may appeal to the Board of Directors to Review the EMO’s decision.

6.3.1 Creation Review

The purpose of the Creation Review is to assess the community and Membership at Large response to the proposal, to verify that appropriate resources are available for the Project to achieve its plan, and to serve as a Committer election for the Project’s initial Committers. The Eclipse Foundation strives not to be a repository of "code dumps" and thus Projects must be sufficiently staffed for forward progress.

The Creation Review documents must include short nomination bios of the proposed initial Committers. These bios should discuss their relationship to, and history with, the incoming code and/or their involvement with the area/technologies covered by the proposal. The goal is to help keep any legacy Contributors connected to new Project and explain that connection to the current and future Eclipse Membership at Large, as well as justify the initial Committers' participation in a meritocracy.

6.3.2 Graduation Review

The purpose of the Graduation Review is to mark a Project’s change from the Incubation Phase to the Mature Phase.

The Graduation Review confirms that the Project is/has:

  • A working and demonstrable code base of sufficiently high quality.

  • Active and sufficiently diverse communities appropriate to the size of the graduating code base: Adopters, Developers, and users.

  • Operating fully in the open following the principles and Purposes of Eclipse.

  • A credit to Eclipse and is functioning well within the larger Eclipse community.

A Graduation Review is generally combined with a progress or Release Review.

6.3.3 Release Review

A Release Review is a type of Progress Review that is aligned directly with a specific Release. A Release Review must be concluded successfully before the corresponding Release is announced to the community.

6.3.5 Progress Review

The purposes of a Progress Review are: to summarize the accomplishments of the Project, to verify that the IP Policy is being followed, to highlight any remaining quality and/or architectural issues, and to verify that the Project is continuing to operate according to the principles and Purposes of Eclipse.

6.3.6 Termination Review

The purpose of a Termination Review is to provide a final opportunity for the Committers and/or Eclipse Membership at Large to discuss the proposed archiving of a Project. The desired outcome is to find sufficient evidence of renewed interest and resources in keeping the Project active.

6.3.8 Restructuring Review

The purpose of a Restructuring Review is to notify the community of significant changes to one or more Projects. Examples of "significant changes" include:

  • Movement of significant chunks of functionality from one Project to another.

  • Modification of the Project structure, e.g. combining multiple Projects into a single Project, or decomposing a single Project into multiple Projects.

  • Change of Project Scope.

6.3.9 Combining Reviews

Reviews can be combined at the discretion of the PMC and EMO. Multiple Projects may participate in a single Review. Similarly, multiple Review types can be engaged in simultaneously. A parent Project may, for example, engage in an aggregated Progress Review involving itself and some or all of its child Projects; a consolidated Restructuring Review may move the code for several Projects; or a Progress Review may be combined with a Graduation Review. When multiple Reviews are combined, the Review documentation must explicitly state all of the Projects and types of Reviews involved, and include the required information about each.

It should be noted that the purpose of combining Reviews is to better serve the community, rather than to reduce effort on the part of the Project (though it is fortunate when it does both). Combining a progress and Graduation Review, or aggregating a Progress Review of a Project and several of its child Projects generally makes sense. Combining Progress Reviews for multiple unrelated Projects most likely does not.

6.4 Releases

Any Project, with exception of Permanent Incubators, may make a Release. A Release may include the code from any subset of the Project’s descendants.

(Most of this section is paraphrased from the excellent Apache Software Foundation Releases FAQ. The Eclipse community has many of the same beliefs about Releases as does the Apache community and their words were already excellent. The Apache Software Foundation Releases FAQ is distributed under the Apache License, Version 2.0.)

Releases are, by definition, anything that is distributed outside of the Committers of a Project. If consumers are being directed to download a build, then that build has been released (modulo the exceptions below). All Projects and Committers must obey the Eclipse Foundation requirements on approving any Release.

The Eclipse IP Policy must be followed at all times. Prior to issuing any Release, the Project Lead must assert that the IP Policy has been followed and all approvals have been received.

The Project Team must provide (either directly or indirectly) a link between the distribution form of Release artifacts and the corresponding source code.

A Project can make official Releases for one calendar year following a successful Progress Review or Release Review. The Project Leadership Chain may—​at its discretion—​require that the Project engage in additional Reviews (e.g. a progress or Release Review) prior to issuing a Release.

Exception 1: Nightly and Integration Builds During the process of developing software and preparing a Release, various nightly and Integration Builds are made available to the Developer community for testing purposes. Do not include any links on the Project website, blogs, wikis, etc. that might encourage non-early-adopters to download and use Nightly Builds, Release Candidates, or any other similar package (links aimed at early-adopters and the Project’s Developers are both permitted and encouraged). The only people who are supposed to know about such packages are the people following the Developer mailing list and thus are aware of the limitations of such builds.

Exception 2: Milestone and Release Candidate Builds Projects are encouraged to use an agile development process including regular Milestones (for example, six week Milestones). Milestones and Release Candidates are "almost Releases" intended for adoption and testing by early-adopters. Projects are allowed to have links on the Project website, blogs, wikis, etc. to encourage these outside-the-Committer-circle early-adopters to download and test the Milestones and Release Candidates, but such communications must include caveats explaining that these are not official Releases. Milestones and Release Candidate builds must be labeled as such (e.g. x.yMn, x.yRCn, alpha, beta, or similar).

Exception 3: Service Releases with no new features Service Releases with no significant changes or additions over the base Release are allowed to be released without an additional Review.

Under no circumstances are builds and Milestones to be used as a substitute for doing proper official Releases. Proper Release management and Reviews is a key aspect of Eclipse quality.

Releases and corresponding artifacts for Projects in the Incubation Phase must be labeled to indicate the incubation status of the Project. See Incubation Branding for more information.

6.5 Grievance Handling

When a member has a concern about a Project, the member will raise that concern with the Project’s leadership. If the member is not satisfied with the result, the member can raise the concern with the parent Project’s leadership. The member can continue appeals up the Project Leadership Chain and, if still not satisfied, thence to the EMO, then the executive director, and finally to the Board of Directors. All appeals and discussions will abide by the guiding principles of being open, transparent, and public.

Member concerns may include:

  • Out of Scope. It is alleged that a Project is exceeding its approved Scope.

  • Dysfunctional. It is alleged that a Project is not functioning correctly or is in violation of one or more requirements of the Eclipse Foundation Development Process.

  • Contributor appeal. It is alleged that a Contributor who desires to be a Committer is not being treated fairly.

  • Invalid veto. It is alleged that a -1 vote on a Review is not in the interests of the Project and/or of Eclipse.

A variety of grievance resolutions are available to the EMO up to, and including, rebooting or restarting a Project with new Committers and leadership.

7. Precedence

In the event of a conflict between this document and a Board of Directors-approved Project charter, the most recently approved document will take precedence.

8. Revisions

As specified in the Bylaws, the EMO is responsible for maintaining this document and all changes must be approved by the Board of Directors.

Due to the continued evolution of the Eclipse technology, the Eclipse community, and the software marketplace, it is expected that the Eclipse Foundation Development Process (this document) will be reviewed and revised on at least an annual basis.

The EMO is further responsible for ensuring that all plans, documents and reports produced in accordance with this development process be made available to the Membership at Large via an appropriate mechanism in a timely, effective manner.

Data Protection Impact Assessment Guidelines

Version 1.0 Last updated: September 11, 2019

This document is meant to provide advice to the Eclipse Foundation projects and community, in order to help determine where and when a data protection impact assessment (DPIA) is required and what it should contain.

This document is maintained by the Eclipse Foundation and the following individuals are responsible for it:

  • Paul White, Data Protection Officer

  • Matt Ward, IT Manager

  • Denis Roy, IT Director

The General Data Protection Regulation (GDPR) requires a DPIA be completed when there is a “high risk to the rights and freedoms of natural persons” due to the collection and processing of data. Some examples of this would be things like:

  • Combining data sets in order to profile users;

  • Where the collected data can be used to make automated decisions about a person or to deny them access to services; or

  • The data is personally sensitive.

When considering the risk you should adopt the perspective of the person providing this information. Would you feel comfortable providing this information to someone else, what concerns would you have about the handling or management of the data?

What should a DPIA include?

At a minimum a good DPIA includes:

  • A description of the planned processing operations;

  • An explanation of why you are collecting this data, and how you plan to use it;

  • An assessment of the risks to individuals; and

  • How do you plan to protect this data (technologically or procedurally).

As a best practice the results from creating a DPIA should be published, in order to promote transparency and trust in the people performing the assessment. However you may wish to produce a slightly ‘pared down’ version for publication if the original version would cause security of the data to be compromised

Example 2. Example Data Protection Impact Assessment

Fish Data Protection Impact Assessment

The Fish IoT project is looking to start combining data from a family of IoT devices (PetFinder Plus series) that are produced by a third-party, and to combine that with data from our public management server in order to produce a contact list of people.

We will do this by using cloud based virtual servers and cross referencing the email addresses stored in our management server with the registration email stored by the PetFinder plus devices and provided by the device when it is contacted by the registration server.

There is a moderate risk to individuals as they may be using email addresses that are not published elsewhere, and the data returned from the remote devices can contain GPS coordinates which could allow a specific individual to be identified.

In order to reduce the risks we:

  • Use SSL/TLS to protect the data in transit between our server and the remote device;

  • Ensure that the data storage area is encrypted using commercially available tools;

  • Limit access to the information to only those identified in our Data retention policy;

  • Keep the data only as long as needed, in keeping with out Data retention policy; and

  • Engage in active monitoring of the server and associated access requests.

Change Log

  • 2024-01-31 Include a change log

  • 2024-01-30 Be consistent that the copyright year is the year of initial creation

  • 2024-01-15 Domains that leverage EF trademarks must be owned by the EF #182

  • 2024-01-15 Add a link to the project lead role description.

  • 2023-12-08 Move content regarding creation reviews from the wiki

  • 2023-12-08 Fix the bullet list of services.

  • 2023-12-08 All project resources are publicly accessible.

  • 2023-12-04 Add IP FAQ entries regarding the Dash License Tool

  • 2023-12-04 Correctly format the URLs as passthrough values.

  • 2023-12-04 Update random links that had been pointing to the old wiki

  • 2023-12-04 Update CBI links.

  • 2023-12-04 Update Simultaneous Release links.

  • 2023-12-04 Add more help regarding the types of source references we can handle.

  • 2023-12-04 Remove the content regarding the Issues tab on release records.

  • 2023-10-31 Spell "organisation" correctly.

  • 2023-10-31 Add a note that describes how to start a graduation review.

Back to the top