| Re: [jakartaee-platform-dev] Full and Web Profile Specification Documents... |
|
On 2019-07-11 1:53 p.m., Mark Struberg
wrote:
Good afternoon! Please allow me a few questions. 1.) How does contributing to those spec documents work from a legal point of view? The Eclipse Foundation Specification License (EFSL) [1] does afaiu NOT allow to modify those documents. So how does e.g. a Pull Request work from a legal pov? Under which rights can someone modify those documents (to _potentially_ contribute back)? Where is this formally stated? The open source contribution license for all of the Specification
Projects is either APACHE-2.0 or the "EPL-2.0 OR GPL-2.0 WITH
Classpath-exception-2.0". The EFSL is not the
contribution license. Once the specification is completed it is re-licensed under the
EFSL and the final version of the document is made available under
the EFSL terms. 2.) The Eclipse Specification Process [2] defines that "Specification Project Committers must be Members of the Eclipse Foundation." So a normal Eclipse Committer cannot just commit to a specification project. (s)he must first apply for Eclipse Membership. Is this correct? Is it intended? Or just a mistake? It is intended. However, it is not in any way a draconian
requirement. It is a side effect of the requirement that everyone
who commits to a Specification Project must be covered under a
Participation Agreement (PA). Please note that a "Member" in the Eclipse Foundation context is
quite different than in the case of the Apache Software
Foundation. Just wanted to say that in case there is some
confusion, as I know that you have much more experience with the
ASF. At the EF, a committer is a Committer Member either by (i)
signing an Eclipse Foundation Membership Agreement in their
personal capacity, or (ii) by being employed by an Eclipse
Foundation corporate member. There are two versions of the Participation Agreement (PA):
corporate and individual. Both forms include the EF Membership
Agreement. So by either signing an PA individually or by being
covered by their employer's PA, each committer on a Spec Project
is a Member. 3.) Most other specifications currently hosted under eclipse-ee4j on github are currently under either EPL (1.0 or 2.0) or ALv2. Will this remain that way? Does the EFSL only apply to the bundled final revisions of that spec? Or will those be re-licensed (and based on which right?). As mentioned above the EFSL will be applied to the final version of the Spec after the Specification Version completes its Release Review and issues its Ratified Final Specification. "Based on which right" is a good question. The answer is in two
parts. Firstly, we have signed agreements from Oracle, IBM, Red
Hat, etc. that gives the EF a broad copyright license to the
specification documents for Java EE created these past 20-odd
years under the JCP. So the Eclipse Foundation itself has the
requisite rights to re-license the Java EE 8 documents under the
EFSL. Secondly, it explains why we updated all of the EF's committer
and contribution agreements in this past year. This text from the
Eclipse Contributor Agreement illustrates the source of the
re-licensing rights for future contributions.
4.) A similar Q like 3 applies to the TCKs. They are right now all EPL-2.0 or ALv2. Will that remain? As with the Specifications, the open source contribution license for the TCKs is either APACHE-2.0 or the EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0. Once the Specification Version completes its Release Review and issues its Ratified Final Specification, binaries of the TCK will be made available under the Eclipse Foundation TCK License. The *source code* for the TCKs will always be made available under either APACHE-2.0 or the EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 HTH txs and LieGrue, strub [1] https://www.eclipse.org/legal/efsl.php [2] https://www.eclipse.org/projects/efsp/Am 29.06.2019 um 09:52 schrieb Guillermo González de Agüero <z06.guillermo@xxxxxxxxx>: It's not only you! Great milestone! El vie., 28 jun. 2019 21:47, Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx> escribió: Maybe it’s just me, but WOO HOOOOOOO!! Mike Milinkovich mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx (m) +1.613.220.3223 On Jun 28, 2019, at 3:45 PM, Ivar Grimstad <ivar.grimstad@xxxxxxxxx> wrote:Done! You can find it here: https://github.com/eclipse-ee4j/jakartaee-platform/tree/master/specification Ivar On Fri, Jun 28, 2019 at 9:02 PM Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> wrote: The documents have been contributed and are approved by the IP Team for check in. Any project committer can grab them off the CQ and commit them to a project repository. If the team feels that a separate repository is required, please connect with Webmaster to request one. The acronym guidelines haven't propagated to the website yet. They are in the website's Git repository, however, so you can review them there. In addition to those guidelines, we'll need these documents to reference the specifications by their Jakarta names. Connect with the PMC if you need additional guidance. Wayne On Sun, Jun 23, 2019 at 10:32 PM Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> wrote: Greetings Jakarta EE Platform Committers and Project Leads. The EMO started a Restructuring Review to convert the existing Eclipse Jakarta EE Platform project into a specification project (as defined by the Eclipse Foundation Specification Process). The review has been open for a week and will conclude on Monday. Following the successful review, the EMO will update the project's name and scope, and convert the existing project into a specification project. In parallel, the EMO has been working to obtain the necessary rights to contribute the existing specification documents (for both the "Full" and "Web" Profiles) to the project under the project's licensing scheme. My intent is to make these document available shortly after the successful conclusion of the Restructuring Review. The specification documents have been converted from their original source formats into Asciidoc. I expect that there may have been some errors in conversion; these documents will need to be reviewed carefully. I will contribute the documents to the project via IPZilla. The IP Team will give the content one final check and, with their approval, the project team can take it from IPZilla and push it into a project repository in the form that they are received (i.e. you don't need to make any changes before committing the content). The project has several repositories already: an existing repository can be used, or--if desired--a new one can be created (connect with the webmaster to request the creation of a new repository). I expect that the Jakarta EE Steering Committee will publish name and acronym usage guidelines sometime this week along with some guidance regarding how to apply these guidelines to the specification documents. The EE4J PMC may also provide some guidance and/or assistance. Here's what we need from you: The conversion of these documents is a critical piece in the success of Jakarta EE 8. With this in mind, we need the Jakarta EE Platform committers to engage in accepting these documents, pushing them into a project repository, validating the conversion into Asciidoc, and applying the guidance provided by the Steering Committee. Please plan to spend some time scoping this work later this week. Note that many of the committers on this project are also members of the Steering Committee, so questions about this process can be asked on this mailing list. I will notify you (via this channel) when the documents are available. Wayne -- Wayne Beaton Director of Open Source Projects | Eclipse Foundation, Inc. -- Wayne Beaton Director of Open Source Projects | Eclipse Foundation, Inc. |