[JIRA] Commented: (JSR358-49) Ambiguity of Specification, Content and License causes Spec Leads to ignore it or use other licenses
- From: "keilw (JIRA)" <
- Subject: [JIRA] Commented: (JSR358-49) Ambiguity of Specification, Content and License causes Spec Leads to ignore it or use other licenses
- Date: Fri, 22 Feb 2013 19:55:53 +0000 (GMT+00:00)
- Auto-submitted: auto-generated
keilw commented on JSR358-49:
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
> 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
> >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
> 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:
For more information on JIRA, see: http://www.atlassian.com/software/jira