Skip to main content

Guide to the Legal Documentation for Eclipse Plug-ins and Features under the EPL-1.0

Last updated: March 31, 2008

1.0 Who should read this document

Committers or Contributors to projects

Reading this document will help you understand the legal documentation requirements of your project. While committers are ultimately responsible for ensuring that content in the projects contains the appropriate legal documentation, it is always appreciated when contributors can deliver content that requires minimal work to be integrated into the codebase.

Redistributors of content

Reading this document will help you choose whether you need to modify, remove, or add to any of the legal documentation. You may be redistributing content as part of your product.

Developers of Eclipse-based content or products

Even if you are not necessarily redistributing content itself, reading this document will help you to determine whether or not you wish to adopt some or all of the described framework, for documenting your own content.

Users of Eclipse-based content or products

Reading this document will help you to locate the various legal notices and agreements that govern your use of the content.

2.0 What will this document explain?

In this document you will be introduced to the basic legal documentation styles; Agreements, Abouts, Licenses and Notices. For each of these styles, we have provided a brief overview, some background information and instructions pertaining to where you can find them as well as where you should place them. After describing the framework used for legal documentation in Eclipse-based content, this document will explain how you should redistribute content and will offer suggestions as to how you may wish to deal with the delivery of legal documentation when including content in your product.

3.0 Why so many notices?

Most software products are delivered with a single license file. This file is usually found in the root directory of the installation or in some obviously-named directory such as "license" or "legal." This straightforward mechanism is used even if there are differently licensed components in the product. In those cases, the single license file may actually contain multiple licenses or notices and it is usually clear which parts of the product each license or notice applies to.

Eclipse-based content is highly modularized to facilitate ease of delivery, extensibility, and upgradeability. Important modular concepts in the Eclipse space include plug-ins, plug-in fragments (herein called "fragments"), and features. A typical Eclipse installation may potentially include plug-ins and features authored and/or distributed by many different parties including the Eclipse Foundation, other open-source organizations, and commercial vendors.

The content that is developed and maintained at is a very large codebase that is continuously evolving and may be accessed in a multitude of ways.

For example:

  • Some parts of the content are constantly changing with updates being committed on an almost continuous basis. With committers on a single project spread across many time zones development may be occurring 24x7.
  • Most of the content is licensed under the Eclipse Public License Version 1.0 ("EPL"), although at the discretion of the Board of Directors a project may be dual-licensed, or even be maintained under another license altogether. However, the codebase also contains redistributions of many packages maintained at sites other than, or content based on such packages. For example, there may be redistributions of packages from the Apache Software Foundation such as Ant and Tomcat, or code based on parts of such packages. These packages may be offered under licenses other than the EPL.
  • The content at may be accessed and downloaded in many ways. Most projects create builds on a regular basis. Some projects create many builds for different platforms and configurations on a daily basis. Because these builds are created straight from the source code repositories, recently committed updates are found in the builds. It is also possible to access content directly from the source code repositories or to download new or updated features using the Eclipse Update Manager.

All of these content characteristics call for a modular approach to legal documentation. Consequently, any distribution of content originating from should contain notices as described in the following sections.

4.0 legal documentation

4.1 Software User Agreement

The Basics:

The top-level umbrella agreement is the Eclipse Foundation Software User Agreement. The Software User Agreement, to be called "SUA" herein, 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 Details:

The most important wording is that which says that the EPL applies to all the content unless otherwise indicated. Note that although the EPL is used by all projects at the Eclipse Foundation, at the discretion of the Board of Directors a project may be dual-licensed, or even be maintained under another license altogether.

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 you 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 Location:

The SUA usually appears in the root directory of Eclipse builds as the file named "notice.html". A copy of the Project's primary license(s) must appear in the same location as the SUA. In most cases this will be the Eclipse Public License alone.

Note: The appropriate SUA and a copy of any referenced license must be located in the root directory of any distributed build (typically distributed as a ZIP file). Any web page that makes builds available must have a link to the appropriate SUA with appropriate wording.

The SUA Checklist

4.2 Abouts

The Basics:

Any directory containing content that is licensed under different terms than the license(s) referred to by the SUA, 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.

The Details:

Most plug-ins will contain a default About that simply confirms that all the content in that plug-in is made available under the 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 project, please see the About templates for plugins.

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

Note: All plug-ins and fragments should contain an About. All 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."

The Location:

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

As an example:

eclipse (installation root directory)
    notice.html Software User Agreement
    epl-v10.html the project’s primary licenses(s) (typically the EPL alone) referenced by the SUA
    plugins (plug-ins and fragments directory)
        org.apache.ant_1.6.2 (plug-in packaged as a directory)
            about.html About
            asl-v20.txt Apache Software License referenced by About
            LICENSE.dom.html W3C License referenced by About
        org.eclipse.core.runtime_3.1.0.jar (plug-in packaged as a JAR)
            about.html About
            about_files (directory for any local files linked from About)
                asl-v20.txt Apache Software License referenced by About

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 and then click on the button "Plug-in Details" and then select a plug-in and click on the button "More Info."

The Abouts Checklist


4.3 Features Licenses and Feature Update Licenses

The Basics:

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

The Details:

The Feature License

Each feature has a file named "license.html." We call this a "Feature License." In builds, this file is an exact copy of the file "notice.html" that is found in the root directory of the distribution. In other words, it is the SUA.

The Feature Update License

Each feature has a file named "" In that file is a property named "license". This is known as the "Feature Update License." For builds, the Feature Update License is an exact copy of the SUA in PLAIN TEXT format. Feature Update Licenses must be delivered in that format whereas all the other files we’ve covered so far have been HTML files.

The Feature Blurb

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

What’s the difference?

The difference between the Feature License and Feature Update License is when they are shown to the user. The Feature License is only available once a feature has been installed. The Feature Update License is seen when a user is using the Eclipse Update Manager to install or upgrade a feature and must agree to an agreement before proceeding with the installation. One thing that is important to note is that with the distributed licensing model used by plug-ins, unless a Feature Update License contains an aggregation of all the notices from the plug-ins for a feature, a user will not be able to see these notices before installing the feature. It is for this reason that the maintainer of a feature may choose to have different text for the Feature License and Feature Update License.

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

The Location:

The Feature License

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

The Feature Update License

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

The Feature Blurb

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

The Feature Checklist

An example directory structure corresponding to the above description:

eclipse (installation root directory)
    features (features directory)
        org.eclipse.sdk_3.0.1 (feature directory)
            license.html (Feature License)
            epl-v10.html the project’s primary licenses(s) (typically the EPL alone) referenced by the SUA/Feature License)
   (Feature Update License in "license" property)
    plugins (plug-ins and fragments directory)
        org.eclipse.sdk_3.0.1 (plug-in packaged as a directory)
   (Feature Blurb in "blurb" property)


4.4 Notices in source code

The Basics:

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

The Details:

The standard format for these notices can be found at > Legal Stuff > Default Copyright and License Notice.

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

The Location:

In the source code.

4.5 Notices in documentation

The Basics:

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

An example is shown below:


The Location:

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

5.0 Redistribution of content

There are a number of considerations when redistributing an build in or with your own products. Such redistribution also covers redistribution of a subset of an build such as one or more plug-ins or features from the build. Specifically:

  1. All of the legal documentation is written on behalf of the Eclipse Foundation as if it were the distributor of the content. If you redistribute the content then it is no longer true that Eclipse Foundation is providing the content. In this case, the content originated with the Eclipse Foundation and you are redistributing it.
  2. If you are redistributing the object code under your own license as the EPL, and other licenses used by the projects allow you to do (there may be exceptions), then the existing legal documentation can be very misleading to readers since it states that use of the object code is governed by various open source licenses.
  3. Although the distributed model of the SUA, Abouts, Feature License, and Feature Update Licenses is necessary for the dynamic model of content distribution from, it may not suit your situation. The downside of this model is that users have to locate and read many files to find all the terms and conditions. In most cases, redistributors want to present a single license although you may want to consider how you will updates provided through the Eclipse Update Manager for example.
  4. Changing any of the existing legal documentation requires a change in the version number of any affected component. Soon, the Eclipse Foundation will begin to digitally sign JAR’ed plug-ins and features and we will likely see developers of Eclipse-based content do the same thing. Thus it’s pretty clear that altering or removing any of the legal documentation is not really an option. Instead it is better to put appropriate wording in your license explaining that the content was originally obtained from the Eclipse Foundation under open source licenses including the EPL, and that you are redistributing it and potentially relicensing it. Such an explanation will provide the opportunity and context for the flowdowns in 3 b) of the EPL.

If you wish to cover the entire redistribution with a single license then you will likely want to locate the necessary licenses for the "special" Abouts and fulfill the obligations of those licenses such as flowing down disclaimers, etc.

6.0 Legal documentation in content

If you are delivering your own Eclipse-based content then it will likely be packaged as plug-ins and features. In these cases it is desirable to follow the framework described above so that users can view Abouts, Feature Licenses, and Feature Update Licenses. You will likely want a single license to cover the entire package of your own content plus the redistributed code. You may therefore wish to point out which plug-ins and/or features are being redistributed from the Eclipse Foundation and which are originating from you. You may wish to have the Abouts, Feature Licenses, and Feature Update Licenses in your own plug-ins and features, simply point the user back to the single license in the root directory of the installation rather than duplicating the text everywhere. Of course if you deliver additional or updated features packaged on an update site for download and installation with the Eclipse Update Manager (in which case you should read the Eclipse Foundation Update Manager Agreement found on the Legal Stuff page at you will probably want to make the user aware of any additional terms and conditions by adding them to the relevant documents.

7.0 Summary

There are many legal documentation issues to consider when redistributing content and delivering Eclipse-based content. It is important that you fully understand what you are redistributing and delivering, and how it will be delivered and thus how your users will encounter (and where necessary agree to) legal documentation, so that you can ensure your conformity with, and their acceptance of, the requirements set forth in the applicable license agreements.

If you have any questions or concerns, please contact the staff of the Eclipse Foundation.

Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

Back to the top