Bugzilla – Bug 4589
Wrong license header in all Spec (API) files and License.txt
Last modified: 2013-02-22 20:56:31 UTC
When looking into files like ItemReader, ItemWriter, etc. I stumbled over a wrong License header in all files under the JSR352.API module.
That module is the "Spec" as far as one can see, no TCK or RI included.
Thus the Spec License like in the JSR page applies and an appropriate header should declare that. Currently all files say they're licensed under Apache 2.0 which is incorrect.
Same goes for the Licence.txt file in the top level Maven project, this shall be moved into appropriate sub-modules like JSR352.Tests.TCK or similar. And JSR352.API get a License.txt with the right license, like found in http://jcp.org/aboutJava/communityprocess/licenses/jsr352/352-spec-license.pdf
Noted. We will resolve before final approval ballot.
I consulted my legal team and they inform me all content delivered in the RI, including the javax.batch.* files, must carry the RI license. Only the spec carries the spec license.
(In reply to comment #2)
> I consulted my legal team and they inform me all content delivered in the RI,
> including the javax.batch.* files, must carry the RI license. Only the spec
> carries the spec license.
Well, there's a wide misunderstanding on what is "Spec" and what is "API", the latter legal departments not just yours seems to consider identical to RI.
The argument is taken and carried into the relevant JSR 358 JIRA ticket and WG discussion.
See http://java.net/jira/browse/JSR358-49 for your info and reference. Feel free to share with legal, though there might be someone by IBM in the 358 WG anyway.
Most recent Red Hat proposal looks closest to resolving this issue and possibly eliminating or simplifying that "Spec" license dilemma, a license effectively just for a piece of paper that's worthless and irrelevant when the API and Spec are really consumed in every day life. Nobody even cares about that Spec license once the Spec/API RI or TCK are used out there either via Maven or inside a Java EE based product.
Thanks for your input.
Keil, thanks for the additional information. It is interesting to see this issue is more wide spread than just JSR 352. I am glad to see you have initiated action to resolve this globally.