Skip to main content
aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorWayne Beaton2020-07-23 15:27:37 +0000
committerWayne Beaton2020-07-23 15:27:37 +0000
commitdc4cc0327958419ab67b0d8e41a60b44b3c7bba7 (patch)
treee15036df02efc5caa55b8e4002349db1c2156c27
parent75fc783a66ffbcc374adedc32f3fa58826bc4ce3 (diff)
downloadorg.eclipse.dash.handbook-master.tar.gz
org.eclipse.dash.handbook-master.tar.xz
org.eclipse.dash.handbook-master.zip
Consistency pass: use "third-party" in place of "third party"HEADmaster
Signed-off-by: Wayne Beaton <wayne.beaton@eclipse-foundation.org>
-rw-r--r--source/chapters/checklist.adoc2
-rw-r--r--source/chapters/contributing.adoc2
-rw-r--r--source/chapters/dpia.adoc2
-rw-r--r--source/chapters/glossary.adoc6
-rw-r--r--source/chapters/ip-thirdparty.adoc24
-rw-r--r--source/chapters/ip.adoc2
-rw-r--r--source/chapters/legaldoc-plugins.adoc2
-rw-r--r--source/chapters/legaldoc.adoc8
-rw-r--r--source/chapters/release.adoc4
-rw-r--r--source/chapters/resources.adoc4
-rw-r--r--source/chapters/specifications.adoc2
-rw-r--r--source/chapters/starting.adoc2
-rw-r--r--source/chapters/trademarks.adoc14
13 files changed, 37 insertions, 37 deletions
diff --git a/source/chapters/checklist.adoc b/source/chapters/checklist.adoc
index b5a5491..8c7b556 100644
--- a/source/chapters/checklist.adoc
+++ b/source/chapters/checklist.adoc
@@ -46,7 +46,7 @@ All projects must conform to the <<trademarks,branding guidelines>> before engag
Most projects provide binary/compiled _downloads_ of their software, intended for consumption by their various communities. If the project does not provide downloads, then that should be stated on the project's website.
* All generated artifacts include only intellectual property that has been subject to the IP Due Diligence Process;
-* All distributed third party content has been approved by the IP Team;
+* All distributed third-party content has been approved by the IP Team;
* The project website and PMI page includes links for artifacts;
* <<starting-incubation-branding,Incubation branding>> (when applicable) is included on distributed artifacts;
* All download artifacts are (if technical feasible) {jarSigningUrl}[signed]; and
diff --git a/source/chapters/contributing.adoc b/source/chapters/contributing.adoc
index 34facea..b0397fb 100644
--- a/source/chapters/contributing.adoc
+++ b/source/chapters/contributing.adoc
@@ -67,7 +67,7 @@ digraph {
[NOTE]
====
-{forgeName} committers must engage with the EMO Intellectual Property Team to review your <<ip-project-code, project code>> contributions, or <<ip-third-party, third party>> content that your contributions leverage. The committers will take are of this, but may need your help as part of the process.
+{forgeName} committers must engage with the EMO Intellectual Property Team to review your <<ip-project-code, project code>> contributions, or <<ip-third-party, third-party>> content that your contributions leverage. The committers will take are of this, but may need your help as part of the process.
====
After establishing a pattern of contributing high quality contributions a contributor may be invited to join the project as a committer; an existing project committer will nominate a contributor to be a committer via <<elections-committer, committer election>>.
diff --git a/source/chapters/dpia.adoc b/source/chapters/dpia.adoc
index d253ab9..92bfcc5 100644
--- a/source/chapters/dpia.adoc
+++ b/source/chapters/dpia.adoc
@@ -45,7 +45,7 @@ As a best practice the results from creating a DPIA should be published, in orde
====
**Fish Data Protection Impact Assessment**
-The Fish IoT project is looking to start combining data from a family of IoT devices (PetFinder Plus series) that are produced by a third party, and to combine that with data from our public management server in order to produce a contact list of people.
+The Fish IoT project is looking to start combining data from a family of IoT devices (PetFinder Plus series) that are produced by a third-party, and to combine that with data from our public management server in order to produce a contact list of people.
We will do this by using cloud based virtual servers and cross referencing the email addresses stored in our management server with the registration email stored by the PetFinder plus devices and provided by the device when it is contacted by the registration server.
diff --git a/source/chapters/glossary.adoc b/source/chapters/glossary.adoc
index 26d3762..e76f348 100644
--- a/source/chapters/glossary.adoc
+++ b/source/chapters/glossary.adoc
@@ -78,7 +78,7 @@ The EMO Records Team (commonly referred to as _EMO Records_) is responsible for
Exempt Prerequisite (Dependency) ::
-An <<ip-third-party-exempt,Exempt Prerequisite>> is defined as third party content which is used by Eclipse project code but is not not subject to review by the IP Team. Content may be considered exempt if it is "is pervasive in nature, expected to be already on the user's machine, and/or an IP review would be either impossible, impractical, or inadvisable."
+An <<ip-third-party-exempt,Exempt Prerequisite>> is defined as third-party content which is used by Eclipse project code but is not not subject to review by the IP Team. Content may be considered exempt if it is "is pervasive in nature, expected to be already on the user's machine, and/or an IP review would be either impossible, impractical, or inadvisable."
Genie ::
@@ -102,7 +102,7 @@ The Eclipse Foundation and Eclipse community is supported by our {memberUrl}[mem
Prerequisite (Dependency)::
-A <<ip-third-party-prereq,Prerequisites>> (or _prereqs_) are third party content that is required by the Eclipse project content to provide core functionality.
+A <<ip-third-party-prereq,Prerequisites>> (or _prereqs_) are third-party content that is required by the Eclipse project content to provide core functionality.
Project::
@@ -137,4 +137,4 @@ Eclipse {wgUrl}[Working Groups] provide a vendor-neutral governance structure th
Works With Dependency ::
-A <<ip-third-party-workswith,Works With Dependency>> is defined as third party content that Eclipse Project Code will work with when it is available. The fundamental requirement is the Eclipse Project Code must be useful and adoptable without the Works With Dependency. That is, either the Project Code provides useful functionality without the Works With Dependency or the Works With Dependency is a suitable alternative for a <<ip-third-party-prereq,Prerequisite>>. \ No newline at end of file
+A <<ip-third-party-workswith,Works With Dependency>> is defined as third-party content that Eclipse Project Code will work with when it is available. The fundamental requirement is the Eclipse Project Code must be useful and adoptable without the Works With Dependency. That is, either the Project Code provides useful functionality without the Works With Dependency or the Works With Dependency is a suitable alternative for a <<ip-third-party-prereq,Prerequisite>>. \ No newline at end of file
diff --git a/source/chapters/ip-thirdparty.adoc b/source/chapters/ip-thirdparty.adoc
index 888bfb8..39ee6b2 100644
--- a/source/chapters/ip-thirdparty.adoc
+++ b/source/chapters/ip-thirdparty.adoc
@@ -15,15 +15,15 @@ The term Intellectual Property (IP) refers to any sort of creative work, be it l
The ease with which software can be copied and combined makes it challenging to know with confidence if content can be used without running into legal issues. Any sort of serious software development effort must be accompanied by a well-defined IP Due Diligence process that can ferret out issues and mitigate the risk of leveraging the work of others. IP Due Diligence is a time consuming process that requires specialized skills and a keen eye for detail.
-There are different kinds of content (source code, documentation, images, …) to consider. Project Code is content that is produced and maintained by the open source project committers and contributors. Third Party Content generally takes the form of libraries (modules, components, …), source files, images, or other forms of IP that are produced and maintained outside of the scope of the open source project. To mitigate the risk associated with adopting open source in products, the Project Code and Third Party Content that it leverages need to be vetted to ensure that the copyrights expressed are correct, licensing is valid and compatible, and other issues have been uncovered and properly investigated.
+There are different kinds of content (source code, documentation, images, …) to consider. Project Code is content that is produced and maintained by the open source project committers and contributors. Third-party Content generally takes the form of libraries (modules, components, …), source files, images, or other forms of IP that are produced and maintained outside of the scope of the open source project. To mitigate the risk associated with adopting open source in products, the Project Code and Third-party Content that it leverages need to be vetted to ensure that the copyrights expressed are correct, licensing is valid and compatible, and other issues have been uncovered and properly investigated.
-The Eclipse Foundation has a well-defined IP Policy, corresponding IP Due Diligence Process, and a dedicated team of professional IP specialists who perform the heavy lifting in the due diligence process. Committers, the software developers who decide what will become Project Code and how an Eclipse open source project will leverage Third Party Content, are responsible for bringing IP issues to the attention of the Eclipse IP Team.
+The Eclipse Foundation has a well-defined IP Policy, corresponding IP Due Diligence Process, and a dedicated team of professional IP specialists who perform the heavy lifting in the due diligence process. Committers, the software developers who decide what will become Project Code and how an Eclipse open source project will leverage Third-party Content, are responsible for bringing IP issues to the attention of the Eclipse IP Team.
Most of the Project Code produced by committers can just be pushed into a project repository without any sort of legal review. However, at least in some cases, the IP Team needs to be engaged to review Project Code that comes from contributors (who are not committers); and there are some cases where even the work of committers needs to be reviewed. I’ll discuss Project Code with more detail in a future post.
-The sort of effort that the Eclipse IP Team brings to bear on Third Party Content varies depending on the type. The Guidelines for the Review of Third Party Dependencies defines three different types: Prerequisite, Exempt Prerequisite, and Works With Dependency.
+The sort of effort that the Eclipse IP Team brings to bear on Third-party Content varies depending on the type. The Guidelines for the Review of Third-party Dependencies defines three different types: Prerequisite, Exempt Prerequisite, and Works With Dependency.
-The simplest form of Third Party Content is Prerequisite. Prerequisites are required by the Eclipse project content to provide core functionality. Prerequisite content is not generally stored in an Eclipse project’s source code repositories, but is likely included in build scripts and referenced as runtime dependencies. Since adopters of Eclipse project content are compelled to adopt the Prerequisite content, that content must also be vetted by the IP Team. The vetting requirement applies recursively: the entire transitive closure of a Prerequisite’s dependencies needs to reviewed (the dependencies of a Prerequisite are themselves Prerequisites).
+The simplest form of Third-party Content is Prerequisite. Prerequisites are required by the Eclipse project content to provide core functionality. Prerequisite content is not generally stored in an Eclipse project’s source code repositories, but is likely included in build scripts and referenced as runtime dependencies. Since adopters of Eclipse project content are compelled to adopt the Prerequisite content, that content must also be vetted by the IP Team. The vetting requirement applies recursively: the entire transitive closure of a Prerequisite’s dependencies needs to reviewed (the dependencies of a Prerequisite are themselves Prerequisites).
[graphviz, images/prereq_dependencies, svg]
.Eclipse Project Dependencies
@@ -38,7 +38,7 @@ digraph {
root[label="Eclipse Project\nContent"];
subgraph cluster_prereq {
- node [fontsize=10;label="Third Party\nContent"]
+ node [fontsize=10;label="Third-party\nContent"]
prereq1; prereq2;
ref1; ref2; ref3; ref4;
label="\"Prereq\" Dependencies\n(Must be vetted by the IP Team)";
@@ -53,7 +53,7 @@ digraph {
}
----
-The transitive closure requirement only applies when an Eclipse project makes a direct reference to Third Party Content (the Eclipse Project Handbook provides some examples of what constitutes a direct reference). In the case where an Eclipse project references code from a second Eclipse project that itself references Prerequisites, no further vetting of that chain of Prerequisite content is required (the IP Team will have already vetted it on behalf of the second project team). Eclipse project teams should take care to only reference release versions of other Eclipse projects in their own releases to ensure that the IP process has been completed.
+The transitive closure requirement only applies when an Eclipse project makes a direct reference to Third-party Content (the Eclipse Project Handbook provides some examples of what constitutes a direct reference). In the case where an Eclipse project references code from a second Eclipse project that itself references Prerequisites, no further vetting of that chain of Prerequisite content is required (the IP Team will have already vetted it on behalf of the second project team). Eclipse project teams should take care to only reference release versions of other Eclipse projects in their own releases to ensure that the IP process has been completed.
[graphviz, images/eclipse_dependencies, svg]
.Eclipse Project Dependencies
@@ -72,14 +72,14 @@ digraph {
label="No further vetting required";
node [fontsize=10;label="Content from\na different\nEclipse Project"]
prereq1;
- node [fontsize=10;label="Third Party\nContent"]
+ node [fontsize=10;label="Third-party\nContent"]
ref1;
}
subgraph cluster_thirdparty {
graph[style=dotted];
label="\"Prereq\" Dependencies\n(Must be vetted by the IP Team)";
- node [fontsize=10;label="Third Party\nContent"]
+ node [fontsize=10;label="Third-party\nContent"]
prereq2;
ref2;
}
@@ -97,7 +97,7 @@ The Eclipse IP process guidelines provide for a notion of Exempt Prerequisite de
One of the key aspects of an Exempt Prerequisite is that the user or adopter is typically the one that actually installs the software and so is the one who must agree to the licensing terms. Content that is declared an Exempt Prerequisite should never be directly distributed by an Eclipse project or otherwise made available without some explicit action from the consumer. Exempt Prerequisites must be approved by the Eclipse Foundation’s Executive Director.
-The Eclipse IP process guidelines also define the notion of a Works With Dependency (commonly referred to as a “works with”) that applies in two different cases. Third Party Content may be declared a Works With Dependency when:
+The Eclipse IP process guidelines also define the notion of a Works With Dependency (commonly referred to as a “works with”) that applies in two different cases. Third-party Content may be declared a Works With Dependency when:
* the functionality of Eclipse project content is enhanced by the presence of the software, but is otherwise functional and useful without it; or
* there are multiple choices and vetting all of them is impractical or impossible.
@@ -123,7 +123,7 @@ digraph {
subgraph cluster_prereq {
label="\"Prereq\" Dependencies\n(Must be vetted by the IP Team)";
graph[style=dotted];
- node [fontsize=10;label="Third Party\nContent"]
+ node [fontsize=10;label="Third-party\nContent"]
prereq1; prereq2;
ref1; ref2; ref3; ref4;
}
@@ -131,12 +131,12 @@ digraph {
subgraph cluster_workswith {
graph[style=dotted];
- node [fontsize=10;label="Third Party\n\"Works With\" Content\n(Must be vetted by the IP Team)"]
+ node [fontsize=10;label="Third-party\n\"Works With\" Content\n(Must be vetted by the IP Team)"]
workswith;
subgraph cluster_workswith_transitive {
label="\"Works With\" Dependencies\n(No vetting required)";
graph[style=dotted];
- node [fontsize=10;label="Third Party\nContent"]
+ node [fontsize=10;label="Third-party\nContent"]
workswith1; workswith2; workswith3;
}
}
diff --git a/source/chapters/ip.adoc b/source/chapters/ip.adoc
index c1f16e5..d36e58d 100644
--- a/source/chapters/ip.adoc
+++ b/source/chapters/ip.adoc
@@ -782,7 +782,7 @@ No. A release may only use released content from other projects. A project may d
Are project websites subject to the IP Due Diligence Process? ::
Website content is separate from project content. Project teams are expected to respect licenses for all web site content, but are not required to submit website content (including third-party libraries) for review by the IP Team.
-My IP Log contains outdated third party dependency information. How do I update this information?::
+My IP Log contains outdated third-party dependency information. How do I update this information?::
Send an email to the {ipTeamEmailLink}, providing a list of CQs to be marked as either:
+
* "unused" - not currently used, but potentially may be in the future or
diff --git a/source/chapters/legaldoc-plugins.adoc b/source/chapters/legaldoc-plugins.adoc
index 81baba4..76242a9 100644
--- a/source/chapters/legaldoc-plugins.adoc
+++ b/source/chapters/legaldoc-plugins.adoc
@@ -40,7 +40,7 @@ The SUA usually appears in place of an actual license in the <<legaldoc-plugins-
Any directory containing content that is licensed under different terms than the project license(s), 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 project license, typically the Eclipse Public License (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 project, please see the <<legal-doc-plugins-about-templates,About templates for plug-ins>>.
+Most plug-ins will contain a default _About_ that simply confirms that all the content in that plug-in is made available under the project license, typically the Eclipse Public License (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 project, please see the <<legal-doc-plugins-about-templates,About templates for plug-ins>>.
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.
diff --git a/source/chapters/legaldoc.adoc b/source/chapters/legaldoc.adoc
index 06dc71f..5dc427b 100644
--- a/source/chapters/legaldoc.adoc
+++ b/source/chapters/legaldoc.adoc
@@ -69,7 +69,7 @@ Project teams should consult with their PMCs for input and advice regarding alte
All products delivered by the project—including executables, websites, documentation, and help must include certain notices. An executable might, for example, provide this information in an _About Dialog_; documentation might include a notice in either the pre- or post-amble, or a website might provide this information in a common footer, or a dedicated page.
-The notices must include one or more copyright statement, the assertion of trademarks owned by the Eclipse Foundation on behalf of the project, indication of third party trademarks in use, and--if applicable--a cryptography notice.
+The notices must include one or more copyright statement, the assertion of trademarks owned by the Eclipse Foundation on behalf of the project, indication of third-party trademarks in use, and--if applicable--a cryptography notice.
.Example website notices
____
@@ -180,7 +180,7 @@ In SPDX, disjunction is used to express dual licensing and conjunction is used t
[[legaldoc-license]]
== License File
-The license file contains the exact text of the project’s declared licenses in human readable form. The declared licenses are those that the project team’s content is distributed under. This does not, for example, include the licenses of third party content or incidental fragments of code that is incorporated into the project content (the license of any such content should be indicated in the source file itself and the notice file that accompanies it).
+The license file contains the exact text of the project’s declared licenses in human readable form. The declared licenses are those that the project team’s content is distributed under. This does not, for example, include the licenses of third-party content or incidental fragments of code that is incorporated into the project content (the license of any such content should be indicated in the source file itself and the notice file that accompanies it).
If the project code is distributed under multiple licenses then the text of those licenses must be included. The file should start with a short paragraph that describes how the licenses are combined. This statement should in most cases, be exactly the same as the license statement in the file <<ip-copyright-headers,copyright and license headers>> (see the example below).
@@ -206,7 +206,7 @@ http://www.eclipse.org/legal/epl-2.0, or the Apache Software License
Notice files are expressed in human-readable plain text format; human readable markup languages may be used. The file is conventionally named `NOTICE` and may include a suffix (e.g. `NOTICE.md`).
-The notice file must include basic project metadata, an expression of the declared project licenses, information regarding the licensing of any third party content, and a statement regarding the use of cryptography in cases where either the project code or third party content implements cryptography.
+The notice file must include basic project metadata, an expression of the declared project licenses, information regarding the licensing of any third-party content, and a statement regarding the use of cryptography in cases where either the project code or third-party content implements cryptography.
Project metadata provides the identity of the originating project, along with pointers to the project’s website and canonical source code repositories.
@@ -395,7 +395,7 @@ The cryptography statement is only required if the project code includes cryptog
What licenses should be listed in a build script (e.g. Maven `pom.xml` file)?::
-The license(s) in the build should reflect what is being built, but typically not the license(s) of referenced third party content. The `pom.xml` file for project code, for example, should list the project license(s).
+The license(s) in the build should reflect what is being built, but typically not the license(s) of referenced third-party content. The `pom.xml` file for project code, for example, should list the project license(s).
In a multiple license scenario, do we use conjunction (`AND`) or disjunction (`OR`)?::
diff --git a/source/chapters/release.adoc b/source/chapters/release.adoc
index bc91ed9..113fbfa 100644
--- a/source/chapters/release.adoc
+++ b/source/chapters/release.adoc
@@ -56,7 +56,7 @@ The _Plan_ tab in the release record contains numerous fields for capturing plan
Producing regular builds is an important part of the release cycle. Builds are an important means of engaging with the community: adopters can help you test your code and test their own so that they can be ready for the eventual release. Project teams should plan to produce at least one _milestone_ build (more are better, depending on the length of your release cycle), and capture the planned date for that milestone in the release record. It is also common practice to generate nightly and weekly integration builds. Project teams must ensure that their project's downloads page provides the information required for the community to obtain builds.
-All requests for review of <<ip,intellectual property>> contributions must be approved by the IP Team before the products of a release are pushed out onto distribution channels (this includes third party content and contributions of code to be maintained by the project).
+All requests for review of <<ip,intellectual property>> contributions must be approved by the IP Team before the products of a release are pushed out onto distribution channels (this includes third-party content and contributions of code to be maintained by the project).
[[release-milestones]]
=== Milestones and Release Candidates
@@ -185,7 +185,7 @@ Click the btn:[Submit] button on the <<ip-iplog-generator,IP Log generator>>. Yo
Can I accept contributions after I submit the IP Log for review? ::
-The short answer is _yes_. Please do accept contributions. If you require a new contribution questionnaire (for either a third party library or code contribution) after submitting the IP Log for review, please ask the mailto:{ipTeamEmail}[IP Team] if they want you to resubmit the IP Log.
+The short answer is _yes_. Please do accept contributions. If you require a new contribution questionnaire (for either a third-party library or code contribution) after submitting the IP Log for review, please ask the mailto:{ipTeamEmail}[IP Team] if they want you to resubmit the IP Log.
How do I obtain PMC approval? ::
diff --git a/source/chapters/resources.adoc b/source/chapters/resources.adoc
index 71ecd65..9971008 100644
--- a/source/chapters/resources.adoc
+++ b/source/chapters/resources.adoc
@@ -15,7 +15,7 @@ Open source projects at the Eclipse Foundation are _required_ to make use of cer
* All project issues must be tracked in the issue tracker assigned to the project;
* Source code must be maintained in source code repositories assigned to the project (e.g. {aforgeName} {gitUrl}[Git] or {gerritUrl}[Gerrit] instance, or an organization on GitHub maintained by the Eclipse Foundation);
-* All third party content used by the project must be <<ip-third-party,tracked and approved>> for use by the Eclipse IP Team;
+* All third-party content used by the project must be <<ip-third-party,tracked and approved>> for use by the Eclipse IP Team;
* Downloads must be distributed via {aForgeName} downloads server;
* Developer (committer) communication must occur in the _dev-list_ provided to the project by the Eclipse Foundation; and
* Projects must keep their <<pmi-metadata, Project Metadata>> up-to-date.
@@ -214,7 +214,7 @@ Where technically sensible, all downloadable artifacts should be {jarSigningUrl}
The project is allocated space on the {forgeName} download and archive servers.
-Project artifacts (e.g. downloads) can be distributed via third party services (e.g. Maven Central), but--where technically sensible--the Eclipse Foundation-provided infrastructure must be considered the primary source of project downloads.
+Project artifacts (e.g. downloads) can be distributed via third-party services (e.g. Maven Central), but--where technically sensible--the Eclipse Foundation-provided infrastructure must be considered the primary source of project downloads.
Project committers can {downloadsUrl}[upload project artifacts] to the project's directory on the download server. The short name is used to denote the area available to the project (e.g. `pass:a[{downloadsHost}/dash]` for the `technology.dash` project) via SFTP or SCP, or from a <<resources-builds,Eclipse Foundation hosted build infrastructure>>.
diff --git a/source/chapters/specifications.adoc b/source/chapters/specifications.adoc
index 7ef56c5..25daa31 100644
--- a/source/chapters/specifications.adoc
+++ b/source/chapters/specifications.adoc
@@ -191,7 +191,7 @@ The Employer Consent Agreement for Eclipse Foundation Specification Projects ("E
[[specifications-efsl]]
== Eclipse Foundation Specification License
-The Eclipse Foundation takes copyright ownership of the specification document of every ratified Final Specification. By asserting copyright ownership on the specification documents, the Eclipse Foundation has the ability to protect the specifications in the event that a third party fails to follow the terms of the Eclipse Foundation Specification License.
+The Eclipse Foundation takes copyright ownership of the specification document of every ratified Final Specification. By asserting copyright ownership on the specification documents, the Eclipse Foundation has the ability to protect the specifications in the event that a third-party fails to follow the terms of the Eclipse Foundation Specification License.
The Eclipse Foundation Specification License is applied to the specification documents for all ratified final specifications. This action ensures that derivative works of those specification documents cannot be created, thus preventing their use as the basis for incompatible implementations.
diff --git a/source/chapters/starting.adoc b/source/chapters/starting.adoc
index ae218b7..062f8d7 100644
--- a/source/chapters/starting.adoc
+++ b/source/chapters/starting.adoc
@@ -116,7 +116,7 @@ Project teams interact with the Eclipse IP Team via the <<ip-ipzilla,IPZilla>> s
The IP Team will indicate check-in permission by adding the `checkin` keyword and final approval by setting the state of the CQ to `approved`. *Do not* push any code into the project repository until after the Eclipse IP Team has indicated that you are ready to do so.
====
-<<ip-third-party,Third party content>> that is required by the project code must also be reviewed by the Eclipse IP Team. Project teams that are new to the process should start by raising no more than three CQs for third party content in order to gain an understanding of the third party review process before proceeding to enter all requests.
+<<ip-third-party,Third-party content>> that is required by the project code must also be reviewed by the Eclipse IP Team. Project teams that are new to the process should start by raising no more than three CQs for third-party content in order to gain an understanding of the third-party review process before proceeding to enter all requests.
[graphviz, images/post-creation, svg]
.Post creation activities
diff --git a/source/chapters/trademarks.adoc b/source/chapters/trademarks.adoc
index ff39dc7..5a9c78d 100644
--- a/source/chapters/trademarks.adoc
+++ b/source/chapters/trademarks.adoc
@@ -107,7 +107,7 @@ Acronyms often become brand names.
[[trademarks-project-existing]]
==== Existing Software Product Names
-To avoid confusion between {forgeName} Projects and commercial products, {forgeName} projects may not be named after commercial products and vice versa. To ensure that users understand the source of software products—i.e. from {aForgeName} project, or from a third party vendor—the brand for {aForgeName} project must not include or be directly reminiscent of a commercial product.
+To avoid confusion between {forgeName} Projects and commercial products, {forgeName} projects may not be named after commercial products and vice versa. To ensure that users understand the source of software products—i.e. from {aForgeName} project, or from a third-party vendor—the brand for {aForgeName} project must not include or be directly reminiscent of a commercial product.
[[trademarks-project-short]]
==== Short Names and Ids
@@ -163,7 +163,7 @@ The Eclipse Foundation will help fund the creation of project logos. A project l
The official project website is the primary means of learning about the project and getting involved: people who are interested in contributing to the project come here to learn about technical details, and to observe the project's development process.
-{forgeName} projects must host all project content on an Eclipse Foundation provided domain,especially the official/primary website for project-related information, communications, access to source code, and downloads. This ensures both that the Eclipse Foundation's Webmaster team can maintain the services, and informs consumers that the content comes from {aForgeName} Project, and not a third party. This further ensures that the project remains independent of any specific vendor or single individual.
+{forgeName} projects must host all project content on an Eclipse Foundation provided domain,especially the official/primary website for project-related information, communications, access to source code, and downloads. This ensures both that the Eclipse Foundation's Webmaster team can maintain the services, and informs consumers that the content comes from {aForgeName} Project, and not a third-party. This further ensures that the project remains independent of any specific vendor or single individual.
All primary links to the project (including, for example, the project’s contribution guide) must point directly to the official website, and not to external sites or domains.
@@ -214,9 +214,9 @@ In Java, for example, package names must start with `{namespace}` and use their
The project team must get approval for exceptions from their PMC.
[[trademarks-external]]
-=== Third Party Use of Trademarks
+=== Third-party Use of Trademarks
-The use of Eclipse Foundation trademarks outside of the immediate scope of the open source project, including the use of project names, is subject to the terms of the {trademarkGuidelinesUrl}[Guidelines for Eclipse Logos & Trademarks]. This includes third party websites, books, publications, conferences, events, and more.
+The use of Eclipse Foundation trademarks outside of the immediate scope of the open source project, including the use of project names, is subject to the terms of the {trademarkGuidelinesUrl}[Guidelines for Eclipse Logos & Trademarks]. This includes third-party websites, books, publications, conferences, events, and more.
[[trademarks-external-events]]
==== Conferences and Events
@@ -281,15 +281,15 @@ The external uses of Eclipse Foundation trademarks must include a prominent trad
For example:
____
-Eclipse Woolsey Intellectual Property Tools, Eclipse Woolsey, Woolsey, Eclipse, the Eclipse logo, and the Eclipse Woolsey project logo are either registered trademarks or trademarks of The Eclipse Foundation in the United States and/or other countries.
+Eclipse Woolsey Intellectual Property Tools, Eclipse Woolsey, Woolsey, Eclipse, the Eclipse logo, and the Eclipse Woolsey project logo are Trademarks of The Eclipse Foundation.
____
[[trademarks-notes]]
=== Important Notes
-Nothing in this Eclipse Foundation document shall be interpreted to allow any third party to claim any association with the Eclipse Foundation or any of its projects or to imply any approval or support by the Eclipse Foundation for any third party products, services, or events, unless specifically covered by an Eclipse Membership agreement.
+Nothing in this Eclipse Foundation document shall be interpreted to allow any third-party to claim any association with the Eclipse Foundation or any of its projects or to imply any approval or support by the Eclipse Foundation for any third-party products, services, or events, unless specifically covered by an Eclipse Membership agreement.
-Questions? Project participants who have questions about Eclipse Foundation trademarks either used here or at third party sites should contact the EMO. Other organizations looking for information on how to use or refer to any Eclipse Foundation project trademarks or logos should see the {trademarkGuidelinesUrl}[Guidelines for Eclipse Logos & Trademarks].
+Questions? Project participants who have questions about Eclipse Foundation trademarks either used here or at third-party sites should contact the EMO. Other organizations looking for information on how to use or refer to any Eclipse Foundation project trademarks or logos should see the {trademarkGuidelinesUrl}[Guidelines for Eclipse Logos & Trademarks].
Thanks and credit to the Apache Software Foundation's http://www.apache.org/foundation/marks/pmcs[Project Branding Requirements] (licensed under the Apache License, v2.0) for parts of this trademark section.

Back to the top