blob: e9454b39165fb506d3c30e716a3d9d3efea72fc7 [file] [log] [blame]
<?php
/**
* Copyright (c) 2005, 2018 Eclipse Foundation and others.
*
* This program and the accompanying materials are made
* available under the terms of the Eclipse Public License 2.0
* which is available at https://www.eclipse.org/legal/epl-2.0/
*
* Contributors:
* Denis Roy (Eclipse Foundation) - Initial implementation
* Eric Poirier (Eclipse Foundation)
*
* SPDX-License-Identifier: EPL-2.0
*/
?>
<style>
.checklist {
border: 1px solid #ccc;
list-style: none;
}
.checklist, .checklist li {
margin: 0;
padding: 0;
}
.checklist label {
display: block;
padding-left: 25px;
text-indent: -25px;
}
.postit {
border: 1px dashed black;
margin: 10px 0 10px 0;
}
.postitinner {
margin: 0 5px 5px 5px;
}
</style>
<div id="midcolumn">
<h1><?php print $pageTitle; ?></h1>
<p>Last updated: March 31, 2008</p>
<h2>
<a name="Who"></a>1.0 Who should read this document
</h2>
<p>
<strong>Committers or Contributors to <a href="/" target="_blank">Eclipse.org</a>
projects
</strong>
</p>
<blockquote>
<p>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 Eclipse.org 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.</p>
</blockquote>
<p>
<strong>Redistributors of Eclipse.org content</strong>
</p>
<blockquote>
<p>Reading this document will help you choose whether you need to modify,
remove, or add to any of the Eclipse.org legal documentation. You may be
redistributing Eclipse.org content as part of your product.</p>
</blockquote>
<p>
<strong>Developers of Eclipse-based content or products</strong>
</p>
<blockquote>
<p>Even if you are not necessarily redistributing Eclipse.org 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.</p>
</blockquote>
<p>
<strong>Users of Eclipse-based content or products</strong>
</p>
<blockquote>
<p>Reading this document will help you to locate the various legal notices
and agreements that govern your use of the content.</p>
</blockquote>
<h2>
<a name="What"></a>2.0 What will this document explain?
</h2>
<p>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-based content, 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.</p>
<h2>
<a name="Why"></a>3.0 Why so many notices?
</h2>
<p>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 &quot;license&quot; or &quot;legal.&quot;
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.</p>
<p>
Eclipse-based content is highly modularized to facilitate ease of delivery,
extensibility, and upgradeability. Important modular concepts in the Eclipse
space include <i>plug-ins</i>, <i>plug-in fragments</i> (herein called
&quot;fragments&quot;), and <i>features</i>. 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.
</p>
<p>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.</p>
<p>For example:</p>
<blockquote>
<ul>
<li>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.</li>
<li>Most of the content is licensed under the <a
href="../org/documents/epl-v10.php"
>Eclipse Public License Version 1.0 (&quot;EPL&quot;)</a>, 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 <a
href="http://www.apache.org" target="_blank"
>Apache Software Foundation</a> such as Ant and Tomcat, or code based on
parts of such packages. These packages may be offered under licenses
other than the EPL.
</li>
<li>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.</li>
</ul>
</blockquote>
<p>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.</p>
<h2>
<a name="LegalDoc"></a>4.0 Eclipse.org legal documentation
</h2>
<h3>4.1 Software User Agreement</h3>
<p>
<strong>The Basics:</strong>
</p>
<p>
The top-level umbrella agreement is the <a href="epl/notice.php"
target="_blank"
>Eclipse Foundation Software User Agreement</a>. The Software User
Agreement, to be called &quot;SUA&quot; 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.
</p>
<p>
<strong>The Details:</strong>
</p>
<p>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.</p>
<p>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 &quot;Cryptography&quot; which lets you know that the content may
contain cryptography.</p>
<p>You will also often see on many of the download pages at Eclipse.org, text
that says:</p>
<blockquote>
<p>
All downloads are provided under the terms and conditions of the <a
href="epl/notice.php" target="_blank"
>Eclipse Foundation Software User Agreement</a> unless otherwise
specified.
</p>
</blockquote>
<p>
<strong>The Location:</strong>
</p>
<p>The SUA usually appears in the root directory of Eclipse builds as the file
named &quot;notice.html&quot;. 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.</p>
<p>
<strong>Note:</strong> The appropriate SUA and a copy of any referenced
license <strong>must</strong> 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 <strong>must </strong>have a link to the
appropriate SUA with appropriate wording.
</p>
<p>
<em>The SUA Checklist</em>
</p>
<ul class="checklist">
<li><label for="o31"><input id="o31" name="o31" type="checkbox" />Every
build distribution has the standard SUA in the root as
&quot;notice.html&quot;</label></li>
<li><label for="o32"><input id="o32" name="o32" type="checkbox" />Every
build distribution has a copy of the primary license(s) in the root,
e.g., &quot;epl-v10.html&quot;</label></li>
</ul>
<h3>
<a name="Abouts"></a>4.2 Abouts
</h3>
<p>
<strong>The Basics:</strong>
</p>
<p>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 &quot;about.html.&quot; We call these files &quot;Abouts.&quot; Abouts
usually contain licensing terms as well as other information such as whether
content contains cryptographic functionality that may be subject to export
controls.</p>
<p>
<strong>The Details:</strong>
</p>
<p>
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 <a href="epl/about.php" target="_blank"> About
templates for plugins</a>.
</p>
<p>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 &quot;interesting&quot; ones that most users will want to
read.</p>
<p>
<strong>Note:</strong> 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&rsquo;ed plug-ins, any local files linked from the About
such as copies of licenses, must be located in a directory called
&quot;about_files.&quot;
</p>
<p>
<strong>The Location:</strong>
</p>
<p>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
&quot;plugins.&quot; Currently, plug-ins and fragments may also be packaged
as JARs (Java&trade; ARchives). For JAR&rsquo;ed plug-ins, any local files
linked from an About such as copies of licenses, must be located in a
directory called &quot;about_files.&quot; The contents of the
&quot;about_files&quot; directory are handled specially so that links
resolve correctly when the About in a JAR&rsquo;ed plug-in is viewed in an
external browser spawned from the About dialog.</p>
<p>As an example:</p>
<blockquote>
<table cellspacing="4">
<tr>
<td><i>eclipse</i></td>
<td>(installation root directory)</td>
</tr>
<tr>
<td>&nbsp;&nbsp;&nbsp;&nbsp;<i>notice.html</i></td>
<td>Software User Agreement</td>
</tr>
<tr>
<td>&nbsp;&nbsp;&nbsp;&nbsp;<i>epl-v10.html</i></td>
<td>the project&rsquo;s primary licenses(s) (typically the EPL alone)
referenced by the SUA</td>
</tr>
<tr>
<td>&nbsp;&nbsp;&nbsp;&nbsp;<i>plugins</i></td>
<td>(plug-ins and fragments directory)</td>
</tr>
<tr>
<td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i>org.apache.ant_1.6.2</i></td>
<td>(plug-in packaged as a directory)</td>
</tr>
<tr>
<td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i>about.html</i></td>
<td>About</td>
</tr>
<tr>
<td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i>asl-v20.txt</i></td>
<td>Apache Software License referenced by About</td>
</tr>
<tr>
<td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i>LICENSE.dom.html</i></td>
<td>W3C License referenced by About</td>
</tr>
<tr>
<td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i>org.eclipse.core.runtime_3.1.0.jar</i></td>
<td>(plug-in packaged as a JAR)</td>
</tr>
<tr>
<td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i>about.html</i></td>
<td>About</td>
</tr>
<tr>
<td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i>about_files</i></td>
<td>(directory for any local files linked from About)</td>
</tr>
<tr>
<td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i>asl-v20.txt</i></td>
<td>Apache Software License referenced by About</td>
</tr>
</table>
</blockquote>
<p>
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 &quot;About plug-ins&quot; dialog in the Eclipse
workbench. To view the Abouts, go to the menu item <strong>Help -> About
Eclipse Platform</strong> and then click on the button &quot;Plug-in
Details&quot; and then select a plug-in and click on the button &quot;More
Info.&quot;
</p>
<p>
<em>The Abouts Checklist</em>
</p>
<ul class="checklist">
<li><label for="o51"><input id="o51" name="o51" type="checkbox" />Every
plug-in has an &quot;about.html&quot;, usually the standard one.</label></li>
<li><label for="o53"><input id="o53" name="o53" type="checkbox" />Every
plug-in with a non-standard &quot;about.html&quot; contains the
additional referenced license files.</label></li>
<li><label for="o52"><input id="o52" name="o52" type="checkbox" />Every
JAR&rsquo;ed plug-in stores linked files in &quot;about_files&quot;</label></li>
</ul>
<br /> <img src="guidetolegaldoc_files/About_plugins_dialog.jpg" width="598"
height="447"
>
<p>&nbsp;</p>
<h3>4.3 Features Licenses and Feature Update Licenses</h3>
<p>
<strong>The Basics:</strong>
</p>
<p>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 &gt; license) and the Feature
Blurb (about.properties &gt; blurb).</p>
<p>
<strong>The Details:</strong>
</p>
<p>
<em>The Feature License</em>
</p>
<p>Each feature has a file named &quot;license.html.&quot; We call this a
&quot;Feature License.&quot; In Eclipse.org builds, this file is an exact
copy of the file &quot;notice.html&quot; that is found in the root directory
of the distribution. In other words, it is the SUA.</p>
<p>
<em>The Feature Update License</em>
</p>
<p>Each feature has a file named &quot;feature.properties.&quot; In that file
is a property named &quot;license&quot. This is known as the &quot;Feature
Update License.&quot; 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&rsquo;ve covered
so far have been HTML files.</p>
<p>
<em>The Feature Blurb</em>
</p>
<p>Each feature has at least one plug-in associated with it which is the
&quot;feature plug-in&quot; for that feature. Not surprisingly, this plug-in
usually has the same name as the feature. The property named
&quot;blurb&quot; contains text that appears in the &quot;About
features&quot; dialog in the Eclipse workbench. This is known as a
&quot;Feature Blurb.&quot; Blurbs often contain copyright notices and any
other statements of attribution that may be required by licenses.</p>
<p>
<em>What&rsquo;s the difference?</em>
</p>
<p>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.</p>
<p>
<strong>Note: </strong>All features must contain a Feature License and a
Feature Update License in the directory for that feature. The
feature&rsquo;s plug-in must contain a Feature Blurb.
</p>
<p>
<strong>The Location:</strong>
</p>
<p>
<em>The Feature License</em>
</p>
<p>The Feature License is found in the feature directory which is usually a
sub-directory of the directory named &quot;features.&quot; Any referenced
files (for example, the EPL or the SUA) are located in the same location.</p>
<p>
<em>The Feature Update License</em>
</p>
<p>The Feature Update License is found in the feature directory which is
usually a sub-directory of the directory named &quot;features.&quot; Any
referenced files (for example, the EPL or the SUA) are located in the same
location.</p>
<p>
<em>The Feature Blurb</em>
</p>
<p>
The Feature Blurb resides in the &quot;plugins&quot; directory as either a
sub-directory or a JAR. In the feature plug-in there is a file named
&quot;about.properties.&quot;, the Feature Blurb is the property named
&quot;blurb&quot;. To view the blurb for each installed feature, go to the
menu item <strong>Help > About Eclipse Platform</strong> and then click
&quot;Feature Details&quot; and then select a feature. The blurb will appear
in the bottom half of the dialog.
</p>
<p>
<em>The Feature Checklist</em>
</p>
<ul class="checklist">
<li><label for="o41"><input id="o41" name="o41" type="checkbox" />Every
feature has the standard SUA in <u>HTML</u> in &quot;license.html&quot;</label></li>
<li><label for="o42"><input id="o42" name="o42" type="checkbox" />Every
feature has the Project&rsquo;s primary license(s) (e.g., typically the
EPL in &quot;epl-v10.html&quot;)</label></li>
<li><label for="o43"><input id="o43" name="o43" type="checkbox" />Every
feature has the standard SUA in <u>plain text</u> in &quot;feature.xml
&lt;license&gt;&quot; or &quot;feature.properties / license&quot;</label></li>
<li><label for="o44"><input id="o44" name="o44" type="checkbox" />Every
feature plug-in has copyright notices, etc. in the &quot;blurb&quot;
property of &quot;about.properties&quot;</label></li>
</ul>
<br /> <img src="guidetolegaldoc_files/About_features_dialog.jpg" width="598"
height="536"
>
<p>An example directory structure corresponding to the above description:</p>
<blockquote>
<table cellspacing="4">
<tr>
<td><i>eclipse</i></td>
<td>(installation root directory)</td>
</tr>
<tr>
<td>&nbsp;&nbsp;&nbsp;&nbsp;<i>features</i></td>
<td>(features directory)</td>
</tr>
<tr>
<td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i>org.eclipse.sdk_3.0.1</i></td>
<td>(feature directory)</td>
</tr>
<tr>
<td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i>license.html</i></td>
<td>(Feature License)</td>
</tr>
<tr>
<td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i>epl-v10.html</i></td>
<td>the project&rsquo;s primary licenses(s) (typically the EPL alone)
referenced by the SUA/Feature License)</td>
</tr>
<tr>
<td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i>feature.properties</i></td>
<td>(Feature Update License in &quot;license&quot; property)</td>
</tr>
<tr>
<td>&nbsp;&nbsp;&nbsp;&nbsp;<i>plugins</i></td>
<td>(plug-ins and fragments directory)</td>
</tr>
<tr>
<td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i>org.eclipse.sdk_3.0.1</i></td>
<td>(plug-in packaged as a directory)</td>
</tr>
<tr>
<td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i>about.properties</i></td>
<td>(Feature Blurb in &quot;blurb&quot; property)</td>
</tr>
</table>
</blockquote>
<p>&nbsp;</p>
<h3>4.4 Notices in source code</h3>
<p>
<strong>The Basics:</strong>
</p>
<p>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.</p>
<p>
<strong>The Details:</strong>
</p>
<p>
The standard format for these notices can be found at www.eclipse.org &gt;
Legal Stuff &gt; <a href="copyrightandlicensenotice.php" target="_blank">
Default Copyright and License Notice</a>.
</p>
<p>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.</p>
<p>
<strong>The Location:</strong>
</p>
<p>In the source code.</p>
<h3>4.5 Notices in documentation</h3>
<p>
<strong>The Basics:</strong>
</p>
<p>The Legal page has a copyright notice and a link to the About in the
plug-in that contains the book.</p>
<p>An example is shown below:</p>
<img src="guidetolegaldoc_files/Help_legal_page.jpg" width="598" height="260">
<p>&nbsp;</p>
<strong>The Location:</strong>
<p>Documentation books usually contain a &quot;Legal&quot; page as the last
page in the book.</p>
<h2>
<a name="Redistribution"></a>5.0 Redistribution of Eclipse.org content
</h2>
<p>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:</p>
<ol>
<li>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.</li>
<li>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.</li>
<li>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.</li>
<li>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&rsquo;ed plug-ins and features and we
will likely see developers of Eclipse-based content do the same thing.
Thus it&rsquo;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.</li>
</ol>
<p>If you wish to cover the entire redistribution with a single license then
you will likely want to locate the necessary licenses for the
&quot;special&quot; Abouts and fulfill the obligations of those licenses
such as flowing down disclaimers, etc.</p>
<h2>
<a name="3rdParty"></a>6.0 Legal documentation in non-Eclipse.org content
</h2>
<p>
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
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 <a href="updatemanager.php" target="_blank">Eclipse Foundation Update
Manager Agreement</a> 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.
</p>
<h2>
<a name="Summary"></a>7.0 Summary
</h2>
<p>There are many legal documentation issues to consider when redistributing
Eclipse.org 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.</p>
<p>
If you have any questions or concerns, please <a
href="mailto:license@eclipse.org"
>contact</a> the staff of the Eclipse Foundation.
</p>
<small>Java and all Java-based trademarks are trademarks of Sun Microsystems,
Inc. in the United States, other countries, or both.</small>
</div>
<div id="rightcolumn">
<div class="sideitem">
<h6>Quick Links</h6>
<ul>
<li><a href="#Who">Who Should Read This?</a></li>
<li><a href="#What">What Will This Explain?</a></li>
<li><a href="#Why">Why So Many Notices?</a></li>
<li><a href="#LegalDoc">The Legal Documents</a></li>
<li><a href="#Redistribution">Redistribution</a></li>
<li><a href="#3rdParty">Documenting Your Products</a></li>
<li><a href="#Summary">Summary</a></li>
</ul>
</div>
</div>