The following resolution was passed by the Board of Directors of the Eclipse Foundation on June 21, 2007.

RESOLVED, that the Board hereby instructs each Eclipse project to conform to the following policy for using proprietary tools in their development process, where there is sufficient value to the project to motivate the use of such proprietary tools. The goal of this policy is to ensure that undue barriers to contributors are not introduced as the result of the use of proprietary tools by one or more projects.

The Board further instructs the EMO to develop a procedure to implement this policy.


"Non-core infrastructure" means those software development tools and aids which are not part of the generally available Eclipse Foundation project infrastructure, examples of "core infrastructure" would include without limitation: project build infrastructure, CVS, Bugzilla and Mailman.

"Proprietary tools" means those software development tools made commercially available under a software license not approved by the Open Source Initiative as an open source license.

Implementation Procedure
  1. The process of approving a proprietary tool begins upon with a request from a project to the EMO to approve a specific tool for use by Eclipse projects. The request should be sent as an email to and must include:

  2. For greater clarity, requests by vendors to pre-approve proprietary tools in the absence of a request by an Eclipse project will not be acted upon.

  3. Within one week after the request has been received by the EMO, the EMO will contact the vendor to ascertain their willingness to abide by the requirements of the Eclipse Foundation. E.g.:

  4. Once an agreement in principle is reached with the vendor, a legal review will take place to ensure that the licensing terms offered by the vendor are consistent with said agreement. If executed agreements are required, they will be executed by the Executive Director or his designate.

  5. Together, the vendor and EMO will create a document for publication on describing how Eclipse committers and contributors can gain access to the proprietary tool. Note that it is acceptable to the Eclipse Foundation that those using these tools may have to register with the vendor in order to gain access.

  6. Once the agreements have been reviewed, approved and (if applicable) executed, the Eclipse development community will be informed that the proprietary tool is available to them via the mailing list and a posting on the Eclipse Foundation newsgroup. The document prepared in the previous step will be made publicly available to the community via

  7. The EMO will contact the vendor at least annually to ensure that they wish to continue the relationship and royalty-free licensing terms with the Eclipse project community.