Eclipse Foundation Legal Frequently Asked Questions (FAQ)

No. All of the materials distributed by the Eclipse Foundation are owned by their respective copyright holders. Eclipse Foundation projects use what is sometimes referred to as “symmetrical inbound/outbound licensing”, which means that contributions are accepted under the same license that they are distributed under. As a result, the Eclipse Foundation itself does not have any particular ownership or licensing stake in the materials it distributes.

The Eclipse Foundation Software User Agreement is an umbrella agreement that covers the use and distribution of materials made available by Eclipse Projects as Plug-ins and Features for the Eclipse Platform.

The Eclipse Foundation Software User Agreement itself does not provide any usage or redistribution rights but instead references the EPL and other notices that grant you rights to the related content.

Eclipse projects convey licensing information via license and notice files. A license file, typically named LICENSE, contain the exact text of the project license(s) and are located in the root of source code repositories and in the distribution content. Notices files, typically named NOTICE, contain information about the project license(s), how they are combined, copyright holders, cryptography, and other project metadata.

For Eclipse Platform Plug-ins, notices are represented in an about.html file.

The Eclipse Foundation Software User Agreement defines Abouts, Feature Licenses, and Feature Update Licenses. Some or all of these notices may be present in content (generally only for Eclipse Platform Plug-ins and Features) made available by the Eclipse Foundation. This framework of other notices is used for a number of reasons:

The Eclipse Public License (EPL) is an open source license that has been approved by the Open Source Initiative.

The terms and conditions of the EPL were crafted to be most appropriate for the Eclipse Foundation. Software made available by the Eclipse Foundation is used by developers who want to freely plug into and extend or alter the content. The EPL goes to great lengths to support and encourage the collaborative open source development of the content, while maximizing the ability to use and/or integrate the content with software licensed under other licenses, including many commercial licenses. Since the Eclipse Foundation seeks to encourage developers of both open source and proprietary development tools to embrace the content, this flexibility is critical.

Eclipse Projects have a Declared License that applies to content developed and maintained by the project team (“Project Code”). Most Eclipse projects use the Eclipse Public License (EPL) as their Declared License, but other licenses (e.g. the Apache Software License 2.0) can be used. All Eclipse Projects exist under the umbrella of a Top-Level Project, each of which specifies one or more permissible licensing schemes. Any licensing scheme other than what is specified by a Top-Level Project must be approved by the Eclipse Board of Directors.

Eclipse Projects may also distribute third party content under different licenses (which are compatible with the project license). The Third Party Content Licenses page provides a list of the most common licenses approved for use by third party content redistributed by Eclipse Foundation Projects. Queries regarding a specific license, should be directed to Eclipse Licensing (license@eclipse.org).

License and notice files that accompany the content produced by an Eclipse Project describe the licenses that apply.

Sometimes the Project Management Committee (PMC) for an Eclipse Foundation Top-Level project may make a decision to include some content from another (third party) open source project. If that content cannot be contributed to an Eclipse Foundation project under the Eclipse.org Terms of Use and the content is not already licensed under EPL, the PMC may decide to use and redistribute the content under the terms and conditions of another license which would usually be the license that the content was received under.

The Eclipse Foundation will only use non-EPL licensed content if the other license is an open source license approved by the Open Source Initiative and it permits commercial products to be built on the software without requiring any form of royalty or other payment.

In some cases the Eclipse Foundation redistributes unmodified non-EPL content and in other cases it redistributes derivative works of non-EPL content. Unmodified non-EPL content is included as a convenience to allow Eclipse Foundation software to be used without first having to locate, obtain, and integrate additional software.

The Eclipse Foundation views license compatibility through the lens of enabling successful adoption of Eclipse technology in both open source and in commercial software products and services. We wish to create a ecosystem based on the redistribution of Eclipse software technologies which includes commercially licensed software products. Determining whether a license for third-party content is acceptable often requires the input and advice of Eclipse’s legal advisors.

The Third Party Content Licenses page provides a list of the most common licenses approved for use by third party content redistributed by Eclipse Foundation Projects. If you have any questions, please contact Eclipse Licensing (license@eclipse.org).

You might want to do some background reading on copyright law or consult a lawyer. "Open source" doesn’t mean that the code does not have a copyright holder. All code has an author and that person is the copyright holder or owner unless the copyright is assigned to another party. In the case of the Eclipse Project, the initial code base was contributed by IBM. Over time, Eclipse Foundation projects have become populated with code provided by many different contributors and as result, different portions of the code have different copyright holders. Licenses such as the EPL grant you a copyright license (subject to certain terms and conditions) and that is how you receive copyright rights to use, modify, redistribute, etc. the content. Although you may receive copyright rights through the EPL, or another license, it still doesn’t change who the copyright holders are for various portions of the content.

The current version is Version 2.0. There is a separate FAQ that focuses entirely on the EPL.

Under the Eclipse Public License (EPL), each Contributor grants rights to create derivative works and for worldwide, royalty-free software redistribution in accordance with the EPL terms, including a royalty-free license to use Contributor’s patents as embodied in its contributions. Section 7 of the EPL includes the following:

Eclipse software is free and open source software that is distributed royalty-free under the terms of the project license(s). If you are going to distribute Eclipse code, you should read our Guidelines and our EPL FAQ. They both contain a great deal of useful information.

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.

Contributors who are invited to join an Eclipse open source project must complete additional committer paperwork before they are granted write access to project resources. 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.

The short answer to this question is "it depends".

Content made available by the Eclipse Foundation is sometimes accompanied by or includes content based on third-party content. This third-party content is often sourced from other open source projects such as those run by the Apache Software Foundation. Eclipse Foundation projects try to avoid branching from other open source projects wherever possible. However sometimes it just can’t be avoided especially if the change is critical and the other project’s next release date is too far out or they won’t accept the change for some reason. Subsequently, while changes to third-party content (either unmodified or derivative works of) might be accepted and incorporated into the Eclipse Foundation codebase, Eclipse Foundation committers may often forward these changes to other open source projects and/or may ask contributors of such changes to do the same.

If the questions you have concern whether or not you can legally contribute the content to the Eclipse Foundation, you should consult a lawyer. If you are contributing content on behalf of the company you work for then you should probably ask your company’s legal department. It is up to you to ensure that you can satisfy section 2 d) of the EPL that says:

Many companies have their own processes for handling contributions to open source projects.

As a committer you have the ability to control the content distributed in the Eclipse Foundation source code repositories and downloads. Contributors may provide contributions to the Eclipse Foundation but such contributions do not exist in the repository or downloads unless they are accepted by a committer. Committers therefore have a responsibility to perform due diligence on any content they release.

The Eclipse Committer Due Diligence Guidelines outline the guidelines for committers.

You should contact the Project Management Committee (PMC) for your project.

Yes. Where possible, copyright notices must be included the file headers for all project content. This includes source files and, where possible, configuration. A best effort approach is expected, and so reasonable exceptions are acceptable (e.g. there is not standard means for providing a file header in JSON content). See the default copyright and license notice template.

Your committer status at the Eclipse Foundation is not based on your employment status. It is an individual recognition of your frequent and valuable contributions to one or more Eclipse projects. If you do change employers, please contact the EMO Records Team by email (emo-records@eclipse.org)  to ensure that the necessary employer consent paperwork is completed. For more details, please see the New Committer Process.

In some cases software made available by the Eclipse Foundation may contain cryptography. For example, the Eclipse Platform contains cryptography and has been classified as Export Control Classification Number (ECCN) 5D002.c.1 by the U.S. Government Department of Commerce, Bureau of Industry and Security. All object code and source code for Eclipse projects are eligible for export from the United States of America under 15 CFR §742.15(b), and deemed not subject to Export Administration Regulations as publicly available encryption source code classified ECCN 5D002.

Notice files (e.g. an about.html files in Eclipse Platform Plug-ins)  contain information about the specific algorithms, key sizes, and other important information that may be required to obtain additional export control classifications and approvals.

Some countries have restrictions regarding the export, import, possession, and use, and/or re-export to another country, another person or for a particular use of encryption software, but it does not restrict you in any way nor require you to do anything special if you receive encryption software from the Eclipse Foundation. In other words, it is your responsibility to determine what laws and regulations apply to you and to act appropriately.

Last updated on December 20/2017