Re: [jakarta.ee-spec.committee] Approval to post the requirements docume

[Kenji Kazumura <kzr@xxxxxxxxxxxxxx>]

+1

-Kenji Kazumura

In message <32016213-16f6-605d-b469-069c3dd4588a@xxxxxxxxxxxxxxxxxxxxxx>
   [jakarta.ee-spec.committee] Approval to post the requirements document
   Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx> 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
> <https://www.eclipse.org/org/workinggroups/industry_wg_process.php>. 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.
> 
> *
> 
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus