Skip to main content

[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.

--
Mike Milinkovich
mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx
(m) +1.613.220.3223

Attachment: OASIS OP for Jakarta EE Spec Committee.pdf
Description: Adobe PDF document


Back to the top