Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Development Resources/New Commmitter Handbook"

m (Typos)
(Licenses, Intellectual Property Due Diligence, and other Legal Stuff)
(23 intermediate revisions by the same user not shown)
Line 5: Line 5:
 
As a committer, you must be familiar with the following documents:<br>  
 
As a committer, you must be familiar with the following documents:<br>  
  
*The [http://www.eclipse.org/projects/dev_process/development_process.php Eclipse Development Process]<br>
+
*The [http://www.eclipse.org/projects/dev_process/development_process.php Eclipse Development Process]
*The [http://eclipse.org/legal/EclipseLegalProcessPoster.pdf Eclipse Intellectual Property Due Diligence Process]<br>
+
*The [http://eclipse.org/legal/EclipseLegalProcessPoster.pdf Eclipse Intellectual Property Due Diligence Process]
  
The Eclipse Resources page is intended as a reference into the rest of the documentation. If you have a question, this is a good place to start. If you can't find the help you need there you should ask your project lead, or PMC.<br>
+
The Eclipse Resources page is intended as a reference into the rest of the documentation. If you have a question, this is a good place to start. If you can't find the help you need there you should ask your project lead, or PMC.
  
We are continually trying to improve this page. If you think that something can be improved, or something should be added, please let us know by opening a bug against [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Process Community/Process]. Or you can just edit this page; it is a wiki, afterall!<br>
+
We are continually trying to improve this page. If you think that something can be improved, or something should be added, please let us know by opening a bug against [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Process Community/Process]. Or you can just edit this page: it is a wiki, afterall!
  
= Terminology/Who's Who?<br>  =
+
= Principles =
  
=== Top-Level Project<br>  ===
+
Several important principles provide a foundation for the Eclipse Development Process.
  
Top-level projects are "[http://www.eclipse.org/projects/dev_process/development_process.php#4_Structure_and_Organization container projects]" as defined by the Eclipse Development Project. As a container project, a top-level project does not contain code. Rather, a top-level project contains other projects. Each top-level project defines a charter that, amoung other things defines a scope for the types of projects that it contains. Top-level projects are managed by a Project Management Committed (described below).
+
=== Quality ===
  
=== Project<br>  ===
+
[[Eclipse 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 - cool/compelling to use, indicative of what is possible) and ready for plug-in developers (deliver usable building blocks - with APIs). 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.
  
There are, essentially, two different types of projects at Eclipse (as defined in the [http://www.eclipse.org/projects/dev_process/development_process.php#4_Structure_and_Organization Eclipse Development Process]).
+
''Copied from [[Eclipse Quality]]''
  
"Container" projects are holders of other projects. You can think of a container project as a grouping of projects that make some logical sense together. Projects can be arbitrarily nested. A container project can itself contain container projects. Container projects do not include code and do not have committers.
+
=== IP Cleanliness ===
  
"Operating" projects are where the real work happens. Each operating project has code and committers. Operating projects may, but do not necessarily, have a dedicated website (many operating projects share a website through their container project). Operating projects are sometimes referred to as "sub-projects" or as "components". The Eclipse Development Process treats these as equivalent.  
+
Intellectual property (IP) is pretty much any artifact that is made available from an eclipse.org 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; pretty much anything that a project makes available to the community in general. Fairly strict rules govern the way that we manage IP and your responsibilities as a committer (the links at the top of this page provide a lot more information).
  
Projects can be arbitrarily nested, forming a tree. The root of the tree is a single top-level project.  
+
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 safe to use. "Safe" basically means that 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.
  
As a new committer, you are most likely associated with an operating project.  
+
=== Transparency ===
 +
 
 +
A project is said to be transparent if the project team makes it easy for a member of the community, who is not part of the core team, to participate in all decisions that affect the project. The project should make it easy for a non-team member to find all the information used and the decisions made by the project team.
 +
 
 +
''Copied from [[WTP Permeability and Transparency Checklist]]''
 +
 
 +
=== Openness ===
 +
 
 +
A project is said to be permeable if the project team is receptive to new ideas from the community and welcomes new committers to its team. This is a measure of the 'responsiveness', 'friendliness' or 'sociability' of the project towards a participant who is not part of the project team.
 +
 
 +
''Copied from [[WTP Permeability and Transparency Checklist]]''
 +
 
 +
= Terminology/Who's Who?  =
 +
 
 +
=== Top-Level Project<br>  ===
 +
 
 +
Top-level projects are defined in the [http://www.eclipse.org/projects/dev_process/development_process.php#4_Structure_and_Organization Eclipse Development Process].
 +
 
 +
A Top-level project is effectively a container for projects that do the real work. A top-level project does not contain code. Rather, a top-level project contains other projects. Each top-level project defines a charter that, amoung other things defines a scope for the types of projects that it contains. Top-level projects are managed by a Project Management Committed (described below).
 +
 
 +
=== Project ===
 +
 
 +
The [http://www.eclipse.org/projects/dev_process/development_process.php#4_Structure_and_Organization Eclipse Development Process] defines what it means to be a project at Eclipse.
 +
 
 +
Essentially, projects are where the real work happens. Each project has code, committers, and resources including a website, source code repositories, space on the build and download server, etc. Projects may act as a parent for one or more child projects. Each child project has its own identity, committers, and resource. Projects may, but do not necessarily, have a dedicated website (many projects share a website through their parent project). Projects are sometimes referred to as "subprojects" or as "components". The alternate terms are still used by some of our more seasoned committers, and in parts of our documentation. The Eclipse Development Process, however, treats the terms project, subproject, and component as equivalent.
 +
 
 +
Projects can be arbitrarily nested, forming a tree. The root of the tree is a single top-level project. In practice, project trees are never more than three levels deep.
  
 
There are numerous project-specific resources (including a list of all projects at Eclipse) on the [http://www.eclipse.org/projects Eclipse Projects Gateway] page.
 
There are numerous project-specific resources (including a list of all projects at Eclipse) on the [http://www.eclipse.org/projects Eclipse Projects Gateway] page.
Line 42: Line 68:
 
Be aware that code contributions from outside of the project are best accepted through Bugzilla records. By attaching code to a Bugzilla record, the committer implicitly grants rights to use the code. Those contributions are subject to our IP policy.  
 
Be aware that code contributions from outside of the project are best accepted through Bugzilla records. By attaching code to a Bugzilla record, the committer implicitly grants rights to use the code. Those contributions are subject to our IP policy.  
  
Some of our documentation refers to contributors as developers.  
+
Some of our documentation refers to contributors as "developers".  
  
=== Project Management Committee (PMC)<br> ===
+
=== Project Management Committee (PMC)  ===
  
Each top-level project is governed by a PMC. The PMC has one or more leads along with several members. The PMC has numerous responsibilities, including the ultimate approval of new committers, and approval of intellectual property contributions. Effectively, the PMC provides oversight for each of the projects that are part of the top-level project.<br>
+
Each top-level project is governed by a [[PMC]]. The PMC has one or more leads along with several members. The PMC has numerous responsibilities, including the ultimate approval of new committers, and approval of intellectual property contributions. Effectively, the PMC provides oversight for each of the projects that are part of the top-level project.  
  
=== Project Lead (PL)<br>  ===
+
If you have a question that your project lead cannot answer, ask the PMC.
  
=== Eclipse Management Organization (EMO)<br> ===
+
=== Project Lead (PL)  ===
  
=== Executive Director (EMO/ED)<br>  ===
+
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 amongst 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.
  
=== Contribution Questionnaire (CQ)<br> ===
+
=== Architecture Council Mentor ===
 +
 
 +
The Eclipse [[Architecture Council]] (AC) is a body of battle-hardened Eclipse committers. All new projects are required to have a minimum of two mentors 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.
 +
 
 +
=== Eclipse Management Organization (EMO)  ===
 +
 
 +
In the strictest sense, the EMO consists of the Eclipse Foundation staff and the Councils (Requirements, Architecture, and Planning). 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 main point of contact with the EMO is by email at [mailto:emo@eclipse.org emo@ecilpse.org]. If you have a question that cannot be answered by project lead, mentor, or PMC, ask the EMO.
 +
 
 +
=== Executive Director (EMO/ED)  ===
 +
 
 +
The Executive Director (EMO/ED) is the head-honcho at the Eclipse Foundation. He is ultimately responsible for all the goings-on at the Eclipse Foundation.
 +
 
 +
=== Contribution Questionnaire (CQ)  ===
 +
Prior to committing a significant contribution of content to an Eclipse Foundation project, the committer must fill out a [[Development Resources/Contribution Questionnaire|contribution questionnaire]] and submit it to the Eclipse Management Organization (EMO) 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 [http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf Eclipse IP Due Diligence Process].
  
 
=== Eclipse  ===
 
=== Eclipse  ===
Line 62: Line 105:
 
=== Community  ===
 
=== Community  ===
  
=== Eco-System  ===
+
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, like the [http://www.eclipse.org/eclipse Eclipse Project], the community is enormous. Other projects (most, frankly) 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.
  
A commercial eco-system is a system in which companies, organizations, and individuals all work together for mutual benefit. There already exists a vast eco-system 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 eco-system by filling the needs of commercial interests, being open and transparent, and being responsive to feedback.  
+
The "Eclipse Community" is formed from the union of the communities that grow around individual projects.
  
Ultimately, being part of a commercial eco-system 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.
+
=== Ecosystem  ===
  
=== Transparency  ===
+
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 eco-system 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.
  
 
= My Foundation Portal  =
 
= My Foundation Portal  =
Line 84: Line 129:
 
Managing intellectual property is an important part of being an Eclipse Committer. All committers should be familiar with the [http://eclipse.org/legal/EclipseLegalProcessPoster.pdf Intellectual Property Due Diligence] process. Any time you accept code from any party (committer or non-committer), you should consult this poster to determine what course of action to take. As a general rule, code created on an ongoing basis by committers for an Eclipse project can simply be committed into the project's source code repository.  
 
Managing intellectual property is an important part of being an Eclipse Committer. All committers should be familiar with the [http://eclipse.org/legal/EclipseLegalProcessPoster.pdf Intellectual Property Due Diligence] process. Any time you accept code from any party (committer or non-committer), you should consult this poster to determine what course of action to take. As a general rule, code created on an ongoing basis by committers for an Eclipse project can simply be committed into the project's source code repository.  
  
Any library authored by a third-party that you intend to distribute from any eclipse.org resource, including those licensed under the EPL or EDL, are subject to the process. The [http://eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf Guidelines for the Review of Third Party Dependencies] provides some guidance on dealing with these third party libraries.  
+
All Eclipse projects start with an [[Development Resources/Initial Contribution|initial contribution]] of code. Some contributions are big, other are small. Whatever the case, the IP Team needs to review your first drop of code before anything gets added to the repository.
 +
 
 +
You need a [[Development Resources/Contribution Questionnaire|contribution questionnaire]] (CQ) for a [http://eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf third-party library] if you make direct use of that library. An import statement in Java source, or a bundle reference or package reference in a manifest file are examples of a direct reference. Indirect references through another project's code do not generally require a CQ.  
  
 
Code contributions of other forms from a third-party should be made through Eclipse Bugzilla. This includes things like patches, lines of code, or files. Any contributions made through Bugzilla are subject to the Eclipse [http://www.eclipse.org/legal/termsofuse.php Terms of Use] which, among other things, implicitly grants us the right to use the contribution. Contributions of all forms are subject to the process (not just source files).  
 
Code contributions of other forms from a third-party should be made through Eclipse Bugzilla. This includes things like patches, lines of code, or files. Any contributions made through Bugzilla are subject to the Eclipse [http://www.eclipse.org/legal/termsofuse.php Terms of Use] which, among other things, implicitly grants us the right to use the contribution. Contributions of all forms are subject to the process (not just source files).  
Line 98: Line 145:
 
Projects are encouraged, where possible, to reuse libraries found in the [http://www.eclipse.org/orbit Orbit] project. Leveraging these libraries will help to reduce redundancy across Eclipse projects.  
 
Projects are encouraged, where possible, to reuse libraries found in the [http://www.eclipse.org/orbit Orbit] project. Leveraging these libraries will help to reduce redundancy across Eclipse projects.  
  
If you are unsure about what you need to do or have other questions, ask your PMC.  
+
If you are unsure about what you need to do or have other questions, ask your PMC.
 +
 
 +
=How do I get Help?=
 +
 
 +
Projects have at least one mailing list. The mailing list is a good place for developers on a project to ask questions of other developers. That is, the mailing list is typically intended for communication amongst developers on a project. Your project's home page should provide some help in identifying the mailing list. Alternatively, you can find the comprehensive list of all mailing lists [http://www.eclipse.org/mail/index_project.php here].
 +
 
 +
Your project teammates are probably your best source of pertinent information. If you are working on an incubating project (i.e. a project that has not yet done a 1.0 release), there should be mentors assigned to your project to help with questions. Don't be afraid to use your mentors. You can identify the mentors on the project summary page (which should be accessible in an entry labeled "About this Project" in the left-menu on your project's web site).
  
<br>
+
For communication with another project, you should go through the community [http://www.eclipse.org/forums Forums]. If you're not sure which forum to post your question on, try posting on the ''newcomer'' group and someone there will point you in the right direction. Note that the forums are also available through NNTP if you prefer to use a newsreader.
  
 
''This page is moderated by the EMO''
 
''This page is moderated by the EMO''

Revision as of 22:10, 26 September 2011

This page is intended for new Eclipse committers, and contributors who plan to become committers. Having said that, there should be a little something in here for everybody.

We are attempting to keep this page as concise as possible (using plain English), while conveying as much information as possible. This document is not the definitive source of information about being an Eclipse committer. It is just the starting point: it provides many links to more information.

As a committer, you must be familiar with the following documents:

The Eclipse Resources page is intended as a reference into the rest of the documentation. If you have a question, this is a good place to start. If you can't find the help you need there you should ask your project lead, or PMC.

We are continually trying to improve this page. If you think that something can be improved, or something should be added, please let us know by opening a bug against Community/Process. Or you can just edit this page: it is a wiki, afterall!

Principles

Several important principles provide a foundation for the Eclipse Development Process.

Quality

Eclipse 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 - cool/compelling to use, indicative of what is possible) and ready for plug-in developers (deliver usable building blocks - with APIs). 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.

Copied from Eclipse Quality

IP Cleanliness

Intellectual property (IP) is pretty much any artifact that is made available from an eclipse.org 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; pretty much anything that a project makes available to the community in general. Fairly strict rules govern the way that we manage IP and your responsibilities as a committer (the links at the top of this page provide a lot more information).

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 safe to use. "Safe" basically means that 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.

Transparency

A project is said to be transparent if the project team makes it easy for a member of the community, who is not part of the core team, to participate in all decisions that affect the project. The project should make it easy for a non-team member to find all the information used and the decisions made by the project team.

Copied from WTP Permeability and Transparency Checklist

Openness

A project is said to be permeable if the project team is receptive to new ideas from the community and welcomes new committers to its team. This is a measure of the 'responsiveness', 'friendliness' or 'sociability' of the project towards a participant who is not part of the project team.

Copied from WTP Permeability and Transparency Checklist

Terminology/Who's Who?

Top-Level Project

Top-level projects are defined in the Eclipse Development Process.

A Top-level project is effectively a container for projects that do the real work. A top-level project does not contain code. Rather, a top-level project contains other projects. Each top-level project defines a charter that, amoung other things defines a scope for the types of projects that it contains. Top-level projects are managed by a Project Management Committed (described below).

Project

The Eclipse Development Process defines what it means to be a project at Eclipse.

Essentially, projects are where the real work happens. Each project has code, committers, and resources including a website, source code repositories, space on the build and download server, etc. Projects may act as a parent for one or more child projects. Each child project has its own identity, committers, and resource. Projects may, but do not necessarily, have a dedicated website (many projects share a website through their parent project). Projects are sometimes referred to as "subprojects" or as "components". The alternate terms are still used by some of our more seasoned committers, and in parts of our documentation. The Eclipse Development Process, however, treats the terms project, subproject, and component as equivalent.

Projects can be arbitrarily nested, forming a tree. The root of the tree is a single top-level project. In practice, project trees are never more than three levels deep.

There are numerous project-specific resources (including a list of all projects at Eclipse) on the Eclipse Projects Gateway page.

Committer

A committer is a software developer who has the necessary rights to write code into the project's source code repository. Committers are responsible for ensuring that all code that gets written into the project's source code repository is of sufficient quality. Further, they must ensure that all code written to an eclipse.org source code repository is clean from an intellectual property point of view. This is discussed with more detail below.

Contributor

Contributions to an Eclipse project take many forms. As a committer, you should do everything possible to encourage contribution by members of the community that surrounds your project. Contributions take the form of code, input into your project's wiki pages, answering questions on newsgroups, and more.

Be aware that code contributions from outside of the project are best accepted through Bugzilla records. By attaching code to a Bugzilla record, the committer implicitly grants rights to use the code. Those contributions are subject to our IP policy.

Some of our documentation refers to contributors as "developers".

Project Management Committee (PMC)

Each top-level project is governed by a PMC. The PMC has one or more leads along with several members. The PMC has numerous responsibilities, including the ultimate approval of new committers, 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 Lead (PL)

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

Architecture Council Mentor

The Eclipse Architecture Council (AC) is a body of battle-hardened Eclipse committers. All new projects are required to have a minimum of two mentors 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.

Eclipse Management Organization (EMO)

In the strictest sense, the EMO consists of the Eclipse Foundation staff and the Councils (Requirements, Architecture, and Planning). 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 main point of contact with the EMO is by email at emo@ecilpse.org. If you have a question that cannot be answered by project lead, mentor, or PMC, ask the EMO.

Executive Director (EMO/ED)

The Executive Director (EMO/ED) is the head-honcho at the Eclipse Foundation. He is ultimately responsible for all the goings-on at the Eclipse Foundation.

Contribution Questionnaire (CQ)

Prior to committing a significant contribution of content to an Eclipse Foundation project, the committer must fill out a contribution questionnaire and submit it to the Eclipse Management Organization (EMO) 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.

Eclipse

Now this is a tough one. For most people in the broader community, "Eclipse" refers to a Java IDE based on the JDT project and assembled by the Eclipse Packaging Project. However, the term "Eclipse" is also used to refer to the Eclipse Foundation, the eclipse.org website, the community, the eco-system, and—of course—The Eclipse Project (which is just one of the top-level projects hosted by the Eclipse Foundation). Confusing?

Community

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, like the Eclipse Project, the community is enormous. Other projects (most, frankly) 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.

Ecosystem

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

My Foundation Portal

The My Foundation Portal is the primary mechanism for committers to interact with the Eclipse Foundation. Using the portal, you can update your personal information, manage information about your project, nominate new committers, and more. New functionality is added on an ongoing basis. The portal presents functionality in the form of individual components. The set of components depends on the roles assigned to you.

You can use either your Eclipse Bugzilla or your committer credentials to login. Some committer-specific functionality is only available when you login using your committer credentials.

Licenses, Intellectual Property Due Diligence, and other Legal Stuff

The Eclipse Legal page is the main resource for legal matters. Janet Campbell, Legal Counsel & Intellectual Property Team Manager for the Eclipse Foundation, presented a talk, IP for Eclipse Committers, at EclipseCon 2009 that provides a great overview of the IP policy and process at Eclipse.

As an Eclipse Committer, you should be familiar with the Eclipse Public License (EPL). Further, you should be aware of the Eclipse Distribution License (EDL). By default all code authored for an Eclipse project is subject to the EPL. The BSD-style EDL license is used by some Eclipse projects which require dual-licensing along with the EPL. Use of this license by an Eclipse project is on a case-by-case basis and requires unanimous approval of the Board of Directors.

Managing intellectual property is an important part of being an Eclipse Committer. All committers should be familiar with the Intellectual Property Due Diligence process. Any time you accept code from any party (committer or non-committer), you should consult this poster to determine what course of action to take. As a general rule, code created on an ongoing basis by committers for an Eclipse project can simply be committed into the project's source code repository.

All Eclipse projects start with an initial contribution of code. Some contributions are big, other are small. Whatever the case, the IP Team needs to review your first drop of code before anything gets added to the repository.

You need a contribution questionnaire (CQ) for a third-party library if you make direct use of that library. An import statement in Java source, or a bundle reference or package reference in a manifest file are examples of a direct reference. Indirect references through another project's code do not generally require a CQ.

Code contributions of other forms from a third-party should be made through Eclipse Bugzilla. This includes things like patches, lines of code, or files. Any contributions made through Bugzilla are subject to the Eclipse Terms of Use which, among other things, implicitly grants us the right to use the contribution. Contributions of all forms are subject to the process (not just source files).

The entry-point into the Eclipse IP Due Diligence Process is the Contribution Questionnaire (CQ). CQs are tracked in a separate Bugzilla instance known as IPZilla. Only committers and other authorized individuals may access IPZilla.

You should create a CQ using the My Foundation Portal. By using the portal, you are given an opportunity to locate similar existing CQs; by leveraging an existing CQ, you may be able to hasten the approval process. The CQ describes the contribution, including important information like the license under which it is distributed and identity of the various authors. Once your CQ is created, you must attach the source code for the library to the record. Do not attach binaries. A separate CQ is required for each library.

Do not commit any contribution to your project's source code repository until the CQ is explicitly marked as approved and a comment is added by the IP Due Diligence Team that explicitly states that you can commit the contribution.

An incubating project may make use of the Parallel IP Process. Using the Parallel IP Process, a contribution can be committed into a project's source code repository while the due diligence process is undertaken. If, at the end of the due diligence process, the contribution is rejected, it must be removed from the source code repository. The Parallel IP Process "How to" page provides some insight. Mature projects can take advantage of the parallel IP process for certain libraries.

Projects are encouraged, where possible, to reuse libraries found in the Orbit project. Leveraging these libraries will help to reduce redundancy across Eclipse projects.

If you are unsure about what you need to do or have other questions, ask your PMC.

How do I get Help?

Projects have at least one mailing list. The mailing list is a good place for developers on a project to ask questions of other developers. That is, the mailing list is typically intended for communication amongst developers on a project. Your project's home page should provide some help in identifying the mailing list. Alternatively, you can find the comprehensive list of all mailing lists here.

Your project teammates are probably your best source of pertinent information. If you are working on an incubating project (i.e. a project that has not yet done a 1.0 release), there should be mentors assigned to your project to help with questions. Don't be afraid to use your mentors. You can identify the mentors on the project summary page (which should be accessible in an entry labeled "About this Project" in the left-menu on your project's web site).

For communication with another project, you should go through the community Forums. If you're not sure which forum to post your question on, try posting on the newcomer group and someone there will point you in the right direction. Note that the forums are also available through NNTP if you prefer to use a newsreader.

This page is moderated by the EMO

Back to the top