|
Thanks to everyone who provided comments and feedback on the draft
requirements document. I've now turned off comments, and the
document can be considered a working version at this point. There
are still a couple of requirements which need to be added (e.g.
being able to work with specifications developed elsewhere), but
we believe this is a reasonable stating point for the next stage
of discussions. Thanks.
On 2018-06-29 8:09 AM, Mike Milinkovich wrote:
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
|
|
