[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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.

This ECA, and the license(s) associated with the particular Eclipse Foundation projects You are contributing to, provides a license to Your Contributions to the Eclipse Foundation and downstream consumers, but You still own Your Contributions, and except for the licenses provided for in this ECA, You reserve all right, title and interest in Your Contributions. In addition to the above, You grant a non- exclusive, worldwide, perpetual, royalty-free license of all necessary rights under Your copyright in and to Your Contributions (the âSpecification Grantâ): (a) for the Eclipse Foundation (and its contributors solely as a part of foundation projects) to create, reproduce, prepare derivative works of, publicly display, publicly perform, distribute and sublicense specifications subject to the terms of the then-current Eclipse Foundation Specification License, based on or derived from the Specification Content (as defined below) and (b) for recipients of such specifications to create, reproduce, and distribute implementations thereof based on the portion of Your Contributions or material derived from them in the specifications, subject to the terms of the then-current Eclipse Foundation Specification License.

âSpecification Contentâ is the collection of interface definitions for the Application or User interfaces (âInterfacesâ) provided by the work to which Your Contribution was made, descriptions of the structure and semantic behavior of those Interfaces, and data formats and protocols associated with those Interfaces, all of which as are reasonably necessary to enable the development of independent implementations of those Interfaces. For the sake of clarity, Specification Content does not include implementation detail of how the Eclipse project code or Your Contribution implements the Interfaces in the Specification and the Specification Grant provide above would not cover such additional material.

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.