diff options
| -rw-r--r-- | pom.xml | 34 | ||||
| -rw-r--r-- | source/chapters/checklist.adoc | 63 | ||||
| -rw-r--r-- | source/chapters/community.adoc | 6 | ||||
| -rw-r--r-- | source/chapters/contributing.adoc | 4 | ||||
| -rw-r--r-- | source/chapters/diagrams/specifications-agreements.dot | 21 | ||||
| -rw-r--r-- | source/chapters/dpia.adoc | 2 | ||||
| -rw-r--r-- | source/chapters/elections.adoc | 2 | ||||
| -rw-r--r-- | source/chapters/glossary.adoc | 16 | ||||
| -rw-r--r-- | source/chapters/ip-thirdparty.adoc | 24 | ||||
| -rw-r--r-- | source/chapters/ip.adoc | 157 | ||||
| -rw-r--r-- | source/chapters/legaldoc-plugins.adoc | 2 | ||||
| -rw-r--r-- | source/chapters/legaldoc.adoc | 18 | ||||
| -rw-r--r-- | source/chapters/pmi.adoc | 57 | ||||
| -rw-r--r-- | source/chapters/preamble.adoc | 6 | ||||
| -rw-r--r-- | source/chapters/release.adoc | 10 | ||||
| -rw-r--r-- | source/chapters/resources.adoc | 18 | ||||
| -rw-r--r-- | source/chapters/roles.adoc | 137 | ||||
| -rw-r--r-- | source/chapters/security.adoc | 8 | ||||
| -rw-r--r-- | source/chapters/specifications.adoc | 23 | ||||
| -rw-r--r-- | source/chapters/starting.adoc | 12 | ||||
| -rw-r--r-- | source/chapters/trademarks.adoc | 143 | ||||
| -rw-r--r-- | source/config.adoc | 3 | ||||
| -rw-r--r-- | source/images/clearlydefined-example.png | bin | 0 -> 39022 bytes |
23 files changed, 537 insertions, 229 deletions
@@ -19,18 +19,15 @@ SPDX-License-Identifier: EPL-2.0 <groupId>org.eclipse.dash</groupId> <artifactId>org.eclipse.dash.handbook</artifactId> - <version>1.0MB</version> + <version>1.0MD</version> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> - <apache.tika.version>1.16</apache.tika.version> - <asciidoctor.maven.plugin.version>1.5.8</asciidoctor.maven.plugin.version> - <asciidoctorj.version>1.6.2</asciidoctorj.version> - <asciidoctorj.diagram.version>1.5.18</asciidoctorj.diagram.version> - <asciidoctorj.pdf.version>1.5.0-beta.5</asciidoctorj.pdf.version> - <asciidoctorj.epub.version>1.5.0-alpha.9</asciidoctorj.epub.version> - <jruby.version>9.2.7.0</jruby.version> - <epub.source>${project.build.directory}/generated-docs</epub.source> + <asciidoctor.maven.plugin.version>2.1.0</asciidoctor.maven.plugin.version> + <asciidoctorj.version>2.4.1</asciidoctorj.version> + <asciidoctorj.diagram.version>2.0.2</asciidoctorj.diagram.version> + <asciidoctorj.pdf.version>1.5.3</asciidoctorj.pdf.version> + <jruby.version>9.2.13.0</jruby.version> </properties> <build> @@ -61,11 +58,6 @@ SPDX-License-Identifier: EPL-2.0 <artifactId>asciidoctorj-pdf</artifactId> <version>${asciidoctorj.pdf.version}</version> </dependency> - <dependency> - <groupId>org.asciidoctor</groupId> - <artifactId>asciidoctorj-epub3</artifactId> - <version>${asciidoctorj.epub.version}</version> - </dependency> </dependencies> <configuration> <sourceDirectory>source</sourceDirectory> @@ -128,20 +120,6 @@ SPDX-License-Identifier: EPL-2.0 <!-- </attributes> --> <!-- </configuration> --> <!-- </execution> --> - -<!-- <execution> --> -<!-- <id>generate-spine-epub</id> --> -<!-- <phase>generate-resources</phase> --> -<!-- <goals> --> -<!-- <goal>process-asciidoc</goal> --> -<!-- </goals> --> -<!-- <configuration> --> -<!-- <backend>epub3</backend> --> -<!-- <sourceHighlighter>coderay</sourceHighlighter> --> -<!-- <sourceDocumentName>eclipse.adoc</sourceDocumentName> --> -<!-- </configuration> --> -<!-- </execution> --> - </executions> </plugin> </plugins> diff --git a/source/chapters/checklist.adoc b/source/chapters/checklist.adoc index b5a5491..bc4a7c2 100644 --- a/source/chapters/checklist.adoc +++ b/source/chapters/checklist.adoc @@ -1,5 +1,5 @@ //// - * Copyright (C) 2015 Eclipse Foundation, Inc. and others. + * Copyright (C) Eclipse Foundation, Inc. and others. * * This program and the accompanying materials are made available under the * terms of the Eclipse Public License v. 2.0 which is available at @@ -9,51 +9,58 @@ //// [[checklist]] -== Project Checklist += Project Checklist -This checklist is provided as a convenience and is included primarily as a guideline or tool to ensure that {forgeName} projects are doing the right sorts of things to attract community and grow. We've tried to strike a balance between being concise while being comprehensive. +This checklist is provided as a convenience and is included primarily as a guideline or tool to ensure that {forgeName} projects are doing the right sorts of things to attract community and grow. + +[TIP] +==== +With this checklist, we've tried to strike a balance between being concise while being as comprehensive as possible. Many of the entries apply for specific technologies only. If an entry on the list doesn't make sense for some particular type of technology in your project, skip it (e.g., file headers do not make sense for JSON content). +==== The Eclipse Foundation staff and Project Management Committee members will use this checklist as part of their evaluation during a <<release-review,Release Review>>. -All projects must conform to the <<trademarks,branding guidelines>> before engaging in any Release or Graduation Review (specific examples are described below). +All projects must conform to the <<trademarks,branding guidelines>> before engaging in any <<release-review,release>> or <<release-graduation,graduation>> review (specific examples are described below). [discrete] == General -* Project is operating within the charter of the Top Level Project; +* Project is operating within the mission and scope defined in its top-level project's charter; * Project is operating within the bounds of its own scope; +* Project is operating in an open and transparent manner; +* All distributed <<ip-third-party,third-party>> content has been approved by the IP Team; * Project content correctly uses Eclipse Foundation trademarks; and * Project content (code and documentation) does not violate trademarks owned by other organizations. [discrete] -=== Code +== Code * All project code is managed in source code repositories provided by The Eclipse Foundation; -* All source files include a copyright and license header; -* All project source code repositories include a https://wiki.eclipse.org/Architecture_Council/Contributor_Guide_Recommendation[CONTRIBUTING] file -(or equivalent) in the root; -* Naming Conventions followed: +* Naming conventions followed: ** e.g. `{namespace}.<shortname>.<component>[.*]` for Java packages and OSGi Bundles; * Provider information is set to the project's formal name: ** e.g. the `Bundle-Vendor` entry set to "Eclipse Foo" in OSGi Bundles; or ** e.g. the `project` and `organization` names are set to "{forgeName} Foo" in Maven `pom.xml` files; -* Every module contains an `about.html` file as required by the {legalDocumentationUrl}[guide to the legal documentation]; and -* Features names and descriptions are captured, are spelled correctly, use proper grammar, and contain content that is actually useful for the intended audience. +* <<legaldoc,Legal documentation>> is provided: +** All source files include a copyright and license header (when technically feasible); +** All source code repositories include a <<legaldoc-license, `LICENSE`>> file (or equivalent) in the root; and +** All source code repositories include a <<legaldoc-notice, `NOTICES`>> file (or--for projects that produce Eclipse Platform plug-ins--`about.html` files as described by the <<legaldoc-plugins>>); +* All source code repositories include a <<legaldoc-contributor, `CONTRIBUTING`>> file (or equivalent) in the root; and +* All feature names and descriptions are captured, are spelled correctly, use proper grammar, and contain content that is actually useful for the intended audience. [discrete] -=== Downloads +== Downloads -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. +Many projects provide binary/compiled _downloads_ of their software, intended for consumption by their various communities. -* 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; -* The project website and PMI page includes links for artifacts; +* All generated artifacts include only intellectual property that has been subject to the <<ip,IP Due Diligence Process>>; +* The project website and <<pmi-project-page, project 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 * Subject to limitations of specific technologies, the {versionNumberingUrl}[Version numbering] rules are followed. [discrete] -=== Project Metadata +== Project Metadata Project metadata is specified and maintained using the <<pmi, Project Management Infrastructure>>. @@ -64,7 +71,7 @@ Project metadata is specified and maintained using the <<pmi, Project Management * Download links and information are up-to-date. [discrete] -=== Release Metadata +== Release Metadata Release metadata is specified and maintained using the <<pmi, Project Management Infrastructure>>. Project teams are required to create a metadata entry for every official release (including major, minor, and service releases). @@ -77,7 +84,7 @@ Use the <<pmi-commands-release, Create a new release>> command on a specific <<p ==== [discrete] -=== Development Website +== Development Website * Is hosted on Eclipse Foundation-provided infrastructure; * Uses the formal name including appropriate marks, e.g. _{forgeName} Foo(TM)_, on the page title, first mention in the text, and on all prominent references to the project; * <<starting-incubation-branding,Incubation branding>> (when applicable) is displayed; @@ -85,21 +92,21 @@ Use the <<pmi-commands-release, Create a new release>> command on a specific <<p * The <<trademarks-website-footer,standard navigation>> links (e.g. `{wwwUrl}`) are included in the website footer. [discrete] -=== Logos and graphics -* Project logo includes the trademark symbol; and -* Are used consistently. +== Logos and graphics +* <<trademarks-project-logo,Project logo>> includes the trademark symbol; and +* Project logo is used consistently. [discrete] -=== Company Logos +== Company Logos Company logos may optionally be included on a project website, but only if the following conditions are met. -* The company is a http://eclipse.org/membership/[member] of the Eclipse Foundation; +* The company is a {memberUrl}[member] of the Eclipse Foundation; * At least one project committer is an employee of the company in question; and -* The committer is active (i.e. they have made at least one commit in the last three months) +* The committer is active (i.e. they have made at least one commit in the last three months). [discrete] -=== Community Portals and Related Websites +== Community Portals and Related Websites <<trademark-external-community,Community portals>>, regardless of who owns and maintains them must conform to the branding guidelines. If you discover a website that does not conform to these guidelines (and it is not within your power to effect the changes yourself), send a note to mailto:{emoEmail}[EMO] to request assistance. @@ -112,7 +119,7 @@ Company logos may optionally be included on a project website, but only if the f * The domain is regarded and used exclusively as a community portal (i.e. is is not presented as the official project website). [discrete] -=== Announcements, News items, Blog posts, ... +== Announcements, News items, Blog posts, ... All announcements regarding project milestones issued by the project must conform to the branding guidelines. diff --git a/source/chapters/community.adoc b/source/chapters/community.adoc index 7ea9c2e..e4d87d1 100644 --- a/source/chapters/community.adoc +++ b/source/chapters/community.adoc @@ -11,11 +11,11 @@ [[community]] == Community -The _{edpUrl}[Eclipse Development Process]_ (EDP) is mostly concerned with engaging in activities that grow community involvement. {aForgeName} project is considered successful only if a vibrant community develops around it and the project team grows in diversity. +The {edpLink} (EDP) is mostly concerned with engaging in activities that grow community involvement. {aForgeName} project is considered successful only if a vibrant community develops around it and the project team grows in diversity. While the reviews and processes described by the EDP may seem onerous, they are a necessary part of community development. You should anticipate spending a significant amount of time responding to questions posed in various forums ({forumsUrl}[{forgeName} Forums], {mailingListsUrl}[mailing lists], and other places where your community gathers. You should plan on attending conferences, presenting webinars, writing papers, and more to support your project. -Community and eco-system development are two things that every committer should spend at least some time thinking about, and--hopefully--some time doing something about. Ultimately, it is difficult to call your project a success without these things. It is from the community and eco-system that you will draw additional contributions and other helpful input to make your open source project a success. +Community and ecosystem development are two things that every committer should spend at least some time thinking about, and -- hopefully -- some time doing something about. Ultimately, it is difficult to call your project a success without these things. It is from the community and ecosystem that you will draw additional contributions and other helpful input to make your open source project a success. [[community-barriers]] === Lower the Barriers @@ -53,7 +53,7 @@ Every project should have at least one committer monitor {forumsUrl}/eclipse.new ==== endif::[] -When your community asks questions, answer them as soon as possible. No question should go unanswered. Encourage all of the project committers to monitor the project forum(s), or--at very least--take turns. When sensible, incorporate the answers into the FAQ or some type of wiki recipe. Repeat this process for as many newsgroups as possible, because Eclipse's overall success will be reflected in your personal success. Your dedication to high-quality service and support is the fuel for your ecosystem and the success of that ecosystem is the most effective way to achieve maximum influence with your limited individual capacity. +When your community asks questions, answer them as soon as possible. No question should go unanswered. Encourage all of the project committers to monitor the project forum(s), or -- at very least -- take turns. When sensible, incorporate the answers into the FAQ or some type of wiki recipe. Repeat this process for as many newsgroups as possible, because Eclipse's overall success will be reflected in your personal success. Your dedication to high-quality service and support is the fuel for your ecosystem and the success of that ecosystem is the most effective way to achieve maximum influence with your limited individual capacity. Adopter questions posed in developer mailing lists (and other _inappropriate_ forums such as personal e-mail) should be answered politely. It is reasonable to recommend that the question (or future questions) be posed in the forum where it can be _viewed by a larger audience as is more likely to receive a timely answer_. diff --git a/source/chapters/contributing.adoc b/source/chapters/contributing.adoc index 34facea..db98c0f 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>>. @@ -75,7 +75,7 @@ After establishing a pattern of contributing high quality contributions a contri [[contributing-committers]] == Committers -For {forgeName} projects (and the open source world in general), committers are the ones who hold the keys. Committers decide what code goes into the code base, they decide how a project builds, and they ultimately decide what gets delivered to the adopter community. With awesome power, comes awesome responsibility, and so the Open Source Rules of Engagement described by the {edpUrl}[Eclipse Foundation Development Process], puts _meritocracy_ on equal footing with _transparency_ and _openness_: becoming a committer isn’t necessarily hard, but it does require a demonstration of merit. +For {forgeName} projects (and the open source world in general), committers are the ones who hold the keys. Committers decide what code goes into the code base, they decide how a project builds, and they ultimately decide what gets delivered to the adopter community. With awesome power, comes awesome responsibility, and so the Open Source Rules of Engagement described by the {edpLink}, puts _meritocracy_ on equal footing with _transparency_ and _openness_: becoming a committer isn’t necessarily hard, but it does require a demonstration of merit. In practical terms, there are two ways to become {aForgeName} Committer. diff --git a/source/chapters/diagrams/specifications-agreements.dot b/source/chapters/diagrams/specifications-agreements.dot index e9f9cb0..6b27be4 100644 --- a/source/chapters/diagrams/specifications-agreements.dot +++ b/source/chapters/diagrams/specifications-agreements.dot @@ -9,7 +9,9 @@ digraph { start [label="Project Team elects\nyou as a committer"; style="filled,bold"]; iwgpa [label=<<b>You</b> sign<br/>the IWGPA>]; - consent_and_iwgpa [label=<Your <b>Employer</b> signs the<br/>Consent Agreement and<br/><b>You</b> sign the IWGPA>]; + consent [label=<Your <b>Employer</b> signs the<br/>Employer Consent Agreement for<br/>Eclipse Specification Projects>]; + ica [label=<<b>You</b> sign<br/>the ICA>]; + employed_iwgpa [label=<<b>You</b> sign<br/>the IWGPA>]; final [label="Congratulations,\nyou're a Committer"; style="rounded,filled,bold"]; node [shape=diamond;style=filled;fillcolor=white;fontsize=10;group=g1]; @@ -17,6 +19,7 @@ digraph { is_self_employed [label="Are you a student,\nself-employed,\nor unemployed?"]; is_member [label="Is your employer\na member of the\nEclipse Foundation?"]; is_participant [label="Is your employer\na participant in\nthe working group?"]; + has_mcca [label="Has your employer\nsigned the MCCA?"]; start -> is_self_employed; is_self_employed -> is_member [label="No"]; @@ -24,10 +27,16 @@ digraph { iwgpa -> final; is_member -> is_participant [label="Yes"]; - is_member -> consent_and_iwgpa [label="No"]; - - is_participant -> final [label="Yes"]; - is_participant -> consent_and_iwgpa [label="No"]; + is_member -> employed_iwgpa [label="No"]; + + employed_iwgpa -> consent; + ica -> consent; - consent_and_iwgpa -> final; + is_participant -> has_mcca [label="Yes"]; + is_participant -> employed_iwgpa [label="No"]; + + has_mcca -> final [label="Yes"]; + has_mcca -> ica [label="No"]; + + consent -> final; }
\ No newline at end of file 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/elections.adoc b/source/chapters/elections.adoc index 5be1b1b..4b4663f 100644 --- a/source/chapters/elections.adoc +++ b/source/chapters/elections.adoc @@ -113,7 +113,7 @@ digraph { ---- -Only project committers may nominate a new committer or vote in a committer election. To be successful, the election must receive a minimum of three positive `pass:[+1]` votes. Any committer can veto the election by casting a +pass:[-1]+ vote. For projects with three or fewer committers all committers must vote. Committer elections run for one week, but will end prematurely if all project committers vote `pass:[+1]`. +Only project committers may nominate a new committer or vote in a committer election. To be successful, the election must receive a minimum of three positive `pass:[+1]` votes. Any committer can veto the election by casting a `pass:[-1]` vote, or indicate their participation in the process but with no opinion with a `pass:[+0]` vote. For projects with three or fewer committers all committers must vote. Committer elections run for one week, but will end prematurely if all project committers vote `pass:[+1]`. Following a successful committer vote, the project's PMC will review the election results and then either approve or veto the election. An election may be vetoed, for example, if the PMC feels that the merit statement is not strong enough. diff --git a/source/chapters/glossary.adoc b/source/chapters/glossary.adoc index 26d3762..bae81cc 100644 --- a/source/chapters/glossary.adoc +++ b/source/chapters/glossary.adoc @@ -18,7 +18,7 @@ The Eclipse Architecture Council (AC) serves the community by identifying and ta Architecture Council Mentor :: -The Eclipse Architecture Council (AC) is a body of battle-hardened Eclipse committers. All new projects are required to have at least one mentor taken from the ranks of the AC. Your project mentors will help you find answers to any questions you may have about the Eclipse Development Process and life-in-general within the Eclipse community. If your mentor doesn't have an answer to your question, they can draw on the wisdom of the full AC and the EMO. +The Eclipse Architecture Council (AC) is a body of battle-hardened Eclipse committers. All new projects are required to have at least one mentor taken from the ranks of the AC. Your project mentors will help you find answers to any questions you may have about the {edpLink} and life-in-general within the Eclipse community. If your mentor doesn't have an answer to your question, they can draw on the wisdom of the full AC and the EMO. Board of Directors :: @@ -54,7 +54,7 @@ A commercial ecosystem is a system in which companies, organizations, and indivi Eclipse :: -This is a tough one. For most people in the broader community, _Eclipse_ refers to the _Eclipse Java IDE_ which based on the Java development tools (JDT) project and assembled by the Eclipse Packaging Project. However, the term _Eclipse_ is also used to refer to the Eclipse Foundation, the eclipse.org website, the community, the ecosystem, and--of course--The Eclipse Project (which is just one of the top-level projects hosted by the Eclipse Foundation). Confusing? Yes. +This is a tough one. For most people in the broader community, _Eclipse_ refers to the _Eclipse Java IDE_ which based on the Java development tools (JDT) project and assembled by the Eclipse Packaging Project. However, the term _Eclipse_ is also used to refer to the Eclipse Foundation, the eclipse.org website, the community, the ecosystem, and -- of course -- The Eclipse Project (which is just one of the top-level projects hosted by the Eclipse Foundation). Confusing? Yes. Eclipse Contributor Agreement (ECA) :: @@ -62,7 +62,7 @@ The purpose of the Eclipse Contributor Agreement (ECA) is to provide a written r Eclipse Management Organization (EMO) :: -The Eclipse Management Organization (EMO) consists of the Eclipse Foundation staff, and the Eclipse Architecture Council. The EMO is responsible for providing services to the projects, facilitating project reviews, resolving issues, and more. The EMO is the maintainer of the {edpUrl}[Eclipse Development Process]. The best method of contact with the EMO is by email ({emoEmail}). If you have a question that cannot be answered by project lead, mentor, or PMC, ask the EMO. +The Eclipse Management Organization (EMO) consists of the Eclipse Foundation staff, and the Eclipse Architecture Council. The EMO is responsible for providing services to the projects, facilitating project reviews, resolving issues, and more. The EMO is the maintainer of the {edpLink}. The best method of contact with the EMO is by email ({emoEmail}). If you have a question that cannot be answered by project lead, mentor, or PMC, ask the EMO. EMO Executive Director :: @@ -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,15 +102,15 @@ 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:: -Projects are where the real work happens. Each project has code, committers, and resources including a web site, source code repositories, space on the build and download server, etc. Projects may act as a parent for one or more child projects. Each child project has its own identity, committers, and resource. Projects may, but do not necessarily, have a dedicated web site. Projects are sometimes referred to as _subprojects_ or as _components_. The Eclipse Development Process, however, treats the terms _project_, _subproject_, and _component_ as equivalent. +Projects are where the real work happens. Each project has code, committers, and resources including a web site, source code repositories, space on the build and download server, etc. Projects may act as a parent for one or more child projects. Each child project has its own identity, committers, and resource. Projects may, but do not necessarily, have a dedicated web site. Projects are sometimes referred to as _subprojects_ or as _components_. The {edpLink}, however, treats the terms _project_, _subproject_, and _component_ as equivalent. Project Lead :: -The project lead is more of a position of responsibility than one of power. The project lead is immediately responsible for the overall well-being of the project. They own and manage the project's development process, coordinate development, facilitate discussion among project committers, ensure that the Eclipse IP policy is being observed by the project and more. If you have questions about your project, the {edpUrl}[Eclipse Development Process], or anything else, ask your project lead. +The project lead is more of a position of responsibility than one of power. The project lead is immediately responsible for the overall well-being of the project. They own and manage the project's development process, coordinate development, facilitate discussion among project committers, ensure that the Eclipse IP policy is being observed by the project and more. If you have questions about your project, the {edpLink}, or anything else, ask your project lead. Project Management Committee (PMC) :: Each top-level project is governed by a Project Management Committee (PMC). The PMC has one or more leads along with several members. The PMC has numerous responsibilities, including the ultimate approval of committer elections, and approval of intellectual property contributions. Effectively, the PMC provides oversight for each of the projects that are part of the top-level project. If you have a question that your project lead cannot answer, ask the PMC. @@ -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..3ded375 100644 --- a/source/chapters/ip.adoc +++ b/source/chapters/ip.adoc @@ -36,7 +36,7 @@ In October 2019, The Eclipse Foundation's Board of Directors approved an update **License certification only for third-party content.** This change removes the requirement to perform deep copyright, provenance and scanning of anomalies for third-party content unless it is being modified and/or if there are _special_ considerations regarding the content. Instead, the focus for third-party content is on _license compatibility_ only, which had previously been referred to as _Type A_ due diligence. -**Leverage other sources of license information for third-party content.** With this change to license certification only for third-party content, we are able to leverage existing sources of information license information. That is, the requirement that the Eclipse IP Team personally review every bit of third-party content has been removed and we can now leverage other _trusted_ sources. +**Leverage other sources of license information for third-party content.** With this change to license certification only for third-party content, we are able to leverage existing sources of information license information. That is, the requirement that the IP Team personally review every bit of third-party content has been removed and we can now leverage other _trusted_ sources. **ClearlyDefined is a _trusted_ source of license information.** We currently have two trusted sources of license information: The Eclipse Foundation’s <<ip-ipzilla,IPZilla>> and <<ip-clearlydefined, ClearlyDefined>>. The IPZilla database has been painstakingly built over most of the lifespan of the Eclipse Foundation; it contains a vast wealth of deeply vetted information about many versions of many third-party libraries. ClearlyDefined is an OSI project that combines automated harvesting of software repositories and curation by trusted members of the community to produce a massive database of license (and other) information about content. @@ -46,7 +46,7 @@ In October 2019, The Eclipse Foundation's Board of Directors approved an update **CQs are not required for third-party content in all cases.** In the case of third-party content due diligence, <<ip-cq,CQs>> are now only used to track the vetting process. -**CQs are no longer required _before_ third-party content is introduced.** Previously, the IP Policy required that all third-party content must be vetted by the Eclipse IP Team before it can be used by {aForgeName} Project. The IP Policy updates turn this around. {forgeName} project teams may now introduce new third-party content during a development cycle without first checking with the IP Team. That is, a project team may commit build scripts, code references, etc. to third-party content to their source code repository without first creating a <<ip-cq,CQ>> to request IP Team review and approval of the third-party content. At least during the development period between releases, the onus is on the project team to--with reasonable confidence--ensure any third-party content that they introduce is license compatible with the project’s license. Before any content may be included in any formal release the project team must engage in the <<ip-prereq-diligence, due diligence process>> to validate that the third-party content licenses are compatible with the project license. +**CQs are no longer required _before_ third-party content is introduced.** Previously, the IP Policy required that all third-party content must be vetted by the IP Team before it can be used by {aForgeName} Project. The IP Policy updates turn this around. {forgeName} project teams may now introduce new third-party content during a development cycle without first checking with the IP Team. That is, a project team may commit build scripts, code references, etc. to third-party content to their source code repository without first creating a <<ip-cq,CQ>> to request IP Team review and approval of the third-party content. At least during the development period between releases, the onus is on the project team to -- with reasonable confidence -- ensure any third-party content that they introduce is license compatible with the project’s license. Before any content may be included in any formal release the project team must engage in the <<ip-prereq-diligence, due diligence process>> to validate that the third-party content licenses are compatible with the project license. **History may be retained when an existing project moves to the Eclipse Foundation.** We had previously required that the commit history for a project moving to the Eclipse Foundation be squashed and that the <<ip-initial-contribution, initial contribution>> be the very first commit in the repository. This is no longer the case; existing projects are now encouraged (but not required) to retain their commit history. The initial contribution must still be provided to the IP Team via <<ip-cq, CQ>> as a snapshot of the `HEAD` state of the existing repository (if any). @@ -60,7 +60,7 @@ ____ There are different kinds of content (e.g., source code, documentation, and images) to consider. <<ip-project-content,_Project content_>> is content (typically source code) that is produced and maintained by the open source project committers and contributors. <<ip-third-party,_Third-party content_>> generally takes the form of libraries (e.g. modules, or 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 content_ and the _third-party content_ that it leverages need to be vetted to ensure that the copyrights expressed are correct, licensing is valid and compatible, and that other issues have been uncovered and properly investigated. -The Eclipse Foundation has a well-defined {ipPolicyUrl}[IP Policy], corresponding IP Due Diligence Process, and an _IP Team_ of dedicated professional IP specialists who perform the heavy lifting in the due diligence process. Committers, the software developers who decide what will become _project content_ and how {aForgeName} 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 {ipPolicyUrl}[IP Policy], corresponding IP Due Diligence Process, and an _IP Team_ of dedicated professional IP specialists who perform the heavy lifting in the due diligence process. Committers, the software developers who decide what will become _project content_ and how {aForgeName} open source project will leverage _third-party content_, are responsible for bringing IP issues to the attention of the IP Team. Most of the _project content_ produced by committers can 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 content that comes from contributors (who are not committers); and there are some cases where even the work of committers needs to be reviewed. @@ -70,7 +70,7 @@ The IP Due Diligence Process does not dictate how source code repositories are s [NOTE] ==== -The {edpUrl}[Eclipse Development Process] does restrict how content can be disseminated based on the state of the IP review. A Project team can create and distribute milestone builds of any content that has been granted _check-in_ from the IP Team. All content must be approved by the IP Team before the project can engage in a formal <<release, release>>. +The {edpLink} does restrict how content can be disseminated based on the state of the IP review. A Project team can create and distribute milestone builds of any content that has been granted _check-in_ from the IP Team. All content must be approved by the IP Team before the project can engage in a formal <<release, release>>. ==== The entry point into the IP Due Diligence Process is the <<ip-cq,Contribution Questionnaire>>, or _CQ_. Project teams should create a single CQ for the <<ip-initial-contribution,initial contribution>> of project content. The initial contribution is a special type of project content contribution in the sense that it is the first thing that the IP Team will review on behalf of the project team. @@ -85,16 +85,50 @@ The entry point into the IP Due Diligence Process is the <<ip-cq,Contribution Qu {clearlyDefinedUrl}[ClearlyDefined] is an OSI project that combines automated harvesting of software repositories and curation by trusted members of the community to produce a massive database of license (and other) information about content. The Eclipse Foundation's IP Team works closely with the ClearlyDefined team, providing input into their processes and helping to curate their data. -In rough terms, if the license information for third-party content can be validated by the Eclipse Foundation's <<ip-prereq-due-diligence, due diligence process>> using ClearlyDefined data, then no further action is required (i.e., no <<ip-cq,CQ>> is required). +In rough terms, if the license information for third-party content can be validated by the Eclipse Foundation's <<ip-prereq-diligence, due diligence process>> using ClearlyDefined data, then no further action is required (i.e., no <<ip-cq,CQ>> is required). [[ip-clearlydefined-identifiers]] ==== ClearlyDefined Identifiers In order to facilitate the use of automation in the IP due diligence process, the Eclipse Foundation has adopted ClearlyDefined identifiers to identify content. -The notion of an identifier for content is pretty natural for developers who are familiar with technologies like Apache Maven which has well defined means of uniquely identifying content in a well-defined software repository. Maven coordinates--which combine `groupid`, `artifactid`, and `version` (often referred to as a “GAV”)--identify a very specific bit of content (especially when combined with a specific source, e.g. Maven Central). For example, `org.junit.jupiter:junit-jupiter:5.5.2` unambiguously identifies content on Maven Central that is known to be under the Eclipse Public License version 2.0 (EPL-2.0). Other systems use different means of identifying content: `node.js`, for example, uses a pURL-like identifier for content in the NPM repository (e.g., `@babel/generator@7.62`). +The notion of an identifier for content is pretty natural for developers who are familiar with technologies like Apache Maven which has well defined means of uniquely identifying content in a well-defined software repository. Maven coordinates -- which combine `groupid`, `artifactid`, and `version` (often referred to as a “GAV”) -- identify a very specific bit of content (especially when combined with a specific source, e.g. Maven Central). For example, `org.junit.jupiter:junit-jupiter:5.5.2` unambiguously identifies content on Maven Central that is known to be under the Eclipse Public License version 2.0 (EPL-2.0). Other systems use different means of identifying content: `node.js`, for example, uses a pURL-like identifier for content in the NPM repository (e.g., `@babel/generator@7.62`). -To bridge the gap between the different means of identifying content (and fill in some of the blanks), we’ve adopted the ClearlyDefined project’s five part identifiers which includes the type of content, its software repository source, its name space and name, and version. ClearlyDefined coordinates are roughly analogous to Maven coordinates, but--by including the type and source--provide a greater degree of precision. ClearlyDefined uses slashes to separate the parts of the identifier, so the Maven GAV `org.junit.jupiter:junit-jupiter:5.5.2` maps to `maven/mavencentral/org.junit.jupiter/junit-jupiter/5.5.2` and the NPM identifier `@babel/generator@7.62` maps to `npm/npmjs/@babel/generator/7.6.2`. +To bridge the gap between the different means of identifying content (and fill in some of the blanks), we’ve adopted the ClearlyDefined project’s five part identifiers which includes the type of content, its software repository source, its name space and name, and version. ClearlyDefined coordinates are roughly analogous to Maven coordinates, but -- by including the type and source -- provide a greater degree of precision. ClearlyDefined uses slashes to separate the parts of the identifier, so the Maven GAV `org.junit.jupiter:junit-jupiter:5.5.2` maps to `maven/mavencentral/org.junit.jupiter/junit-jupiter/5.5.2` and the NPM identifier `@babel/generator@7.62` maps to `npm/npmjs/@babel/generator/7.6.2`. + +[[ip-clearlydefined-using]] +==== Using ClearlyDefined + +ClearlyDefined is used as part of the overall <<ip-prereq-diligence, due diligence process for third-party prerequisites>>. + +[NOTE] +==== +The Eclipse Foundation's <<ip-ipzilla, IPZilla>> is the primary source of information regarding third-party licensing for {forgeName} projects. In cases where IPZilla and ClearlyDefined results differ, IPZilla results take precedence. +==== + +When content is known to ClearlyDefined and has a _Licensed_ score of at least {clearlyDefinedMinimumScore}, and the _declared_ and all _discovered_ licenses are on the Eclipse Foundation's {approvedLicensesUrl}[approved licenses list], then the content can be used without further action. + +ClearlyDefined provides three different scores. For example: + +image::images/clearlydefined-example.png[Screenshot from ClearlyDefined] + +Three numbers are highlighted in this screenshot: + +// These will generate warnings; the callouts are included +// part of the above image. + +<1> The overall score; +<2> The _Described_ score (i.e., completeness of the metadata); and +<3> The _Licensed_ score (i.e., confidence in the licensing). + +In this particular example, the declared and discovered licenses are all on the approved licenses list, and the _Licensed_ score meets the threshold. This content can be used by {aForgeName} project without further consideration. + +Note that when the ClearlyDefined record shows any of the following, a project committer must <<ip-project-content-cq, engage with the IP Team via CQ>>: + +* `NOASSERTION` appearing as a _declared license_; +* `NOASSERTION` appearing as a _discovered license_; +* No declared license; or +* A _License_ score of less than {clearlyDefinedMinimumScore}. [[ip-cq]] === Contribution Questionnaires @@ -160,7 +194,7 @@ The initial contribution is a snapshot of the existing code base. The initial co Any project committer can start the initial contribution review process by creating a <<ip-cq,CQ>>. The IP Team will review the initial contribution to ensure that it hasn't been copied inappropriately, that licenses are being used correctly, and so forth. As part of this process, the IP Team will research the source of all code; depending on the size of the contribution, this can be a time-consuming process. -Because a full review can be time-consuming, the IP Team will in most cases start with a cursory review of the content, and--assuming that no significant issues are uncovered by that cursory review--will grant _check-in_ indicating that the project team can push/merge the initial contribution into their Git repository (or initiate the transfer of their existing repository) and start working with the code while the IP team continues their review in _parallel_ (they will add completing the review to their work queue and address it in turn). +Because a full review can be time-consuming, the IP Team will in most cases start with a cursory review of the content, and -- assuming that no significant issues are uncovered by that cursory review -- will grant _check-in_ indicating that the project team can push/merge the initial contribution into their Git repository (or initiate the transfer of their existing repository) and start working with the code while the IP team continues their review in _parallel_ (they will add completing the review to their work queue and address it in turn). After _check-in_ has been granted for the initial contribution, the project team should start the due diligence process for their <<ip-third-party,third-party content>>. @@ -171,7 +205,7 @@ Eclipse Foundation systems use email to inform and remind interested parties of The email address that is associated with your Eclipse Foundation account is used; be sure to check spam filters to ensure that these messages are not missed. Send a note to mailto:{emoEmail}[EMO] if you are concerned that you are not receiving these notification. ==== -A project cannot make a <<release, release>> until the due diligence on the IP contained in that release--including project content contributions and third-party content--is complete. +A project cannot make a <<release, release>> until the due diligence on the IP contained in that release -- including project content contributions and third-party content -- is complete. [[ip-project-content]] === Project Content @@ -189,7 +223,7 @@ When the contributor has signed the <<contributing-eca, Eclipse Contributor Agre * Contains no cryptography; and * Is it less than 1,000 lines of code, configuration files, and other forms of source code. -If all of these conditions have **not** been met, then a project committer must <<ip-project-code-cq, open a CQ>> to request review by the IP Team before the contribution is pushed/merged. +If all of these conditions have **not** been met, then a project committer must <<ip-project-content-cq, open a CQ>> to request review by the IP Team before the contribution is pushed/merged. [TIP] ==== @@ -207,7 +241,7 @@ The author of a contribution (or their employer) retains copyright of the intell [TIP] ==== -The _applicable license_ is typically the project license. Contributions may, however, be received and distributed under different licenses in some circumstances. If you need to accept content under a license that is not the project license, engage with the IP Team for assistance (create a CQ). +The _applicable license_ is typically the project license. Contributions may, however, be received and distributed under different licenses in some circumstances. If you need to accept content under a license that is not the project license, engage with the IP Team for assistance (<<ip-project-content-cq, create a CQ>>). ==== [[ip-project-content-cq]] @@ -249,7 +283,7 @@ Creating a CQ for a project content contribution requires two steps. In the firs [TIP] ==== -When engaged in the workflow to create a CQ for a project content contribution, indicate that the CQ is for "Project Content" on the first page of the wizard and provide the information requested on the following page. Set the value of the "Contribution Record" to some publicly accessible link. This could be a link to a pull request, or--in the case of an <<ip-initial-contribution, initial contribution>>--a link to the proposal tracking bug. +When engaged in the workflow to create a CQ for a project content contribution, indicate that the CQ is for "Project Content" on the first page of the wizard and provide the information requested on the following page. Set the value of the "Contribution Record" to some publicly accessible link. This could be a link to a pull request, or -- in the case of an <<ip-initial-contribution, initial contribution>> -- a link to the proposal tracking bug. After creating the CQ, the committer will be sent an email with instructions to attach the corresponding source code. Bundle the `HEAD` state of the source code into a ZIP file for the attachment. @@ -258,14 +292,14 @@ Be sure to click btn:[Issues addressed, return CQ to IP Team] to release the CQ The IP Team will engage in two phases. In the first phase, they will perform a rudimentary license check. If the licenses represented in the content are found to be compatible with the project license, the project team will grant _check-in_ meaning that the project team may add the content to a project repository (or engage with the Eclipse webmaster to move an existing repository). The IP Team will add the CQ to their queue for further detailed analysis. When that analysis is complete, the IP Team will mark the CQ as `approved`, indicating that the content is fully vetted for use and may be included in a project <<release>>. -The Eclipse IP team may require assistance from the project team as it analyzes content. Once that analysis is complete and the Eclipse IP Team has made a decision, they will outline the next steps directly on the CQ. +The IP team may require assistance from the project team as it analyzes content. Once that analysis is complete and the IP Team has made a decision, they will outline the next steps directly on the CQ. Be advised that this process may take a while. The actual amount of time that it takes to process a CQ depends on numerous factors including the size of the IP Team's work queue, and the nature and size of the contribution. [[ip-third-party]] === Third-party Content -The sort of effort that the Eclipse IP Team brings to bear on third-party content varies depending on the type. The {ipThirdParty}[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 IP Team brings to bear on third-party content varies depending on the type. The {ipThirdParty}[Guidelines for the Review of Third-party Dependencies] defines three different types: _Prerequisite_, _Exempt Prerequisite_, and _Works With Dependency_. [NOTE] ==== @@ -356,6 +390,69 @@ digraph { } ---- +[[ip-example-maven]] +===== Maven Example + +The following snippet from a Maven `pom.xml` file includes a single dependency that itself has dependencies. + +[source, xml] +.Snippet from an example Maven `pom.xml` file +---- +... +<dependencies> + <dependency> + <groupId>commons-httpclient</groupId> + <artifactId>commons-httpclient</artifactId> + <version>3.1</version> + </dependency> +</dependencies> +... +---- + +When Maven resolves the dependencies, it must also resolve dependencies of dependencies recursively. The `dependency:tree` plug-in generates a graph of the entire dependency tree (note that the example is abridged). + +[source] +.Dependency graph generated by Maven +---- +$ mvn dependency:tree +... +[INFO] org.eclipse.dash:good-stuff:jar:0.0.1-SNAPSHOT +[INFO] \- commons-httpclient:commons-httpclient:jar:3.1:compile +[INFO] +- commons-logging:commons-logging:jar:1.0.4:compile +[INFO] \- commons-codec:commons-codec:jar:1.2:compile +... +---- + +Every library in the entire transitive closure of the dependency graph is a prerequisite. + +[graphviz, images/mvn-example-dependencies, svg] +.Visualization of the dependency graph (the Maven _type_ and _scope_ have been removed for brevity) +---- +digraph { + graph [ranksep="0.25"; nodesep="0.25"; fontsize=12]; + bgcolor=transparent + rankdir=LR; + + node [shape=box;style=filled;fillcolor=white;fontsize=12;label="Content"] + edge [fontsize=12] + + projectcode [label="org.eclipse.dash:\ngood-stuff:0.0.1"]; + subgraph cluster_dependencies { + graph[style=dotted]; + label="\"Prereq\" Dependencies\n(licenses must be verified)"; + httpclient [label="commons-httpclient:\ncommons-httpclient:3.1"]; + logging [label="commons-logging:\ncommons-logging:1.0.4"]; + codec [label="commons-codec:\ncommons-codec:1.2"]; + } + + projectcode -> httpclient [label="requires"]; + httpclient -> logging; + httpclient -> codec; +} +---- + +In this example, `commons-httpclient:commons-httpclient:3.1`, `commons-logging:commons-logging:1.0.4`, and `commons-codec:commons-codec:1.2` must all be <<ip-prereq-diligence, vetted for license compatibility>>. + [[ip-prereq-versions]] ===== Versions of Prerequisites @@ -377,9 +474,14 @@ Content that claims to be distributed under a particular license may in fact inc The Eclipse Foundation has two trusted sources of license information: <<ip-ipzilla, IPZilla>> and <<ip-clearlydefined, ClearlyDefined>>. -IPZilla is the primary source of license information for third-party content. If the IPZilla record (<<ip-cq,CQ>>) for third-party content is marked as `approved` or `license_certified`, then it can be used without further action. If, however, third-party content is otherwise marked (e.g., `withdrawn` or `rejected`), then the project team must engage with the Eclipse IP Team via CQ to get approval to use the content. +IPZilla is the primary source of license information for third-party content. If the IPZilla record (<<ip-cq,CQ>>) for third-party content is marked as `approved` or `license_certified`, then it can be used without further action. If, however, third-party content is otherwise marked (e.g., `withdrawn` or `rejected`), then the project team must engage with the IP Team via CQ to get approval to use the content. -If third-party content is not known to IPZilla, then <<ip-clearlydefined, ClearlyDefined>> can be used. When an entry is known to ClearlyDefined and has a score of at least {clearlyDefinedMinimumScore} and all discovered licenses are on the Eclipse Foundation's {approvedLicensesUrl}[approved licenses list], then the content can be used without further action. +If third-party content is not known to IPZilla, then <<ip-clearlydefined, ClearlyDefined>> can be used. When an entry is known to ClearlyDefined and has a _Licensed_ score of at least {clearlyDefinedMinimumScore} and all discovered licenses are on the Eclipse Foundation's {approvedLicensesUrl}[approved licenses list], then the content can be used without further action (for more information see <<ip-clearlydefined-using, Using ClearlyDefined>>). + +[NOTE] +==== +The Eclipse Foundation's <<ip-ipzilla, IPZilla>> is the primary source of information regarding third-party licensing for {forgeName} projects. In cases where IPZilla and ClearlyDefined results differ, IPZilla results take precedence. +==== [graphviz, images/ip_prereq_diligence, svg] .Due Diligence for Prerequisites @@ -426,15 +528,14 @@ digraph { } ---- - -When content fails to meet these requirements, the project team must engage with the Eclipse IP Team via CQ to get approval to use the content. +When content fails to meet these requirements, the project team must engage with the IP Team via CQ to get approval to use the content. [TIP] ==== The Eclipse Dash project's <<ip-license-tool, IP License Tool>> will help you determine whether or not a CQ is required. ==== -When in doubt, committers should check with the Eclipse IP Team. +When in doubt, committers should check with the {ipTeamEmailLink}. [[ip-prereq-cq]] ===== CQ Workflow for Prerequisites @@ -504,16 +605,16 @@ After creating the CQ, the committer will be sent an email with instructions to Be sure to click btn:[Issues addressed, return CQ to IP Team] to release the CQ back to the workflow. ==== -The Eclipse IP team may require assistance from the project team as it analyzes content. Once that analysis is complete and the Eclipse IP Team has made a decision, they will outline the next steps. These next steps may--in the event that the content is rejected--require that the content be removed from the project's source code repository, or that some part be removed. Most often, the content is _approved_ and the CQ is marked as such. +The IP Team may require assistance from the project team as it analyzes content. Once that analysis is complete and the IP Team has made a decision, they will outline the next steps. These next steps may -- in the event that the content is rejected -- require that the content be removed from the project's source code repository, or that some part be removed. Most often, the content is _approved_ and the CQ is marked as such. Be advised that this process may take a while. The actual amount of time that it takes to process a CQ depends on numerous factors including the size of the IP Team's work queue, and the nature and size of the contribution. [[ip-third-party-exempt]] ==== Exempt Prerequisites -When one follows a dependency graph all the way to the bottom, the entire runtime environment including virtual machines and the operating system are included in the transitive closure of dependencies. Clearly, having the IP team review virtual machines and operating systems is not a great use of time, and--in the case of closed source operating systems--just not be possible. +When one follows a dependency graph all the way to the bottom, the entire runtime environment including virtual machines and the operating system are included in the transitive closure of dependencies. Clearly, having the IP team review virtual machines and operating systems is not a great use of time, and -- in the case of closed source operating systems -- just not be possible. -The Eclipse IP Due Diligence Process guidelines provide for a notion of _Exempt Prerequisite_ dependencies, which are not subject to review. According to the guide, content may be considered exempt if it "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." The Eclipse IP Team does not review the source code associated with an Exempt Prerequisite. +The Eclipse IP Due Diligence Process guidelines provide for a notion of _Exempt Prerequisite_ dependencies, which are not subject to review. According to the guide, content may be considered exempt if it "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." The IP Team does not review the source code associated with an Exempt Prerequisite. 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. @@ -606,7 +707,7 @@ To declare build and test test dependencies, create a <<ip-cq, CQ>>: * Enter a description that indicates that the CQ is for test/build-only dependencies, and set the CQ type to "works with"; and * Enter "various" in the _license_ field and "binary" in the ; -* List all the third-party dependencies--one on each line--along with version information. +* List all the third-party dependencies -- one on each line -- along with version information. For example: @@ -671,7 +772,7 @@ It first sends the content list to <<ip-ipzilla, IPZilla>>; if an entry has been It then sends the content that has not been flagged as either `approved` or `restricted` to <<ip-clearlydefined, ClearlyDefined>>; ClearlyDefined matches are marked as `approved`. -Everything else is marked `restricted`. The License Tool lists all content that ended up marked as `restricted` as requiring further scrutiny. It is this list of content that requires further scrutiny that the project team must engage on with the Eclipse IP Team. +Everything else is marked `restricted`. The License Tool lists all content that ended up marked as `restricted` as requiring further scrutiny. It is this list of content that requires further scrutiny that the project team must engage on with the <<ip-prereq-diligence, IP Team via CQ>>. For many build technologies, it is relatively easy to generate lists of dependencies directly (e.g., the Maven Dependencies plugin). There are some specific examples in the prototype tool’s README (e.g., Maven-, Gradle-, NPM-, and Yarn-based systems). Project teams that use technologies that do not provide easily parsed/converted dependency lists can manually generate a list and feed that to the tool. @@ -749,7 +850,7 @@ The Automated IP Log tool populates the _Contributors_ section with information <<resources-commit,Git commits>> contributed by non-committers are identified by the author credentials on the commit record; the _Author_ field must be set to the identity of the actual author of the commit. -The Third-party Software section of the log is populated from IPZilla. The IP Team will mark your contributions in such a way that they will appear in the log. If third-party software is not appearing properly, contact the mailto:{ipTeamEmail}[EMO IP Team] to make corrections. +The Third-party Software section of the log is populated from IPZilla. The IP Team will mark your contributions in such a way that they will appear in the log. If third-party software is not appearing properly, contact the {ipTeamEmailLink} to make corrections. [TIP] ==== @@ -766,7 +867,7 @@ Yes. Third-party content can be included in binary form (e.g. source and binary + Third-party content that is stored in the project repository as source code is effectively a _fork_ of that third-party content. This is a bit of a grey area in that it is _third-party content_ that will be ultimately treated as <<ip-project-content,_project content_>> (i.e. contributors may potentially modify it). + -Third-party _source code_ must be reviewed by the EMO IP Team (i.e., open a <<ip-cq,CQ>>) before it may be included in a project repository. +Third-party _source code_ must be reviewed by the IP Team (i.e., open a <<ip-cq,CQ>>) before it may be included in a project repository. The IP Due Diligence Process says that I need to create a CQ for project content contributions that exceed 1,000 lines of code; how do I calculate lines of code? :: @@ -782,7 +883,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 @@ -816,4 +917,4 @@ The IP Log is generated based on data from Eclipse Foundation servers. If the lo [[ip-parallel-ip]]What is Parallel IP? :: -The parallel IP Process allows {aForgeName} projects to make use of project code contributions and third-party content before they are fully approved by the Eclipse IP Team. In versions of the IP Policy prior to 2019, projects needed to meet specific requirements to be able to leverage the Parallel IP. This is no longer the case: full vetting is now always applied in parallel in all cases.
\ No newline at end of file +The parallel IP Process allows {aForgeName} projects to make use of project code contributions and third-party content before they are fully approved by the IP Team. In versions of the IP Policy prior to 2019, projects needed to meet specific requirements to be able to leverage the Parallel IP. This is no longer the case: full vetting is now always applied in parallel in all cases.
\ No newline at end of file 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..7661395 100644 --- a/source/chapters/legaldoc.adoc +++ b/source/chapters/legaldoc.adoc @@ -11,7 +11,7 @@ [[legaldoc]] = Legal Documentation Requirements -The content developed and maintained by Eclipse Foundation open source projects is distributed via multiple channels, including distributed source code management systems, download servers, and software repositories. Further, open source project content is--by design--integrated into and distributed as part of the products of adopters. The legal obligations of the content must be observed in all forms of which the content is available. +The content developed and maintained by Eclipse Foundation open source projects is distributed via multiple channels, including distributed source code management systems, download servers, and software repositories. Further, open source project content is -- by design -- integrated into and distributed as part of the products of adopters. The legal obligations of the content must be observed in all forms of which the content is available. Where possible we adopt standards and conventions in order to be good open source citizens. We use the Software Package Data Exchange(R) (https://spdx.org[SPDX](R)) specification for communicating the licenses associated with software packages. @@ -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 -- when 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. @@ -381,9 +381,15 @@ Keeping a help-wanted list up-to-date can be challenging. Consider including a q == Frequently Asked Questions [qanda] +How do file headers change when content is refactored?:: + +When you split a file during a refactoring exercise, any new files that you create must automatically inherit the header of the original. If even fragment of text from a single line of the original content survives the refactoring (whether generated, rote, or otherwise), then the original copyright statement and author information should be retained. ++ +Even a refactoring exercise that does not change behaviour, may add intellectual property. When refactoring adds content, copyright statements should be updated to reflect the addition. In concrete terms, you can either add the new copyright holders to the existing copyright statement or append "and others" (especially when the list of copyright holders gets long). + Do the _license_ and _notice_ files need to be named `LICENSE` and `NOTICE`?:: -No. If there are technical limitations, for example, that require that you select different names, you can do so. But for the sake of consistency for our communities we prefer that this convention be followed. Format-specific file extensions (e.g. `NOTICE.md`) can be used. +No. If there are technical limitations, for example, that require that you select different names, you can do so. But for the sake of consistency for our communities we prefer that this convention be followed. Format-specific file extensions (e.g. `.md` as in `NOTICE.md`) can be used. Can the _license_ and _notice_ files use Markdown?:: @@ -395,7 +401,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/pmi.adoc b/source/chapters/pmi.adoc index 1ed802e..b012be0 100644 --- a/source/chapters/pmi.adoc +++ b/source/chapters/pmi.adoc @@ -15,7 +15,7 @@ The {forgeName} Project Management Infrastructure (PMI) consolidates project man Project Management Infrastructure themes: -_Improved consistency._ Configuration/data-driven project web presence, direct linkage between releases, reviews, and plans. Information--including basic project metadata, project plans, and review information--is captured and retained in a consistent (and easily leveraged) data-based format (rather than in multiple documents in arbitrary formats). +_Improved consistency._ Configuration/data-driven project web presence, direct linkage between releases, reviews, and plans. Information -- including basic project metadata, project plans, and review information -- is captured and retained in a consistent (and easily leveraged) data-based format (rather than in multiple documents in arbitrary formats). _All-in-one-place._ Project leads and committers are able to edit information in place on the project information pages. Text/information in one place with links in another is eliminated where possible. Comments and discussion related to reviews, elections, etc. are connected directly to the item being discussed. @@ -154,6 +154,24 @@ Repositories are displayed in the order they are specified. The order can be cha A _Contribution Message_ should be provided; it is displayed at the top of the section and is one of the primary means by which the community will find the project code. Arbitrary text is permitted, but we recommend that you limit this content to a single paragraph with a few sentences that include a link to more information. +[[pmi-project-logos]] +==== Project Logos + +Any member of the project team can set the project's logo. The logo will be resized to a maximum of 200x200 pixels. Project logos are considered trademarks of the Eclipse Foundation (see <<trademarks-project-logo>> for more information). + +[TIP] +==== +The Eclipse Foundation will use your logo to promote your project. Be sure to create your project logo with a transparent background so that it will display well on arbitrary background colors. +==== + +Any committer or project lead can set the logo for their own project. To set the project logo: + +* Log into the PMI; +* Navigate to the <<pmi-project-page,project page>>; +* click <<pmi-editing,_Edit_>>; +* Open the section labeled _Basics_; and +* Upload your logo to the _Logo_ field. + [[pmi-company-logos]] ==== Company Logos @@ -235,7 +253,7 @@ To populate this list: [NOTE] ==== -The matching algorithm tries to be as forgiving as possible, a release named `3.5`, `3.5.0`, or `3.5 (Luna)` will--for example--match target milestones named `3.5` ,`3.5M1`, `3.5 M2`, `3.5.0M3`, etc., but will not match `3.5.1`. +The matching algorithm tries to be as forgiving as possible, a release named `3.5`, `3.5.0`, or `3.5 (Luna)` will -- for example -- match target milestones named `3.5` ,`3.5M1`, `3.5 M2`, `3.5.0M3`, etc., but will not match `3.5.1`. ==== The bugs for all projects participating in the release will be included. Bugs are grouped by Bugzilla product and component. @@ -279,21 +297,40 @@ When the review is displayed, it automatically includes the _review_ information This can make things a bit confusing when you want to make changes to the metadata for a review record. Just remember that the _review_ information for a release is stored in the release record. -ifeval::["{forgeName}"=="Eclipse"] [[pmi-joining-a-simultaneous-release]] === Joining a Simultaneous Release -Projects cannot add themselves directly to a simultaneous release (e.g. https://projects.eclipse.org/releases/luna[Luna]), but rather must be added by the EMO. +A simultaneous release (also referred to as a _coordinated release_ or _release train_) is a means of grouping together projects that are coordinating their respective releases and need a means of representing the aggregation. Simultaneous releases must themselves coordinated and managed by supervising body (e.g., a PMC or working group specification committee). The rules for joining and participating in a simultaneous release are defined by the supervising body. + +[NOTE] +==== +Simultaneous releases are not a formal concept in the EDP. While the supervising body has considerably latitude to define the nature of their simultaneous release, the project teams that opt to participate in a simultaneous release are still individually required to fully meet their obligations under the EDP and the Eclipse IP Policy. +==== + +To create a simultaneous release record and update its contents, the supervising body must connect with the {emoEmailLink}. -To join a simultaneous release: +[TIP] +==== +The Eclipse Planning Council manages the https://wiki.eclipse.org/Category:SimRel[Eclipse IDE Simultaneous Release], and maintains the https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements[participation rules] (in particular, see the https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#State_intent_early[process for joining]). +==== -1. Create a release record: -* Provide at least a description of the release initially; +[TIP] +==== +The https://jakarta.ee/committees/specification/[Jakarta EE Specification Committee] manages the Jakarta EE release. +==== + +To join a simultaneous release, {aForgeName} project committer must + +1. Meet the requirements defined by the supervising body; +2. Create a <<pmi-releases,release record>>: +* The record must include at least brief description of the release (that can be changed later); and * The date of the release should generally match that of the simultaneous release; -2. Send a note to the https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev[cross-project-issues-dev mailing list] (the EMO monitors this mailing list) with the name of your project, the name/number of the release, and the offset. +3. The committer must then connect with the supervising body and the {emoEmailLink} to add their release record to the simultaneous release record. -The offset indicates how many days after the start of the aggregation process for a milestone your project's bits will be available. If your project's bits depend on a `pass:[+1]` project's bits then your project is probably a `pass:[+2]` project, for example. -endif::[] +[NOTE] +==== +Release records are added to a simultaneous release record by reference. If you change information in the release (including the release name/number), those changes will be automatically reflected. +==== [[pmi-faq]] === Frequently Asked Questions diff --git a/source/chapters/preamble.adoc b/source/chapters/preamble.adoc index 4ae4919..0ef08d0 100644 --- a/source/chapters/preamble.adoc +++ b/source/chapters/preamble.adoc @@ -14,15 +14,15 @@ This document provides you with the information that you need to create a new {forgeName} open source project or become a committer on an existing one. ifeval::["{forgeName}"!="Eclipse"] -While this document is focused on {forgeName}, it makes several "Eclipse" references, including the _Eclipse Foundation_, _Eclipse Development Process_, and _Eclipse Management Organization_. The Eclipse Foundation is the legal entity that manages the operations of the {forgeName} working group, software development forge, and community.Many of the provided services and contacts are so-named on that basis. +While this document is focused on {forgeName}, it makes several "Eclipse" references, including the _Eclipse Foundation_, _{edpLink}_, and _Eclipse Management Organization_. The Eclipse Foundation is the legal entity that manages the operations of the {forgeName} working group, software development forge, and community.Many of the provided services and contacts are so-named on that basis. endif::[] -The _{edpUrl}[Eclipse Development Process]_ (EDP) is the foundational document for {forgeName} projects and committers. It describes the manner in which we do open source software. The Eclipse Development Process does not prescribe any particular development methodology; it is more concerned with the larger-scale aspects of open source project lifecycle, including such things as reviews, processes for running votes and elections, bringing new committers onto a project, etc. This document will elaborate on some key points of the Eclipse Development Process. +The _{edpLink}_ (EDP) is the foundational document for {forgeName} projects and committers. It describes the manner in which we do open source software. The EDP does not prescribe any particular development methodology; it is more concerned with the larger-scale aspects of open source project lifecycle, including such things as reviews, processes for running votes and elections, bringing new committers onto a project, etc. This document elaborates on some key points of the EDP. [[preamble-principles]] === Principles -Four basic principles lie at the heart of the Eclipse Development Process: +Four basic principles lie at the heart of the EDP: * Transparency; * Openness; diff --git a/source/chapters/release.adoc b/source/chapters/release.adoc index bc91ed9..6f29086 100644 --- a/source/chapters/release.adoc +++ b/source/chapters/release.adoc @@ -56,12 +56,12 @@ 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 -Milestone builds and release candidates are not themselves official releases. Per the Eclipse Development Process, milestone and release candidate builds are intended to be consumed by a limited audience to solicit, gather, and incorporate feedback from leading edge consumers. A predictable schedule for the delivery of milestone builds is especially valuable when the period of time between formal releases spans multiple months. +Milestone builds and release candidates are not themselves official releases. Per the {edpLink}, milestone and release candidate builds are intended to be consumed by a limited audience to solicit, gather, and incorporate feedback from leading edge consumers. A predictable schedule for the delivery of milestone builds is especially valuable when the period of time between formal releases spans multiple months. Project teams should include at least one milestone build during every release cycle. The timing of milestone and release candidate builds should be included in release plans. @@ -134,7 +134,7 @@ The EMO will conclude the review on the scheduled end date and advise the projec [[release-graduation]] === Graduation Reviews -The purpose of a _graduation review_ is to confirm that the project has a working and demonstrable code base of sufficiently high quality active and sufficiently diverse communities; has adopters, developers, and users operating fully in the open following the {edpUrl}[Eclipse Development Process]; and is a credit to {forgeName} and is functioning well within the larger {forgeName} community +The purpose of a _graduation review_ is to confirm that the project has a working and demonstrable code base of sufficiently high quality active and sufficiently diverse communities; has adopters, developers, and users operating fully in the open following the {edpLink}; and is a credit to {forgeName} and is functioning well within the larger {forgeName} community Graduation reviews are generally combined with a _<<release-review, release review>>_ (typically, but not necessarily the `1.0` release). Upon successful completion of a graduation review, a project will leave the incubation phase and be designated as a _mature_ project. @@ -175,7 +175,7 @@ What is the difference between a release review and progress review? :: In practice, there is really no difference. The activities involved are the same and a project may create major and minor releases for an entire year following a successful release or progress review. + -Progress reviews were added to the {edpUrl}[Eclipse Foundation Development Process] primarily to support the {efspUrl}[Eclipse Foundation Specification Process], which requires that specification project teams engage periodic reviews that do not necessarily align with releases. +Progress reviews were added to the {edpLink} primarily to support the {efspUrl}[Eclipse Foundation Specification Process], which requires that specification project teams engage periodic reviews that do not necessarily align with releases. + In cases where, for example, a project team has gone an extended period of time without having engaged in a review, the project leadership chain may compel the project team to engage in a progress review to ensure that the project team is following the processes and is generally engaging in the sorts of activities required for success. @@ -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..eb511db 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. @@ -168,7 +168,7 @@ Granting `admin` level access is a relatively new feature. By providing an expla [[resources-issues]] === Issue Trackers -{forgeName} projects must use an Eclipse Foundation-provided issue tracker. Project teams may opt to use either the {bugzillaUrl}[{forgeName} Bugzilla] instance or--for projects that use <<resources-github,GitHub>>--GitHub Issues instances associated with Eclipse Foundation-managed GitHub project repositories. +{forgeName} projects must use an Eclipse Foundation-provided issue tracker. Project teams may opt to use either the {bugzillaUrl}[{forgeName} Bugzilla] instance or -- for projects that use <<resources-github,GitHub>> -- GitHub Issues instances associated with Eclipse Foundation-managed GitHub project repositories. [[resources-forums]] === Forums and Outbound Communication @@ -182,10 +182,12 @@ The EMO strongly encourages the use of alternative communication channels for co // Project-specific websites are only supported on the Eclipse forge. ifeval::["{forgeName}"=="Eclipse"] -Project websites are an excellent way to connect an open source project with the community. Many projects opt to use the <<pmi,Project Management Infrastructure>> (PMI) as their <<pmi-project-page,project website>>. PMI-based website URLs take the form of `pass:c,a[{forgeUrl}/projects/<projectid>]` (e.g. `pass:c,a[{forgeUrl}/projects/technology.foo]`). +Project websites are an excellent way to connect an open source project with the community. Many projects opt to use the <<pmi,Project Management Infrastructure>> (PMI) <<pmi-project-page,project page>> as their webite. PMI-based website URLs take the form of `pass:c,a[{forgeUrl}/projects/<projectid>]` (e.g. `pass:c,a[{forgeUrl}/projects/technology.foo]`). Many project teams opt to create a custom main project website: if so-desired, a project may host a website on Eclipse Foundation-hosted servers. Project website URLs generally take the form `pass:c,a[{wwwUrl}/<shortname>]` (e.g. `pass:c,a[{wwwUrl}/foo]`). Custom project website content is maintained in Git repositories hosted on Eclipse Foundation infrastructure. A background job moves content from the Git repository to the website; content pushed to the repository will appear on the live website within five minutes. +Project websites must implement the <<trademarks-website, branding guidelines for project websites>>. + [NOTE] ==== If a project website has not already been created for your project, {websiteRequestUrl}[open a bug] to request that the Eclipse Webmaster create one. @@ -195,7 +197,7 @@ ifeval::["{forgeName}"!="Eclipse"] The <<pmi,Project Management Infrastructure>> (PMI) provides the main <<pmi-project-page,project website>>. Website URLs take the form of `pass:c,a[{forgeUrl}/projects/<projectid>]` (e.g. `pass:c,a[{forgeUrl}/projects/technology.foo]`). endif::[] -Websites _not_ hosted by the Eclipse Foundation are considered <<trademark-external-community,community portals>> and are subject to the {trademarkGuidelinesUrl}[Guidelines for Eclipse Logo & Trademarks] (the Eclipse Foundation asserts ownership of all project name trademarks). +Websites _not_ hosted by the Eclipse Foundation are considered <<trademark-external-community,community portals>> and are subject to the {trademarkGuidelinesUrl}[Eclipse Foundation Trademark Usage Guidelines] (the Eclipse Foundation asserts ownership of all project name trademarks). [[resources-builds]] === Builds @@ -214,7 +216,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>>. @@ -246,12 +248,14 @@ External resources can be used for: * Container image management (e.g. <<resources-dockerhub,DockerHub>>); and * Examples, blogs, social media handles. -This list is not exhaustive. Project leads should work with their PMC and the EMO to determine the terms and conditions for an external resource are compatible with the project license(s), the {ipPolicyUrl}[Eclipse IP Policy], and {edpUrl}[Eclipse Development Process]. +This list is not exhaustive. Project leads should work with their PMC and the EMO to determine the terms and conditions for an external resource are compatible with the project license(s), the {ipPolicyUrl}[Eclipse IP Policy], and {edpLink}. [[resources-dockerhub]] ==== DockerHub -The Eclipse Foundation owns several organizations on DockerHub, including https://hub.docker.com/u/eclipse/[eclipse], https://hub.docker.com/u/locationtech/[locationtech], and https://hub.docker.com/u/polarsys/[polarsys], but does not formally support or strictly manage the use of these organizations. Due to manner in which permissions are managed, membership in the _owners_ team for these organizations is required to create new repositories. The project's PMC or the mailto:{emoEmail}[EMO] can grant membership in this team to designated committers for projects that require this access. The EMO periodically reviews membership in the teams associated with these organizations and will remove members who are not active committers. Repositories created in these organizations must follow the pattern `<organization>/<shortname>[-<component>]` (e.g. `eclipse/che-server`). +The Eclipse Foundation owns several organizations on DockerHub, including https://hub.docker.com/u/eclipse/[eclipse], https://hub.docker.com/u/locationtech/[locationtech], and https://hub.docker.com/u/polarsys/[polarsys], but does not formally support or strictly manage the use of these organizations. + +For more information, please see https://wiki.eclipse.org/CBI#Docker_Hub[CBI/DockerHub] in the Eclipse wiki. [NOTE] ==== diff --git a/source/chapters/roles.adoc b/source/chapters/roles.adoc new file mode 100644 index 0000000..067ddd9 --- /dev/null +++ b/source/chapters/roles.adoc @@ -0,0 +1,137 @@ +//// + * Copyright (C) 2020 Eclipse Foundation, Inc. and others. + * + * This program and the accompanying materials are made available under the + * terms of the Eclipse Public License v. 2.0 which is available at + * http://www.eclipse.org/legal/epl-2.0. + * + * SPDX-License-Identifier: EPL-2.0 +//// + +[[roles]] += Project Roles + +TBD + +[[roles-cm]] +== Committers + +For {forgeName} projects (and the open source world in general), committers are the ones who hold the keys. Committers decide what code goes into the code base, they decide how a project builds, and they ultimately decide what gets delivered to the adopter community. With awesome power, comes awesome responsibility, and so the Open Source Rules of Engagement described by the {edpLink}, puts _meritocracy_ on equal footing with _transparency_ and _openness_: becoming a committer isn’t necessarily hard, but it does require a demonstration of merit. + +Operate in an open, transparent, and meritocratic manner. + +Write code. Code written by a committer should be pushed directly into the project's source code repository. + +Review contributions from contributors. Contributions + +[NOTE] +==== +The IP due diligence process refers to content that is written "under the supervision of the PMC". We regard this to mean content that has been developed in an open and transparent manner. That is, content that is in-scope and in-plan. Generally, this means that the content is developed in response to a documented issue or plan item, or is otherwise a natural evolution of the code developed in manner that allows participation by the community. + +A committer who spends a few hours developing content before pushing it directly into the project's source code repository is likely working "under the supervision of the PMC"; a committer who _disappears_ for a few weeks to work on a feature and then drops it into the project repository is not. In the former example, the hypothetical committer is working in a manner that faciliates participation by others; the later hypothetical committer is not. + +It is extremely difficult to attract contributors to participate in an open source project when massive changes are held back and then dumped. +==== + + +[[roles-pl]] +== Project Lead + +The short version is that the project lead is the first link in the project leadership chain and is the primary liaison between the project team and the EMO. + +A project lead is not a super committer or anything like that. Committer and project lead are two different roles. A project lead is almost always also a committer. Most privileges on an Eclipse open source project are given to committers. I say most privileges, because we're always trying to sort out how to give project leads more privileges in GitHub and GitLab (e.g., Bug 533471). + +They are responsible for ensuring that project committers are following the rules. At the most basic level, "the rules" are the open source rules of engagement defined in the EDP (openness, transparency, and meritocracy), and we depend on them to make sure that team members understand their obligations under the Eclipse IP Policy (and seek help/advice from the PMC and EMO when they need assistance). + +I don't generally expect that anybody has read the IP Policy. I agree that it is cruel and unusual punishment. We describe the various practices with regard to the IP Policy in the handbook; we need the project leads to help us make sure that these practices are followed. + +When committers are disruptive or otherwise behaving in a manner that is detrimental to the project, the project lead should work with the PMC and the EMO to resolve the issue. As you've noted, the project lead does have the ability to retire committers. This is a power that must be used responsibly. The project lead needs to be able to support their decision to retire a committer. As a best practice, the project lead should give committers reasonable opportunity to retrain their status, and--should the decision be made to retire--committer retirements should be announced on the project's mailing list. The six months of inactivity is more of a suggested period of time for considering retirement of committers; we defer to the judgement of the project lead to determine when and if somebody who is inactive should be retired. + +The project lead is not the technical lead. So it's not strictly their responsibility to develop things like coding standards, project policies, and such. They are responsible, however, for making sure that those sorts of things get created and for making sure that the project team is working to complete shared goals. We have no formal designation of technical lead; this tends to occur organically. + +Any committer can initiate a review with the EMO, but we always copy the project lead(s) in related communication to ensure that they are aware that the committer is acting as their delegate. + +Regarding the assertion that the IP Policy has been followed... this happens when the project lead (or their delegate) submits the IP Log for review. That is, we regard the act of submitting the IP Log for review as this assertion. + +The EDP also defines a project lead role: project leads are responsible for ensuring that the processes are being followed. So, for example, project leads need to ensure that committers are engaging in the IP due diligence process. But they are also responsible for ensuring that committers are “playing nice”. That is, they need to ensure that the level playing field and vendor neutrality bits in the EDP are being observed, but the EDP does not explicitly grant project leads any special powers to make technical decisions on behalf of the project team. + +As the first link in the project leadership chain, one important power granted to project leads by the EDP is the ability to retire committers who are working against the interests of the team. This is essentially the nuclear option (per Merriam-Webster, “an extreme option regarded as a drastic step or last resort”) and it should be used with care. + +[[roles-pmc]] +== Project Management Committee + +A project management committee (PMC) is responsible for the operation of exactly one top-level project as defined by the {edpLink} (EDP). Per the EDP, top-level projects sit at the top of the open source project hierarchy. + +Top-level projects do not generally maintain open source code of their own, but rather provide oversight and guidance to those open source projects that fall under them in the project hierarchy. All projects that fall under a particular top-level project must fit within the mission and scope defined by the top-level project’s charter. In addition to mission and scope, the charter may further define other requirements or establish guidelines for practices by the project that fall under its purview. + +The primary role of the PMC is to ensure that project teams are implementing the EDP and operating within the terms outlined by the top-level project's charter. In particular, the PMC monitors project activity to ensure that project teams are operating in an open and transparent manner. + +The PMC is responsible for defining and managing the structure of the top level project and the organization of the open source (software and specification) projects contained within. + +The PMC provides other oversight regarding the operation of open source projects. They review and approve release and progress review materials, and facilitate cross-project communication within the top level project. + +=== Composition + +A PMC has one or more PMC leads and zero or more PMC Members. Together the PMC provides oversight and overall leadership for the projects that fall under their top Level project. The PMC as a whole, and the PMC leads in particular, are ultimately responsible for ensuring that the Eclipse Development Process (EDP) is understood and followed by their projects. The PMC is additionally responsible for maintaining the top level project's charter. + +The PMC’s role is, fundamentally, to maintain the overall vision and operation of the top level project and all of the projects that fall within its purview. Very often (though it really depends on the nature of the top level project), the PMC will take a very active role in determining how its projects fit together, and how they communicate and interoperate. In pragmatic terms, the PMC ensures that projects are following the rules, set the standards over and above the basic requirements for releases and corresponding documentation, approves intellectual property contributions, and approves committer and project lead elections. + +The PMC Lead is appointed by the Eclipse Foundation's Board of Directors. When an existing PMC Lead retires, the EMO will work with the PMC to identify a replacement and then with the EMO(ED) to have that individual ratified by the board of directors. + +PMC Members are appointed by the EMO(ED). The criteria by which PMC members are identified varies by PMC, but is generally by nomination and election within the existing PMC. Some PMCs are designed to be composed of representatives from some subset of the projects that operate under their purview. In such a case, the means of identifying members should be documented in the corresponding top-level project charter. + +=== PMC Role in the Intellectual Property Due Diligence Process + +The PMC is responsible for ensuring that project teams abide by the Eclipse IP Policy and implementing the Eclipse Intellectual Property (IP) Due Diligence process. + +Further, the Eclipse IP Team has limited technical knowledge and so relies on the PMC to provide technical insight. + + +One of the key responsibilities of the PMC is to ensure that projects are following the Eclipse Intellectual Property Process. In that regard, the PMC has a role in the intellectual property vetting process. Specifically, we need the PMC to approve contribution questionnaires (CQ). + +The criteria by which a PMC grants approval of a CQ varies by PMC. + +At least in part, PMC approval is required to ensure that the PMC is actively engaged with the project that operate under their purview in the event that the EMO requires some assistance working with the project (the PMC member that approves a CQ becomes an obvious contact should the IP Team require your assistance). + +In part, PMC approval of CQ means that the PMC believes that the contribution represented by the CQ makes technical sense, but from an intellectual property perspective (i.e. does it make sense to incorporate this contribution into the project?). + +Finally, we depend on the PMC to use their knowledge and experience with their community and technology to flag any potential issues that may not be obvious to our intellectual property due diligence team (e.g. you know that the license for some content was changed). + +Some PMCs make additional requirements; we can discuss what those additional requirements might be, but I recommend that you defer considering that until a need is demonstrated. + +==== Project Content + +Is the contribution in scope. + +==== Third Party Content + +=== PMC Role in Elections + +The PMC reviews and approves (or vetos) committer elections, first validating that candidate committers have demonstrated sufficient merit. + +=== PMC Role in Reviews + +Literally put a `pass:[+1]` on the email thread when approving a review. + +=== PMC Role in Grievance Handling + +The PMC is a link in the project leadership chain. As such, the PMC has a role in the grievance handling process: they identify and document project dysfunction (with the responsibility to remove or replace disruptive committers). + +=== The PMC Mailing list + +We set the "pmc" list as the "dev" list for top level projects. This list is the primary means that the EMO and the Eclipse Foundation processes (e.g. committer elections) use to interact with the PMC. + +The PMC members should all be subscribed to that list. + +Over time, at least one committer/project lead from each subproject will also be subscribed to that list, making the list a good way for the EMO to interact with the entire project community under that TLP. + + + +The PMC is an important link in the project leadership chain, which is composed of the project's project lead(s), the leadership of the parent project (if any), the PMC leads and PMC members, the EMO, and the Executive Director of the Eclipse Foundation. In exceptional situations—such as projects with zero active committers, disruptive committers, or no effective project leads—the project leadership chain has the authority to make changes (add, remove) to the set of committers and/or project leads of that project, and otherwise act on behalf of the project lead. + +PMC Leads are are not elected. They are vetted by the EMO, approved by the Eclipse Board of Directors, and appointed by the Executive Director of the Eclipse Foundation. PMC members are elected by the existing PMC leads and members, and approved by the Executive Director of the Eclipse Foundation. + +In the unlikely event that a member of the PMC becomes disruptive to the process or ceases to contribute for an extended period, the member may be removed by the unanimous vote of the remaining PMC members, subject to approval by the EMO. Removal of a PMC Lead requires approval of the Board. + +Every PMC is entitled to appoint one representative to each of the Eclipse Architecture and Planning Councils. The Architecture Council’s main roles are to provide general architectural oversight for projects, and maintain the EDP. In particular, a representative of EE4J on the Architecture Council could advocate for modifications to the Eclipse Development Process if there are requirements that are counter-productive for a large runtime project such as EE4J. + diff --git a/source/chapters/security.adoc b/source/chapters/security.adoc index 2fe190f..023e5a4 100644 --- a/source/chapters/security.adoc +++ b/source/chapters/security.adoc @@ -51,7 +51,7 @@ Disclosure is initially limited to the reporter and all Eclipse Committers, but ==== Knowledge of a vulnerability can be easily extended to individuals by adding them to the `cc` list on the corresponding Bugzilla report -Contacts added to an unresolved vulnerability must be _individuals_. Groups (e.g. mailing lists with open subscription and public archives)--with the exception of the mailto:{securityTeamEmail}[Security Team email address]--should never be copied on a vulnerability issue. +Contacts added to an unresolved vulnerability must be _individuals_. Groups (e.g. mailing lists with open subscription and public archives) -- with the exception of the mailto:{securityTeamEmail}[Security Team email address] -- should never be copied on a vulnerability issue. The `committers-only` must be removed and the `security` keyword must be added on Bugzilla records for disclosed vulnerabilities. ==== @@ -65,7 +65,7 @@ The Eclipse Foundation is a {cveUrl}[Common Vulnerabilities and Exposures] (CVE) Whether or not a vulnerability requires a CVE is decided by the project team with assistance from their PMC (if required). -To request a CVE Number assignment, the vulnerability must be captured in a Eclipse Bugzilla record. The project team can track work on a vulnerability elsewhere, but the vulnerability reporting is tracked via Bugzilla. +To request a CVE Number assignment, the vulnerability must be captured in an Eclipse Bugzilla record. If a record for the vulnerability report does not already exist, a _project committer_ must {vulnerabilityReportUrl}[create one]. The project team can track work on a vulnerability elsewhere, but the vulnerability reporting is tracked via Bugzilla. [TIP] ==== @@ -103,7 +103,7 @@ The required information is rendered into the appropriate form by the EMO and fo [NOTE] ==== -The security team will assign a CVE Number to the Bugzilla record as an _alias_, they will then notify the central authority, and--when the report is accepted and posted--add the central authority's link to the URL field of the bug. +The security team will assign a CVE Number to the Bugzilla record as an _alias_, they will then notify the central authority, and -- when the report is accepted and posted -- add the central authority's link to the URL field of the bug. ==== [[security-faq]] @@ -141,7 +141,7 @@ The general rule is that a CVE is required when a vulnerability impacts release + [quote] ____ -If someone can download compiled (e.g., JAR) files and use them without any sort of compilation process then we are inclined to say that there exists a tangible risk to consumers and so a CVE should be requested. That is, unless that version string specifically says alpha or beta, or the content has otherwise clear warnings to not use it in a production context, then we should--as good citizens--create a CVE. Merely being versioned 0.x instead of 1.x doesn't absolve the situation. +If someone can download compiled (e.g., JAR) files and use them without any sort of compilation process then we are inclined to say that there exists a tangible risk to consumers and so a CVE should be requested. That is, unless that version string specifically says alpha or beta, or the content has otherwise clear warnings to not use it in a production context, then we should -- as good citizens -- create a CVE. Merely being versioned 0.x instead of 1.x doesn't absolve the situation. ____ + If you're not sure, check with your PMC or the <<vulnerability-team, Security Team>>. diff --git a/source/chapters/specifications.adoc b/source/chapters/specifications.adoc index 7ef56c5..d021c07 100644 --- a/source/chapters/specifications.adoc +++ b/source/chapters/specifications.adoc @@ -13,7 +13,7 @@ The {efspUrl}[Eclipse Foundation Specification Process] (EFSP) defines a means of creating specifications in open source. The EFSP defines specifications as a “... collection of Application Programming Interface (API) definitions, descriptions of semantic behavior, data formats, protocols, and/or other referenced specifications, along with its TCK, intended to enable the development and testing of independent Compatible Implementations.” -Under the EFSP, all specification work must be done in a designated specification project. Specification projects operate according to the {edpUrl}[Eclipse Foundation Development Process] (EDP), just like "regular" Eclipse open source projects, but with special consideration for the intellectual property management differences that are inherent in specification development. Specifically, the flow of intellectual property license grants is a critical difference between open source software development and open source specification development that is addressed by the EFSP. Due to these differences in the intellectual property license grants, specification project committers must be covered by additional legal agreements and must engage in additional governance steps. +Under the EFSP, all specification work must be done in a designated specification project. Specification projects operate according to the {edpLink} (EDP), just like "regular" Eclipse open source projects, but with special consideration for the intellectual property management differences that are inherent in specification development. Specifically, the flow of intellectual property license grants is a critical difference between open source software development and open source specification development that is addressed by the EFSP. Due to these differences in the intellectual property license grants, specification project committers must be covered by additional legal agreements and must engage in additional governance steps. Unlike Eclipse open source software projects which have no formal association with {wgUrl}[Eclipse Foundation Working Groups] (“working groups”), every specification project is aligned directly with an Eclipse Foundation working group and operates under the purview of that working group’s specification committee. @@ -116,7 +116,7 @@ To become a contributor, an individual must: [NOTE] ==== -If you are already a committer, your committer agreement includes an ECA; so you’re already covered. If your employer is a member of the Eclipse Foundation and your employer has signed the <<contributing-mcca,Member Committer and Contributor Agreement>> (MCCA), then you’re already covered. You can check your status on the <<contributing-account, Eclipse Foundation account>> page (your ECA status is in the top-right corner). If you’re not sure contact mailto:{emoRecordsEmail}[EMO Records] for assistance. +If you are already a committer, your committer agreement includes an ECA; so you’re already covered. If your employer is a member of the Eclipse Foundation and your employer has signed the <<paperwork-mcca,Member Committer and Contributor Agreement>> (MCCA), then you’re already covered. You can check your status on the <<contributing-account, Eclipse Foundation account>> page (your ECA status is in the top-right corner). If you’re not sure contact mailto:{emoRecordsEmail}[EMO Records] for assistance. ==== Regular contributors of high quality content shoul be invited to join the specification project team as a committer (via <<elections-committer, committer election>>). @@ -124,7 +124,7 @@ Regular contributors of high quality content shoul be invited to join the specif [[specifications-committers]] == Committers -Committers are developers who have the ability to directly push (i.e., they have write access) their own contributions to the project’s Git repositories, and have the responsibility to review and merge the contributions of others. Committers are responsible for implementing the Eclipse Development Process and abiding by the Eclipse Intellectual Property Due Diligence Process. +Committers are developers who have the ability to directly push (i.e., they have write access) their own contributions to the project’s Git repositories, and have the responsibility to review and merge the contributions of others. Committers are responsible for implementing the {edpLink} and abiding by the Eclipse Intellectual Property Due Diligence Process. Committer status is assigned on a project-by-project basis. That is, individuals have committer rights only on those projects for which they hold committer status. For all other projects, they are contributors. @@ -144,6 +144,11 @@ Due to the nature of specification project work, the <<paperwork, committer agre include::diagrams/specifications-agreements.dot[] ---- +[NOTE] +==== +Specific agreements need only be signed once. If you've already signed the agreement, you're good-to-go. +==== + A committer who is self-employed, unemployed, or a student needs: * <<specifications-iwgpa, Individual Working Group Participation Agreement>> (IWGPA), which includes: @@ -191,7 +196,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. @@ -238,7 +243,7 @@ In the event of a failure, the specification committee will provide feedback reg Creation reviews give the community a last opportunity to review and comment on a new project proposal before it is created. -The specification committee needs to approve of the creation of a specification project from a proposal by taking a role in the creation review. The expectation is that the specification committee members will consider the details of a proposed specification project (with particular focus on the scope) before making their decision. In addition to the requirements defined by the {edpUrl}[Eclipse Development Process] (EDP), a <<specifications-ballots,super-majority ballot>> of the entire specification committee is required to approve a creation review. +The specification committee needs to approve of the creation of a specification project from a proposal by taking a role in the creation review. The expectation is that the specification committee members will consider the details of a proposed specification project (with particular focus on the scope) before making their decision. In addition to the requirements defined by the {edpLink} (EDP), a <<specifications-ballots,super-majority ballot>> of the entire specification committee is required to approve a creation review. [TIP] ==== @@ -257,7 +262,7 @@ During the development cycle, the project team will produce one or more _milesto A milestone build must never be used to claim compatibility with a specification. An implementation of a specification may only be considered _compatible_ when it is based on a <<specifications-final,_final specification_>>. ==== -A development cycle begins when a either a creation review or a <<specifications-plan,plan review>> is declared successful. A specification project team must engage in a <<specifications-progress,_progress review_>> when a development cycle exceeds one year in duration. +A development cycle begins when a either a creation review or a <<specifications-plan-review,plan review>> is declared successful. A specification project team must engage in a <<specifications-progress-review,_progress review_>> when a development cycle exceeds one year in duration. [[specifications-progress-review]] === Progress Review @@ -278,7 +283,7 @@ At the end of every development cycle, the project team must produce a _release [TIP] ==== -To engage in a release review, create a <<pmi-release, release record>> (if one has not already been created as part of the planning process) and contact the mailto:{emoEmail}[EMO] to schedule the review. Your PMC and specification committee may provide additional requirements and documentation that must be met to get their approval of the review. +To engage in a release review, create a <<pmi-releases, release record>> (if one has not already been created as part of the planning process) and contact the mailto:{emoEmail}[EMO] to schedule the review. Your PMC and specification committee may provide additional requirements and documentation that must be met to get their approval of the review. ==== [[specifications-plan-review]] @@ -290,7 +295,7 @@ The plan itself must be in-scope (i.e. all new work must fall within the bounds [TIP] ==== -To engage in a plan review, create a <<pmi-release, release record>> and contact the mailto:{emoEmail}[EMO] to schedule a review. +To engage in a plan review, create a <<pmi-releases, release record>> and contact the mailto:{emoEmail}[EMO] to schedule a review. ==== After the Plan is approved, the Project Team engages in Development as before. @@ -298,7 +303,7 @@ After the Plan is approved, the Project Team engages in Development as before. [[specifications-final]] === Final Specification -Following a successful release review, the final release version of the specification artifacts are considered _ratified_ and transmogrifies into what the EFSP refers to as a _final specification_. It is the final specification that must be used to build <<specifications-implementation,compatible implementations>>. +Following a successful release review, the final release version of the specification artifacts are considered _ratified_ and transmogrifies into what the EFSP refers to as a _final specification_. It is the final specification that must be used to build <<specifications-implementations,compatible implementations>>. All versions of specifications that are referenced by a ratified final specification must themselves be ratified. The <<specifications-release-review,release review>> for related specification versions may be run concurrently. diff --git a/source/chapters/starting.adoc b/source/chapters/starting.adoc index ae218b7..f782900 100644 --- a/source/chapters/starting.adoc +++ b/source/chapters/starting.adoc @@ -73,15 +73,15 @@ A proposal must minimally include a description of the project, a declaration of When you feel that the proposal is ready, send a note to the mailto:{emoEmail}[Eclipse Management Organization] (EMO) requesting that the proposal be made available to the public for review. The EMO will review the proposal and may provide feedback before initiating the _community review_ period. -At the beginning of the _community review_ period, the EMO will announce the proposal on several channels (the {activityUrl}[Project Activity News] page, Twitter, the {proposalsForum}[Proposals Forum], blog post, and an email note to the Eclipse Foundation members and committers). The EMO will also open a record in the Eclipse Foundation's issue tracker--an instance of Bugzilla--to track the progress of the proposal; the proposal's author and project leads will be copied on that record. +At the beginning of the _community review_ period, the EMO will announce the proposal on several channels (the {activityUrl}[Project Activity News] page, Twitter, the {proposalsForum}[Proposals Forum], blog post, and an email note to the Eclipse Foundation members and committers). The EMO will also open a record in the Eclipse Foundation's issue tracker -- an instance of Bugzilla -- to track the progress of the proposal; the proposal's author and project leads will be copied on that record. A proposal will be open for community review for a minimum of two weeks. The Eclipse Foundation holds the _trademark_ for all {forgeName} projects. Trademark assignment is undertaken prior to the creation of any new project. If you already have a trademark on your project name, that trademark must be assigned to the Eclipse Foundation. Be advised that trademark assignment can be a time-consuming process (it can take hours, days, or weeks depending on the circumstances surrounding the name). If you currently hold the trademark, you will be asked to complete a {trademarkTransferUrl}[Trademark Transfer Agreement]. -The proposal must list at least one mentor from the Eclipse Architecture Council. Members of the Eclipse Architecture Council have considerable experience with Eclipse Foundation practices, and the {edpUrl}[Eclipse Development Process]. The EMO will engage directly with the Architecture Council to identify mentors as necessary. Mentors are assigned to the project through the incubation phase; they are released from their duties when the project <<release-graduation,graduates>>. +The proposal must list at least one mentor from the Eclipse Architecture Council. Members of the Eclipse Architecture Council have considerable experience with Eclipse Foundation practices, and the {edpLink}. The EMO will engage directly with the Architecture Council to identify mentors as necessary. Mentors are assigned to the project through the incubation phase; they are released from their duties when the project <<release-graduation,graduates>>. -When the project name trademark has been secured, a mentor has been identified, and the proposal contents are finalized, the EMO will schedule a _creation review_. Reviews--which run for a minimum of one week--are scheduled twice a month, generally concluding on the first and third Wednesday of each month. The creation review may overlap with the _community review_ period. +When the project name trademark has been secured, a mentor has been identified, and the proposal contents are finalized, the EMO will schedule a _creation review_. Reviews -- which run for a minimum of one week -- are scheduled twice a month, generally concluding on the first and third Wednesday of each month. The creation review may overlap with the _community review_ period. [NOTE] ==== @@ -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 @@ -192,11 +192,11 @@ Key project lifeycle events are gated by reviews; moving from the incubation pha A project in the incubation phase is said to be _incubating_. -The classification of a project in the incubation phase is not a statement about the quality of the project's code; rather, the incubation phase is more about the project team's progress in practicing the open and transparent processes described by the {edpUrl}[Eclipse Development Process] to establish the three communities (developers, adopters, and users) around the project. +The classification of a project in the incubation phase is not a statement about the quality of the project's code; rather, the incubation phase is more about the project team's progress in practicing the open and transparent processes described by the {edpLink} to establish the three communities (developers, adopters, and users) around the project. Incubating projects are encouraged to produce milestone builds, make releases, and grow their community. -When the project code is ready (e.g. stable APIs) and the project team has learned to operate as an open source project according to the Eclipse Development Process, the project may opt to _graduate_ (via <<release-graduation,graduation review>> into the _mature phase_. +When the project code is ready (e.g. stable APIs) and the project team has learned to operate as an open source project according to the {edpLink}, the project may opt to _graduate_ (via <<release-graduation,graduation review>> into the _mature phase_. [[starting-incubation-branding]] ===== Incubation branding diff --git a/source/chapters/trademarks.adoc b/source/chapters/trademarks.adoc index ff39dc7..ddd9365 100644 --- a/source/chapters/trademarks.adoc +++ b/source/chapters/trademarks.adoc @@ -1,5 +1,5 @@ //// - * Copyright (C) 2015 Eclipse Foundation, Inc. and others. + * Copyright (C) Eclipse Foundation, Inc. and others. * * This program and the accompanying materials are made available under the * terms of the Eclipse Public License v. 2.0 which is available at @@ -9,22 +9,41 @@ //// [[trademarks]] -== Branding +== Project Branding -This section defines how {forgeName} Projects must use and display all Eclipse Foundation trademarks as well as how they showcase their project's website within the community and ecosystem. The requirements described here are a complement to the {trademarkGuidelinesUrl}[Guidelines for Eclipse Logos & Trademarks], targeting {forgeName} open source project leads and committers specifically. +This section defines how {forgeName} projects must use and display all Eclipse Foundation trademarks as well as how they showcase their project's website within the community and ecosystem. The requirements described here are a complement to the {trademarkGuidelinesLink}, targeting {forgeName} open source project leads and committers specifically. -These requirements are meant to promote and improve the image of all projects that are part of the {forgeName} community, as well as to show that all {forgeName} Projects are part of our community of developers, adopters and users that we believe is an important factor in our mutual success. While every project manages their own development within the broader {edpUrl}[Eclipse Development Process], a consistent public branding and web presence that ties all of our projects together benefits all of us. +These requirements are meant to promote and improve the image of all projects that are part of the {forgeName} community, as well as to show that all {forgeName} projects are part of our community of developers, adopters and users that we believe is an important factor in our mutual success. While every project manages their own development within the broader {edpLink}, a consistent public branding and web presence that ties all of our projects together benefits all of us. -All projects must conform to these branding requirements before engaging in any Release or Graduation Review. +All projects must conform to these branding requirements before engaging in any <<release-review, release>> or <<release-graduation, graduation>> review. + +[[trademarks-brands]] +=== Brands + +The Eclipse Foundation supports multiple brands (e.g., _Eclipse_, _Jakarta_, and _LocationTech_). All {forgeName} open source projects are associated with a top-level brand. + +All {forgeName} open source projects may use the _{forgeName}_ brand. Other brands are managed by working groups and so whether or not the brand can be used with your project is at the corresponding working group's discretion. + +[NOTE] +==== +The brand that is associated with a particular project is used on the corresponding <<pmi-project-page, project page>>. +==== + +The <<trademarks-project-formal,formal name>> of all {forgeName} open source projects starts with a brand. The brand should not generally be concatenated with any other words (there are some historical exceptions). [[trademarks-background]] -=== Naming, Branding, and Trademarks +=== Naming and Trademarks -Naming and branding are important issues for project teams to consider: both for the project's future success as well as to help support and share the good values from the {forgeName} brand itself. Not only can a memorable name help new users and contributors find a project, having a distinctive name makes the trademark much stronger, and ensures that third parties will respect it. +Naming and branding are important issues for project teams to consider: both for the project’s future success as well as to help support and share the good values from the brand itself. Not only can a memorable name help new users and contributors find a project, having a distinctive and unique name makes the Trademark much stronger and enforceable, and ensures that third parties will respect it. -To ensure that future trademarks conflicts don't arise, it is necessary to show other parties that Eclipse Foundation trademarks were chosen in good faith and with appropriate research. The Eclipse Foundation has no business infringing on pre-existing trademarks for the software products or services from other organizations, whether they are Member organizations or not. +To ensure that future trademarks conflicts don’t arise, all Eclipse Foundation trademarks go through a rigorous search and clearance procedure before they are approved for use. The Eclipse Foundation values its intellectual property rights and the rights of others and these procedures are followed to ensure that there are no infringement allegations. -All {forgeName} projects and corresponding software products are trademarks of the Eclipse Foundation. As a legal entity, the Eclipse Foundation owns all {forgeName} project and corresponding product trademarks on behalf of the the {forgeName} community. The EMO will initiate a trademark review as part of the project creation or renaming process. Existing project name trademarks must be transferred to the Eclipse Foundation (please see the {trademarkTransferUrl}[Trademark Transfer Agreement]). +All {forgeName} projects and corresponding software products are trademarks of the Eclipse Foundation. As a legal entity, the Eclipse Foundation owns all open source project and corresponding product trademarks on behalf of the {forgeName} community. The EMO initiates a trademark search and clearance review as part of the project creation or renaming process. Existing project name trademarks must be transferred to the Eclipse Foundation. The transfer of names applies to both registered and unregistered trademarks that have been previously used (please see the {trademarkTransferUrl}[Trademark Transfer Agreement]). + +[NOTE] +==== +When naming a project, the <<trademarks-brands,brand>> is a consideration. All {forgeName} projects are able to use the _{forgeName}_ brand. Other brands are managed by working groups and so whether or not the brand can be used with your project is at the corresponding working group's discretion. For help, please contact {emoEmailLink}. +==== Who needs these requirements? @@ -34,19 +53,20 @@ Who needs these requirements? All project and product names must be vetted and approved by the EMO. +[[trademarks-registered]] ==== Registered Trademarks -Project teams may request legal trademark registration for their project or product name. Since trademark registration requires a non-trivial investment in time and money, project teams must work with their PMC and the EMO to determine whether not trademark registration is necessary, determine in which countries the trademark must be registered, and how that registration will impact the project (e.g. adding registration marks on the website and in products). +Project teams may request legal trademark registration for their project or product name. Since trademark registration requires a significant investment in time money and ongoing maintenance project teams must work with the EMO to determine whether trademark registration is necessary, determine in which jurisdictions the trademark must be registered, and how that registration will impact the project (e.g. adding registration marks on the website and in products). [[trademarks-background-orgs]] ==== Other Organization’s Trademarks -Project teams must ensure that products names that include other organizations’ trademarks in names must be conform to those organizations’ trademark usage guidelines. For example, "{forgeName} Foo Perl" is not appropriate, since it improperly uses the trademark "Perl" (which is a trademark of The Perl Foundation); a better project name would be "{forgeName} Foo for Perl". +Project teams must ensure that product names that include other organizations’ Trademarks in names must conform to those organizations’ trademark usage guidelines. For example, "{forgeName} Foo Perl" is not appropriate, since it improperly uses the trademark "Perl" (which is a trademark of The Perl Foundation); a better project name would likely be "{forgeName} Foo for Perl" (assuming that is permitted by the Perl Foundation). Use of another organization’s trademark should be limited and approved on a case by case basis. [[trademarks-background-name]] ==== Choosing a Name -Naming and branding are challenging issues that generally require some real investment in time and energy. The best project names are distinctive and memorable. +Naming and branding are challenging issues that generally require some real investment in time and energy. The best project names are distinctive, unique, and memorable. Project teams should start the process of securing the trademark for a name as early as is practical. This is required to ensure the EMO has sufficient time to review and approve the name. @@ -64,35 +84,37 @@ Renaming projects (i.e. after a project has been created and provisioned) requir [[trademarks-project]] === Project Names -A project, as defined by the Eclipse Development Process, is the main operational unit; all open source software development at {forgeName} occurs within the context of a project. The Eclipse Foundation holds the trademark for all {forgeName} Projects. +A project, as defined by the {edpLink}, is the main operational unit; all open source software development at {forgeName} occurs within the context of a project. The Eclipse Foundation holds the trademark for all {forgeName} Projects. All project names must be approved by the Eclipse Management Organization (EMO) either before a project is created or before an existing project is renamed. [[trademarks-project-formal]] ==== Formal Name -The primary branding for any project name is fully-qualified formal name which includes the "{forgeName}" prefix (e.g. "{forgeName} Woolsey Intellectual Property Tools" or "{forgeName} Woolsey Framework"). This ensures that the project is associated with the Eclipse Foundation in the community, ecosystem, and the minds of users and adopters. However, {forgeName} Projects are oftentimes known by many names: it is common for a project to have both a formal and a nickname or commonly-used acronym. +The primary branding for any project name is fully-qualified formal name which includes the <<trademarks-brands,brand>> (typically _{forgeName}_, but projects may leverage other Eclipse Foundation brands) prefix (e.g. _{forgeName} Woolsey Intellectual Property Tools_ or _{forgeName} Woolsey Framework_). This ensures that the project is associated with the Eclipse Foundation in the community, ecosystem, and the minds of users and adopters. However, {forgeName} projects are oftentimes known by many names: it is common for a project to have both a formal and a nickname or commonly-used acronym. The formal name may include a brand name and/or a descriptive name. -[[trademarks-project-brand]] -==== Brand Names +[[trademarks-project-distinct]] +==== Distinctive Names + +Ideal project names are distinctive and memorable. _Woolsey_, _Apogy_, and _Whiskers_ are examples of project names that are distinctive and memorable: they make the project easier to talk and write about than a wordier descriptive name. -Project teams should strongly consider choosing a brand name. "Woolsey", "Apogy", and "Whiskers" are examples of brand names that are distinctive and memorable; they make the project easier to talk and write about than a wordier descriptive name. These names are not descriptive and so don’t stand well on their own; combining a brand name with a descriptive name (e.g. "{forgeName} Woolsey Intellectual Property Tools") can help in this regard. +Distinctive names don't tend to convey information about the nature of the project; combining a distinctive name with a descriptive name (e.g. _{forgeName} Woolsey Intellectual Property Tools_) can help in this regard. [[trademarks-project-descriptive]] ==== Descriptive Names -Projects are encouraged to use a descriptive name. Descriptive names provide context that can help a casual viewer appreciate the purpose of the project in way that is difficult or impossible to convey with a brand name "Graphical Modeling Framework", "Trust Framework" or "Component Assembly Tools" are examples of descriptive names.. +Descriptive names tend to be challenging to register as a trademark and so are generally discouraged as a project name. That's not to say that descriptive names are prohibited, but rather that they are more likely to be rejected during the trademark vetting process. -The best names do not include the word "Project", and are—in formal contexts—prepended by "{forgeName}". The project name should still work with or without the prefix. For example, "Graphical Modeling Framework" and "{forgeName} Graphical Modeling Framework" are equally understandable. +Descriptive names can, however, be helpful as an informal secondary name for a project. -Descriptive names may optionally include the words "Framework", "Platform", or "Tools" if the project has a specific emphasis on extensible frameworks, a platform, or obvious development tooling technology. {forgeName} projects always provide both but may be tailored more toward one or the other. When choosing to use these words, the team should consider that "Framework", "Platform", and "Tools" mean different things to different people and may be becoming overused. +The best names do not include the word _Project_, and are--in formal contexts--prepended by the <<trademarks-brands,brand name>>. Descriptive names may optionally include the words _Framework_, _Platform_, or _Tools_ if the project has a specific emphasis on extensible frameworks, a platform, or obvious development tooling technology. {forgeName} projects always provide both but may be tailored more toward one or the other. When choosing to use these words, the team should consider that _Framework_, _Platform_, and _Tools_ mean different things to different people and are becoming overused. [[trademarks-project-nick]] ==== Nicknames -A project may have a nickname or common name that is a shorter form of the formal name (and will likely be the same as the brand name). The "{forgeName} Woolsey Intellectual Property Tools" project may be referred to as "{forgeName} Woosley" or simply "Woolsey". An acronym may be used as a nickname (e.g. "ECF" and "GMF"). +A project may have a nickname or common name that is a shorter form of the formal name (and will likely be the same as the brand name). The _{forgeName} Woolsey Intellectual Property Tools_ project may be referred to as _{forgeName} Woosley_ or simply _Woolsey_. An acronym may be used as a nickname (e.g. _ECF_ and _GMF_). [[trademarks-project-acronym]] ==== Acronyms For Long Names @@ -107,7 +129,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 @@ -116,21 +138,21 @@ Projects require a short name; this name is used to as an ID for the project in The short name may contain lowercase alphanumeric characters, dashes, and underlines. The short name may not contain periods (.). Short names are used in some project URLs, download directories, <<ip-ipzilla,IPZilla>>, and in other parts of the supported infrastructure. -The short name is joined with the short name of the parent project(s) to form a qualified identifier for the project that is used as a key on many of the webpages and services generated and/or maintained for the project by the Eclipse Foundation. e.g. the "{forgeName} Woolsey" project has a short name of "woolsey"; its qualified name is "technology.dash.woolsey", indicating that it is a subproject of the {aForgeName} _Dash_ Project which is itself a subproject of the {forgeName} _Technology_ Top Level Project. +The short name is joined with the short name of the parent project(s) to form a qualified identifier for the project that is used as a key on many of the webpages and services generated and/or maintained for the project by the Eclipse Foundation. e.g. the _{forgeName} Woolsey_ project has a short name of `woolsey`; its qualified name is `technology.dash.woolsey`, indicating that it is a subproject of the {aForgeName} _Dash_ Project which is itself a subproject of the {forgeName} _Technology_ Top Level Project. Project names should always be referred to in a consistent casing, and used as an adjective (never as a noun or verb) like any trademark should be used (e.g. "Download {forgeName} Woolsey software here", using the Woolsey name as an adjective for software). [[trademarks-project-product]] ==== Product Names -A product is a specific, downloadable software product that users or consumers might want to use in some way. Most projects release a product with the same name (e.g. the {forgeName} Woolsey project releases a software product called "{forgeName} Woolsey") or some variation of the project name (e.g. "{forgeName} Woolsey SDK"). +A product is a specific, downloadable software product that users or consumers might want to use in some way. Most projects release a product with the same name (e.g. the {forgeName} Woolsey project releases a software product called _{forgeName} Woolsey_) or some variation of the project name (e.g. _{forgeName} Woolsey SDK_). [NOTE] ==== -Most open source projects produce products that share the project name. There are, however, numerous examples of projects that produce additional products. The Eclipse CDO project, for example, has a product named "Dawn"; and the Eclipse Graphical Editing Framework project has a product named "Zest". +Most open source projects produce products that share the project name. There are, however, numerous examples of projects that produce additional products. The Eclipse CDO project, for example, has a product named _Dawn_; and the Eclipse Graphical Editing Framework project has a product named _Zest_. ==== -Product names should also be prefixed with "{forgeName}" when used in any formal context (e.g. _{forgeName} Widgets_). +Product names should also be prefixed with an Eclipse Foundation <<trademarks-brands,brand>> when used in any formal context (e.g. _{forgeName} Widgets_). Project teams should work with their PMC to determine whether or not to pursue assertion of ownership of the trademark for product names. Project teams should work with the Eclipse Management Organization (EMO) to assert ownership of product trademarks. @@ -148,34 +170,44 @@ The complete description can certainly include much more information, but starti Project teams may seek guidance from the PMC and EMO to ensure that the text is a proper trademark goods description; i.e. one that describes the specific functionality of the software available for download and use. [[trademarks-project-logo]] -=== Logos And Graphics +=== Logos and Graphics + +All {forgeName} projects are encouraged to create a unique logo to identify their project. -All {forgeName} projects are encouraged to create a unique logo to identify their project. Projects teams can engage a graphic design crowdsouring site or similar service to create a logo. The project leader and committers are responsible for setting up the design process and providing the feedback to the graphic designers. Based on past experience, faster and more detailed feedback to the designers yields better results. +[TIP] +==== +The Eclipse Foundation will use your logo to promote your project. Be sure to create your project logo with a transparent background so that it will display well on arbitrary background colors. Square logos are preferred and we recommend that the logo be sized to display well at the 200x200 pixels resolution maximum permitted by the project metadata. +==== -Logos are important to recognize as trademarks as well. For a project's official logo (if it has one, and especially if it uses the Eclipse Logo in any way), the designer must ensure that it includes a small trademark (™) or registered trademark (®) symbol (as appropriate) in the graphic or immediately adjacent to it. +Logos are important to recognize as trademarks. For a project's official logo, the designer must ensure that it includes a small trademark (™) or registered trademark (®) symbol (as appropriate) in the graphic or immediately adjacent to it. -Projects may request to use the Eclipse Logo within their project logo, or otherwise create a derivative of the Eclipse Logo. However, they must contact the EMO (via a {emoApprovalsUrl}[Bugzilla record]) to request the Board's permission to do so. +Projects may request to use an Eclipse logo within their project logo, or otherwise create a derivative of the Eclipse logo. However, they must contact the EMO (via a {emoApprovalsUrl}[Bugzilla record]) to request the Eclipse Foundation's Board of Directors' permission to do so. -The Eclipse Foundation will help fund the creation of project logos. A project leader or committer will have to pay for the logo design in advance. Once the logo is created, the project can then send the invoice to the Eclipse Foundation {marketingEmail}[marketing team]. The Foundation will reimburse up to USD$600 for the logo design. Please also feel free to contact the Foundation marketing team with any questions about the logo design. +Projects teams can engage a graphic design crowdsourcing site or similar service to create a logo. The project leader and committers are responsible for setting up the design process and providing the feedback to the graphic designers. Based on past experience, faster and more detailed feedback to the designers yields better results. The Eclipse Foundation will help fund the creation of project logo. A project leader or committer will have to pay for the logo design in advance. Once the logo is created, the project can then send the invoice to the Eclipse Foundation {marketingEmail}[marketing team]. The Foundation will reimburse up to {euro}500 for the logo design. Project team members should contact the Eclipse Foundation's marketing team with any questions regarding logo design. + +[NOTE] +==== +Add your project logo to your project's metadata via the <<pmi-project-logos,PMI>>. +==== [[trademarks-website]] -=== Project Websites +=== Project Website Branding -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. +The official <<resources-website, 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. [[trademarks-website-name]] ==== Name References -The first reference to a project or product on every web page—especially in page titles or headers—must use the formal name and must include the relevant trademark (™) or registered trademark (®) symbol (e.g. "{forgeName} Woolsey Intellectual Property Tools™"). If the webpage features an otherwise prominent reference to the project or product (e.g. in a callout), that reference should also use the formal name. Other references may use the nickname or acronym (e.g. "{forgeName} Woolsey" or "Woolsey") as appropriate. +The first reference to a project or product on every web page--especially in page titles or headers--must use the <<trademarks-project-formal,formal name>> and must include the relevant trademark (™) or registered trademark (®) symbol (e.g. _{forgeName} Woolsey Intellectual Property Tools™_). When a webpage features an otherwise prominent reference to the project or product (e.g. in a callout), that reference should also use the formal name. Other references may use the nickname or acronym (e.g. _{forgeName} Woolsey_ or _Woolsey_) as appropriate. [[trademarks-website-footer]] ==== Footers -All project web pages must include a footer that prominently displays an approved Eclipse Logo, important links back to key pages, and a copyright notice. +All project web pages must include a footer that prominently displays an approved Eclipse logo, important links back to key pages, and a copyright notice. Approved Eclipse logos are available on the https://www.eclipse.org/artwork[Eclipse Logos and Artwork] page. @@ -192,18 +224,6 @@ The following minimal set of links must be included on the footer of all pages i An appropriate footer is included automatically by the default website infrastructure and the PMI. ==== -[[trademarks-metadata]] -=== Project Metadata - -All Projects must keep their metadata updated regularly in the central <<pmi, Project Management Infrastructure>> (PMI). Projects must ensure that all metadata is kept up-to-date in the PMI tool to ensure that other infrastructure tools and processes can make connections to and disseminate information for the project. - -The project description, scope, and other free-form text fields in the PMI must conform to the project naming guidelines. - -[NOTE] -==== -The PMI supports teasers or summaries for many fields; ensure that these teasers also conform to the guidelines. -==== - [[trademarks-code]] === Code Namespaces @@ -214,18 +234,18 @@ 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 {trademarkGuidelinesLink}. This includes third-party websites, books, publications, conferences, events, and more. [[trademarks-external-events]] ==== Conferences and Events -Use of the terms "Eclipse", "EclipseCon", and "Eclipse Day" are reserved for exclusive use by events authorized by the Eclipse Foundation. +Use of the terms _Eclipse_, _EclipseCon_, and _Eclipse Day_ are reserved for exclusive use by events authorized by the Eclipse Foundation. Other Eclipse Foundation trademarks (e.g. project names) may be used in events, but must be approved by the EMO subject to the following considerations: -* The name of the event must conform to the terms laid out in the Guidelines for Eclipse Logos & Trademarks; +* The name of the event must conform to the terms laid out in the {trademarkGuidelinesLink}; * The event must include sessions that focus on content provided by the corresponding open source projects; * Representatives from corresponding {forgeName} open source projects (e.g. committers, project leads, PMC members) must be directly involved in the event; and * Websites, printed materials, and other content associated with the event must provide pointers/links to the project website and trademark attribution. @@ -242,15 +262,15 @@ Permission is *not required* to present a talk on {aForgeName} project. [[trademark-external-community]] ==== Community Portals -Community portals are generally operated at "arms length" from the {forgeName} open source project. The community portal may help users find information about what the project software does and how to get it, or provide a means for the community to contribute to related side projects that are not part of the {forgeName} open source project. +Community portals are generally operated at _arms length_ from the {forgeName} open source project. The community portal may help users find information about what the project software does and how to get it, or provide a means for the community to contribute to related side projects that are not part of the {forgeName} open source project. The community portal is not a replacement for a developer portal which takes form in the official project website as described by this document. A community portal is operated with these considerations: -* The name of the community portal must conform to the terms laid out in the Guidelines for Eclipse Logos & Trademarks; -* The first and most prominent reference to the {forgeName} open source project or corresponding product name on every web page must use the formal name and must include the relevant trademark or registered trademark symbol (subsequent references may use the nickname or acronym as appropriate); -* All references to {forgeName} open source project names must be prefixed with "{forgeName}"; +* The name of the community portal must conform to the terms laid out in the {trademarkGuidelinesLink}; +* The first and most prominent reference to the open source project or corresponding product name on every web page must use the <<trademarks-project-formal,formal name>> and must include the relevant trademark or registered trademark symbol (subsequent references may use the nickname or acronym as appropriate); +* All references to {forgeName} open source project names must use the <<trademarks-project-formal,formal name>>; * The website must include trademark attributions for all Eclipse Foundation trademarks used on the site; and * Contributors must be directed to the official project website for information regarding contribution or related development activities. @@ -258,7 +278,7 @@ Community portals must include a prominent text paragraph or sidebar that points [NOTE] ==== -Naming exceptions may be granted for names that follow established conventions (e.g. *Woolsey(TM) Labs*). Contact the EMO to request an exception. +Naming exceptions may be granted for names that follow established conventions (e.g. _Woolsey(TM) Labs_). Contact the EMO to request an exception. ==== [[trademarks-domains]] @@ -281,15 +301,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 {trademarkGuidelinesLink}. 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. @@ -298,4 +318,5 @@ Thanks and credit to the Apache Software Foundation's http://www.apache.org/foun [qanda] Can my company use the project name as part of their product name?:: - It depends on how the name will be used. Please see the {trademarkGuidelinesUrl}[Guidelines for Eclipse Logos & Trademarks].
\ No newline at end of file + +It depends on how the name will be used. Please see the {trademarkGuidelinesLink}.
\ No newline at end of file diff --git a/source/config.adoc b/source/config.adoc index 19e5ada..acdf6aa 100644 --- a/source/config.adoc +++ b/source/config.adoc @@ -35,6 +35,7 @@ :ipTeamEmailLink: mailto:{ipTeamEmail}[EMO IP Team] :emoEmailLink: mailto:{emoEmail}[EMO] :emoRecordsEmailLink: mailto:{emoRecordsEmail}[EMO Records Team] +:trademarkGuidelinesLink: {trademarkGuidelinesUrl}[Eclipse Foundation Trademark Usage Guidelines] :developerPortalUrl: http://portal.eclipse.org :bylawsUrl: https://www.eclipse.org/org/documents/eclipse_foundation-bylaws.pdf @@ -87,6 +88,8 @@ :clearlyDefinedMinimumScore: 75 +:euro: € + :linkcss: :stylesdir: ./resources :scriptsdir: ./resources diff --git a/source/images/clearlydefined-example.png b/source/images/clearlydefined-example.png Binary files differnew file mode 100644 index 0000000..d32dfe3 --- /dev/null +++ b/source/images/clearlydefined-example.png |
