Initial import of existing legal documentation guidelines.

The original guidelines are concerned with Eclipse Platform Plug-ins and
Features.

6 files changed, 194 insertions, 0 deletions

diff --git a/source/chapters/legaldoc-plugins.adoc b/source/chapters/legaldoc-plugins.adoc
new file mode 100644
index 0000000..3b75188
--- /dev/null
+++ b/source/chapters/legaldoc-plugins.adoc
@@ -0,0 +1,189 @@
+[[legaldoc-plugins]]
+= Legal Documentation for Eclipse Platform Plug-ins and Fragments
+
+In this document you will be introduced to the basic Eclipse.org 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 Platform Plug-ins and Fragments, this document will explain how you should redistribute Eclipse.org content and will offer suggestions as to how you may wish to deal with the delivery of legal documentation when including non-Eclipse.org content in your product.
+
+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 Platform Plug-ins and Fragments are 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 Eclipse.org 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 link:../org/documents/epl-v10.php[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 Eclipse.org, or content based on such packages. For example, there may be redistributions of packages from the http://www.apache.org[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 Eclipse.org 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 Eclipse.org 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 Eclipse.org should contain notices as described in the following sections.
+
+[[legaldoc-plugins-software-user-agreement]]
+== Software User Agreement
+
+The top-level umbrella agreement is the {suaUrl}[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 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 Eclipse.org, text that says:
+
+[NOTE]
+====
+All downloads are provided under the terms and conditions of the {suaUrl}[Eclipse Foundation Software User Agreement] unless otherwise specified.
+====
+
+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 Eclipse.org 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
+
+* Every build distribution has the standard SUA in the root as "notice.html"
+* Every build distribution has a copy of the primary license(s) in the root, e.g., "epl-v10.html"
+
+[[legaldoc-plugins-abouts]]
+== About Files
+
+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.
+
+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 Eclipse.org project, please see the link:epl/about.php[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 Eclipse.org 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 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:
+
+____
+[cols=",",]
+|=======================================================================================================
+|_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_
+
+* 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.
+* Every JAR’ed plug-in stores linked files in "about_files"
+
+image::images/About_plugins_dialog.jpg[]
+
+[[legaldoc-plugins-features]]
+== Features Licenses and Feature Update Licenses
+
+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 (feature.properties > license) and the Feature Blurb (about.properties > blurb).
+
+Each feature has a file named "license.html." We call this a "Feature License." In Eclipse.org 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.
+
+Each feature has a file named "feature.properties." In that file is a property named "license". This is known as the "Feature Update License." For Eclipse.org 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.
+
+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 "about.properties.", 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_
+
+* Every feature has the standard SUA in HTML in "license.html"
+* Every feature has the Project’s primary license(s) (e.g., typically the EPL in "epl-v10.html")
+* Every feature has the standard SUA in plain text in "feature.xml <license>" or "feature.properties / license"
+* Every feature plug-in has copyright notices, etc. in the "blurb" property of "about.properties"
+
+.The About Eclipse Platform Features Dialog
+image::images/About_features_dialog.jpg[]
+
+An example directory structure corresponding to the above description:
+
+____
+[cols=",",]
+|================================================================================================================================
+|_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.properties__ |(Feature Update License in "license" property)
+|    __plugins__ |(plug-ins and fragments directory)
+|        __org.eclipse.sdk_3.0.1__ |(plug-in packaged as a directory)
+|            __about.properties__ |(Feature Blurb in "blurb" property)
+|================================================================================================================================
+____
+
+[[legaldoc-plugins-source-code]]
+== Notices in source code
+
+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 standard format for these notices can be found at www.eclipse.org > Legal Stuff > http://www.eclipse.org/legal/copyrightandlicensenotice.php[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.
+
+[[legaldoc-plugins-notices-in-documentation]]
+== Notices in documentation
+
+The Legal page has a copyright notice and a link to the About in the plug-in that contains the book.
+
+.Example legal notice in documentation
+image::images/Help_legal_page.jpg[]
+
+Documentation books usually contain a _Legal_ page as the last page in the book.
+
+[[legaldoc-plugins-redistribution]]
+== Redistribution of Eclipse.org content
+
+There are a number of considerations when redistributing an Eclipse.org build in or with your own products. Such redistribution also covers redistribution of a subset of an Eclipse.org 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 Eclipse.org projects allow you to do (there may be exceptions), then the existing Eclipse.org 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 Eclipse.org, 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 Platform Plug-ins and Fragments 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.
+
+[[legaldoc-plugins-non-eclipse.org-content]]
+== Legal documentation in non-Eclipse.org content
+
+If you are delivering your own Eclipse Platform Plug-ins and Fragments then it is desirable to follow the framework described above so that users can view <<legaldoc-plugins-abouts,Abouts>>, <<legaldoc-plugins-features,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 Eclipse.org 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 link:updatemanager.php[Eclipse Foundation Update Manager Agreement] found on the Legal Stuff page at eclipse.org) you will probably want to make the user aware of any additional terms and conditions by adding them to the relevant documents.
diff --git a/source/config.adoc b/source/config.adoc
index ae3969f..707ce25 100644
--- a/source/config.adoc
+++ b/source/config.adoc
@@ -16,6 +16,7 @@
 :committerQuestionnaireUrl: http://portal.eclipse.org
 :committerGuidelinesUrl: http://www.eclipse.org/legal/committerguidelines.php
 :legalDocumentationUrl: http://www.eclipse.org/legal/guidetolegaldoc.php
+:suaUrl: http://www.eclipse.org/legal/epl/notice.php
 :ipDueDiligenceUrl: http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf
 :ipThirdParty: http://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf
 :ipPolicyUrl: http://eclipse.org/org/documents/Eclipse_IP_Policy.pdf
diff --git a/source/eclipse.adoc b/source/eclipse.adoc
index 9518027..c0465fe 100644
--- a/source/eclipse.adoc
+++ b/source/eclipse.adoc
@@ -50,3 +50,7 @@ include::chapters/checklist.adoc[leveloffset=+1]
 include::chapters/glossary.adoc[]
 
 include::chapters/contact.adoc[]
+
+= Appendix A
+
+include::chapters/legaldoc-plugins.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/source/images/About_features_dialog.jpg b/source/images/About_features_dialog.jpg
new file mode 100644
index 0000000..a67552a
--- /dev/null
+++ b/source/images/About_features_dialog.jpg
diff --git a/source/images/About_plugins_dialog.jpg b/source/images/About_plugins_dialog.jpg
new file mode 100644
index 0000000..b6061b0
--- /dev/null
+++ b/source/images/About_plugins_dialog.jpg
diff --git a/source/images/Help_legal_page.jpg b/source/images/Help_legal_page.jpg
new file mode 100644
index 0000000..9fc2085
--- /dev/null
+++ b/source/images/Help_legal_page.jpg