search

jcp-org / jsr358

0 stars 0 forks source link

JSR358-49: Ambiguity of Specification, Content and License causes Spec Leads to ignore it or use other licenses #42

Open apastsya opened 11 years ago

apastsya commented 11 years ago

Jira issue originally created by user keilw:

The Process Document under Definitions http://jcp.org/en/procedures/jcp2_9#DEF defines

Java Specification (Specification): A written specification for some aspect of the Java technology. This includes the language, virtual >machine, Platform Editions, Profiles, and application programming interfaces.

Several Spec Leads and related organizations interpret "Specification" only as the first part of that, "A written specification for some aspect of the Java technology." ignoring the remaining definition, especially "and application programming interfaces."

This first became clear, when I looked at all aspects of JSR 330, Dependency Injection, including Spec, RI and TCK prior to my vote. While, Bob Lee may have been misinformed, and we know, 330 was rushed into Java EE 6 not to miss the Release Train and still be used by CDI, that JSR and several others, mostly EE and non-Oracle lead have applied the same practice. It also looks the same for JSR 352, Batch, all the way down to the Java sources of the Specification which say "Apache License".

This seems to be a common question of Spec Leads, e.g. one said:

We license all software artifacts, including JavaDoc, API jars etc. under the Apache License 2. It's only the Spec text that is >licensed differently, AIUI. So several Spec Leads assume, the Spec License was a "Shrinkwrap" license, before you download the Spec text (the "written specification for some aspect of the Java technology.") from JCP.org, but is otherwise irrelevant to their JCP or its users.

Hence, where the Spec API is "really" downloaded from in everyday life, Maven, Artifactory, Eclipse P2 or similar Software repositories, none of the specs ever even mention a Spec License. Those who do also use Apache or a respective other license, usually that of the RI. Others may not mention a license, mainly Oracle lead specs, who leave the (Maven) POM or similar metafiles empty. With few exceptions like the Java EE 6 Web Profile, or newer JSRs by Oracle to be included in Java EE 7.

For most Build Tools like Maven, this could also be supported by plugins like "License Maven Plugin" to check and adjust licenses.

apastsya commented 11 years ago

Comment created by keilw:

Sonatype, the keepers of MavenCentral are just starting this "Java Application Health Check" Program: http://www.sonatype.com/Products/Application-Health-Check Which certainly uses information in its POM, not plain text documents accompanying a JSR.

apastsya commented 11 years ago

Comment created by keilw:

apastsya commented 11 years ago

Comment created by keilw:

Based on the Batch JSR, the Spec Lead consulted IBM legal team and they informed him all content delivered in the RI, including the javax.batch.* files, must carry the RI license. Only the spec (paper/prosa document from their advice) carries the spec license.

That confirms what Red Hat and at least for JSR 236 also Oracle Legal seem to agree on. As spoken in the last EC call, it makes a separate "Spec" license barely relevant and is a strong argument in favor of Scott/Red Hat's recent proposal.

apastsya commented 11 years ago

Comment created by keilw:

Unless there is a different statement by Oracle Legal (or i.E. Jim Wright) licenses of the API (javax.*) tend to be the identical to the RI license in a majority of JSRs, while the plain text Spec document as well as JavaDoc for this API is commonly understood as covered by the Spec License.

Note, Red Hat Spec Leads (e.g. CDI and Bean Validation, also pending JSRs like 347) expressed the intent to dual-license also the Spec documents, see below from a thread on the Spec License with Pete Muir, as well as EC Reps Mark and Scott:

I don't infer the same conclusion from Bill's comment as you do, I'm afraid. I will speak to our legal team to get their expert opinion on this matter, but assuming they approve, I will be publishing the Javadoc on jboss.org under the apache 2 license, effectively dual licensing the javadoc such that the version you get from the jcp page, which is behind the Oracle click through license, is licensed using the Oracle spec license, and the versions you get from maven, jboss.org or cdi-spec.org are Apache 2 licensed.

To date, I believe there are no licensing issues, as we do agree that the version of the javadoc and spec you get from jcp.org, >which are the versions you are reviewing for the Final Ballot, are both licensed under the spec license, and are adequately flagged >as such, due to the presence of the click through license agreement. The version you get from Maven is clearly Apache License, as >the POM correctly states the license. We have not yet published a version on docs.jboss.org or cdi-spec.org.