search

jsr107 / jsr107spec

JSR107 Cache Specification
Apache License 2.0
413 stars 164 forks source link

Relicense the Java code of the specification under a standard license #333

Closed philwo closed 7 years ago

philwo commented 8 years ago

Hi,

I understand that the JSR107 specification itself is licensed under these terms: https://github.com/jsr107/jsr107spec/blob/master/LICENSE.txt

The Java code ("JCache API") and released Java bytecode, namely the "cache-api-.jar" as available from Sonatype or maven.org seem to be licensed under the same license. As this is not a standard open-source license like Apache 2.0, BSD, MIT, CDDL, ... which are usually used for open-source code, we unfortunately cannot use the JCache API in our open-source project, but we'd love to do so.

Would it be possible for the Java code making up the JCache API to be relicensed under a well-known open-source license, preferably Apache 2.0?

Thanks, philwo

ekaganovich commented 8 years ago

I would like to second this request. My organisation provides software-as-a-service. We develop commercial applications that run within the walls of our data centers. We are looking to leverage the open source implementations such as Hazelcast or Apache-Ignite which has run-time dependencies on cache-api-1.0.0. Does this "Spec License" effectively prohibit us from using these implementation providers that transitively require cache-api to be on the runtime classpath of a commercial software?

cruftex commented 8 years ago

@ekaganovich: You are asking for legal advice on an issue tracker. Combining licenses and its effects keeps lawyers quite busy and you will not get an definitive answer anyways, see the current ZFS licensing discussion for Ubuntu.

Anyhow, we need to fix this issue.

cruftex commented 8 years ago

I did a check what other specs are doing. Java-EE also has a jar file on maven central (javax:javaee-api), which is licensed jointly under GP2 and CDDL.

Interestingly the JPA part in the javaee api (didn't check everything) has a different copyright header and referes to: Eclipse Public License v1.0 and Eclipse Distribution License v. 1.0

cruftex commented 8 years ago

Asked at the java ee working group:

What license will the upcoming EE API have? What license (the same or compatible) would the JCache API need to have integrated in EE?

cruftex commented 8 years ago

Summary of the current state:

The API (1.0.0) has the following in the pom:

<licenses>
    <license>
        <name>JSR-000107 JCACHE 2.9 Public Review - Updated Specification
            License
        </name>
        <url>https://raw.github.com/jsr107/jsr107spec/master/LICENSE.txt</url>
        <distribution>manual</distribution>
    </license>
</licenses>

The RI (1.0.0) and the TCK (1.0.1) has:

<licenses>
    <license>
        <name>The Apache Software License, Version 2.0</name>
        <url>http://www.apache.org/licenses/LICENSE-2.0.txt</url>
        <distribution>repo</distribution>
    </license>
</licenses>

RI and TCK depend on the API, of course.

cruftex commented 8 years ago

Maven central inclusion was applied with: https://issues.sonatype.org/browse/OSSRH-1910

Relevant here:

The RI is being done under Apache 2 and the spec under the standard JCP spec license which provides for free use.

cruftex commented 8 years ago

Raised an issue at sonatype, what to do for maven central: https://issues.sonatype.org/browse/OSSRH-20917

cruftex commented 8 years ago

Questions:

cruftex commented 8 years ago

Answer from sonatype:

Per the current terms of use for Maven Central, http://repo1.maven.org/terms.html, a artifact's license doesn't necessarily have to be open-source for the license to be hosted on Central. The license simply has to permit the free distribution of the artifact via Maven Central. That being said, submitting an artifact with a different/corrected license is certainly possible, though the original licensing and older versions have to remain the same.

gregrluck commented 8 years ago

Every JSR specification has a similar license to JCache. If you are using any part of Java you are using the JCP license. Go to any of the JSRs and you will see the same license.

Here is JDBC: http://download.oracle.com/otn-pub/jcp/jdbc-4_1-mrel-spec/jdbc4.1-fr-spec.pdf?AuthParam=1456857617_74cb95b68a78ada92dd2c6fa36bc2799 It is almost exactly the same.

And so is every standard the JCP has ever done.

These standards are free to use and form the basis of Java.

ulfjack commented 8 years ago

The JSR 107 homepage says: "The RI will be available for commercial use under the CDDL 1.1 open source license, the GPLv2 with Classpath Exception open source license, or this RI license."

See here: https://jcp.org/en/jsr/detail?id=107

Similarly, OpenJDK is licensed under GPLv2 / GPL with classpath exception: "What open-source license is OpenJDK published under?

GPL v2 for almost all of the virtual machine, and GPL v2 + the Classpath exception for the class libraries and those parts of the virtual machine that expose public APIs."

See here: http://openjdk.java.net/faq/

However, this github archive only shows the license referenced above. And the source files do not specify a license, except to say that they fall under the license terms: /**

See here: https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cache/Cache.java

If you look at the license file, it says specifically: "1. License for Evaluation Purposes. Specification Leads hereby grant you a fully-paid, non-exclusive, non-transferable, worldwide, limited license (without the right to sublicense), under Specification Leads' applicable intellectual property rights to view, download, use and reproduce the Specification only for the purpose of internal evaluation."

(If you think point 2 applied, then you need to read point 5.)

I don't see how this could possibly be construed as to mean that we're allowed to use the code. If JDBC is distributed under the same license, then the same applies to JDBC.

ulfjack commented 8 years ago

Here's the source of java.sql.DriverManager: http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b27/java/sql/DriverManager.java

It clearly says: /*

ekaganovich commented 8 years ago

@gregrluck thanks for your comments. "Spec license" is probably more applicable for specifications that exist in the form of a document (which is the case for JDBC) which grant the right to implement the spec to independent implementors and not required for the runtime use. In case of jsr107 we are subjecting cache-api bytecode to this "specification license" and unfortunately it is extremely hard (if not impossible) to find the angle to interpret it as a permission to use. What are the challenges to change the license to apache 2.0 or alike? Thank you

cruftex commented 8 years ago

@gregrluck:

You can read about the legal implications at the apache legal FAQ. Compatible open source licenses required for components are listed here: http://www.apache.org/legal/resolved.html#category-a

GPL or CDDL is more complicated and also evaluated.

You cannot include a non open source license. The FAQ says:

CAN APACHE PROJECTS RELY ON COMPONENTS UNDER PROHIBITED LICENSES? Apache projects cannot distribute any such components. As with the previous question on platforms, the component can be relied on if the component's licence terms do not affect the Apache product's licensing. For example, using a GPL'ed tool during the build is OK.

So if someone build a product with hazelcast and ships it to a customer, it will probably include the JCache API. Of course, that customer needs to check and accept the JCP licence. That's a showstopper.

Inclusion in the Java EE API woulnd't work either, as stated above that is GPL and CDDL.

Options:

  1. Release under Apache license
  2. Release under CDDL or GPL. => If EE stays with CDDL&GPL it can go in directly to EE, Apache projects cannot use it.
  3. Keep it like that. => Nobody can use it.

Of course there are standards opting for 2 or 3. In this case the Apache world does a clean room reimplementation of the API. That also already happened for the JCache API: http://mvnrepository.com/artifact/org.apache.geronimo.specs/geronimo-jcache_1.0_spec/1.0-alpha-1

Every apache licensed product needs to switch to the apache licensed API jar.

If this happens, that is a major set back for the standard. Simple question: How do we check the compatibility?

gregrluck commented 8 years ago

I will get our General Counsel to check into this.

Regards

Greg Luck

web: http://gregluck.com http://gregluck.com/ skype: gregrluck mobile US: +1 650 924 6244 mobile Australia: +61 408 061 622

On 1 Mar 2016, at 10:52 PM, Jens Wilke notifications@github.com wrote:

view it on GitHub https://github.com/jsr107/jsr107spec/issues/333#issuecomment-191096820

gregrluck commented 8 years ago

BTW the spec is here: https://docs.google.com/document/d/14BvLUyv5U3zhsbIGwA4hkLfFieBkaCPfaHazh_yQGSY/edit

brianoliver commented 8 years ago

Morning / Evening / Afternoon All,

Ultimately this is a question for Legal and it’s not something we can really decide. While we can certainly ask questions and make recommendations, none of us really have the authority to make the change without approval (from Oracle is my guess).

Personally speaking, I honestly believe we simply made a mistake when we made the initial release not to include the usual license, which by Java EE/ JCP terms is traditionally CDDL + GPL v2 (with Class Path Exception). As I understand it, these are compatible with Apache 2.0, but then again, I’m not a lawyer. I do know that the opposite is not always true which means releasing JCache under Apache 2.0 is extremely unlikely as it causes incompatibility with the rest of Java (hence why the Java platform avoids it).

So if someone build a product with hazelcast and ships it to a customer, it will probably include the JCache API. Of course, that customer needs to check and accept the JCP licence. That's a showstopper.

This is in no way something new or a show stopper. Architects of products that embeds any other product must always be aware of the issues regarding license compatibility and re-distribution. Failure to understand this is not a licensing problem, but an architecture problem. I agree that the current license for JCache needs resolving, but we shouldn’t make this out to be something bigger than it is.
Release under CDDL or GPL. => If EE stays with CDDL&GPL it can go in directly to EE, Apache projects cannot use it.

Personally I don’t think that is true. Look at all of the Apache projects that use / implement Java EE APIs, especially those licensed under CDDL / GPL v2 (WCPE). eg: Ever heard of Tomcat? Surely Tomcat wouldn’t work if it couldn’t implement the servlet, jndi, java server pages et al specs!

While we can debate this endlessly here, the only solution is legal counsel. In this case there’s two areas for counsel. Greg needs his own (as he’s a copyright owner) and Oracle needs their own (also a copyright owner).

Greg has started the conversation with his external counsel. I’ve started the conversation with Oracle Legal. Fortunately Oracle Legal is usually pretty quick to respond, so I’ll update everyone when I know something.

Sorry I don’t have a better answer, but I’m guessing CDDL + GPLv2 (like all other Java EE APIs) will be the quickest / easiest path.

— Brian

On Mar 2, 2016, at 1:52 AM, Jens Wilke notifications@github.com wrote:

@gregrluck https://github.com/gregrluck:

You can read about the legal implications at the apache legal FAQ. Compatible open source licenses required for components are listed here: http://www.apache.org/legal/resolved.html#category-a http://www.apache.org/legal/resolved.html#category-a GPL or CDDL is more complicated and also evaluated.

You cannot include a non open source license. The FAQ says:

CAN APACHE PROJECTS RELY ON COMPONENTS UNDER PROHIBITED LICENSES? Apache projects cannot distribute any such components. As with the previous question on platforms, the component can be relied on if the component's licence terms do not affect the Apache product's licensing. For example, using a GPL'ed tool during the build is OK.

So if someone build a product with hazelcast and ships it to a customer, it will probably include the JCache API. Of course, that customer needs to check and accept the JCP licence. That's a showstopper.

Inclusion in the Java EE API woulnd't work either, as stated above that is GPL and CDDL.

Options:

Release under Apache license

Release under CDDL or GPL. => If EE stays with CDDL&GPL it can go in directly to EE, Apache projects cannot use it.

Keep it like that. => Nobody can use it.

Of course there are standards opting for 2 or 3. In this case the Apache world does a clean room reimplementation of the API. That also already happened for the JCache API: http://mvnrepository.com/artifact/org.apache.geronimo.specs/geronimo-jcache_1.0_spec/1.0-alpha-1 http://mvnrepository.com/artifact/org.apache.geronimo.specs/geronimo-jcache_1.0_spec/1.0-alpha-1 Every apache licensed product needs to switch to the apache licensed API jar.

If this happens, that is a major set back for the standard. Simple question: How do we check the compatibility?

— Reply to this email directly or view it on GitHub https://github.com/jsr107/jsr107spec/issues/333#issuecomment-191096820.

philwo commented 8 years ago

@brianoliver If the JCache API code could be licensed under the "CDDL + GPL v2 (with Class Path Exception)", that would be totally fine with us and would make it usable for our open-source project.

Thanks so much for looking into this!

cruftex commented 8 years ago

@brianoliver Thanks, for digging into this!

Ever heard of Tomcat? Surely Tomcat wouldn’t work if it couldn’t implement the servlet, jndi, java server pages et al specs!

Apache Tomcat ships with a servlet-api.jar and a jsp-api.jar, which is Apache licensed. Just checked. So I expect everything of the Tomcat download is correctly Apache licensed.

In the comment above, I mentioned TomEE since this is relevant for JCache and the EE integration and I double checked with a TomEE contributor as well before commenting.

I understand Oracles intentions for CDDL + GPLv2, that, we won't resolve here.

Then, for compatibility testing this means we need to allow different API implementations. The Apache world will use a reimplementation of the API, not the original one.

cruftex commented 8 years ago

Apache Tomcat ships with a servlet-api.jar and a jsp-api.jar, which is Apache licensed. Just checked. So I expect everything of the Tomcat download is correctly Apache licensed.

Ha! I was wrong, since I didn't scroll down in the license file (license ignorant user errror....)

So, checking apache-tomcat-8.0.32:

The license file of the servlet-api.jar contains both the Apache and the CDDL. There are contents in the Jar, e.g. javaee_web_services_1_2.xsd which have the GPL+CDDL header.

The final Tomcat license explicitly lists components (the XSDs) covered by the CDDL as follows:

APACHE TOMCAT SUBCOMPONENTS:

Apache Tomcat includes a number of subcomponents with separate copyright notices
and license terms. Your use of these subcomponents is subject to the terms and  
conditions of the following licenses.

For the following XML Schemas for Java EE Deployment Descriptors:  
 - javaee_5.xsd
 - javaee_web_services_1_2.xsd
 - javaee_web_services_client_1_2.xsd
 - javaee_6.xsd
 - javaee_web_services_1_3.xsd
 - javaee_web_services_client_1_3.xsd
 - jsp_2_2.xsd
 - web-app_3_0.xsd
 - web-common_3_0.xsd
 - web-fragment_3_0.xsd
 - javaee_7.xsd
 - javaee_web_services_1_4.xsd
 - javaee_web_services_client_1_4.xsd
 - jsp_2_3.xsd
 - web-app_3_1.xsd
 - web-common_3_1.xsd
 - web-fragment_3_1.xsd

COMMON DEVELOPMENT AND DISTRIBUTION LICENSE (CDDL) Version 1.0

1. Definitions.
. . . (rest of CDDL)

Speculative: Maybe the decision is that CDDL based schemas don't have any effect on the build applications.

brianoliver commented 8 years ago

Quick update.

I’ve requested permission from Oracle Legal / Licensing et al to simply include and re-release JCache using the standard Java EE / Platform licenses (CDDL + GPLv2 wcpe). I’m assuming this will be approved on the Oracle side of things fairly quickly as this is what was originally approved and required, but simply we made a mistake. I’m also assuming Greg’s Legal Counsel will also approve this, so we should be good.

I say should as you never know with lawyers.

— Brian

On Mar 9, 2016, at 8:48 PM, Brian Oliver brian.oliver@oracle.com wrote:

Morning / Evening / Afternoon All,

Ultimately this is a question for Legal and it’s not something we can really decide. While we can certainly ask questions and make recommendations, none of us really have the authority to make the change without approval (from Oracle is my guess).

Personally speaking, I honestly believe we simply made a mistake when we made the initial release not to include the usual license, which by Java EE/ JCP terms is traditionally CDDL + GPL v2 (with Class Path Exception). As I understand it, these are compatible with Apache 2.0, but then again, I’m not a lawyer. I do know that the opposite is not always true which means releasing JCache under Apache 2.0 is extremely unlikely as it causes incompatibility with the rest of Java (hence why the Java platform avoids it).

So if someone build a product with hazelcast and ships it to a customer, it will probably include the JCache API. Of course, that customer needs to check and accept the JCP licence. That's a showstopper.

This is in no way something new or a show stopper. Architects of products that embeds any other product must always be aware of the issues regarding license compatibility and re-distribution. Failure to understand this is not a licensing problem, but an architecture problem. I agree that the current license for JCache needs resolving, but we shouldn’t make this out to be something bigger than it is.
Release under CDDL or GPL. => If EE stays with CDDL&GPL it can go in directly to EE, Apache projects cannot use it.

Personally I don’t think that is true. Look at all of the Apache projects that use / implement Java EE APIs, especially those licensed under CDDL / GPL v2 (WCPE). eg: Ever heard of Tomcat? Surely Tomcat wouldn’t work if it couldn’t implement the servlet, jndi, java server pages et al specs!

While we can debate this endlessly here, the only solution is legal counsel. In this case there’s two areas for counsel. Greg needs his own (as he’s a copyright owner) and Oracle needs their own (also a copyright owner).

Greg has started the conversation with his external counsel. I’ve started the conversation with Oracle Legal. Fortunately Oracle Legal is usually pretty quick to respond, so I’ll update everyone when I know something.

Sorry I don’t have a better answer, but I’m guessing CDDL + GPLv2 (like all other Java EE APIs) will be the quickest / easiest path.

— Brian

On Mar 2, 2016, at 1:52 AM, Jens Wilke <notifications@github.com mailto:notifications@github.com> wrote:

@gregrluck https://github.com/gregrluck:

You can read about the legal implications at the apache legal FAQ. Compatible open source licenses required for components are listed here: http://www.apache.org/legal/resolved.html#category-a http://www.apache.org/legal/resolved.html#category-a GPL or CDDL is more complicated and also evaluated.

You cannot include a non open source license. The FAQ says:

CAN APACHE PROJECTS RELY ON COMPONENTS UNDER PROHIBITED LICENSES? Apache projects cannot distribute any such components. As with the previous question on platforms, the component can be relied on if the component's licence terms do not affect the Apache product's licensing. For example, using a GPL'ed tool during the build is OK.

So if someone build a product with hazelcast and ships it to a customer, it will probably include the JCache API. Of course, that customer needs to check and accept the JCP licence. That's a showstopper.

Inclusion in the Java EE API woulnd't work either, as stated above that is GPL and CDDL.

Options:

Release under Apache license

Release under CDDL or GPL. => If EE stays with CDDL&GPL it can go in directly to EE, Apache projects cannot use it.

Keep it like that. => Nobody can use it.

Of course there are standards opting for 2 or 3. In this case the Apache world does a clean room reimplementation of the API. That also already happened for the JCache API: http://mvnrepository.com/artifact/org.apache.geronimo.specs/geronimo-jcache_1.0_spec/1.0-alpha-1 http://mvnrepository.com/artifact/org.apache.geronimo.specs/geronimo-jcache_1.0_spec/1.0-alpha-1 Every apache licensed product needs to switch to the apache licensed API jar.

If this happens, that is a major set back for the standard. Simple question: How do we check the compatibility?

— Reply to this email directly or view it on GitHub https://github.com/jsr107/jsr107spec/issues/333#issuecomment-191096820.

gregrluck commented 8 years ago

At Brian's suggestion I analysed JPA.

If you go to the spec you get: http://download.oracle.com/otndocs/jcp/persistence-2_1-fr-spec/index.html Software License Agreement

If you go to the javadoc you get: https://docs.oracle.com/javaee/7/api/doc-files/speclicense.html

Both are the same as our spec license. i.e. not CDDL or GPLv2cpe but the JCP license.

Now when I check the source code I see the CDDL. See http://grepcode.com/file/repo1.maven.org/maven2/javax.persistence/persistence-api/1.0/javax/persistence/Persistence.java

/ 2 * The contents of this file are subject to the terms 3 * of the Common Development and Distribution License 4 * (the License). You may not use this file except in 5 * compliance with the License. 6 * 7 * You can obtain a copy of the license at 8 * https://glassfish.dev.java.net/public/CDDLv1.0.html or 9 * glassfish/bootstrap/legal/CDDLv1.0.txt. 10 * See the License for the specific language governing 11 * permissions and limitations under the License. 12 * 13 * When distributing Covered Code, include this CDDL 14 * Header Notice in each file and include the License file 15 * at glassfish/bootstrap/legal/CDDLv1.0.txt.
16 * If applicable, add the following below the CDDL Header, 17 * with the fields enclosed by brackets [] replaced by 18 * you own identifying information: 19 * "Portions Copyrighted [year] [name of copyright owner]" 20 * 21 * Copyright 2006 Sun Microsystems, Inc. All rights reserved. 22 /

philwo commented 8 years ago

@gregrluck Just FYI, the specification you linked is version 2.1, but the code you linked is version 1.0, if I understand it correctly.

Version 1.0 (linked in your post) has the CDDL only header, however this seems to have been fixed in version 1.0-rev1 and 1.0.2, as they have the more common CDDL + GPLv2-with-classpath-exception header: http://grepcode.com/file/repo1.maven.org/maven2/javax.persistence/persistence-api/1.0.2/javax/persistence/Persistence.java?av=f

Java Persistence 2.0 and higher seem to be licensed under the Eclipse Public License: https://github.com/eclipse/javax.persistence/blob/master/src/javax/persistence/Persistence.java

As said, CDDL+GPLv2-with-classpath-exception or any other usual Open-Source license would be fine for us :) Thanks again so much for looking into this!

keilw commented 8 years ago

"Initially" for JSR 107 was ages ago. I know, because we were told by then Sun for JSR 275 to use the Spec License for at least the API, too. 107 started even before JSR 108, the first Unit-related JSR and precursor to 277 (and later 363). We addressed this issue with the PR of JSR 363 but that's not final yet, so it was easier to change than for a Final JSR.

brianoliver commented 8 years ago

Morning, Afternoon, Evening All,

Just a quick update on the licensing issue.

I’ve been in contact with Oracle Legal to confirm that we’re good to move forward with a re-release with the correct / previously approved licenses applied.

As we’re not re-licensing, just correcting the missing license(s), I expect there will be no issues…. but then again, I’m not a lawyer.

There’s a chance we’ll also have to inform Oracle Export and Compliance (yes it’s a thing) to ensure everything is ok according to US/EU Export Regulations, but again, that should be ok.

I’ll update everyone when I know more.

Cheers

— Brian

On Mar 18, 2016, at 10:28 AM, Philipp Wollermann notifications@github.com wrote:

@gregrluck https://github.com/gregrluck Just FYI, the specification you linked is version 2.1, but the code you linked is version 1.0, if I understand it correctly.

Version 1.0 (linked in your post) has the CDDL only header, however this seems to have been fixed in version 1.0-rev1 and 1.0.2, as they have the more common CDDL + GPLv2-with-classpath-exception header: http://grepcode.com/file/repo1.maven.org/maven2/javax.persistence/persistence-api/1.0.2/javax/persistence/Persistence.java?av=f http://grepcode.com/file/repo1.maven.org/maven2/javax.persistence/persistence-api/1.0.2/javax/persistence/Persistence.java?av=f Java Persistence 2.0 and higher seem to be licensed under the Eclipse Public License: https://github.com/eclipse/javax.persistence/blob/master/src/javax/persistence/Persistence.java https://github.com/eclipse/javax.persistence/blob/master/src/javax/persistence/Persistence.java As said, CDDL+GPLv2-with-classpath-exception or any other usual Open-Source license would be fine for us :) Thanks again so much for looking into this!

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/jsr107/jsr107spec/issues/333#issuecomment-198385283

gregrluck commented 8 years ago

Ok. Have applied the following license header to the source code in accordance with Brian's suggestion. This is what Glassfish is currently doing. Should please everyone.

/*

keilw commented 8 years ago

Guess there will be either a MR or new JSR built on top of that soon? The likes of Apache or Eclipse should accept it that way similar to other EE JSRs.

philwo commented 8 years ago

Thank you very much, @gregrluck and @brianoliver!

brianoliver commented 8 years ago

Greg,

Please undo this. You do not have permission to re-license this without permission from Oracle.

As discussed many times, we are currently waiting for permission from Oracle Legal, which are this point is in progress.

Oracle may choose to license this under a different license, something more pervasive than CDDL, which would be of greater benefit to the community.

I neither provided permission or have permission to provide such permission.

— Brian

keilw commented 8 years ago

Still not done?;-O At least Eclipse Foundation is still chewing on the header change of JSR 363, so take your time. What about the TCK btw? There it says Apache in the files/headers but the jcp.org page says otherwise.

brianoliver commented 8 years ago

Oh how I wish it was done!

Does anyone have some magical device to make these things easier, faster and less painful?

Anyone? Anyone? Pretty please?

RE: TCK. It's Apache 2.0 licensed. The JCP page is incorrect (unless I get corrected by someone more correct than myself)

On May 17, 2016, at 11:12 AM, Werner Keil notifications@github.com wrote:

Still not done?;-O At least Eclipse Foundation is still chewing on the header change of JSR 363, so take your time. What about the TCK btw? There it says Apache in the files/headers but the jcp.org page says otherwise.

— You are receiving this because you modified the open/close state. Reply to this email directly or view it on GitHub https://github.com/jsr107/jsr107spec/issues/333#issuecomment-219749421

keilw commented 8 years ago

The only thing I know (that especially JSR 363 or 375 already use) are Maven plugins checking license headers and failing the build if an old/wrong was found, but I'm afraid that won't help you with the lawyers ;-) Did you try asking PMO (Heather/Harold,...) about the update of the jcp.org detail page. If the 1.0 TCK was at least "also" or even entirely licensed under Apache 2 (which many in the Community would highly appreciate) then it should be fixed on jcp.org not here.

brianoliver commented 8 years ago

PMO has been notified. I'll try again.

gregrluck commented 8 years ago

Brian

This is a commit in anticipation of the long coming Oracle approval.

Eventually we need to make a software release. So this and many other changes I am making.

Does this have any practical effect until we actually release 1.1? There is no maven jar someone can use.

Regards

Greg Luck

web: http://gregluck.com http://gregluck.com/ skype: gregrluck mobile US: +1 650 924 6244 mobile Australia: +61 408 061 622

On 17 May 2016, at 5:59 PM, Brian Oliver notifications@github.com wrote:

Greg,

Please undo this. You do not have permission to re-license this without permission from Oracle.

As discussed many times, we are currently waiting for permission from Oracle Legal, which are this point is in progress.

Oracle may choose to license this under a different license, something more pervasive than CDDL, which would be of greater benefit to the community.

I neither provided permission or have permission to provide such permission.

— Brian

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/jsr107/jsr107spec/issues/333#issuecomment-219745234

cruftex commented 8 years ago

Does this have any practical effect until we actually release 1.1? There is no maven jar someone can use.

Legally yes! The applicable license is the one in the source. I can just grab it and release it.

brianoliver commented 8 years ago

After being dragged across the coals, Oracle Legal has instructed me to revert license until an approved license is issued.

gregrluck commented 8 years ago

Talked to Brian about this Thursday. He has applied for the licenses at Oracle. We will keep going on the 1.1 release. If Oracle Legal is done before we release we will include the relicense. If not, we will release 1.1 without this fixed and then do a 1.1.1 as soon as the license gets approved.

philwo commented 8 years ago

@gregrluck @brianoliver Thank you very much for your work on this and posting updates.

philwo commented 7 years ago

Friendly ping - do you happen to have any news on this?

gregrluck commented 7 years ago

Spoke to Brian last week. Says Oracle lawyer are working on it. I am not foreseeing any problems but delay.

brianoliver commented 7 years ago

A quick update.

Currently there are two views on this, which I'm trying to confirm with lawyers, JCP et al.

  1. It's already licensed as Apache 2.0, because that's what the RI is licensed as and it naturally follows that everything else, except the SPEC, JAVADOC and TCK are licensed in the same manner.
  2. It's licensed as Apache 2.0, but was never approved as such, with thus needs to happen.

I'm hoping it's the first one, in which case we can just update the licenses and re-release. Alternatively it's the second, in which case I've got to nurse it through the necessary legal approval process.

Worse case it's something else all together.

gregrluck commented 7 years ago

Good one Brian.

Well I got a lot done on the weekend and want to have everything ready for as soon as you know.

I guess this also means we will be most likely using the Apache 2 license when re relicense?

Regards

Greg Luck

web: http://gregluck.com http://gregluck.com/ skype: gregrluck mobile US: +1 650 924 6244 mobile Australia: +61 408 061 622

On 3 Oct. 2016, at 9:54 am, Brian Oliver notifications@github.com wrote:

A quick update.

Currently there are two views on this, which I'm trying to confirm with lawyers, JCP et al.

It's already licensed as Apache 2.0, because that's what the RI is licensed as and it naturally follows that everything else, except the SPEC, JAVADOC and TCK are licensed in the same manner.

It's licensed as Apache 2.0, but was never approved as such, with thus needs to happen.

I'm hoping it's the first one, in which case we can just update the licenses and re-release. Alternatively it's the second, in which case I've got to nurse it through the necessary legal approval process.

Worse case it's something else all together.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jsr107/jsr107spec/issues/333#issuecomment-251128561, or mute the thread https://github.com/notifications/unsubscribe-auth/AANyhIzFMC5CyohRFd_xqyQ2nnMl_5cDks5qwRc5gaJpZM4HS1XL.

brianoliver commented 7 years ago

We've now had clarification that the API is meant to be licensed under Apache 2.0, just as the Reference Implementation is. I'm now in the process of updating the licenses and we'll release with the correct license as part of the 1.1 maintenance release.

Thanks for the patience in resolving this. It's taken a lot of time, but I think the outcome is pretty good for everyone.

ekaganovich commented 7 years ago

This is great news. Thanks Brian!

On Oct 14, 2016, at 9:16 AM, Brian Oliver notifications@github.com wrote:

We've now had clarification that the API is meant to be licensed under Apache 2.0, just as the Reference Implementation is. I'm now in the process of updating the licenses and we'll release with the correct license as part of the 1.1 maintenance release.

Thanks for the patience in resolving this. It's taken a lot of time, but I think the outcome is pretty good for everyone.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

brianoliver commented 7 years ago

Done!

keilw commented 7 years ago

Good to see some progress on that. Also if Apache 2.0 is acceptable for API, RI and TCK of a JSR Oracle is involved in (and started) this sounds like a ray of hope something similar could also work for at least new upcoming JSRs, especially config. Given almost every major framework and library out there (Apache Commons, Tamaya, Spring, Typesafe,...) some of them could also act as RI use Apache 2.0 as well.

keilw commented 7 years ago

Guess we can expect an official MR (either 1.0,1 or 1.1) published to https://jcp.org/en/jsr/detail?id=107 soon, too.

keilw commented 7 years ago

Or rather offered to the EC for confirmation Ballot first.

brianoliver commented 7 years ago

Greg and I are planning on having all of the license issues resolved in the next MR (1.1 is our goal).

The licenses will be (now approved) API = Apache 2.0 RI = Apache 2.0 TCK = SATCK (Standalone TCK) license (at zero cost).

I've raised an issue on the TCK project to resolve that license issue (it wasn't approved to be Apache) and there are apparently contractual agreements that it should be SATCK. Fortunately it will be available for free under the standard TCK license.

If we need to change the TCK to something else, we can start the process to do that, but first we need to get everything in compliance with want was approved and contractually agreed between the various companies that own copyright. Oh the fun!

gregrluck commented 7 years ago

The license header for the spec, which is supposed to be Apache 2, per the above discussion, is actually showing as:

/**
 *  Copyright (c) 2011-2013 Terracotta, Inc.
 *  Copyright (c) 2011-2013 Oracle and/or its affiliates.
 *
 *  All rights reserved. Use is subject to license terms.
 */

I guess the "license" in this statement refers to LICENSE.txt which is the fully stated Apache 2 license.

However normal open source practice is for each source code header to include the license. e.g the RI header used for each source code file is as shown below:

/**
 *  Copyright 2011-2013 Terracotta, Inc.
 *  Copyright 2011-2013 Oracle America Incorporated
 *
 *  Licensed under the Apache License, Version 2.0 (the "License");
 *  you may not use this file except in compliance with the License.
 *  You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 *  Unless required by applicable law or agreed to in writing, software
 *  distributed under the License is distributed on an "AS IS" BASIS,
 *  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 *  See the License for the specific language governing permissions and
 *  limitations under the License.
 */

Moreover the Apache Software Foundation says that this SHOULD be done. See http://www.apache.org/legal/src-headers.html#headers