Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[] DRAFT: Specification Process Goals and Requirements


On behalf of the Jakarta EE Specification Committee, I would like to share a document for community review and feedback. The Committee has been working on a draft document capturing the goals and requirements[1] for the specification process. The document is open to all for comment.

It is our intent to define a truly open, vendor neutral specification process that reflects the current best practices in open standards and collaborative open source development. In my personal opinion, I think what the group has drafted does an excellent job of achieving those goals.

A few key points that are worth calling out and explaining are:

  • This is largely driven from Jakarta EE requirements, but the document is set up as establishing an Eclipse Foundation Specification Process that can be specialized for use by various working groups, such as IoT.
  • It is the purpose of this process to support the creation of open specifications 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.
  • There are a number of very important differences between this specification process and the JCP.
    • There is no Spec Lead. Specification projects are managed in a very similar fashion to regular Eclipse Foundation open source projects. So while there are "Specification Project Leaders", they have none of the special powers and IP rights of the JCP's Spec Lead.
    • There is no Reference Implementation. There must be at least one compatible implementation of a specification available under an open source license before a specification can be declared final. However, there is no longer a normative reference implementation that is special.
    • Implementations of the specifications do not have to be independent, and can explicitly be derived from any of the open source implementations. So the purpose of this specification process is to be of sufficient quality to allow the creation of independent implementations, but implementations do not necessarily need to be clean room in the traditional sense.
  • You will note that there is a specific recognition that member corporations have some special rights to control who their representative is on a specification team. This is not typical open source best practice, where meritocratic committer rights are not tied to employment. However, it is unavoidable in the context of specifications because there are patent licenses which flow from companies to the specifications by virtue of their participation in a specification team. If a company is going to be providing licenses to its patents by participating in a specification, it is reasonable that they would want to control who their representative is. In turn, the community as a whole benefits from ensuring clarity on all of the patent license contributions to our specifications.
  • The document envisages the creation of several agreements:
    • A participation agreement for everyone involved in the working group that lays out the IP flows.
    • A specification license that clearly grants the rights necessary to allow the creation of independent implementations.
    • A trademark license that allows the use of the brand by compatible implementations.
    • A TCK license that will clearly state that a specific version of the TCK must be used to test for compliance with a specific version of a specification. Note that the source code for TCKs must be under an open source license. It is possible that we won't need this license in the end as if we can handle this requirement via the process then we'll avoid writing yet another license.

I am sure that I speak on behalf of the entire Specification Committee when I say that we are looking forward to hearing everyone's feedback!



Mike Milinkovich
(m) +1.613.220.3223

Avast logo

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

Back to the top