Eclipse Foundation Specification Process Operations Guide

This operations guide applies to the Eclipse Foundation Specification Process, version 1.4. Updated 2024-11-05.

This document describes the operation of the Eclipse Foundation Specification Process (EFSP) for use by Eclipse Foundation Working Groups engaged in specification development.

The Eclipse Foundation Specification Process (EFSP) provides definitions and a framework for the governance of open source development of specifications at the Eclipse Foundation.

The Eclipse Foundation Development Process (EDP) is the foundation upon which the EFSP is based. It provides definitions and a framework for the governance of open source development at the Eclipse Foundation.

The Eclipse Foundation Intellectual Property (IP) Policy describes the policies and mechanisms that the Eclipse Foundation uses for accepting and licensing the intellectual property developed by Eclipse projects and specifications.

The Eclipse Foundation Working Group Process (EFWGP) defines the process for creating and managing Eclipse Foundation Working Groups, and how Eclipse Foundation members lead, influence, and collaborate within Working Groups. The corresponding Eclipse Foundation Working Group Operations Guide describes the life cycle and operation of Eclipse Foundation Working Groups.

In the event of a conflict between this document and the documents listed above, the documents listed above take precedence.

Projects and Specifications

The EFSP focuses on specification projects in matters of governance (e.g. project structure, committers and project leads). That is, in matters of governance, open source projects are the atomic unit.

Specification projects are a special type of open source project: In mathematical terms, a specification project (as defined by the EFSP) can be thought of as a subtype of project (as defined by the EDP). The EDP describes governance that applies to both projects and specification projects; the EFSP defines additional governance that applies to specification projects.

Specification Project (EFSP) is a subtype of project (EDP) that contains specifications.
A specification project may be the host of more than one specification: Subject to approval by the specification committee, a specification project may host multiple specifications.
A specification project may have more than one Git repository: A specification project can have as many {handbookUrl)#resources-gitlab[GitLab] and {handbookUrl)#resources-github[GitHub] repositories as required. All repositories are managed by the Eclipse Foundation on behalf of the project and community.
Git repositories are assigned to projects not specifications: Project resources, like Git repositories, are managed by the Eclipse Foundation at the project level.
Committer status is granted on projects not specifications: That is an individual is said to be a committer on the corresponding project, and as such has committer-level access to all resources assigned to the project. In the case of specification projects that manage the life cycle of multiple specifications, all committers have the same level of access to all resources (e.g., Git repositories) allocated for all specifications.
There is no formal notion of specification lead: Specification projects must have one or more project leads, as that role is defined in the EDP. Specification projects may choose to have a de facto notion of a specification lead, but that role has no formal standing in the specification process.
Development of a new version of an existing specification occurs in the context of the existing specification project: That is, the specification project, along with its team of committers and associated resources, persists beyond the release of any particular version of a specification. After a specification is released, the same specification project with its associated committers and resources are used to plan, develop, and release subsequent versions of the specification.

A specification project produces all versions of a specification

Specification projects engage in releases and reviews: This one is more subtle and only applies to specification projects that support the development of more than one specification. The EDP allows projects to engage in releases that contain some subset of their content, so the notion of engaging in, for example, a release (and corresponding release review) for one single specification is fully supported. While, strictly speaking, this sort of hypothetical release would be a project release and be owned by the project, it would be a specification release in a practical sense. There are no requirements regarding how releases are named/numbered.

Specification projects operating under the EFSP follow the same life cycle as open source projects operating under the EDP with the additional requirements that they engage in a plan review at the beginning of a development cycle, that they engage in a release review for all major and minor releases, and that all reviews be approved by super-majority ballot of the working group’s specification committee.

Working Groups and Specifications

Specifications are created and maintained by specification projects. Each specification project is aligned with exactly one Eclipse Foundation working group. Specification projects are said to work under the purview of a particular working group, or—more specifically—the specification committee of a working group.

Working groups provide governance for specification projects: A working group’s specification committee, must approve—by super-majority ballot—all reviews.
The specification committee ratifies specifications as final: Via ballot during a release review the working group’s specification committee must vote to a approve ratifying the release version of a specification as a final specification. Approval by a super-majority of the specification committee is required.

Specification project committers write the specification: Committer and specification committee member are two distinct roles. Being granted one of these roles does not automatically grant the other. Specifically, holding the role of specification committee member does not grant any write privileges on specification project repositories.

Roles

Specification Committee

The specification committee is responsible for implementing the EFSP for all specification projects (as that term is defined by the EFSP) that operate under the purview of a working group. A working group may, via their charter, assign specification committee responsibilities to another committee.

The specification committee is ultimately responsible for ensuring that the final specifications produced by the working group’s specification projects make sense. The definition of “makes sense” varies by specification committee participant, but is generally understood to mean that the specification can be implemented and that those aspects of the Eclipse Intellectual Property Policy with regard to essential claims are observed. In practical terms, specification committee participants wield power via the ballots that are required to approve key lifecycle events per the EFSP.

The Specification Committee is responsible for producing, publishing, and maintaining operational guidance documentation for specification projects. This includes the minimum requirements and process for producing a final specification. It also includes operational guidance for running a specifications TCK for the purpose of testing for compatibility.

The Specification Chair (or their delegate) is responsible for initiating ballots, tallying their results, disseminating them to the community, and (when appropriate; e.g., in the case a release review ballot) reporting them to the EMO.

The Specification Committee is also responsible for defining and refining how they implement the EFSP for those Specification Projects under their purview.

Project Management Committee

The primary role of the Project Management Committee (PMC) is to ensure that project teams are implementing the EDP. In particular, the PMC monitors project activity to ensure that project teams are operating in an open and transparent manner. The PMC reviews and approves (or vetoes) committer elections, first validating that candidate committers have demonstrated sufficient merit.

The PMC is further responsible for ensuring that project teams abide by the Eclipse IP Policy and implement the IP Due Diligence process. In practical terms, the PMC approves intellectual property contributions (CQs) and provides (limited) guidance to project teams regarding intellectual property (deferring to the Eclipse IP Team as necessary).

The PMC is responsible for the structure of the top-level project and the organization of the open source (software and Specification) projects contained within.

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/replace/add disruptive committers).

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.

Project Lead(s)

A specification project has one or more project leads. Project leads are the main liaison between the project team and the Eclipse Management Organization (EMO), and are responsible for ensuring that team members are implementing their responsibilities under the EDP, EFSP, and the Eclipse Foundation’s IP Policy. The lead is responsible for initiating reviews as the project reaches the appropriate milestone.

Participant Representative

The EFSP states that a member participant may appoint a participant representative committer. A member participant is defined as a strategic member or contributing member of the Eclipse Foundation that is a participant in the working group (i.e., has signed the corresponding working group participation agreement). In the case of specifications, vendor-neutrality trumps meritocracy. A specification process must be accessible to all companies who wish to participate.

Appointment of a participant representative:

If the mechanism by which their patent portfolio is licensed to the resulting specifications;
Ensures that the specification process is accessible to all companies that wish to participate; and
Is consistent with how all other specification processes work.

The notion of a participant representative specifically excludes committer members; this makes sense as, to be a committer member participant (the EFSP refers to this an an individual participant) in a working group, one must already be a committer. This does mean, however, that an individual participant who is a committer on one specification project cannot appoint themselves as a participant representative on another.

Appointing a participant representative this is a power that a member participant will use to ensure that they have at least one committer on a specification project. If the member participant already has an employee as a committer, then that member participant is considered to already have a participant representative and cannot appoint another.

Additional committers can be added via committer election.

Creating a Specification Project

Specification projects start with a project proposal that is presented to the community for review and then used as the basis for a creation review (which requires a successful ballot of the specification committee).

Specification projects start the same way that all of our project start, but with the extra requirement that the the specification committee must vote their approval during the creation review. See Starting an Open Source Project at the Eclipse Foundation for more information.

The gist of how this works is shown here:

An overview of the Specification Project Creation Process

Proposal

Use the web form to create a new project proposal. This is the same form that we use for all Eclipse Projects and it captures the same sort of information, including the identity of the working group under which the specification project is intended to operate (the field labelled "Is this a specification project?").

A proposal document is initially accessible only by the person who creates the proposal and anybody that they list in a project role. Everyone who is listed as a project lead will have read and write access to the proposal document while it is in this draft state; all other listed persons will have read access.

To be listed on a project proposal as a project lead, an individual must be known to the project system. That is, to be listed as a project lead, an individual must have previously created an Eclipse Foundation account and must have logged into projects.eclipse.org at least once.

To open the proposal for community review, send a note to the EMO. The EMO will review the proposal and may make recommendations for changes to the team. When the EMO is satisfied that the proposal is ready for community review, they will open the proposal for community review.

Approvals

Immediately after opening a specification project proposal for community review, the EMO will request approval from the corresponding PMC and inform the corresponding specification committee.

The EMO will connect with the PMC via their mailing list request their approval. With their approval, the PMC indicates that they believe that the scope of the specification project fits in with the overall mission and scope of the top-level project and that they are prepared to provide guidance to the project team and participate in the specification project’s governance as required by the Eclipse Foundation Development Process. The EMO will accept a +1 from any member of the PMC as approval on behalf of the entire PMC. PMC approval is required before the start of the creation review.

Implementing the EFSP

The specification committee must establish open and transparent communication channels for specification-related discussion and ballots. The specification committee’s public mailing list is typically used for this sort of communication.

An overview of the Specification Release Process

Planning

Every development cycle starts with a plan and a plan review. The project team assembles their release plan, the project lead (or their delegate) presents the plan to the specification committee, and the specification committee initiates plan review. The plan review consists entirely of a ballot of the specification committee. A super-majority of the specification committee must vote to approve the plan.

A plan should concisely describe the new features and themes on which the development team intends to focus. The level of detail required in a plan varies by working group.

The specification project committers assemble the plan in an open and transparent manner. Project committers create a release record. The release record can be used to actually capture the plan, or can include a pointer to the plan represented elsewhere.

The specific means by which a plan is assembled is left to the discretion of the project team.

Specification project teams should engage with the specification committee during their planning phase to request feedback and mitigate the risk of surprises during the plan review. That is, engage with the specification committee early to ensure success for your plan review.

A committer representing the specification project delivers the plan to the specification committee along with a request for them to initiate an approval ballot.
A specification committee member initiates the ballot, and tallies the results after the ballot period has completed and reports the results. Approval requires a super-majority affirmative vote from the specification committee.

Development

Committers work in a specification project Git repository. Committers collaborate, accept contributions from contributors, and otherwise construct the specification.

Specification project committers implement the plan.
Committers and contributors work directly in the assigned Git repositories.

If a development cycle extends beyond a year, the project team must engage in a progress review.

Release

To initiate the release process, the project team starts by creating a specification version. A specification version is, effectively, a release candidate build of the specification document and related artifacts.

Specification project committers initiate the final build.
The build is referred to as a specification version; it is effectively a release candidate.
A committer initiates the release review by sending an email to EMO.
A committer sends an email to the specification committee

Reviews

Specification projects in active development must engage in a progress or release review at least once per year. In practical terms, this means that the clock starts ticking when the plan review that occurs at the beginning of the development cycle concludes successfully, and is reset following a successful progress review.

The entire process is halted when either the specification project engages in a successful release review (thereby concluding the development cycle), or the specification team decides to abandon the cycle.

The PMC approval and the specification committee ballot are different activities with different intention and purpose.

The primary role of the PMC is to ensure that project teams are implementing the EDP. In particular, the PMC monitors project activity to ensure that project teams are operating in an open and transparent manner. Any specification project committer or project lead can solicit approval for a release from their PMC by posting on the PMC’s mailing list.

The Committer Tools block on the right side of the project page contains links subscribe to the PMC’s mailing list ("PMC Mailing List") and to send a note ("Send Email to the PMC").

The specification committee is ultimately responsible for ensuring that the ratified final specifications produced by the working group’s specification projects match the working group’s purpose and goals, that they can be implemented, and that those aspects of the Eclipse Intellectual Property Policy with regard to essential claims are observed. The specification committee exercises their responsibility via ballot.

Creation Reviews

A creation review is required before a new specification project is created.

In the case where an existing Eclipse open source project is converted into a specification project, or a specification moves from working under the supervision of one working group to another, the creation review will be combined with a restructuring review.

Creation reviews are tracked and managed by the EMO. A creation review requires a ballot of the specification committee. The ballot may be initiated directly by a member of the specification committee; the EMO can provide assistance if required.

In considering their vote in the ballot, the question that specification committee members must consider is whether or not they would vote to approve the eventual release, ratification, and creation of a Final Specification when the project returns for a release review. If the answer is yes, then the specification committee member should vote in the affirmative +1; they should either vote in the negative -1 or abstain +0 otherwise.

Plan Reviews

Plan reviews occur at the start of a development cycle. A creation review serves as the plan review for a specification project’s first release.

Plan reviews are not formally tracked or managed by the EMO, but rather are initiated and managed directly by a member of specification committee; the EMO can provide assistance if required. In practice, a plan review requires no more formal ceremony than a successful ballot of the specification committee.

When reviewing a plan, the question that specification committee members must consider is whether or not they would vote to approve the eventual completion of the plan when the project returns for a release review. If the answer is yes, then the specification committee member should vote in the affirmative +1; they should either vote in the negative -1 or abstain +0 otherwise.

Ideally, when casting their vote, specification committee members should focus less on the mechanics of implementing the plan and more on the broader implications of the themes and changes suggested in the plan to implementors, adopters, and the ecosystem.

Release Reviews

A release review is required for all major and minor releases from a specification project. The review may be skipped for service releases that do not implicate any new intellectual property (i.e., bug fixes only). A specification project must engage in a release review for the first release of all specifications (independent of whether or not it is a major, minor, or service release).

Releases of specification projects operate under the EDP augmented by the EFSP. Release reviews are tracked and managed by the EMO. A release review requires a ballot of the specification committee. The ballot may be initiated directly by a member of the specification committee; the EMO can provide assistance if required.

See release and progress reviews for a more complete description of the release review process.

The basic timeline for a release review is as follows.

Release Review Timeline and Steps

The review itself involves several parallel activities:

The EMO will review the intellectual property management practices of the project to ensure that the Eclipse Foundation Intellectual Property Policy and Intellectual Property Due Diligence process is being correctly implemented by the project team (and will provide guidance as necessary);
The EMO ensure that standard documentation (e.g., README, CONTRIBUTING, and LICENSE files) are present in project repositories (and will provide guidance as necessary);
The EMO will seek the PMC’s approval via their mailing list (the PMC has their own criteria for approval; the EMO will accept a +1 from any PMC member as approval); and
The Specification Committee will initiate and complete the required ballot.

While the above chart shows that the ballot occurs after the review starts, the ballot can be initiated at any time. The requirement is that the ballot must conclude with an affirmative result before the review can be declared successful.

It is up to the individual parties to determine the basis on which they will vote in the ballot. When determining how to vote, the question that specification committee members must consider is whether or not they believe that the specification as written can be implemented, that the TCK is complete enough, and whether or not the project team has met their obligations under the EFSP. If the answer is yes, then the specification committee member should vote in the affirmative +1; they should either vote in the negative -1 or abstain +0 otherwise.

Progress Reviews

A progress review is required by a specification project when the time elapsed between a Plan Review and a Release Review exceeds one year.

Progress reviews are tracked and managed by the EMO. A progress review requires a ballot of the specification committee. The ballot may be initiated directly by a member of the specification committee; the EMO can provide assistance if required.

The specification committee may make additional requirements. The specification project team should communicate their intent to engage in a progress review with the specification committee in advance to ensure that any additional requirements are addressed and that the specification committee has an opportunity to ask questions and otherwise provide guidance in advance of the initiation of the ballot.

The timeline for a progress review is similar to that for a release review.

Before initiating a Progress Review, the specification project team and specification committee need to coordinate and discuss the state of the specification work, and decide on what—if any—mitigation work is required. This discussion should occur on a public channel (either on an issue in a a public project or working group issue tracker, or on the specification committee’s public mailing list). The process can be initiated by a specification project committer, a PMC member, or a working group representative. The specification project team and specification committee should reach agreement on the state of the project and any mitigation that is required before initiating the Progress Review.

With the conditions established, a project committer must contact the EMO to initiate the review.

From the EMO’s perspective, a Progress Review is primarily concerned with assisting the project. That is, the EMO regards a Progress Review as an opportunity to provide guidance to the project regarding how to implement the Eclipse Foundation Development Process, Eclipse Foundation Specification Process, and Eclipse Foundation Intellectual Property Policy. This is a means of providing guidance and assistance, not enforcement.

When determining how to vote in a release review ballot, the question that specification committee members must consider is whether or not they believe that the specification is progressing in a manner that will produce a specification that can later be ratified. If the answer is yes, then the specification committee member should vote in the affirmative +1; they should either vote in the negative -1 or abstain +0 otherwise.

Progress Reviews are posted for community review for one week.

Restructuring Review

A restructuring review is required whenever the nature of a project is changed.

Examples include (but are not limited to):

Moving significant functionality (e.g., an entire Git repository) from one project to another;
Splitting an existing project into multiple separate projects;
Combining multiple separate projects into a single project;
Rolling functionality from one project into another; or
Changing a regular open source project into a specification project.

Engage with the EMO to discuss options and requirements when the nature of a project must be changed.

Ballots

Specification ballots are run in the specification committee’s public mailing list.

A ballot is initiated by a member of the specification committee by sending an email to the specification committee’s public mailing list, inviting specification committee members to indicate their vote in the affirmative with a +1, the negative with -1 or their decision to abstain with +0. Specification committee members express their vote by responding on the public mailing list.

Specification committee members vote on behalf of their constituency (generally the company whose interests they represent on the committee, or—in the case of an elected representative—their electoral base). The basis upon which this decision is made is at the discretion of the individual specification committee member. The specification committee may decide to establish a set of guidelines or requirements to provide a basis for voting; though these may instead be regarded as a gate to even starting a ballot.

The following templates can be modified accordingly and used to initiate a ballot.

The ballot initiation message does not need to follow these templates; they are provided here only as examples.

Creation Review Ballot Template

Title: BALLOT: Approval to Create the <specification> Specification Project

Your vote is required to approve the creation of the <specification> Specification Project with the following scope:

<scope>

The project proposal can be found here: <link>

Per the Eclipse Foundation Specification Process, this will be a <duration> ballot, ending on <date> that requires a super-majority positive vote of the <working-group> specification committee members (note that there is no veto). Community input is welcome, but only votes cast by specification committee representatives will be counted.

Specification committee representatives, your vote is hereby requested. Please respond with +1 (positive), +0 (abstain), or -1 (reject). Any feedback that you can provide to support your vote will be appreciated.

Where:

<specification> is the name of the specification project;
<scope> is the scope of the specification that the specification project will focus on (in the event that the specification project has multiple specifications in scope, the names of all of the specifications and their scope should be provided);
<link> is a link to the project proposal document on projects.eclipse.org;
<duration> is the number of days over which the ballot will run (the default is seven days);
<date> is the calendar date that is at least <duration> days into the future; and
<working-group> is the name of the working group under which the new specification project is anticipated to operate under.

Release Review Ballot Template

Title: BALLOT: <specification> Specification Project Release Review

Your vote is required to approve and ratify the release of <specification> <version>.

The Eclipse Foundation Specification Process (EFSP) requires a successful ballot of the specification committee in order to ratify the products of this release as a Final Specification (as that term is defined in the EFSP).

<details>

Per the process, this will be a <duration> day ballot, ending on <date> that requires a super-majority positive vote of the <working-group> specification committee members (note that there is no veto). Community input is welcome, but only votes cast by specification committee representatives will be counted.

Specification committee representatives, your vote is hereby requested. Please respond with +1 (positive), +0 (abstain), or -1 (reject). Any feedback that you can provide to support your vote will be appreciated.

The <details> for a release review ballot should include:

Links to relevant source code repositories;
Links to the Specification Version (release candidate) artifacts;
A brief description of the progress made;
A description of changes (if any) to the release plan; and
A description of issues (if any) that should be brought to the attention of the specification committee.

Progress Review Ballot Template

Title: BALLOT: <specification> Specification Project Progress Review

Your vote is required to approve the continuation of work on the <specification> specification release plan.

The Eclipse Foundation Specification Process (EFSP) requires a successful ballot of the specification committee in order to continue work on specifications when the time elapsed between the plan review and corresponding release review exceeds one year.

<details>

Per the process, this will be a <duration> day ballot, ending on <date> that requires a super-majority positive vote of the <working-group> specification committee members (note that there is no veto). Community input is welcome, but only votes cast by specification committee representatives will be counted.

Specification committee representatives, your vote is hereby requested. Please respond with +1 (positive), +0 (abstain), or -1 (reject). Any feedback that you can provide to support your vote will be appreciated.

The <details> for a progress review ballot should include:

Links to relevant source code repositories;
Links to milestone build artifacts (if any);
A description of the progress made on implementing the release plan to-date;
A description of changes (if any) to the release plan; and
A description of issues (if any) that may be impeding progress.

Restructuring Review Ballot Template

Restructuring Reviews are used to change the structure of a project. A restructuring review would be used to, for example, move a specification from one project to another, move a specification project from one working group to another, or convert an existing open source software project into a specification project.

Title: BALLOT: Approval to change the <project> into a Specification Project

We need to restructure the existing <project> into a specification project as defined by the Eclipse Foundation Specification Process (EFSP). For this, the EMO has initiated a restructuring review.

The purpose of a restructuring review is to change the nature of a project. While we are not strictly creating a new project, we are in a manner of thinking, creating a new specification project from an existing project. With this in mind, we are treating this as a creation review from the perspective of the specification committee approval requirement.

Per the process, this will be a <duration> day ballot, ending on <date> that requires a super-majority positive vote of the <working-group> specification committee members (note that there is no veto). Community input is welcome, but only votes cast by specification committee representatives will be counted.

<details>

Specification committee representatives, your vote is hereby requested. Please respond with +1 (positive), +0 (abstain), or -1 (reject). Any feedback that you can provide to support your vote will be appreciated.

The <details> for a restructuring review should concisely describe the changes that are proposed. This could be as simple as a statement stating that "The Eclipse Foo project will be converted into a specification project.", but other changes may be included.

For example:

We will rename "Eclipse Project for JTA" project to "Jakarta Transactions" and convert it into a specification project with this project/specification scope statement:

Jakarta Transactions defines a standard that allows the demarcation of transactions and the transactional coordination of XA-aware resource managers as described in the X/Open XA-specification and mapped to the Java SE XAResource interface within Java applications.

TCK Inbox

The TCK License has this requirement:

make TCK test results showing full and complete satisfaction of all requirements of the TCK publicly available on the testing party’s website and send a link to such test results to Eclipse at tck@eclipse.org; and

We do not actively monitor the TCK inbox. It is configured with a perpetual auto-responder that replies with this message:

Thank you for your submission. We do not respond to messages sent to this inbox.

If your message contains a link to your TCK/QVS test results showing full and complete satisfaction of all requirements as required by the Eclipse Foundation’s TCK License or the Eclipse Foundation Quality Verification Suite License, you may consider that requirement complete.

If you have questions regarding the TCK or QVS License, please send them to license@eclipse-foundation.org

Information regarding branding programmes can be found on brand-specific websites.

Jakarta EE Compatible Products

MicroProfile Compatible Implementations

Sparkplug Compatible Software

If you have technical questions regarding the TCK or QVS, please direct them to the corresponding Eclipse open source project or working group channel.

For all other inquiries, please contact emo@eclipse-foundation.org.

Naturally, the message contains actual links to all of the cited resources.

The EMO only reviews this inbox periodically. The EMO does not generally reply to any messages send to it. The EMO does not provide any sort of approval.

Specialising the EFSP

A working group may, through their specification committee, choose to specialise the EFSP for their own implementation. The process document is a foundational document that defines underlying principles, fundamental rules, and other requirements with regard to implementing specifications. The process document does not generally prescribe the use of specific technology, or provide any detail with regard to implementation.

This document starts by describing what must not be taken away from the specification process, and concludes with some suggestions of what might be considered for a working group’s specialisation of the process.

Minimum Values

The most critical aspect of the EFSP is the management of essential claims as defined by the Eclipse IP Policy. In this regard, the requirement that all committers be covered by an Eclipse Foundation Membership Agreement and Working Group Participation Agreement cannot be relaxed. By extension, the restrictions placed on participants and participant representatives cannot be relaxed in any customisation of the process, nor can the ability of a participant to appoint a participant representative be inhibited in any way.

The requirements regarding scope must not be relaxed. Specifically, the requirements regarding approvals and the requirement that the development work of the project stay with the boundaries defined by the scope must not be curtailed.

The underlying principles of open source (the so-called “Open Source Rules of Engagement”) may not be curtailed. Specifically, all specification projects must operate in an open and transparent manner, must follow meritocratic practices to promote individuals to positions of power and authority, and (although not strictly listed as a rule of engagement) operate in a vendor neutral manner.

The powers granted to the project leadership chain by the EDP must not be restricted.

In general, quantities included in the EFSP and EDP can be increased, but not decreased. For example, the period of time required to run a simple ballot (e.g. a committer election) must not be less than seven days (it is generally accepted at a week is a reasonable minimum period of time to run a ballot that meets a minimum standard of community inclusion).

Specialising the Process

The EFSP defines a set of underlying principles and fundamental requirements. It intentionally does not define any sort of practical implementation, or prescribe any specific technologies. Specialisations of the process should take a similar approach. The process might, for example, extend the amount of time required for a specification committee ballot; but any attempt to describe the specific mechanisms and technology by which a ballet is run in a practical sense is more of an operational detail that should be defined in an operations document.

Example Process Specialisations

Providing a comprehensive list of every possible thing that can be customised is an impossible task. In place of a comprehensive list, we provide a list of examples of things that might be customised and/or tuned.

A customisation may extend the list of Open Source Licenses (but many not remove licenses from the main list).

A customisation may define requirements for evolving itself to create future versions of the working group-specific specification process.

A customisation may:

Require progress reviews at some interval;
Specify a maximum and/or minimum period of time required for specification committee approval ballot;
Specify the period of time that must pass between reviews; and
Describe mitigation steps in the event that a review fails.

The process requires that a specification project engage in a release review. A customisation may:

Specify a maximum and/or minimum period of time required for specification committee approval votes;
Specify the period of time that must pass between the last progress review and the release review; and
Describe mitigation steps in the event that the review fails.

A customisation may also define:

Technical namespaces;
Criteria for designating a release as major, minor, or service; and
Criteria, requirements, etc. for managing exceptions in a TCK.

While generally considered best practices, a customisation may prescribe:

How a specification is bundled for dissemination;
Specific file formats for documentation; and
Document structure and style.

The EFSP provides no specific criteria for designating a specification as a profile, nor does it attempt to define “platform”. A specialisation may choose to provide definitions or specify the criteria for designating a specification as a profile.

Operational Considerations

Specification committees are encouraged to create an operations document that describes how the process is implemented. The evolution of an operations document tends to be organic, based on building consensus within the team instead of relying on a formal approvals process.

Out of convenience, an operations document may repeat information that’s captured in the process; as such, an operations document must include a clear statement that in the event of conflict the process document must be taken as the authority.

The practical implementation of aspects of the process are not defined by the EFSP, and so a working group specification process (specialisation) may choose to formalise (for example):

How to run specification committee ballot;
How a participant appoints a participant representative;
What to do when a ballot fails or approval is not otherwise granted;
The mechanism by which a specification committee determines whether or not a minor correction made during a ballot changes semantic meaning;
How a specification version becomes a final specification;
Requirements/guidelines to pass a progress/release review, along with timing of the review itself; and
A standard means of describing relationships between specifications.

Compatible Implementations

In order to make claims regarding compatibility of your implementation with a specification, you must:

Satisfy the requirements of the Final Specification;
Pass the Final Specification’s TCK (that is, the released version of the TCK); and
Satisfy the requirements of the Eclipse Foundation TCK License.

The TCK requires that you post a durable link to your TCK results on a public website (that is, the results must be accessible to anybody who cares to review them for as long as the Compatible Implementation is available) and you must send a link to those results to tck@eclipse.org.

These requirements apply to open and closed source implementations of a specification. This includes Eclipse projects that provide Compatible Implementations included in a specification release.

There’s an obvious "chicken and egg" problem with the requirement that a Compatible Implementation that’s included with a specification release must pass the release version of the TCK: to be ratified as a Final Specification, a specification must have a Compatible Implementation based on the released version of the TCK, but an implementation cannot be considered a Compatible Implementation until it passes the released version of the TCK.

It helps to not think about it too hard. Test the Compatible Implementation with the pre-release version of the TCK and then run to produce TCK results immediately after the specification is ratified as a Final Specification.

TCK License

In order to be able to claim compatibility with a specification, the Eclipse Foundation TCK License requires that you send your TCK results to tck@eclipse.org. The note is a means by which you satisfy the terms of the TCK license by notifying the Eclipse Foundation of the results; it is not a request to approve the results. The Eclipse Foundation keeps a record of the results; it does not approve the results.

The TCK inbox has a perpetual autoresponder that says (in part): "If your message contains a link to your TCK test results showing full and complete satisfaction of all requirements as required by the Eclipse Foundation’s TCK License, you may consider that requirement of the TCK License complete." It also includes links to the various branding programmes. The Eclipse Foundation does review the messages send to this inbox, but — other than the autoresponder — we never reply to messages sent to this inbox.

Direct any questions that you have about the license to license@eclipse-foundation.org.

Frequently Asked Questions

Is a specification project is a subtype of a Eclipse project, governed by the EDP?

In a mathematical sense, yes. A specification project as defined by the EFSP is a specialisation or subtype of an Eclipse open source project as defined by the EDP.
Does a specification need to list patents?

No. In fact, a specification must not specifically list patents.
How do patent grants work?

We cannot provide legal advice. Connect with your lawyer for more information.
Can a working group’s steering committee take on the responsibilities of the specification committee?

Yes. A working group’s charter can assign the responsibilities of the specification committee to any working group committee.
The ability of a member participant (i.e., a participant representing a company) to appoint a participant representative committer isn’t very meritocratic; is meritocracy irrelevant?

Meritocracy is very relevant. However, the rules of engagement with specification projects is different in consideration of factors like patent grants and antitrust. In the case of specifications, vendor-neutrality trumps meritocracy: a specification process must be accessible to all companies who wish to participate.
Can a member participant (i.e., a participant representing a company) appoint as many participant representative committers as they’d like?

No. A member participant (i.e., a company that is a participant in the working group) can appoint a single participant representative committer on a specification project, and only if they do not already have a committer representing their interests on that project. Additional committers representing the interests of a member participant may demonstrate merit through contribution and be elected to the project using the standard mechanism for electing committers.
Is a participant representative a special kind of committer?

A participant representative is indistinguishable from any other committer once appointed.
Do participant representatives have any special powers or privileges?

No. Participant representatives have exactly the same privileges and responsibilities as any other committer.
Will a participant representative be retired from a specification project when they change employers?

No. A participant representative is indistinguishable from any other committer and so retains their committer status even after changing employers. After changing employers, a committer may require new committer agreements, but once those are in place, the committer retains all privileges. In the event that a committer changing employers leaves a member participant unrepresented, that member participant may appoint a new participant representative.
How does the role of the Specification Committee differ from the role of the PMC?

The Project Management Committee (PMC) manages the technical governance process, and provides oversight. It ensures that the open source rules of engagement are observed and the Eclipse Development Process (EDP) as a whole is followed. It participates in the Intellectual Property Due Diligence Process to ensure that requests for review are technically sound (for example, to ensure that the use of third-party content makes technical sense). The PMC provides best practices. It tends to work more at the development and technical level.

The Specification Committee is responsible for ensuring that the rules and processes outlined by the EFSP are implemented by Specification Projects, that the integrity of the Scope is maintained (e.g. that release plans define changes that are in-scope), that community has been properly consulted, implementation is technical feasible, and that the Specification otherwise remains consistent with the goals of the Working Group.

The PMC is in the Project Leadership Chain; the Specification Committee is not. Approvals from both parties are required for Progress and Release Reviews.
If a Specification Project is archived, do the Final Specifications that it previously produced remain valid?

Yes. All previously created Final Specifications remain valid.
What does it mean for a Specification Project to be “under the supervision” of a Specification Committee?

A Specification Project effectively belongs to one Working Group. By aligning itself with a particular Working Group, a Specification Project agrees to take direction from the corresponding Specification Committee.
How does the Specification Committee manage the overall road map for the Specification Projects under their supervision?

How a Specification Committee manages a road map varies based on the nature of the parties involved. The Specification Committee may choose to defer this responsibility to one of the Specification Projects (e.g. a Platform Specification Project). The road map itself may take the form of a set of published guidelines or best practices, the implementation of a simultaneous release, or required themes and other elements in Release Plans. Ultimately, the Specification Committee should work with the PMC and the Project Teams to build consensus rather than impose rules.
By what criteria does the specification committee assess a plan? What constitutes an acceptable plan?

When reviewing a plan, the question that specification committee members need to answer is whether or not they, would vote to approve the eventual completion of that plan when the project returns to the committee for a release review.

Specification committee members have to decide whether or not, for example, themes and plan items described in a plan are something they would actually want to see in an implementation of the specification.

A specification committees may opt to make specific requirements for plans (including delivery format). That notwithstanding, how specification committee members vote is left to the discretion of the individual committee members.
What happens if a Review fails?

The party that fails (i.e. denies approval) the review is expected to provide feedback in the event of failure. The Specification Team will engage with the party to determine the correct course of action. That course of action may be to re-engage in the Review at a later date or take some other corrective action. In any case, the Reviews required by the process must be completed successfully to proceed to the next step.
What do I do if I feel that my Review was failed unfairly?

Follow the Grievance Handling process defined in the EDP.
How is the association of the artifacts of a particular Specification Version represented?

The Specification Committee should provide best practices to Specification Projects, for example, a standard metadata format.
What is the difference between a Specification Version and a Final Specification?

A Specification Version is produced by a release cycle, then becomes a Final Specification when it is Ratified and distributed under the Eclipse Foundation Specification License (EFSL).

The intellectual property rights required to build a Compatible Implementation flow from the Final Specification. That is, in order to be considered a Compatible Implementation and benefit from the intellectual property protections, an implementation must be based on a final specification. No claims regarding compatibility may be made for an implementation based on a milestone build or unratified Specification Version.
What types of changes are not appropriate for a Service Release?

Changes to method signatures or additions of new methods or behaviour (for example) are generally not considered appropriate in a Service Release. A Specification Team should consult with their PMC and Specification Committee to determine precisely what sort of review is required for a particular change.
Are Specification Projects required to implement the Eclipse IP Policy and engage in the Eclipse IP Due Diligence Process?

Yes.

Appendix A: Patents and Specifications

This section is derived from On Patents and Specifications by Mike Milinkovich, published on May 13/2021.

We’ve been fielding a number of questions lately about the intersection of our specification process and patents. A couple of these community discussions have gone off in directions that are off target, factually incorrect, or both. Therefore, the purpose of this short FAQ is to explain the patent license options provided by the Eclipse Foundation Intellectual Property Policy for use by specifications developed by specification projects under the Eclipse Foundation Specification Process (EFSP).

Disclaimer: This is not legal advice. I am not a lawyer. It has not been reviewed by counsel. Consult your own attorney. In addition, this note does not form part of any official Eclipse Foundation policy or process, but rather is provided for informational purposes only to aid those involved in our specification projects to better understand the EFSP and the choices available. I’ll update the content as needed.

One important point to keep in mind when reading this: we believe that the EFSP fully complies with the Open Standards Requirement for Software established by the Open Source Initiative. In other words, the EFSP is designed specifically to be open source friendly.

Why do specifications require patent licenses?

The purpose of every specification is to stimulate the development of implementations. These implementations may be derived from open source code maintained at the Eclipse Foundation or elsewhere, or they may be independently developed. They may be made available under open source licenses or proprietary. In order to facilitate and encourage these implementations, all specification processes provide some notion of patent licenses from the parties involved in developing the specifications.
What types of patent licenses are used by various specification organizations?

There are a wide variety of specification patent license options available from various sources.

Some terms that you may hear are:
- FRAND means fair, reasonable, and non-discriminatory licenses. This means that before you can implement the specification you are required to obtain a license from the patent holders who developed the specification. FRAND is generally considered to be antithetical to open source development, as it requires permission and money to implement a specification or potentially even to use an implementation of such a specification.
- FRAND-Z is FRAND where the cost of the license is set to zero. Note that although this removes the cost concerns of FRAND, permission may still be required for use and/or implementation.
- RF or royalty-free provides a priori royalty-free licenses from the participants developing the specifications to downstream users and implementers. This is considered a best practice for enabling open source implementations of a specification. All Eclipse Foundation specifications are developed on a royalty-free basis.
- Non-assert is another legal mechanism which provides a result effectively similar to royalty-free. A non-assert says that a patent holder will not assert their patent rights against an implementer or user.
Do these licenses mean that an implementer or user can never be sued for patent infringement?

No. The patent licenses are intended to ensure that an implementer or user doesn’t need to be worried about being sued by the parties involved in developing the specifications. It does not provide protection from uninvolved third parties who may believe they have intellectual property rights applicable to the specification.

Note that the above implies that it is in the interests of the entire community and ecosystem that many participants (particularly patent-owning participants) be involved in developing the specifications. It also explains why it is in the best interest of the community that all participants in the specification process have signed agreements in place documenting their commitment to the patent licensing under the EFSP.
What patent licenses are granted by the EFSP?

The patent licenses provided via the EFSP apply to all downstream implementations of Final Specifications, including independent implementations. They cover all patents owned by each Participant in the specification project that are essential claims needed by any implementer or user of the specification. Note that the licenses cover the entire specification, not just to the parts of the specification that a participant may have contributed to. We provide our specifications two options for patent licenses: the Compatible Patent License and the Implementation Patent License. The differences between those two are explained below.
But my open source license already has a patent license in it. Why do I need more than that?

The patent licenses provided in open source licenses such as Apache-2.0 grant a license for contributor-owned patents which apply to their contribution either alone or as combined with the work. The patent license is only to that program/implementation. Note that the Apache-2.0 patent license “…applies only to those patent claims licenseable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work…”. Relative to the EFSP, such grants are deficient in both scope (applies only to their contributions) and target (applies only to that implementation).
What is the difference between the two patent license options provided by the EFSP?

The only difference between the Compatible Patent License and and the Implementation Patent License is the timing of when the patent license grant comes into effect. In the Compatible Patent License, the license grant only happens when the implementation has demonstrated that it is fully compatible with the specification by passing the relevant TCK. The Implementation Patent License provides immediate patent licenses to all implementers, even to partial or work-in-progress implementations. The first choice emphasises the importance of compatibility. The latter choice emphasises the importance of open development. Both are valuable options available to Eclipse specification projects.
I’ve read the EFSP and I don’t see anything about patent licenses.

The patent licenses are provided in the Eclipse Foundation Intellectual Property Policy. A future version of the EFSP will make this clearer.
Is the Eclipse Foundation itself granted any licenses to patents?

No. The Eclipse Foundation itself does not acquire any patent rights in the specifications. The patent licenses are granted from the participating patent owners directly to implementers and users of those specifications. More specifically, the patent license grants are “… to everyone to make, have made, use, sell, offer to sell, and import…” implementations of the specifications.

Breadcrumbs

Eclipse Foundation Specification Process Operations Guide