Skip to main content
Eclipse Project Handbook


Copyright © 2015, 2018 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.

Version 1.0M1.


This document provides you with the information that you need to create a new Eclipse open source project or become a committer on an existing one.

The Eclipse Development Process (EDP) is the foundational document for Eclipse projects and committers. It describes the manner in which we do open source software. The Eclipse Development Process does not prescribe any particular development methodology; it is more concerned with the larger-scale aspects of open source project lifecycle, including such things as reviews, processes for running votes and elections, bringing new committers onto a project, etc. This document will elaborate on some key points of the Eclipse Development Process.


Four basic principles lie at the heart of the Eclipse Development Process:

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


Employment status has no bearing at whether or not somebody can participate in an open source project at Eclipse. Employment does not guarantee committer status; committer status must be earned by everybody.

Vendor neutrality is similar to openness in that it’s concerned with maintaining a level playing field. No vendor is permitted to dominate a project, and nobody can be excluded from participating in a project based on their employment status. While project resources will contain copyright statements that assert ownership of various assets by individual vendors, the project itself must remain vendor neutral.

Quality and intellectual property cleanliness are also important principles.

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

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

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

Starting an Open Source Project at 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.

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.

An overview of the Project Creation Process
An overview of the Project Creation Process

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


Keep track of the URL of the proposal. We do not provide public links to the document until after the proposal is opened for community review.

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

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

At the beginning of the community review period, the EMO will announce the proposal on several channels (the Project Activity News page, Twitter, the Proposals Forum, 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 Bugzilla—​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.

The Eclipse Foundation holds the trademark for all Eclipse projects. Trademark assignment is undertaken prior to the creation of any new project. If you already have a trademark on your project name, that trademark must be assigned to the Eclipse Foundation. Be advised that trademark assignment can be a time-consuming process (it can take hours, days, or weeks depending on the circumstances surrounding the name). If you currently hold the trademark, you will be asked to complete a Trademark Transfer Agreement.

The proposal must list at least one mentor from the Eclipse Architecture Council. Members of the Eclipse Architecture Council have considerable experience with Eclipse Foundation practices, and the Eclipse Development Process. The EMO will engage directly with the Architecture Council to identify mentors as necessary. Mentors are assigned to the project through the incubation phase; they are released from their duties when the project graduates.

When the project name trademark has been secured, a mentor has been identified, and the proposal contents are finalized, the EMO will schedule a creation review. Reviews—​which run for a minimum of one week—​are scheduled twice a month, generally concluding on the first and third Wednesday of each month. The creation review may overlap with the community review period.


Creation reviews tend to always be successful. They should be considered low stress as the hard work has already been done in advance of the start of the review.


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

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


The provisioning process will not start until after the paperwork for at least one project committer is received and processed by the EMO Records Team. If you can be ready with the paperwork in time for the completion of the creation review, then we can move quickly through the provisioning process.

When we initiate provisioning, committers will be sent an email with instructions; please don’t send any paperwork in until after you receive those instructions.

When the paperwork is received and processed for one committer, the Eclipse Webmaster will begin the resources provisioning process. When that process is complete, the Eclipse Webmaster 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.

Project teams interact with the Eclipse IP Team via the IPZilla system using Contribution Questionnaires (CQs). Those members of the project team that are included in the CQ’s CC list will be informed of progress via email.


The IP Team will indicate check-in permission by adding the checkin keyword and final approval by setting the state of the CQ to approved. Do not push any code into the project repository until after the Eclipse IP Team has indicated that you are ready to do so.

Third party content that is required by the project code must also be reviewed by the Eclipse IP Team. Project teams that are new to the process should start by raising no more than three CQs for third party content in order to gain an understanding of the third party review process before proceeding to enter all requests.

Post creation activities
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

All new projects start in the 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 practicing the open and public processes necessary to establish the three communities (developers, adopters, and users) around the project.

Egg incubation
The Incubation Logo

In order to alert potential consumers of the incubating nature, projects in the incubation phase must include incubation branding. The project team must:

  • Display the incubation logo on their project web page (if they have one);

  • Display the incubation logo on their project’s primary download page;

  • Include the word "incubation" in the filename of all downloadable files (when technically feasible) for builds and milestones; and

  • When technically feasible, include the word "incubation" in features (e.g. about dialogs, feature lists, and installers).

There are no incubation branding requirements for general user interface elements.


For projects that produce OSGi artifacts, include the word "incubation" in the Bundle-Name, feature names, and p2 repositories. The word "incubation" should not be included in technical namespaces (especially when it may result in confusion when the project leaves incubation). e.g. an OSGi bundle’s Bundle-SymbolicName, or a Java package name.

Incubating projects that correctly conform to the incubation branding rules outlined above may take advantage of the Parallel IP Process. They 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 Development Process, the project may opt to graduate into the 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 behavior;

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

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

Frequently Asked Questions

  1. How do I find Eclipse Architecture Council mentors?

    You don’t have to find them yourself. Focus on the content of the proposal. We can solicit mentors from the Eclipse Architecture Council after the proposal has been opened for community review.

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

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

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

  4. 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 Eclipse Webmaster will let you know when provisioning is complete.

  5. Does the new project have to use Git?

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

  6. Can I host my project code on GitHub?

    New projects can make use of GitHub. Official project repositories must be moved under the Eclipse Organization at GitHub. Official repositories are subject to the same intellectual property due diligence rules and processes that all Eclipse project repositories must follow.

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

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

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

    Please see the glossary.

Project Resources and Services

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

  • All project issues must be tracked in the issue tracker assigned to the project;

  • Source code must be maintained in source code repositories assigned to the project (e.g. an Eclipse Git or Gerrit instance, or an organization on GitHub maintained by the Eclipse Foundation);

  • All third party content used by the project must be tracked and approved for use by the Eclipse IP Team;

  • Downloads must be distributed via a forge-specific downloads server;

  • Developer (committer) communication must occur in the dev list provided to the project by the Eclipse Foundation; and

  • Projects must keep their Project Metadata up-to-date.


Project resources make use of two sorts of ids:

Short name

The short name is used in various parts of Eclipse Foundation infrastructure (e.g. the name of the project’s directory on the downloads and Git servers, and the URL for the project website). The short name may contain lowercase alphanumeric characters, dashes, and underlines; but does not contain periods.

Qualified identifier

The project’s short name is joined with the short name of the parent project(s) to form a qualified identifier (project id) for the project that is used as a key on services generated and/or maintained for the project by the Eclipse Foundation.

For example the "Eclipse Woolsey" project has a short name of "woolsey"; its qualified 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.

Source Code Management

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

In order for the project to operate in an open manner, it must be possible for potential contributors to have access to the code base in its most current form, so all ongoing development must be regularly pushed to these canonical repositories.

Eclipse Contributor Agreement (ECA)

The Eclipse Foundation has implemented the Eclipse Contributor Agreements (ECA) to improve intellectual property (IP) management and workflow. All contributors, who are not committers on the Eclipse project, must sign the ECA.

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

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 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 <> 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 <> 4
    Signed-off-by: Some Body <> 5
1 The email address of the author must match the email address on the Eclipse Foundation Account.
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.
5 Non-committers must sign-off the commit, indicating that they aware of the terms by which the contribution has been provided to the project, using the same email address as used in the author field.

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

Commits that are provided by non-committers must have a Signed-off-by field in the footer indicating that the author is aware of the terms by which the contribution has been provided to the project. The non-committer must additionally have an Eclipse Foundation Account and must have a signed Eclipse Contributor Agreement (ECA) on file.


Those projects that want to use Git on the Eclipse forge, are assigned a directory in which they may create as many Git repositories as required. Open a bug to request that the Webmaster create a new Git repository for your project. Alternatively, committers with shell accounts can create repositories themselves.

Create a new Git repository
> initrepo /gitroot/project/

For consistency, the name of the repository must end with .git.

To set the description of the repository, use sftp or scp to copy a text file to /gitroot/project/ Git repository descriptions should be limited to a paragraph of one or two sentences.

Only project committers can push to an Eclipse Git repository. A push that includes commits that do not conform to the required form will be rejected.

You can browse Eclipse repositories directly on the Git server.

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. Open a bug to request that the Webmaster configure your Git repository for Gerrit.

Commits may be pushed directly to the Git repository through Gerrit by a project committer (e.g. to the master branch).

Anybody can push to a refs/for/* branch for review in a Gerrit repository. A push that includes commits that do not conform to the required form will be rejected. Commits intended for review should have a Change-Id

You can browse Eclipse repositories directly on the Gerrit server.


Projects may opt to move 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.

Open a bug to request that the Webmaster create a new, or move an existing, Git repository for your project. The Webmaster will install some hooks on your GitHub repository.

The Committers hook grants designated project committers write access to the GitHub-hosted project repositories. Project committers must use the email address they provide to the Eclipse Foundation as their GitHub email address.

The Eclipse Contributor Agreement (ECA) hook will inspect incoming GitHub pull requests to ensure that the contributor has a valid ECA on file, and that the commit has been "signed-off" as required. Project committers should only merge pull green requests:

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

Since the GitHub API does not provide a means of absolutely denying a merge the hook will warn you that the contributors have not signed a ECA or that the commit message is not correctly structured:

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

Click on the Details link for more information. Do not merge unless you are absolutely certain that the contributer does have a valid ECA on file and the commit message includes the required Signed-off-by statement in the footer.


The Eclipse Webmaster creates and maintains a mirror of all GitHub-hosted repositories on Eclipse Foundation hardware.

Issue Trackers

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

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: your project team knows your community and how to best connect with them.

Project Websites

Project websites are an excellent way to connect your project with your community. Many projects opt to use the Project Management Infrastructure (PMI) as their project website. PMI-based website URLs take the form of<projectid> (e.g.

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<shortname> (e.g. Custom project website content is maintained in Git repositories hosted on Eclipse Foundation infrastructure. A background job moves content from the Git repository to the website; content pushed to the repository will appear on the live website within five minutes.


If a project website has not already been created for your project, open a bug to request that the Eclipse Webmaster create one.

Websites not hosted by the Eclipse Foundation are considered community portals and are subject to the Guidelines for Eclipse Logo & Trademarks (the Eclipse Foundation asserts ownership of all project name trademarks).


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 your 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-provided certificate.


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

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

You can upload content to downloads/<shortname> (e.g. downloads/dash) via SFTP or SCP (to {downloadsHost}) or from a CI instance at

Project committers can upload project artifacts to the project’s directory on the download server.

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


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, presentations;

  • Builds and alternative sources for downloads;

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

  • Examples, blogs, social media handles.

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


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. Due to manner in which permissions are managed, membership in the owners team for these organizations is required to create new repositories. The project’s PMC or the EMO can grant membership in this team to designated committers for projects that require this access. The EMO periodically reviews membership in the teams associated with these organizations and will remove members who are not active committers. Repositories created in these organizations must follow the pattern <organization>/<shortname>[-<component>] (e.g. eclipse/che-server).

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.

Frequently Asked Questions

  1. Can a project use the gh-pages support from Github to host at <project>

    The project’s primary website must be hosted on Eclipse Foundation infrastructure. GitHub’s gh-pages support can be used to host supplementary content only as a Community Portal (and is subject to the branding requirements).

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


Roles in a project are assigned based on merit demonstrated in a publicly-accessible forum, in the form of an election. Elections start with a nomination that contains a statement of merit. The nature of a statement of merit varies widely, but is generally expected to to concisely state the impact that the nominee has had on the project.


Employment status has no bearing at whether or not somebody can participate in an open source project at Eclipse. Employment does not, for example, guarantee committer status; committer status must be earned by everybody.

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 organizations. A committer gains voting rights allowing them to affect the future of the project. Becoming a committer is a privilege that is earned by contributing and showing discipline and good judgment. It is a responsibility that should be neither given nor taken lightly, nor is it a right based on employment by an Eclipse Foundation member company or any company employing existing committers.

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

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

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 judgment". This definition needs to be a transparent and public document on the project’s website (the top-level project charter may provide this). It is extremely important to publish these criteria to avoid any issues around cliques or "the in-crowd" preventing others from joining a project.

There must not be any hint of "we (company W) hired person X to work on project Y thus person X should elected a committer". Committer status is independent of employment; thereare well-supported mechanisms for contributors without commit-rights and thus Committer status is not required for a team member to be effective. Additionally, the team will want to make sure that they have confidence in the candidate irrespective of employment and management because the committer status will continue even after moves to another job.

The nomination and election process for a new Committer is for more than just the project team - it is also for the entire Eclipse community, current and future. The larger community uses the artifacts of elections as (one of many pieces of) evidence about the maturity of the project team, and thus quality of the frameworks.


Nominations such as "we all know Bob, vote for him" may work within the team, but actually harm the project’s reputation in the larger Eclipse community: that larger community does not know Bob and does not understand why the project team trusts him with the source code.

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.


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.

An overview of the Election Process
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. 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. 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

Sounak has been part of the Ogee 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 Sounak is currently the top committer of Ogee:

Apart from that Sounak took care of the project page and the build. For release 0.6 he also handled the review formalities for me. Finally I would like to mention a blog post he did at to promote Ogee in the OData community:

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

The manner in which a top-level project’s Project Management Committee (PMC) Member is appointed 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 run an election similar to that of a project lead election.

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.

PMC Lead Appointments

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

Frequently Asked Questions

  1. Do we really need to do this?


  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. Connect with EMO for assistance.

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 Paperwork 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 Agreement, and one for everyone else.

committer questionnaire
The Committer Paperwork 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.


If you indicate that you are employed, you will be asked to identify your employer. Only member companies that have provided a signed Member Committer Agreement 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 Member Committer Agreement you must list your employer as "Other".


The exact nature of the documentation required is dependent upon the employment status of the individual.

What paperwork is required?
What paperwork is required?

The new committer must download and print the documents, complete and sign them, and then provide them to the EMO Records Team. The new committer paperwork 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 Webmaster to provision a committer account.

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

Member Committer Agreement

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


If your employer is a member of the Eclipse Foundation and has not already provided an MCA, consult with your management team to determine who has the necessary authority to sign it on your company’s behalf. Provide the MCA 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 MCA, ask the EMO Records Team.

If the committer’s employer is a member of the Eclipse Foundation that cannot provide a signed MCA, 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 Member Committer Agreement.

An ICA is required when:

  • The committer works for a company that is not a member of the Eclipse Foundation;

  • The committer works for member company that has not signed a Member Committer Agreement;

  • 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 paperwork 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 happens if I do not fill out the paperwork?

    If you do not fill out the paperwork, then you do not get your credentials for write-access to the source code repository(s) and other project resources.

  2. What happens if I cannot convince my employer to fill out the paperwork?

    The Eclipse Board of Directors has taken a firm position that if you are employed then you must meet one of the scenarios described above. If you cannot convince your employer to fill out the necessary paperwork, then you cannot have write-access to project resources. This is the Board’s position even if you are working on Eclipse projects on your own time. We realize that this prevents some talented and desirable people from being able to commit to the projects but this is our IP risk reduction strategy.

  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; just contact us at

  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?

  6. What if a I change employers?

    Edit your Eclipse Account Profile to update your employment status.

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

There are different kinds of content (e.g., source code, documentation, and images) to consider. Project code (or project content) is content that is produced and maintained by the open source project committers and contributors. Third party content generally takes the form of libraries (e.g. modules, or components), source files, images, or other forms of IP that are produced and maintained outside of the scope of the open source project. To mitigate the risk associated with adopting open source in products, the project code and the third party content that it leverages need to be reviewed to ensure that the copyrights expressed are correct, licensing is valid and compatible, and that other issues have been uncovered and properly investigated.

The Eclipse Foundation has a well-defined IP Policy, corresponding IP Due Diligence Process, and an IP Team of dedicated professional IP specialists who perform the heavy lifting in the due diligence process. Committers, the software developers who decide what will become project code and how an Eclipse open source project will leverage third party content, are responsible for bringing IP issues to the attention of the Eclipse IP Team.

Most of the project code produced by committers can just 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 code that comes from contributors (who are not committers); and there are some cases where even the work of committers needs to be reviewed. These cases are highlighted in the IP Due Diligence Process document.

The IP Due Diligence Process focuses on source content. For the purposes of the IP Due Diligence Process, the term source code (or source content) refers to the pre-compiled content, including programming language source, configuration and property files, as well as binary things that don’t have a pre-compiled form like icons. The IP Due Diligence Process is concerned with reviewing the IP that is either consumed (third party content) or produced (project code) by the Eclipse open source project. The process doesn’t generally focus on compiled content (e.g. the IP Team looks at source code, not JAR files).

The IP Due Diligence Process does not dictate how source code repositories are structured. When the IP Team signals that content can be used, the project team can put content into their repositories in whatever structure makes the most sense. Similarly, the IP Due Diligence Process is not concerned with how third party content is represented (e.g. how it is integrated into builds) or how it is disseminated.


The Eclipse Development Process does restrict how content can be disseminated based on the state of the IP review. A Project team can create and distribute milestone builds of any content that has been granted check-in from the IP Team. All content must be approved by the IP Team before the project can engage in a formal release.

The entry point into the IP Due Diligence Process is the Contribution Questionnaire, or CQ. Project teams should create a single CQ for the initial contribution of project code. The initial contribution is a special type of project code contribution in the sense that it is the first thing that the IP Team will review on behalf of the project team.


IPZilla is a modified instance of Bugzilla that tracks the progress of the IP due diligence review and approval process. It is the main interaction point between committers and the IP Team. IPZilla is accessible only by committers, Eclipse Foundation member company representatives, and other specifically-designated individuals. Authorized users can review both completed and ongoing reviews via IPZilla.

Contribution Questionnaires

A Contribution Questionnaire (CQ) is the main interface between Eclipse committers and the IP Team.

A CQ is started when a committer completes a questionnaire regarding a project code contribution or third party content. In literal terms, a CQ is a record in IPZilla that tracks the progress of the approval process. The CQ record is the primary communication channel between the submitting committer and the IP Team. CQ records persist indefinitely.


Use the Create a Contribution Questionnaire tool on a specific project page in the Project Management Interface (PMI) to create a CQ.

All significant contributions of code to be maintained by an Eclipse project, as defined by the Eclipse IP Due Diligence Process require a CQ. Projects further require a CQ for every piece of third party content that project code makes direct use of (regardless of whether or not the content is directly distributed by the project.

CQs are not generally required for ongoing work done by project committers. Consult the IP Due Diligence Process document for more information.

Initial Contribution

Code provenance tracking is critical (the source of all code that ends up in Eclipse Foundation repositories must be well known). To that end, all new projects are required to make an initial contribution before any code is committed to a project’s source code repository.

The initial contribution, like any other project code contribution, should contain only project code/content. Any third party content that might be included in the existing source tree should be excluded from the initial contribution and submitted as separate CQs.

The IP Team will review the initial contribution to ensure that it hasn’t been copied inappropriately, that licenses are being used correctly, and so forth. As part of this process, the IP Team will research the source of all code; depending on the size of the contribution, this can be a time-consuming process.

Because a full review can be time-consuming, the IP Team will in most cases engage the Parallel IP Process. This starts with a cursory review of the content, and—​assuming that no significant issues are uncovered by that cursory review—​the IP Team will grant check-in indicated that the project team can push the initial contribution into their Git repository (or initiate the transfer of their existing repository) and start working while the IP team continues their review in parallel.

After check-in has been granted for the initial contribution, the project team should start the process of engaging the IP Team with their third party content review requests.

Any project committer can initiate the review process by creating a CQ.


Eclipse Foundation systems use email to inform and remind interested parties of the various steps in this process. Only the committer who creates a CQ is notified by default, but other committers can be added to a CQ’s CC list to be included in the communication.

The email address that is associated with your Eclipse Foundation account is used; be sure to check spam filters to ensure that these messages are not missed. Send a note to EMO if you are concerned that you are not receiving these notification.

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

The IP Team is not able to review the history of project code being moved to an Eclipse project. The IP Team will review a snapshot of the project code and that snapshot, the initial contribution, must be the first commit in the Eclipse repository. If your project uses an existing GitHub repository, the Eclipse Webmaster team will help you obscure the history into a hidden branch.

Project Code Contributions

In general, contributions made by project committers do not require review and can be pushed directly into a project repository (though, some project teams may impose additional review restrictions).

Some contributions of code to maintained by the project (i.e. committed to a project source code repository and maintained by the project team) must be reviewed by the IP Team. The IP Due Diligence Process provides help to determine whether or not the contribution needs to be reviewed by the IP Team (when uncertain, Project teams should connect with their project mentors or PMC for assistance).

All contributions of project code must be tracked in the project’s IP Log. This is done automatically when the author information is correctly specified in Git commit records.

Any project committer can create a CQ to submit a project code contribution for review by the IP Team. The project code must be attached to the CQ in source form.


The author of a contribution (or their employer) retains ownership of the intellectual property contained in the contribution. As part of the contribution process, the contributor licenses their contribution under the project license.

Third Party Content

The sort of effort that the Eclipse IP Team brings to bear on third party content varies depending on the type. The Guidelines for the Review of Third Party Dependencies defines three different types: Prerequisite, Exempt Prerequisite, and Works With Dependency.


The term contribution questionnaire is a bit misleading when it comes to third party content. Third party content is not a really a contribution to the project, but since the requirements for tracking project code and third party content is very similar, the same mechanism is used for both.


The simplest form of third party content is the Prerequisite (or prereq). Prerequisites are required by the Eclipse project content to provide core functionality. Prerequisite content is not generally stored in an Eclipse project’s source code repositories, but is likely included in build scripts and referenced as runtime dependencies. Since adopters of Eclipse project content are compelled to adopt the Prerequisite content, that content must also be reviewed by the IP Team. The review requirement applies recursively: the entire transitive closure of a Prerequisite’s dependencies needs to reviewed (the dependencies of a Prerequisite are themselves Prerequisites).

Eclipse Project Dependencies
Eclipse Project Dependencies

Examples of Prerequisite dependencies:

  • the Java/OSGi manifest for one of the project bundles makes a direct reference to third party content (either a bundle or package);

  • project code includes an import statement for a package from third party content;

  • project code imports a third party library’s header file;

  • project code uses reflection or other means to reference APIs and implementation;

  • project code uses OSGi Services to make a reference to a specific implementation of a service; or

  • project code invokes a command line interface.

This list is not intended to be exhaustive, but rather to provide common examples. Fundamentally, when project code makes some kind of use of third party content, then that content is likely a Prerequisite. Under certain conditions, the content may also be classified as an Exempt Prerequisite or a Works With Dependency (see below).

In the case where an Eclipse project references code from another Eclipse project that itself references Prerequisites, no further review of that chain of Prerequisites is required (the IP Team will have already reviewed it on behalf of the second project team). Eclipse project teams should take care to only reference release versions of other Eclipse projects in their own releases to ensure that the IP Due Diligence Process has been completed.

Eclipse Project Dependencies
Eclipse Project Dependencies

Any project committer can create a CQ to submit a Prerequisite for review by the IP Team. The source code that was used to build the content must be attached to the CQ.

Project teams must create a separate CQ for each source (e.g. open source project) of third party content. Source code must be provided for all Prerequisite CQs. CQs for Prerequisite content are version specific, so separate CQs are required for each different version.


The project team can provide the IP Team with finer-grained requests if that’s easier. That is, a project team can ask the IP Team to review the source for specific subsets of content (e.g. individual JAR files or modules), or an entire source tree that’s used to build several components. The IP Team’s focus is on source content; they do not generally review built content or focus on how the source code is assembled (i.e. they don’t generally review JAR files).

Many third party libraries have already been approved by the IP Team. The first stage of the CQ creation process involves a search of existing content; if the content has already been approved, the project team can piggyback on the already-approved content (via a Piggyback CQ). Piggyback CQs are approved automatically and immediately.

Versions of Prerequisites

Reviews of Prerequisites are version specific. That is, project teams are required to engage the IP Team with each separate version of Prerequisite content they require. When the project team adopts a new version of some third party content, a new CQ with a new source attachment must be created and taken through the process.

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 license certified or approved by the IP Team. 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 and let the IP Team decide.

Due Diligence for Prerequisites

The Eclipse IP Policy defines two types of due diligence review for Prerequisites. These types are used to refer to the third party content itself, the type of the CQ, and to the overall process.

Type A Prerequisites are reviewed to ensure that the licenses contained in the content align with the project license. Successful application of the Type A Due Diligence Process results in a CQ that is license certified. Type B content undergoes a far more thorough due diligence process that validates license certification, confirms the provenance of the content, and scans for various anomalies; successful application of the Type B Due Diligence Process results in a CQ that is approved.

The notion of due diligence types extends to projects and releases. A project team may specify a default due diligence type for the project, which both indicates intent to the community, and specifies the default value (which may be overridden) when creating new CQs for the project. When a release makes reference to any Type A Prerequisite software, then the release must also be designated Type A. If all of the Prerequisites referenced by a release are Type B, then than release may be designated as Type B. A project team can decide what level of due diligence is required for each separate release. Hypothetically, a project team could opt to make several Type A releases followed by a Type B release, and then switch back (project teams that need to engage in short release cycles may adopt this sort of cycle).

Type A CQs are processed automatically by the Eclipse Genie process. When a single license is identified for all files in the source content attached to a Type A CQ, and that license is on the Eclipse Foundation’s Third Party Content Licenses White List, then the CQ is automatically marked license_certified, indicating the project team is free to use that content. When multiple licenses, blacklisted licenses, or otherwise problematic licenses are detected (i.e. anything other a single white listed license), then the CQ is sent to the Eclipse IP Team for further investigation.


The Eclipse IP Team encourages new project teams to start with one or two Prerequisites and then work with the IP Team to ensure that the process is well understood, so that the process can be engaged in as efficiently as possible (for all parties).

Exempt Prerequisites

When one follows a dependency graph all the way to the bottom, the entire runtime environment including virtual machines and the operating system are included in the transitive closure of dependencies. Clearly, having the IP team review virtual machines and operating systems is not a great use of time, and—​in the case of closed source operating systems—​just not be possible.

The Eclipse IP Due Diligence Process guidelines provide for a notion of Exempt Prerequisite dependencies, which are not subject to review. According to the guide, content may be considered exempt if it "is pervasive in nature, expected to be already on the user’s machine, and/or an IP review would be either impossible, impractical, or inadvisable." The Eclipse IP Team does not review the source code associated with an Exempt Prerequisite.

One of the key aspects of an Exempt Prerequisite is that the user or adopter is typically the one that actually installs the software and so is the one who must agree to the licensing terms. Content that is declared an Exempt Prerequisite should never be directly distributed by an Eclipse project or otherwise made available without some explicit action from the consumer.

Any project committer an create a CQ to submit an Exempt Prerequisite for review by the IP Team. Exempt Prerequisites must be approved by the Eclipse Foundation’s Executive Director.

Works With Dependencies

The Eclipse IP Due Diligence Process guidelines also define the notion of a Works With Dependency (commonly referred to simply as a Works With) that applies in two different cases. Third party content may be declared a Works With Dependency when:

  • the functionality of Eclipse project code is enhanced by the presence of the software, but is otherwise functional and useful without it; or

  • there are multiple choices and reviewing all of them is impractical or impossible.

A Works With Dependency is, literally, a dependency that the Eclipse project code will work with when it is available. The fundamental requirement is the Eclipse project code must be useful and adoptable without the Works With Dependency. That is, either the project code provides useful functionality without the Works With Dependency or the Works With Dependency is a suitable alternative for a Prerequisite.

Prerequisite and "Works with" Dependencies
Prerequisite and "Works with" Dependencies

As with an Exempt Prerequisite, a Works With Dependency should never be directly distributed or otherwise made available without some explicit action from the consumer. The consumer is responsible for making the Works With Dependency content available and otherwise agreeing to the terms for that content.

It’s enough to just create a CQ to register the use of Works With Dependency without seeking IP Team approval for its dependencies. Works With Dependencies must be approved by the Eclipse project’s PMC.

Piggyback CQs

Many third party libraries have already been approved for use in Eclipse projects. While these libraries have already been cleared for use by all projects, their use must be tracked so that—​in the event that a issue is uncovered following the due diligence process—​we can mitigate the impact of that issue.

A Piggyback CQ can be created on top of an existing resolved CQ. Piggyback CQs share the due diligence type of the CQ that they reference (when a CQ’s due diligence type changes, Piggyback CQs are also changed).

Piggyback CQs are generally approved very quickly as the due diligence work has already been completed.

Content from Other Eclipse Projects

IP Team review or approval is not required for an Eclipse open source project to use released content from another Eclipse open source project as part of a release (a project may use unreleased content from another project in milestone builds). A release of one project should never include unreleased content from another project.

A CQ is not required for third party content that is indirectly used by virtue of consuming content from another Eclipse open source project. If an Eclipse projects makes direct use of third party content inherited by consuming another Eclipse open source project, then a Piggyback CQ is required

CQ Workflow

The workflow for creating a CQ for third party content starts with a search of existing CQs. If an existing CQ can be found that is concerned with the same content and version, then a Piggyback CQ is created. Piggyback CQs are automatically and immediately approved.

If an existing CQ cannot be found, a new one must be created. Once created, the source code for the third party content must be attached to the record by the committer. The PMC must then approve the record. If the project is eligible to leverage the Parallel IP Process, the IP Team performs a cursory review of the record and—​if the CQ meets with the requirements—​tentatively approves the use of the content while the full review is undertaken in parallel.

The Eclipse IP team may require assistance from the project team it performs a deep analysis of the content. Once that analysis is complete and the Eclipse IP Team has made a decision, they will outline the next steps. These next steps may—​in the event that the content is rejected—​require that the content be removed from the project’s source code repository, or that some part be removed. Most often, the content is approved and the CQ is marked as such.

Be advised that this process may take a while. The actual amount of time that it takes to process a CQ depends on numerous factors including the size of the queue, and the nature and size of the contribution.

Parallel IP Process

The Parallel IP Process allows Eclipse projects to make use of project code contributions and third party content before they are fully approved by the IP Team. In practical terms, the Parallel IP Process permits—​with preliminary approval from the IP Team—​a project to check-in code contributions into their source code repository and run builds against third party content without having to wait for the full IP Due Diligence Process to compete.


There is some risk associated with the Parallel IP Process. The IP Team will grant preliminary approval based on a cursory review of the contribution; but during their full review, they may uncover issues that require mitigation. This may require, for example, that some parts of a contribution be removed completely (history and all) from a source code repository.

To leverage the Parallel IP Process, projects still submit a CQ. The difference is that once a CQ has been reviewed for license compatibility, the project will be authorized via IPZilla to check-in the code and start working on it.

All IP must be fully resolved before it is included in a release.

IP Logs

An IP Log is a record of the intellectual property contributions to a project. This includes such as a list of all committers, past and present, that have worked on the code and (especially) those who have made contributions to the current code base.


An IP Log is a record of intellectual property for an entire project. The purpose of the IP Log review is to confirm that the project team understands the Eclipse IP Policy and is implementing the supporting processes. An IP Log is not intended to reflect the intellectual property included with any particular release.

The IP Log is a big part of the official release cycle. You are required to submit your project’s IP Log prior to scheduling a release, or restructuring review. We encourage you to keep your IP log current rather than rushing at the end. The IP Log includes important information about your project that lets adopters know where all the code comes from, who owns the copyrights, and so forth.

Specifically, the log tracks:

  • Licenses;

  • Past and present committers;

  • Third party content; and

  • Contributions from outside the project (i.e. non-committers)

IP Log Generator

The Automated IP Log Tool automatically generates an IP Log using information that is available to the Eclipse Foundation. The list of contributors, for example is automatically generated using information extracted out of the project’s source code repositories.

The IP Log generator pulls information from multiple location to assemble the log:

Sources for the IP Log generator
Sources for the IP Log generator
  • The list of third party content used by the project comes from IPZilla;

  • The project source code repositories are scanned to identify non-committer authors of contributions; and

  • License information is obtained from the Foundation database

To fully leverage the value of the Automated IP Log Tool, the project team needs to:

The Automated IP Log tool populates the Contributors section with information gathered from the project’s source code repositories (source code repository paths specified in the the Source Repositories section in the project metadata). This section lists contributions from non-committers (this is time-sensitive, so contributions made by current committers before they became committers will also be included). Only non-committer contributions are recorded in the generated log.

Git commits contributed by non-committers are identified by the author credentials on the commit record; the Author field must be set to the identity of the actual author of the commit.

The Third Party Software section of the log is populated from IPZilla. The IP Team will mark your contributions in such a way that they will appear in the log. If third party software is not appearing properly, contact the EMO IP Team to make corrections.


Use the Generate IP Log tool on a specific project page in the Project Management Interface (PMI) to generate and submit the IP Log for review.

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.

  2. Can we include third party source code in an Eclipse project’s source code repository?

    Third party content that is stored in the project repository 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 code (i.e. contributors may potentially modify it). Forked source code that is included in a project’s source code repository should be treated as third party content with a separate CQ.

  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 code. 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. Can project code be license certified by the Type A due diligence process?

    No. Only third party Prerequisites can be license certified. Project code is reviewed using a process that is similar to that employed for Type B Prerequisite content.

  6. Is my project eligible to choose Type A level IP Review?

    Yes, all Eclipse projects are eligible to choose Type A or Type B for its Prerequisites by choosing the preferred option when creating a CQ.

  7. How does a Project Lead document their project as Type A?

    The Project Lead and all committers have the ability to designate their project as Type A via the project metadata.

  8. Can a project consist of both Type A and Type B CQs?


  9. If my project requests Type A review for a CQ, can we later change the request to Type B?


  10. How do I change a CQ from Type A to Type B?

    Add a comment to the CQ asking the IP Team to change the due diligence type. If you want to change multiple CQs from Type A to Type B, the Project Lead should contact the IP Team to coordinate and discuss scheduling and timelines.

  11. Can a project join a simultaneous release if it has chosen Type A due diligence?

    From the point of view of the Eclipse Foundation and the Eclipse Development Process, it is completely acceptable for a project to join a simultaneous release while leveraging Type A content. The parties that manage the simultaneous release (e.g. the Eclipse Planning Council), however, may impose additional restrictions.

  12. Can a project release and/or graduate if it has chosen Type A CQs?

    Yes. There is no barrier to releasing and/or graduating based on the IP due diligence type chosen.

  13. My project is new to the Eclipse Foundation, am I eligible for Type A or Type B?

    That is entirely up to the project. However, during the bootstrapping process, new projects will automatically be configured to employ Type A due diligence for all Prerequisite content in order to get the project up and running.

  14. Can a Type B only project consume other projects/releases that are Type A or combination Type A/B?

    This is an individual project choice. If a project decides this does not work for them, it is up to the projects work together to resolve any issue.

  15. Is an IP Log Type A or Type B?

    IP Logs are not themselves intellectual property and so are neither Type A nor B.

  16. The IP Log references Type A content, but my release is Type B. What should I do?

    The purpose of the IP Log review is to checkpoint the IP Due Diligence Process; an IP Log is not intended to be an accurate reflection of exactly what is in any particular release. If your project engages in a combination of Type A and Type B releases, then it is natural for the IP Log to include both. It is the project team’s responsibility to ensure that the content specifically associated with a a Type B Release includes only Type B Prerequisites.

  17. What do you do with the IP Log?

    IP Log reviews occur in two stages. In the first stage, the EMO performs a technical assessment to make sure that the artifacts produced by the project are properly accounted for in the IP log. You may be asked to assist with the resolution of any discrepancies found during this assessment. In the second stage, the IP Team reviews the log to ensure that it matches their records. The IP log review concludes with approval by the IP Team.

  18. When should I submit the IP Log for review?

    The IP Log should be submitted for review by the IP Team two weeks before the planned end date for a release review or (if code moves are involved) a restructuring review. Note that the date of your review may be different from the date of the actual release.

  19. We submitted an IP Log for our release, but we’ve made some changes since then that will end up in the release, should we resubmit the IP Log?

    The purpose of the IP Log review is to checkpoint the IP Due Diligence Process and ensure that nothing is slipping through the cracks; an IP Log is not intended to be an accurate reflection of exactly what is in any particular release.

  20. Are there other reasons to submit the IP Log for review?

    Generally no. If the IP Team requires an IP Log review outside of the context of a release or restructuring review, they’ll ask for it. It is not generally necessary to submit an IP Log for review outside of the context of a review. It is, however, good practice to do your own review of the generated IP Log periodically to make sure that it accurately reflects the state of the project.

  21. How do I fix problems with the generated IP Log?

    The IP Log is generated based on data from Eclipse Foundation servers. If the log is being generated incorrectly, then the underlying data needs to be fixed. If you spot a problem, send a note to EMO.

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.


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, license and notice files must be included in the root of every source code repository.
 └── ...


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

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

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

 │   ├── NOTICE
 │   └── LICENSE
 └── ...

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 PMCs 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—​if applicable—​a cryptography notice.

Example website notices

All material on this website is Copyright (c) 2002-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).


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) {date} {owner}.

The {date} is either a year or a range of years with the first and last years of the range separated by a comma (e.g. “2004” or “2004, 2017”). The first year is when the contents of the file were first created and the last year is when the contents were last modified.

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), there is nothing wrong with listing all of them especially if their contributions are more proportionately equal. For example: "XYZ Corp., John Smith, and ABC Enterprises."

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) {date} {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
 * 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 organizations that have contributed are either listed individually or grouped together by appending "and others". The date is expressed as a single year or a range spanning the year of the very initial assertion and that of the most recent change.
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).


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) {date} 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
 * SPDX-License-Identifier: EPL-2.0 4
1 The date is expressed as a single year or a range spanning the year of the very initial assertion and that of the most recent change.
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.

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) {date} {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
 *, or the Apache Software License 2.0
 * which is available at
 * 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.

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, or the Apache Software License
2.0 which is available at

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

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 file
# Notices for Dash, Tools for Committers

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

 * Project home:

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

SPDX-License-Identifier: EPL-1.0

## Source Code

The project maintains the following source code repositories:


## Third-party Content

ckeditor (3.0.1)

 * License: MPL 1.1, BSD
 * Project:
 * Source:

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:
 * Source:

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

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

Frequently Asked Questions

  1. 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. can be used.

  2. Can the license and notice files use Markdown?

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

  3. Is the cryptography statement required?

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

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

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

  6. How do I get help?

    If you have any questions or concerns, contact


Releases are formal for Eclipse projects. They start with planning, and end with a community review. You can capture as many future releases as you’d like. It’s common practice to specify releases three or six months into the future.

Releases are broadly categorized 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.

For all major and minor releases, you must engage in a release review. Release reviews are not required for bug-fix/service releases.

The Release Cycle
The Release Cycle

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.


Use the Create a new release command on a specific project page in the Project Management Interface (PMI) to create a new release record.

At the start of the release cycle, your plan should minimally include a release number, date, and short description. Think of the description as an elevator pitch: how would you describe the release in a fifteen second elevator ride? 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 dev list and other project channels.

The Plan tab in the release record contains numerous fields for capturing plan information. The amount of information that you should capture for a release plan varies by top-level project, so consult with your Project Management Committee (PMC) for advice.

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. 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. Ensure that your project’s downloads page provides the information required for the community to obtain your builds.

All of your project’s intellectual property contributions must be approved by the IP Team before you can release (this includes third party content and contributions of code to be maintained by the project).

Release Review

A release review is a formal announcement of your release to the community and a request for feedback. In practical terms, experience has shown that those individuals and organizations who are interested in your project follow development throughout the release cycle and so are have likely already provided feedback during the development cycle (i.e. they are unlikely to provide feedback during the review period). With this in mind, the review generally serves as a means for a project to engage in a retrospective of the progress made during the release, discover areas of potential improvement, demonstrate that the project is operating in an open and transparent manner, and ensure that the development process and intellectual due diligence processes have been followed.

Release reviews run for a week and always conclude on a Wednesday.


We schedule reviews to conclude on the first and third Wednesdays of the month. Your release date does not have to coincide with the review date (you can set the release date as necessary). The review must, however, conclude successfully before you can make the release official.

A release review requires review documentation and an intellectual property (IP) log check. The review process must be initiated at least two weeks in advance of the anticipated review date.

Release review work flow
Release review work flow

Prepare the review documentation well in advance of the start of the review period. The release record which contains your project plan also includes a Review tab with appropriate fields for a review. As with the plan fields, all of the review fields are optional and the level of detail you need to provide varies by top-level project. You can assemble review information during the release cycle (there’s no need to wait until the end)

The review materials must be approved by the PMC; send an email to the PMC’s mailing list asking for approval. The PMC will respond with feedback or a simple +1 indicating approval.


Click the handy Committer Tools  Communication  Send Email to the PMC link on the release record page to connect with the PMC.

Submit the IP Log for review by the IP Team. The IP Team must approve the IP Log before we can schedule the review, so submitting this early is important. The IP Log generator automatically collects information based on the information that the project team has provided to the IP Team through contribution questionnaires in IPZilla, commits in the project’s source code repository, and other information in our databases. Carefully review the IP Log before submitting to the IP Team for their review.


Use the Generate IP Log tool on a specific project page in the Project Management Interface (PMI) to generate and submit the IP Log for review.

The information used to generate an IP Log should always be up-to-date (don’t wait until the end of the release cycle to make it right).

At any point in this process, you can request that the review be initiated by clicking the Schedule a review for this release link that appears at the top of the release record page. This will invite you to select a review date. You must then follow up with the EMO to approve the review.


The EMO will likely notice that you’ve created the release record, connected with your PMC, and submitted an IP Log for review by the IP team and will take steps to initiate the actual review. However, since there is a great deal of variability in this process, send an email to EMO stating your intent to release.

The EMO will conclude the review on the scheduled end date and advise the project team of the outcome.

Graduation Review

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 Development Process; and is a credit to Eclipse and is functioning well within the larger Eclipse community

Graduation reviews are generally combined with a release review (typically, but not necessarily the 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, release review documentation must be augmented to include demonstration of:

  • solid working code with stable APIs;

  • an established and growing community around the project;

  • diverse multi-organization 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".

Frequently Asked Questions

  1. Can a release review fail?

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

  2. Do we really need to do this?


  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 mentors and top-level project 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 the release review. If the amount of effort seems too onerous, you may be trying too hard. Connect with your project mentors, top-level project’s PMC, or the EMO for guidance.

  5. How do I submit the IP Log for review?

    Click the Submit button on the IP Log generator. You need to be logged in as project committer to have access to this button.

  6. Can I accept contributions after I submit the IP Log for review?

    The short answer is yes. Please do accept contributions. If you require a new contribution questionnaire (for either a third party library or code contribution) after submitting the IP Log for review, please ask the IP Team if they want you to resubmit the IP Log.

  7. How do I obtain PMC approval?

    Send the the 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 labeled 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 top-level project PMC for advice.

  11. How do I name/number milestone builds?

    Milestone builds should contain the name/number of the release suffixed with "Mn" (e.g. the second milestone for 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. How can I get help?

    Contact your mentors (for projects in the incubation phase), top-level project 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 release 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 faster. By default, projects are provided with a data-driven website that includes consistent links to project releases, reviews, downloads, etc. Projects can opt to override the default and provide their own customized web presence. Setting up a project presence is a matter of configuration, not PHP programming against proprietary APIs.

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, the bugzilla products, source code repositories, etc.

  2. Historical information such as previous release downloads, release review slides and IP logs, etc.

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

PMC members and the Eclipse Foundation staff also have the ability to make changes on behalf of a project.


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

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
A logged in committer can access commands and tools from the Committer Tools block on the right side of the project page.

The URL for a project page takes the form<projectid> (e.g., 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 Contribution Questionnaire

Any project committer create Contribution Questionnaire (CQ). CQs are required to track some contributions of project code, as well as all uses of third-party content.

To create a Contribution Questionnaire:

  1. Log in to the PMI;

  2. Navigate to a project page;

  3. Click Committer Tools  Intellectual Property  Create a Contribution Questionnaire; and

  4. Follow the workflow.

Submit a Project’s IP Log for Review

Any project committer generate the Intellectual Property (IP) Log and submit it for review by the Eclipse IP Team. An IP Log review is required, for example, for all release reviews (release reviews are required for all major and minor releases).

To generate an IP Log:

  1. Log in to the PMI;

  2. Navigate to a project page;

  3. Click Committer Tools  Intellectual Property  Generate IP Log; and

  4. Follow the workflow.

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 generate an IP Log:

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

Some of the fields are described below.

Description and Scope

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.


Providing a summary gives you control over what will get rendered. In views where we are displaying more than one project, the system will artifically 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. 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.


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

The Eclipse Foundation strongly encourages all projects (especially those that produce Eclipse Platform Plug-ins and Features) to create an maintain and Eclipse Marketplace presence.

Source Repositories

The project can specify zero or more source repositories. These are displayed in the Contribute to this Project section.

The values specified are used to query against a database of known existing source repositories (this database is updated nightly by a discovery process). Those repositories that are found in the database will be displayed with enhanced information (including links to repository mirrors, Gerrit, etc.). All values that you provide will be displayed, whether they point to real repositories or not. If the database does not contain your repository, the PMI will assume that the value is correct and try its best to display the information.

Repositories should be specified using the file system path, e.g. /gitroot/egit/egit.git. The name that is displayed for the repository is extracted from the last segment of the URL.

If a description file exists in the Git repository, the contents are automatically displayed under the repository name.


The script that we us to identify repositories attempts to identify a corresponding Gerrit interface for the repository. If it exists, the Gerrit URL is used in place of the Git one. If the repository uses Gerrit, then only the Gerrit URL is displayed. Otherwise, the git:// and ssh:// URLs are displayed.

You can use wildcards to match multiple repositories, e.g. /gitroot/virgo/*. Note that wildcards only work for repositories that exist on Eclipse infrastructure (they do not work for GitHub-based repositories, for example).

Repositories are displayed in the order they are specified. The order can be changed in the edit screen by dragging entries into the desired order. All wildcard matches are sorted alphabetically by name at the end of the list.

A Contribution Message should be provided; it is displayed at the top of the section and is one of the primary means by which the community will find the project code. 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.

Company Logos

Company logos automatically appear on the 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 Portal;

  • At least one committer has to be listed as an employee of the company in question;

  • The committer must be on this project; and

  • The committer must be active (must have made at least one commit in the last three months)

If all of those conditions are met and the logo is still not showing up, then it’s possible that the project meta-data doesn’t have the correct source code repository information specified.

Due Diligence Type

Any committer or project lead can specify the default due diligence type for the project (it’s reported on the Governance page). A project may be designated as Type A or Type B, indicating the default due diligence type that is employed by that project. This default is used when creating new CQs. This value indicates the default; individual releases can specify a different type of due diligence.

project dd type

If nothing is specified, Type B is assumed. Specifying the value at the project level is basically a way for the project team to make a statement that their releases tend to employ a certain type of due diligence for third-party content.

All new projects start with Type A due diligence.

Build Technology

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 Hudson builds, pages of build instructions, or whatever else the project team feels will help the community build the project.

Technology Types

A project can specify the types of technology produced by the project. This is specified in rather broad terms like OSGi or Runtime. Th 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).

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.

The relationship between proposals, projects, 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 milestones. Enter milestone information in the Plan information for your release.


Use the Create a new release command on a specific project page in the Project Management Interface (PMI) to create a new release record.


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.


The release record will automatically generate a list of targeted bugs.

To populate this list:

  • Ensure that the Bugzilla Product is set the to correct value in the project metadata;

  • Set the target milestones in Bugzilla need to match the name of your release.


The matching algorithm tries to be as forgiving as possible, a release named 3.5, 3.5.0, or 3.5 (Luna) will—​for example—​match target milestones named 3.5 ,3.5M1, 3.5 M2, 3.5.0M3, etc., but will not match 3.5.1.

The bugs for all projects participating in the release will be included. Bugs are grouped by Bugzilla product and component.


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


Enter the name, date, and optional description for each milestone expected with the release.

Projects should generally include more than one milestone build with each release. To include additional milestones, click the Add another item button. Note that milestones can be dragged into the desired order. To remove a milestone, leave the Name field blank.


The release has a 'Review' section that can be used to provide information for the associated review. If you provide information here, 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.

All major and minor releases require a review. Service releases (i.e. bug fix releases that do not change public APIs or add new functionality) do not require a review.

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.


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

Projects cannot add themselves directly to a simultaneous release (e.g. Luna), but rather must be added by the EMO (there is a bug open to extend this ability to planning council members).

To join a simultaneous release:

  1. Create a release record:

    • Provide at least a description of the release initially;

    • The date of the release should generally match that of the simultaneous release;

  2. Send a note to the planning council (Eclipse projects normally do this via the cross-project-issues-dev mailing list) with the name of your project, the name/number of the release, and the offset.

The offset indicates how many days after the start of the aggregation process for a milestone your project’s bits will be available. If your project’s bits depend on a +1 project’s bits then your project is probably a +2 project, for example.


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 Guidelines for Eclipse Logos & Trademarks, 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 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.

Naming, Branding, 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 Eclipse brand itself. Not only can a memorable name help new users and contributors find a project, having a distinctive name makes the trademark much stronger, and ensures that third parties will respect it.

To ensure that future trademarks conflicts don’t arise, it is necessary to show other parties that Eclipse Foundation trademarks were chosen in good faith and with appropriate research. The Eclipse Foundation has no business infringing on pre-existing trademarks for the software products or services from other organizations, whether they are Member organizations or not.

All Eclipse projects and corresponding software products are trademarks of the Eclipse Foundation. As a legal entity, the Eclipse Foundation owns all Eclipse project and corresponding product trademarks on behalf of the the Eclipse community. The EMO will initiate a trademark review as part of the project creation or renaming process. Existing project name trademarks must be transferred to the Eclipse Foundation (please see the Trademark Transfer Agreement).

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 non-trivial investment in time and money, project teams must work with their PMC and the EMO to determine whether not trademark registration is necessary, determine in which countries 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 Organization’s Trademarks

Project teams must ensure that products names that include other organizations’ trademarks in names must be conform to those organizations’ 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 be "Eclipse Foo for Perl".

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


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 Development Process, is the main operational unit; all open source software development at Eclipse occurs within the context of a project. The Eclipse Foundation holds the trademark for all Eclipse Projects.

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

Formal Name

The primary branding for any project name is fully-qualified formal name which includes the "Eclipse" 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.

Brand Names

Project teams should strongly consider choosing a brand name. "Woolsey", "Apogy", and "Whiskers" are examples of brand names that are distinctive and memorable; they make the project easier to talk and write about than a wordier descriptive name. These names are not descriptive and so don’t stand well on their own; combining a brand name with a descriptive name (e.g. "Eclipse Woolsey Intellectual Property Tools") can help in this regard.

Descriptive Names

Projects are encouraged to use a descriptive name. Descriptive names provide context that can help a casual viewer appreciate the purpose of the project in way that is difficult or impossible to convey with a brand name "Graphical Modeling Framework", "Trust Framework" or "Component Assembly Tools" are examples of descriptive names..

The best names do not include the word "Project", and are—in formal contexts—prepended by "Eclipse". The project name should still work with or without the prefix. For example, "Graphical Modeling Framework" and "Eclipse Graphical Modeling Framework" are equally understandable.

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 may be becoming overused.


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.


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, IPZilla, and in 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 webpages 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").


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 "Eclipse" when used in any formal context (e.g. Eclipse Widgets).

Project teams should work with their 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 Organization (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.

All Eclipse projects are encouraged to create a unique logo to identify their project. Projects teams can engage a graphic design crowdsouring 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.

Logos are important to recognize as trademarks as well. For a project’s official logo (if it has one, and especially if it uses the Eclipse Logo in any way), 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 the Eclipse Logo within their project logo, or otherwise create a derivative of the Eclipse Logo. However, they must contact the EMO (via a Bugzilla record) to request the Board’s permission to do so.

The Eclipse Foundation will help fund the creation of project logos. 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 USD$600 for the logo design. Please also feel free to contact the Foundation marketing team with any questions about the logo design.

Project Websites

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 Webmaster 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™"). If the webpage 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:


An appropriate footer is included automatically by the default website infrastructure and the PMI.

Project Metadata

All Projects must keep their metadata updated regularly in the central Project Management Infrastructure (PMI). Projects must ensure that all metadata is kept up-to-date in the PMI tool to ensure that other infrastructure tools and processes can make connections to and disseminate information for  the project.

The project description, scope, and other free-form text fields in the PMI must conform to the project naming guidelines.


The PMI supports teasers or summaries for many fields; ensure that these teasers also conform to the guidelines.

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  (i.e. follow the pattern org.eclipse.<short-name>.<component>), e.g.,, and Component names are left to the discretion of the project team.

The project team must petition the Planning Council via their PMC to request exceptions.

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 Guidelines for Eclipse Logos & Trademarks. 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 authorized 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 Guidelines for Eclipse Logos & Trademarks;

  • 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 used with the permission of the Eclipse Foundation (e.g. "Woolsey is a trademark of the Eclipse Foundation, Inc. and is used with permission.").


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 Guidelines for Eclipse Logos & Trademarks;

  • The first and most prominent reference to the Eclipse 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 be prefixed with "Eclipse";

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


Naming exceptions may be granted for names that follow established conventions (e.g. Woolsey™ Labs). Contact the EMO to request an exception.


Websites on external domains that use a project name trademark (e.g. 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.

Only existing, well-known domains that are already heavily linked and known by the community are permitted as external domains. For other historical domains that are not an important part of the project’s brand, permanent (301) redirects should point to the official project website hosted on Eclipse Foundation infrastructure.

Projects with widely-used historical domain names may continue using the domain with these considerations:

  • Ownership of the domain name must be transferred to the Eclipse Foundation; and

  • The domain must be regarded and used exclusively as a community portal (and not as an official project website).

Trademark Attributions

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 either registered trademarks or trademarks of The Eclipse Foundation in the United States and/or other countries.

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 organizations looking for information on how to use or refer to any Eclipse Foundation project trademarks or logos should see the Guidelines for Eclipse Logos & Trademarks.

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 Guidelines for Eclipse Logos & Trademarks.


The Eclipse 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 eco-system 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 eco-system 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 attact 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.


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.


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.


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 beween 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 center 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. We’ve tried to strike a balance between being concise while being comprehensive.

The Eclipse Foundation staff and Project Management Committee members will use this checklist as part of their evaluation during a Release Review.

All projects must conform to the branding guidelines before engaging in any Release or Graduation Review (specific examples are described below).


  • All project code is managed in source code repositories provided by The Eclipse Foundation;

  • All source files include a copyright and license header;

  • All project source code repositories include a CONTRIBUTING file (or equivalent) in the root;

  • Naming Conventions followed:

    • e.g. org.eclipse.<short-name>.<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 organization names are set to "Eclipse Foo" in Maven pom.xml files;

  • Every module contains an about.html file as required by the guide to the legal documentation; and

  • Features names and descriptions are captured, are spelled correctly, use proper grammar, and contain content that is actually useful for the intended audience.


Most projects provide binary/compiled downloads of their software, intended for consumption by their various communities. If the project does not provide downloads, then that should be stated on the project’s website.

  • All generated artifacts include only intellectual property that has been subject to the IP Due Diligence Process;

  • All distributed third party content has been approved by the IP Team;

  • The project website and PMI page includes links for artifacts;

  • Incubation branding (if applicable) is included on distributed artifacts;

  • All download artifacts are (if technical feasible) signed; and

  • Subject to limitations of specific technologies, the Version numbering 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.


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;

  • Project incubation status (if applicable) is correctly noted;

  • Includes a concise description of the project (with all necessary marks); and

  • The standard navigation links (e.g. are included in the website footer.

Logos and graphics

  • Project logo includes the trademark symbol; and

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


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.

Architecture Council Mentor

The Eclipse Architecture Council (AC) is a body of battle-hardened Eclipse committers. All new projects are required to have at least one mentor taken from the ranks of the AC. Your project mentors will help you find answers to any questions you may have about the Eclipse Development Process and life-in-general within the Eclipse community. If your mentor doesn’t have an answer to your question, they can draw on the wisdom of the full AC and the EMO.

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


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 is a nebulous sort of term. Community is the group of individuals and organizations 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.

Contribution Questionnaire

Prior to committing a significant contribution of content from a non-committer to an Eclipse project, the committer must fill out a contribution questionnaire (CQ) and submit it to the IP Team for approval. In addition to the EMO, the relevant PMC must also provide a technical review and approval of the contribution. In general, ongoing development by project committers does not require EMO or PMC approval. When in doubt, consult the Eclipse IP Due Diligence Process.


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, IP Logs, and more.


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 Eclipse Foundation’s automated systems communicate with the project team.


A commercial ecosystem is a system in which companies, organizations, 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.


This is a tough one. For most 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 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 Organization (EMO)

The Eclipse Management Organization (EMO) consists of the Eclipse Foundation staff, and the Eclipse Architecture and Planning Councils. 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 Development Process. The best method of contact with the EMO is by email ( If you have a question that cannot be answered by project lead, mentor, 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.


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

Exempt Prerequisite (Dependency)

An Exempt Prerequisite is defined as third party content which is used by Eclipse project code but is not not subject to review by the IP Team. Content may be considered exempt if it is "is pervasive in nature, expected to be already on the user’s machine, and/or an IP review would be either impossible, impractical, or inadvisable."


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.

Intellectual Property (IP) Log

An Intellectual Property Log (commonly referred to as an IP Log) is a record of the intellectual property (IP) contributions to a project. This includes such as a list of all committers, past and present, that have worked on the code and (especially) those who have made contributions to the current code base.

Member Company

The Eclipse Foundation and Eclipse community is supported by our member organizations. Through this support, the Eclipse Foundation provides the open source community with IT, intellectual property, and marketing services.

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 Eclipse IP Team.

Planning Council

The Eclipse Planning Council is responsible for cross-project planning, architectural issues, user interface conflicts, and all other coordination and integration issues. The Planning Council discharges its responsibility via collaborative evaluation, prioritization, and compromise.

Prerequisite (Dependency)

A Prerequisites (or prereqs) are third party content that is required by the Eclipse project content to provide core functionality.


Projects are where the real work happens. Each project has code, committers, and resources including a web site, 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 web site. Projects are sometimes referred to as subprojects or as components. The Eclipse 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 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.

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.


The Webmaster team is responsible for maintaining the IT infrastructure of the Eclipse Foundation and the Eclipse forge. You can contact the Webmaster team directly via email (

Working Group

Eclipse Working Groups provide a vendor-neutral governance structure that allow organizations to freely collaborate on new technology development.

Works With Dependency

A Works With Dependency is defined as third party content that Eclipse Project Code will work with when it is available. The fundamental requirement is the Eclipse Project Code must be useful and adoptable without the Works With Dependency. That is, either the Project Code provides useful functionality without the Works With Dependency or the Works With Dependency is a suitable alternative for a Prerequisite.


Legal Documentation for Eclipse Platform Plug-ins and Fragments


This is draft content. If you have an issue, please open a report against Dash/Handbook.

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.

Eclipse Platform Plug-ins and Fragments are highly modularized 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 organizations, 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.


You will also often see on many of the download pages at, 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.


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