Skip to main content

[JIRA] Issue Comment Edited: (JSR358-49) Ambiguity of Specification, Content and License causes Spec Leads to ignore it or use other licenses

  • From: "keilw (JIRA)" < >
  • To:
  • Subject: [JIRA] Issue Comment Edited: (JSR358-49) Ambiguity of Specification, Content and License causes Spec Leads to ignore it or use other licenses
  • Date: Sat, 9 Feb 2013 13:11:53 +0000 (GMT+00:00)
  • Auto-submitted: auto-generated


    [ 
http://java.net/jira/browse/JSR358-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355761#action_355761
 ] 

keilw edited comment on JSR358-49 at 2/9/13 1:10 PM:
-----------------------------------------------------

Even an Oracle-lead JSR, 236, Concurrency Utilities for Java EE has a 
discrepancy between Spec and API License.
the Spec License is mentioned on the detail page:
The API is licensed under one or both of these 2
<licenses>
 <license>
    <name>CDDL 1.1</name>
    <url>http://glassfish.java.net/public/CDDL+GPL_1_1.html</url>
    <distribution>repo</distribution>
  </license>
  <license>
    <name>GPL2 w/ CPE</name>
    <url>http://glassfish.java.net/public/CDDL+GPL_1_1.html</url>
    <distribution>repo</distribution>
  </license>
</licenses>

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.

      was (Author: keilw):
    Even an Oracle-lead JSR, 236, Concurrency Utilities for Java EE has a 
discrepancy between Spec and API License.
the Spec License is mentioned on the detail page:
The API is licensed under one or both of these 2
<licenses>
 <license>
    <name>CDDL 1.1</name>
    <url>http://glassfish.java.net/public/CDDL+GPL_1_1.html</url>
    <distribution>repo</distribution>
  </license>
  <license>
    <name>GPL2 w/ CPE</name>
    <url>http://glassfish.java.net/public/CDDL+GPL_1_1.html</url>
    <distribution>repo</distribution>
  </license>
</licenses>

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???
  
> Ambiguity of Specification, Content and License causes Spec Leads to ignore 
> it or use other licenses
> ----------------------------------------------------------------------------------------------------
>
>                 Key: JSR358-49
>                 URL: http://java.net/jira/browse/JSR358-49
>             Project: jsr358
>          Issue Type: Bug
>          Components: Licensing
>            Reporter: 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.
> - If the Spec License really does only apply to the written document, not 
> any API or actual Java code, then there is no action required.
> - If this is not the case, both Process Document, and probably other 
> resources like Spec Lead Guide should be revised and improved for a better 
> understanding by Spec Leads and EG Members.
> For most Build Tools like Maven, this could also be supported by plugins 
> like "License Maven Plugin" to check and adjust licenses.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://java.net/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


[JIRA] Issue Comment Edited: (JSR358-49) Ambiguity of Specification, Content and License causes Spec Leads to ignore it or use other licenses

keilw (JIRA) 02/09/2013

<Possible follow-up(s)>

[JIRA] Issue Comment Edited: (JSR358-49) Ambiguity of Specification, Content and License causes Spec Leads to ignore it or use other licenses

keilw (JIRA) 02/09/2013
 
 
Close
loading
Please Confirm
Close