[JSR358-49] Ambiguity of Specification, Content and License causes Spec Leads to ignore it or use other licenses Created: 30/Jan/13 Updated: 08/Apr/14
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
The Process Document under Definitions
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.
This seems to be a common question of Spec Leads, e.g. one said:
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.
For most Build Tools like Maven, this could also be supported by plugins like "License Maven Plugin" to check and adjust licenses.
|Comment by keilw [ 02/Feb/13 ]|
Sonatype, the keepers of MavenCentral are just starting this "Java Application Health Check" Program:
|Comment by keilw [ 09/Feb/13 ]|
Even an Oracle-lead JSR, 236, Concurrency Utilities for Java EE has a discrepancy between Spec and API License.
While the API is licensed under one or both of these 2
This confirms the assumption, though a final assesment by either this EG or Oracle Legal could be helpful, that the "Spec License" is nothing more than "shrinkwrap" for the PDF or similar written document. And totally irrelevant to the actual API and other binaries.
Unless there is a legal requirement for this overhead, why can't it be dropped and replaced by a Single Spec License for Spec/API, RI and TCK???
The "compatibility" argument is ridiculous, given that not this PDF document, but the actual code and binary licensed totally different is running everywhere.
|Comment by keilw [ 22/Feb/13 ]|
Based on the Batch JSR, the Spec Lead consulted IBM legal team and they informed him all content delivered in the RI,
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.
|Comment by keilw [ 22/Jul/13 ]|
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:
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.