Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec.committee] Approval to post the requirements document

Mike,

I am tardy with the steering committee minutes for this past Tuesday's meeting. Adding my summary of the discussion from Tuesday (will be forthcoming in my post of steering committee meeting minutes);

Does this committee recommend this document for publication? (+1 requested by by Mike)

Opened discussion by noting there is still debate about how / when IP rights are transferred (Dan). This does not appear to be finalized yet. When does a contributor contribution become transferred to the specification committee? When is said contribution available by the committee to be re-conveyed to a "user." What about various logistical issues (members coming and going, long-lived specifications, etc.). Currently outbound license is conveyed when compatibility is demonstrated. Dan would like this to be elaborated more carefully before initial publication. Scott suggested that there are related issues in other committees (IP advisory committee as an example was mentioned) that aren't being folded into this. Mike is the effective Chair of the IP committee. Ian: Is IP sub-committee membership legal reps? Paul isn't sure. (Scott Peterson is rep. from Red Hat.) Some consensus that having broader discussions between active related committees would be useful. Paul pointed out that IP advisory is a standing Eclipse Foundation committee. (Sharon and Wayne both attend.) Ian raised concerns that visibility into actions of this committee is difficult to obtain. Wayne confirmed that minutes are published. Ian suggested that Minutes be made available for review. (Wayne to look after this?) Dan reminds us that Lawyer/counsel detail is also necessary for final document drafts. These, and several other reservations about the document were noted. Ed observed that it can be difficult to respond in writing to documents like this. We agreed that this will be referred back to the committee for further action, likely on Thursday.

Steering Committee is not prepared to give +1 yet.
I'll let Dan give clarity to his sense for timing.

-- Ed


On 6/21/2018 9:04 AM, Mike Milinkovich wrote:
All,

Can I please get your +1 to post this document to the working group list? (Dan Bandera, we weren't sure if you still wanted to discuss things with your lawyer before having this go public.)

Thanks.

Eclipse Foundation Specification Process: Goals and Requirements

The document describes the set of requirements for an Eclipse Foundation Specification Process for optional use by Eclipse Foundation Working Groups. Note that although many of the activities related to this process are conducted by open source projects operating under the Eclipse Development Process, this Specification Process, and the Specifications delivered under it are to be managed by Working Groups.

Terms and Definitions

A “Working Group” is an Eclipse Foundation Working Group established under the Working Group Process. Definitions from the Working Group Process are included herein by reference.


A “Specification Committee” is a committee of a Working Group established to manage this Process for technologies within the Scope of its Working Group. Note that this document describes the requirements for the Eclipse Foundation Specification Process. Individual Specification Committees may specialize the process for their unique requirements.


The “Brand” is the name and logo selected by the Working Group solely for the use of Compatible Implementations.


An “Open Source License” is one of the following OSI-approved open source licenses: EPL-2.0 (possibly with Secondary Licenses), and APACHE-2.0. Open source licenses used by this Specification Process may be added or removed from this list with the unanimous approval of the Working Group Steering Committee, and the Eclipse Foundation Board of Directors.


A “Specification” is a collection of application programming interface (API) definitions, descriptions of semantic behavior, data formats, and/or protocols intended to enable the development of Independent Implementations. A Specification includes all of the artifacts necessary, including without limitation descriptions of APIs and behavior, documentation, and data formats, necessary to provide sufficient precision to enable Independent Implementations. Specifications using an Eclipse Foundation Brand must be developed by Specification Projects.

A Specification has one or more “Versions” (each, a “Version”), which references specific versions of its constituent artifacts: references to its Specification, other Specifications, one or more SI, and its TCK..

A “Specification Project” is an Eclipse Foundation project operating under the Eclipse Development Process which is constituted to deliver Versions of a Specification. The individual Committers on the Specification Project constitute its “Specification Team”.


The “Scope” for a Specification Project is intended to define the technology area to be addressed by the Specification Project. Amongst other things, the Scope is intended to inform companies and individuals on whether they want to contribute to the Specification.


A “Specification Implementation” (“SI”) is a Compatible Implementation made available under an Open Source License. An SI is intended to demonstrate that the Specification can be implemented, and the TCK can be passed. There must be at least one SI available for a new Version of a Specification to be approved by its Specification Committee.

A “Technology Compatibility Kit” (“TCK”) allows the testing of implementations to ensure that they are compatible with the Specification. The TCK is selected by the Specification Project for each Version of the Specification. Any implementation that passes the associated TCK may claim that it is a Compatible Implementation. TCKs must be available under an Open Source License.

A “Profile” is a Specification that includes by reference a collection of Specifications. Profiles do not have to be arranged in unique subsets. I.e. a Specification may appear in more than one Profile. A Profile may optionally add additional tests to its TCK that tests interactions between its Specifications.

A “Compatible Implementation” is any implementation of a Version of a Specification which fully complies with its TCK.

An “Independent Implementation” is a Compatible Implementation which does not derive from a Specification Implementation. For the sake of clarity:

  1. It must be possible to create a clean room implementation that is derived solely from the Specification.

  2. It may be possible that there are no Independent Implementations of a Specification if, for example, the Specification Implementations are of sufficient quality.

A “Platform” is a Profile that has been optionally selected by a Specification Committee as defining the full capabilities of the technologies within the Scope of its Working Group. There is no requirement that every Specification adopted by the Specification Committee must be included in its Platform. There is no requirement that a Specification Committee must select a Platform.

Open Standards

It is the purpose of this process to support the creation of open standards that are rigorous and controlled in their creation and testing, while facilitating the creation of Compatible Implementations. For example, there is no requirement to pay a license fee, join the Eclipse Foundation or an Eclipse Working Group to create a Compatible Implementation.

Code First

It is a requirement that it be possible to create Specifications from existing open source projects at the Eclipse Foundation and other well-managed open source hosts such as the Apache Software Foundation.


It is a requirement that Specifications may be co-developed along with multiple Specification Implementations.

Participation

Participation in a Specification Project will be limited to parties (collectively the “Participants”, and individually the “Specification Participant”) covered under a <<Working Group>> Participation Agreement that will document the intellectual property contributions to the specifications. Participants may be organizational Members of the Eclipse Foundation (e.g. Solutions Member, Enterprise Member, Strategic Member (“Member Participants”)) or individual Committer Members (“Committer Participants”). All Participants with a representative on a Specification Project will grant royalty-free licenses to any Essential Claims (i.e. patent rights) which apply to any Compatible Implementation of that Specification. [Note: The Specification Team is the team of committers working on a Specification Project. These Participants are the organizations they represent.]


Member Participants will have the right to designate the individual representing them on the Specification Project (each, a “Specification Participant Representative”).

Approvals

A Specification Committee may approve Specifications, Profiles, and Platforms as follows:


  • A supermajority is required to approve the creation of a new Specification.

  • A supermajority is required to approve the revision to the Scope of a Specification.

  • A supermajority is required to approve each Review of a Specification, including its adoption.

  • A supermajority, including a supermajority of Strategic Members, is required to approve a Profile Specification.

  • A Platform must be approved unanimously.


Note that once a new Specification has been approved by the Specification Committee, its Specification Project will be approved by the normal Eclipse Development Process procedures. This includes PMC and EMO(ED) approvals.


In all cases above the materials provided to the Specification Committee in support of the decision and the voting records will be made publicly available.

Branding and Certification

There may be multiple Specification Implementations. Compatible Implementations may make use of Specification Implementations.


Source code for TCKs must be made available under an Open Source License. For each Specification Version there will be a single corresponding TCK version selected by the Specification Project and made available under the Eclipse TCK License which must be used to test each Compatible Implementation.  


Specifications will be made available under an Eclipse Foundation Specification License (EFSL) that will clearly license all necessary copyright rights to enable Independent Implementations.


The Brand will be licensed by the Eclipse Foundation for Compatible Implementations of Profiles using an Eclipse Foundation Trademark License Agreement (EFTLA). This EFTLA will contain terms to ensure the sustainability of working groups which have adopted the specification process, such as requiring membership in the working group.




Avast logo

This email has been checked for viruses by Avast antivirus software.
www.avast.com 




_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee

Back to the top