Community-led development "The Apache Way"
This was extracted (@ 2021-01-20 20:10) from a list of minutes
which have been approved by the Board.
Please Note
The Board typically approves the minutes of the previous meeting at the
beginning of every Board meeting; therefore, the list below does not
normally contain details from the minutes of the most recent Board meeting.
Meeting times vary, the exact schedule is available to ASF Members and Officers, search for "calendar" in the Foundation's private index page (svn:foundation/private-index.html).
Not much to report since November’s report. I do know that there is active movement towards TomEE’s Jakarta EE 8 and 9 certification. I also plan to attend the board meeting next week to get the board’s opinion on my actively pursuing the Apache Software Foundation becoming a guest member of the Eclipse foundation.
I have established contact with the Jakarta EE team, and actually attended one of their Jakarta EE working group calls. From what I can tell we have two Apache members that seem to have close contacts with the Jakarta EE community: Romain Manni-Bucau and Mark Thomas. I believe that Romain has potentially paved the way for us to potentially become Guest Members. Lastly, I would like to note that there is appetite that the Apache Projects that implement the Jakarta EE standard, use some form of the Jakarta logo on their websites or with their marketing materials. Having spoken with Mark Thomas about this, I’m not certain what appetite we have in accommodating these changes. I would think that such an appetite would reside at the project level if at all. I would love to hear your thoughts on these matters, particularly if you would think it prudent for me to start us down the path of establishing a guest membership at Jakarta because they would need to have requisite votes for us to establish ourselves in that manner.
A report was expected, but not received
A report was expected, but not received
With the Jakarta EE role, there are two 'open' items: 1) We have an open offer from Eclipse to sit as a guest on their EE committee. I don't think we have an individual who is interested in doing that however. It feels to me that we either find a Jakarta EE replacement, or if one is not available, let Eclipse know that we don't have anyone. I would like to inform Eclipse that I'm stepping away from the role. 2) There will be a Java package rename coming in the next few months (though my info is limited due to my lack of recent focus). Projects will rename reactively, but an active person in the role could help us be more proactive.
This month I communicated with Eclipse that: * We won't claim exclusive rights to any contributions made to the JCP forums/lists/specs for <relevant JSRs>. * But we won't sign something in which the ASF is claiming ownership of contributions made by our contributors to a third party (JCP). I noted that I doubted there would be any energy to resolve differences of opinion on interpretation of the JSPA, and they agreed that this wasn't worth pursuing further. This closes out last month's A2 action item. Remaining action items are: A1] Review documents for Apache joining Jakarta as a Guest Member and get these signed. A3] To communicate the topic to affected projects. This will probably mean a general communication to all committees visibly using Java, and directing them to jcp-open for follow-up.
Not much progress this month. There was discussion on board regarding the
request from Eclipse for a copyright license for Apache contributions to the
J2EE JSR.
My action items are:
A1] Review documents for Apache joining Jakarta as a Guest Member and get
these signed.
A2] Propose text to indicate that: Insomuch as the ASF licensed
copyright to the JCP, said copyright is also licensed to Eclipse.
I note that this month's TomEE report indicates that the summer release of
Jakarta EE 9 will involve a large breaking namespace change. A third action
item is:
A3] To communicate the topic to affected projects. This will probably mean a
general communication to all committees visibly using Java, and directing
them to jcp-open for follow-up.
Some minor progress to report. I've reviewed the emails over the last year and received valuable input from Mark Struberg, David Blevins, and Mark Thomas. I reached out to Mike Milinkovich and Paul Buck at Eclipse to determine the current status of things. My summary: * There was a 2018-ish agreement on the Jakarta name signed by Mark Thomas. * There was an invitation from Eclipse for Apache to join the Jakarta EE Working Group as a guest, with 2 agreements to sign. * There was also IP moved from Oracle to Eclipse related to the JCP and a desire for Apache to sign something. * There will be a big javax to jakarta package renaming coming down the pipeline. On these, the invitation is still open (#2) and there is still interest from Eclipse in completing their diligence (#3). My current action items are to identify the documents to be signed in #2 and confirm that these were approved for signing; and to identify the mechanism by which copyright licensing flowed from the ASF to the JCP so I understand what copyright's in various JSRs the ASF may be able to license.
A report was expected, but not received
A report was expected, but not received
A report was expected, but not received
A report was expected, but not received
A report was expected, but not received
A report was expected, but not received
This is a report about the current status of the Eclipse JakarteEE relations. I will reference the following documents in the further reading: * Eclipse Foundation Specification License (EFSL [1]) * Eclipse Foundation TCK License (EFTL [2]) * Eclipse Foundation Specification Process (EFSP [3]) # Overview The JakartaEE project hosts various specifications which are derived from JavaEE JSRs. Each of them consists of 4 different parts. 1.) the APIs (e.g. JPA - Jakarta Persistence API) 2.) the Reference Implementation (RI, e.g. Eclipse EclipseLink) 3.) the TCKs (previously one big monolithic TCK with only a few specs having their own separated ones) 4.) the spec documentation PDFs # Ad 1 and 2 - APIs and RIs The APIs owned by Oracle have been re-licensed to EPLv2 and donated to the Eclipse Foundation. Other APIs - mostly owned by IBM and RedHat - have been ALv2 ever since and afaik have also been donated to the EF. Reference Implementations have to be licensed under an 'Open Source Lincense' as defined by the EFSP. Which are EPLv2 or ALv2. Future development of spec APIs will happen under either EPLv2 or ALv2 (based on what each specification decides). This is legally perfectly fine for us to both contribute to and consume under (at worst) CatB [4]. # Ad 3 & 4 - TCKs and Specification Documents Some TCKs are ALv2: JBatch, CDI, Bean Validation. Most others got donated from Oracle to the Eclipse Foundation and are now licensed under EPLv2. I want to take this opportunity to say thanks to Oracle for this gracious move! There is one little complicated detail though. When a final specification gets ratified it will be published and distributed under the EFSL resp EFTL. This procedure is defined in the EFSP. Note that neither the EFSL nor EFTL are OSI licensed and never will be due to not allowing any modifications which makes them not an OSS license. The Specification Document for the Final Specification must be distributed as read-only text under the Eclipse Foundation Specification License. The Ratified TCK in composite must be distributed under the Eclipse Foundation Technology Compatibility Kit License. This could legally be achieved via either sub-licensing or re-licensing. The Eclipse ECA [5] explicitly talks about sublicensing. That means we would be fine to contribute to and consume TCKs and Specs _under work_ as well. The IP flow is that contributions to the TCK and Spec Documents are performed under ALv2 or EPLv2. And we can also consume those bits. The final versions though are ratified and bundled under very restrictive non-OSS licenses which you only get if one passes the TCK and are certified. There is also an Eclipse Foundation IP Policy [6] to which the EFSP refers to. It only applies to Specification Reviews. It contains some patent grant clauses which need to be further evaluated. In a first review they look roughly equivalent to the patent grant we have in ALv2. But this needs some more legal review. Interestingly this only becomes effective during the review and not during contributing. But the review and voting on the specs is only a small group of people/companies and not all contributors. # Other business The Eclipse Foundation reached out to us to help them collect IP for existing specification documents. Oracle transferred their right to the EF as far as they did hold them. They of course could only transfer IP they own themselves. Whether there is anything uncovered is an open question. The EF now reached out to us to also grant them rights for parts some ASF committers provided 'on behalf of the ASF'. Our current legal conclusio is that the ASF itself cannot do this but we will help to identify the individuals in question. # Summary * The ASF (or it's individuals) can both consume from and contribute to APIs and Reference Implementations. * The ASF can both consume from and contribute to TCKs and Spec Documents _under development_. * Consuming the final ratified EFSL and EFTCK licensed specs and TCKs are out of scope for the ASF without restricting us in any way. * The patent handling for contributors needs another review. [1] https://www.eclipse.org/legal/efsl.php [2] https://www.eclipse.org/legal/tck.php [3] https://www.eclipse.org/projects/efsp/ [4] https://www.apache.org/legal/resolved#category-b [5] https://www.eclipse.org/legal/ECA.php [6] https://www.eclipse.org/org/documents/Eclipse_IP_Policy.pdf
A report was expected, but not received
## Description: Apache Jakarta EE Relations exists to discover how the ASF can work together with the Eclipse Foundations Jakarta EE working group. ## Issues: - There are no issues requiring board attention at this time. ## Activity: The initial setup still has to be done. Do we need a mailing list and who else want's to provide input on the matter?
WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to appoint an officer responsible for being the primary liaison with the Eclipse Jakarta EE Platform. NOW, THEREFORE, BE IT RESOLVED that the office of "Vice President, Jakarta EE" be and hereby is created, the person holding such office to serve at the direction of the Board, and to have primary responsibility of managing the foundation's Jakarta EE strategy; and be it further RESOLVED, that Mark Struberg be and hereby is appointed to the office of Vice President, Jakarta EE, to serve in accordance with and subject to the direction of the Board until death, resignation, retirement, removal or disqualification, or until a successor is appointed. Special Order 7E, Appoint a Vice President of Jakarta EE Relations, was approved by Unanimous Vote of the directors present.