Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec.committee] [jakartaee-spec-project-leads] License files in javadoc and sources artifacts
Yes, it is a bit strange.  But, some of this is due to the bootstrapping required for Jakarta EE 8 and the lack of the formal Specification documents for the various components.  The skeletal Spec document that every component is creating in conjunction with the Javadoc is considered our "Specification" for Jakarta EE 8.  Thus, both pieces need to be licensed under the EFSL -- the skeletal Spec and the generated Javadoc.

Post Jakarta EE 8, we may be able to relax this requirement as more components will have access to the original Java EE specifications and we can drop the requirement for the Javadoc to be EFSL licensed.

Given all of that...  David brings up a valid concern...  If OSSRH will not allow the EFSL licensed Javadoc in the repo, then we have to figure out an alternative solution.

---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter



From:        Joakim Erdfelt <joakim.erdfelt@xxxxxxxxx>
To:        JakartaEE Spec Project Leadership discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>
Cc:        "jakarta.ee-spec.committee@xxxxxxxxxxx" <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date:        07/31/2019 07:29 AM
Subject:        [EXTERNAL] Re: [jakartaee-spec-project-leads] License files in javadoc and sources artifacts
Sent by:        jakartaee-spec-project-leads-bounces@xxxxxxxxxxx



It does seem strange that the generated Javadoc is EFSL, but the source of the javadoc is EPL.

So if a tool / ide / user wanted to use the source only, and never the generated javadoc to do their work, they would be subject to the EPL, not the EFSL.


On Tue, Jul 30, 2019 at 8:57 PM David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
This brings up a more important discussion.

OSSRH does not want non-OSS binaries being staged and published.

We've clearly identified we should not be publishing the spec PDF there for this reason as it is under the EFSL.  In the future (when there's more time) we can publish EPL versions to OSSRH and Maven Central like CDI has done.

If the EFSL is being applied to the generated javadoc.jar file, the same rule must apply.

Do we strictly need the javadoc jar to contain the EFSL or is the EPL enough?  Understandably there might be different short-term and long-term answers.

One approach:

 - Short-term: Just use EPL in the javadoc jar and good old find-and-replace for the apidoc PR.  Long term: yay tool yet-to-be-written that solves this


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

On Jul 30, 2019, at 1:56 PM, Kevin Sutter <sutter@xxxxxxxxxx> wrote:

This brings up another question...  As Joakim points out, there does seem to be some inconsistency on the licensing requirements for these various jar files.  I think we have answered the question for the javadoc jar file and how to include the EFSL license.

But, what about the sources jar file?  Should that contain the EPL (or ASL or whatever is used for development) in the META-INF directory?

And, the main api jar file...  Should that also contain the EPL (or ASL or whatever is used for development) in the META-INF directory?

Since we have so many different teams generating these artifacts, I wonder if we have another inconsistency brewing?

---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect
e-mail:  sutter@xxxxxxxxxx    Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter



From:        Bill Shannon <bill.shannon@xxxxxxxxxx>
To:        JakartaEE Spec Project Leadership discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>, Joakim Erdfelt <joakim.erdfelt@xxxxxxxxx>, "jakarta.ee-spec.committee@xxxxxxxxxxx" <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date:        07/30/2019 03:39 PM
Subject:        [EXTERNAL] Re: [jakartaee-spec-project-leads] License files in javadoc and sources artifacts
Sent by:        jakartaee-spec-project-leads-bounces@xxxxxxxxxxx



The json-api javadoc jar file is correct.  The doc-files/speclicense.html file is the EFSL license that's linked to in the footer of the javadoc pages.

Joakim Erdfelt wrote on 7/30/19 1:12 PM:
Per the instructions at https://wiki.eclipse.org/How_to_Prepare_API_Projects_for_the_Jakarta_EE_8_Release

All of the jar artifacts produced should have an appropriate license file.

For the spec artiacts and javadoc artiacts it's the EFSL (Eclipse Foundation Specification License) - https://raw.githubusercontent.com/eclipse-ee4j/jakartaee-api/master/licenses/EFSL.html
For the rest of the artifacts (main artifact jar/bundle, and its sources classified jar) it's whatever that project is licensed at.

So for a typical jakarta project (with source) we'll have 3 artifacts for each maven module.

jakarta.<name>-<version>.jar - main artifact
jakarta.<name>-<version>-sources.jar - sources classified artifact
jakarta.<name>-<version>-javadoc.jar - javadoc classified artifact

Getting the license file into /META-INF/ for the main artifact is easy enough.
So is getting the license into the sources classified artifact.

However, getting the license into the javadoc classified artifact is a bit tricky.
I'm sure someone here has figured it out, but I can't find that project.

I sampled a few "done" projects on the "Jakarta EE 8 Release" project at https://github.com/orgs/eclipse-ee4j/projects/15

Here's what I found when searching sources classified artifacts from "Done" list ...

$ jar -tvf jakarta.security.enterprise-api-1.0.2-sources.jar | grep -Ei "(license|eclipse|efsl)"
$ jar -tvf jakarta.servlet-api-4.0.3-sources.jar | grep -Ei "(license|eclipse|efsl)"
$ jar -tvf jakarta.security.enterprise-api-1.0.2-sources.jar | grep -Ei "(license|eclipse|efsl)"
$ jar -tvf jakarta.inject-api-1.0-sources.jar | grep -Ei "(license|eclipse|efsl)"
$ jar -tvf jakarta.jms-api-2.0.3-sources.jar | grep -Ei "(license|eclipse|efsl)"
$ jar -tvf jakarta.json-api-1.1.6-sources.jar | grep -Ei "(license|eclipse|efsl)"
 35084 Fri Jul 19 19:29:04 CDT 2019 META-INF/LICENSE.md

Here's what I found when searching javadoc classified artifacts from "Done" list ...

$ jar -tvf jakarta.servlet-api-4.0.3-javadoc.jar | grep -Ei "(license|eclipse|efsl)"
$ jar -tvf jakarta.security.enterprise-api-1.0.2-javadoc.jar | grep -Ei "(license|eclipse|efsl)"
$ jar -tvf jakarta.inject-api-1.0-javadoc.jar | grep -Ei "(license|eclipse|efsl)"
$ jar -tvf jakarta.jms-api-2.0.3-javadoc.jar | grep -Ei "(license|eclipse|efsl)"
$ jar -tvf jakarta.json-api-1.1.6-javadoc.jar | grep -Ei "(license|eclipse|efsl)"
  3250 Fri Jul 19 19:35:18 CDT 2019 doc-files/speclicense.html

The json-api project has figured out how to get a license file into their javadoc classified jar, but not in the correct place.
But json-api did figure out how to get the /META-INF/LICENSE.md correctly.

I'm reaching out to find out if another project has figured this out yet for javadoc classified artifacts?

Thanks,
- Joakim Erdfelt (Jakarta WebSocket)

_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads

_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads



_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads

_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads


Back to the top