|
All,
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!
Thanks.
[1]
https://docs.google.com/document/d/1M51ZXlvCNS_X23OZupPs34pbkOuTPxKryZC0buA_smE/edit?usp=sharing
![Avast logo]()
|
This email has been checked for viruses by Avast antivirus software.
www.avast.com
|
|
