[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[jakarta.ee-spec.committee] Minutes: 8-June Specification Committee Call
|
All,
Here are some rough notes from today's call.
- Dave Ings of IBM presented OASIS's approach to open source and
open standards. His presentation is attached.
- The net is that they arrived at an approach which is very
close to what we are discussing:
- First, an enhanced CLA.
- Second, a governance design that both encouraged and
compelled the project leaders to make IPR commitments to the
entire body of work.
- The licenses that they will permit are: Apache, MIT,
BSD-3-Clause, and EPL.
- Open source projects are hosted at GitHub. I assume that
they are hosted in their own organization so that they can
control the CLA.
- We then discussed the "Eclipse Foundation Specification
Process: Goals and Requirements" document.
- Kenji had asked in Specifications had to be developed at
Specification Projects. The answer from me was yes, the specification
projects do need to be hosted at Eclipse. RIs and TCKs can
be hosted elsewhere.
- The reason for this is IP flows. I at least am not smart
enough to figure out how to not require that Specifications be
developed by Specification Projects hosted at the Eclipse
Foundation. The Eclipse Specification Process will not have
the JCP-like notion of a Spec Lead which acquires special
rights to IP. That means that the IP grants will be via EF
agrements, terms of use, ECAs, committer agreements, etc. I
can't think of any way for this to work without having the
specifications developed at Eclipse. (Which does include our
organizations on GitHub.)
- Richard Monson-Haefel wanted to register that Tomitribe
objects to this approach.
- We agreed to add the Open Standards section as written.
- Added "...there is no requirement to pay a license
fee, join the Eclipse Foundation or an Eclipse
Working Group to create a Compatible Implementation. "
- We discussed the Eclipse TCK License and agreed that it makes
sense to have one in order to ensure that there are legal terms
that ties compatibility to a specific Version of a Specification
to a very specific TCK version/binary. There's no obvious way to
do that under the EPL.
- We deferred the Brand conversation in the last paragraph of
the document.
Comments welcomed.
|
Attachment:
OASIS OP for Jakarta EE Spec Committee.pdf
Description: Adobe PDF document