OpenJ9 license


Dennis Clark
 

Hi SPDX Legal Team,

With all the excitement (depending on your point of view, of course) about the latest OpenJ9 announcements, I went over to check it out on github, and discovered a very interesting notice at

https://github.com/eclipse/openj9/blob/master/LICENSE

The interesting part being this:  "SPDX-License-Identifier: EPL-2.0 OR Apache-2.0"   followed by further useful details. 

i guess we really ought to try to get moving on EPL-2.0 whenever we can.

Regards,
Dennis Clark
nexB Inc.


Wayne Beaton
 

The Eclipse Foundation is trying to weave SPDX into our processes. 

This is a new project that needed to hit the ground running and we really wanted to include an SPDX entry in the header. I figured that if I didn't include it in the initial commit, then it'd be a fight later to get the project team to add it.

I guessed that "EPL-2.0" would be a safe best-guess.

FWIW, "EPL-2.0" is actually not entirely correct for this project; this project uses our Secondary Licenses feature to add compatibility with GPL-2.0 + classpath exception + assembly exception. I figured getting even just the base SPDX code was better than nothing (I was less confident guessing at how you're going to represent the secondary licenses).

Wayne

On Tue, Sep 19, 2017 at 2:38 PM, Dennis Clark <dmclark@...> wrote:
Hi SPDX Legal Team,

With all the excitement (depending on your point of view, of course) about the latest OpenJ9 announcements, I went over to check it out on github, and discovered a very interesting notice at

https://github.com/eclipse/openj9/blob/master/LICENSE

The interesting part being this:  "SPDX-License-Identifier: EPL-2.0 OR Apache-2.0"   followed by further useful details. 

i guess we really ought to try to get moving on EPL-2.0 whenever we can.

Regards,
Dennis Clark
nexB Inc.

_______________________________________________
Spdx-legal mailing list
Spdx-legal@...
https://lists.spdx.org/mailman/listinfo/spdx-legal




--
Wayne Beaton
Director of Open Source Projects
The Eclipse Foundation


J Lovejoy
 

Thanks Wayne - this is great to hear!

As per our general pattern and guidelines for short identifiers, you are correct that the short identifiers will be/is: EPL-2.0

As to the Secondary License issue - I suspect we need to think on that, especially as it looks like some text may have changed since the last email thread on this.  I’ll will make sure this gets bumped to the top of the agenda list!

Thanks,
Jilayne

SPDX Legal Team co-lead
opensource@...


On Sep 19, 2017, at 1:29 PM, Wayne Beaton <wayne.beaton@...> wrote:

The Eclipse Foundation is trying to weave SPDX into our processes. 

This is a new project that needed to hit the ground running and we really wanted to include an SPDX entry in the header. I figured that if I didn't include it in the initial commit, then it'd be a fight later to get the project team to add it.

I guessed that "EPL-2.0" would be a safe best-guess.

FWIW, "EPL-2.0" is actually not entirely correct for this project; this project uses our Secondary Licenses feature to add compatibility with GPL-2.0 + classpath exception + assembly exception. I figured getting even just the base SPDX code was better than nothing (I was less confident guessing at how you're going to represent the secondary licenses).

Wayne

On Tue, Sep 19, 2017 at 2:38 PM, Dennis Clark <dmclark@...> wrote:
Hi SPDX Legal Team,

With all the excitement (depending on your point of view, of course) about the latest OpenJ9 announcements, I went over to check it out on github, and discovered a very interesting notice at

https://github.com/eclipse/openj9/blob/master/LICENSE

The interesting part being this:  "SPDX-License-Identifier: EPL-2.0 OR Apache-2.0"   followed by further useful details. 

i guess we really ought to try to get moving on EPL-2.0 whenever we can.

Regards,
Dennis Clark
nexB Inc.

_______________________________________________
Spdx-legal mailing list
Spdx-legal@...
https://lists.spdx.org/mailman/listinfo/spdx-legal




--
Wayne Beaton
Director of Open Source Projects
The Eclipse Foundation
_______________________________________________
Spdx-legal mailing list
Spdx-legal@...
https://lists.spdx.org/mailman/listinfo/spdx-legal


J Lovejoy
 

Hi Wayne,

Just found this after sending last message.

I believe you noted that the “assembly exception” was not on the SPDX License List.  Sounds like we should add this.

I’m not sure if it needs to be added alone or if the combination with the class path exception is such that they are used together and so we ought to treat it as one exception.  but that is another consideration (which someone else already noticed)

Sorry to be so slow to catch up - lots going on with SPDX these days and open source licenses!

Thanks,
Jilayne

SPDX Legal Team co-lead
opensource@...


On Sep 19, 2017, at 1:29 PM, Wayne Beaton <wayne.beaton@...> wrote:

The Eclipse Foundation is trying to weave SPDX into our processes. 

This is a new project that needed to hit the ground running and we really wanted to include an SPDX entry in the header. I figured that if I didn't include it in the initial commit, then it'd be a fight later to get the project team to add it.

I guessed that "EPL-2.0" would be a safe best-guess.

FWIW, "EPL-2.0" is actually not entirely correct for this project; this project uses our Secondary Licenses feature to add compatibility with GPL-2.0 + classpath exception + assembly exception. I figured getting even just the base SPDX code was better than nothing (I was less confident guessing at how you're going to represent the secondary licenses).

Wayne

On Tue, Sep 19, 2017 at 2:38 PM, Dennis Clark <dmclark@...> wrote:
Hi SPDX Legal Team,

With all the excitement (depending on your point of view, of course) about the latest OpenJ9 announcements, I went over to check it out on github, and discovered a very interesting notice at

https://github.com/eclipse/openj9/blob/master/LICENSE

The interesting part being this:  "SPDX-License-Identifier: EPL-2.0 OR Apache-2.0"   followed by further useful details. 

i guess we really ought to try to get moving on EPL-2.0 whenever we can.

Regards,
Dennis Clark
nexB Inc.

_______________________________________________
Spdx-legal mailing list
Spdx-legal@...
https://lists.spdx.org/mailman/listinfo/spdx-legal




--
Wayne Beaton
Director of Open Source Projects
The Eclipse Foundation
_______________________________________________
Spdx-legal mailing list
Spdx-legal@...
https://lists.spdx.org/mailman/listinfo/spdx-legal


Philippe Ombredanne
 

On Mon, Oct 2, 2017 at 12:50 PM, J Lovejoy <opensource@...> wrote:
I’m not sure if it needs to be added alone or if the combination with the
class path exception is such that they are used together and so we ought to
treat it as one exception. but that is another consideration (which someone
else already noticed)
Jilayne:

Here are my 2 cents:

- the text of the “assembly exception” is specific to the OpenJDK and
derivatives: this code is used widely but there are very few projects
that can use this licensing because of its specificity.

- the “assembly exception” text and the designated modules list refers
to the classpath exception and I do not know of any case of "assembly
exception" texts and designated modules list used without a reference
to the classpath exception so far.

- Wayne suggested to introduce a new "with assembly with classpath"
expression syntax to deal with the “assembly exception” and "classpath
exception" cases.

Instead, the way I am handling this for now to detect licensing
properly in ScanCode is with a new "openjdk-exception" key that has
the combined text of the classpath-exception-2.0 and the "assembly
exception"

The benefits are that there is no need to deal with any new "with
with" expression syntax and I think it captures well the cases where
the classpath exception is used alone or used with the assembly
exception (e.g. as "openjdk-exception") and this avoids to create a
special case for this.

--
Cordially
Philippe Ombredanne


J Lovejoy
 

Thanks Philippe - that was my understanding from reading the previous thread, but I wanted to be sure.

and yes, I agree - one exception to deal with this seems the best way to go, especially if the “assembly exception” is not used by itself. I also agree having multiple “with” operators could get really confusing and I don’t see a need for that generally. I don’t think we want to alter the license expression syntax for one-off cases.

Can you point to the text precisely so we can work on adding it?

Unless Wayne has any objection, I’m happy to put in a request to add it ;)

Cheers,
Jilayne

On Oct 2, 2017, at 2:15 PM, Philippe Ombredanne <pombredanne@...> wrote:

On Mon, Oct 2, 2017 at 12:50 PM, J Lovejoy <opensource@...> wrote:
I’m not sure if it needs to be added alone or if the combination with the
class path exception is such that they are used together and so we ought to
treat it as one exception. but that is another consideration (which someone
else already noticed)
Jilayne:

Here are my 2 cents:

- the text of the “assembly exception” is specific to the OpenJDK and
derivatives: this code is used widely but there are very few projects
that can use this licensing because of its specificity.

- the “assembly exception” text and the designated modules list refers
to the classpath exception and I do not know of any case of "assembly
exception" texts and designated modules list used without a reference
to the classpath exception so far.

- Wayne suggested to introduce a new "with assembly with classpath"
expression syntax to deal with the “assembly exception” and "classpath
exception" cases.

Instead, the way I am handling this for now to detect licensing
properly in ScanCode is with a new "openjdk-exception" key that has
the combined text of the classpath-exception-2.0 and the "assembly
exception"

The benefits are that there is no need to deal with any new "with
with" expression syntax and I think it captures well the cases where
the classpath exception is used alone or used with the assembly
exception (e.g. as "openjdk-exception") and this avoids to create a
special case for this.

--
Cordially
Philippe Ombredanne


Wayne Beaton
 

For entertainment purposes, here's what I'm currently using for a project.

(EPL-2.0 OR (LicenseRef-GPL-2.0-with-Assembly-exception OR GPL-2.0 with Classpath-exception-2.0)) OR Apache-2.0

I threw in the extra grouping because it felt like they needed to be together. I don't think that the grouping is meaningful in SPDX syntax.

I'm pretty sure that I got the LicenseRef right. I trust that somebody will let me know if otherwise.

Wayne

On Mon, Oct 2, 2017 at 4:26 PM, J Lovejoy <opensource@...> wrote:
Thanks Philippe - that was my understanding from reading the previous thread, but I wanted to be sure.

and yes, I agree - one exception to deal with this seems the best way to go, especially if the “assembly exception” is not used by itself.  I also agree having multiple “with” operators could get really confusing and I don’t see a need for that generally. I don’t think we want to alter the license expression syntax for one-off cases.

Can you point to the text precisely so we can work on adding it?

Unless Wayne has any objection, I’m happy to put in a request to add it ;)

Cheers,
Jilayne


> On Oct 2, 2017, at 2:15 PM, Philippe Ombredanne <pombredanne@...> wrote:
>
> On Mon, Oct 2, 2017 at 12:50 PM, J Lovejoy <opensource@...> wrote:
>> I’m not sure if it needs to be added alone or if the combination with the
>> class path exception is such that they are used together and so we ought to
>> treat it as one exception.  but that is another consideration (which someone
>> else already noticed)
>
> Jilayne:
>
> Here are my 2 cents:
>
> - the text of the “assembly exception” is specific to the OpenJDK and
> derivatives: this code is used widely but there are very few projects
> that can use this licensing because of its specificity.
>
> - the “assembly exception” text and the designated modules list refers
> to the classpath exception and I do not know of any case of "assembly
> exception" texts and designated modules list used without a reference
> to the classpath exception so far.
>
> - Wayne suggested to introduce a new "with assembly with classpath"
> expression syntax to deal with the “assembly exception” and "classpath
> exception" cases.
>
> Instead, the way I am handling this for now to detect licensing
> properly in ScanCode is with a new "openjdk-exception" key that has
> the combined text of the classpath-exception-2.0 and the "assembly
> exception"
>
> The benefits are that there is no need to deal with any new "with
> with" expression syntax and I think it captures well the cases where
> the classpath exception is used alone or used with the assembly
> exception (e.g. as "openjdk-exception") and this avoids to create a
> special case for this.
>
> --
> Cordially
> Philippe Ombredanne




--
Wayne Beaton
Director of Open Source Projects
The Eclipse Foundation


Philippe Ombredanne
 

On Thu, Oct 12, 2017 at 11:32 AM, Wayne Beaton
<wayne.beaton@...> wrote:
My understanding is that the Secondary Licensing provision in the EPL-2.0 is
not the same as dual licensing using an OR. From our FAQ (which we're still
working on):

The notion of Secondary Licenses is intended to permit combining content
licensed under the EPL-2.0 with an otherwise incompatible license,
specifically the GNU General Public License, v2.0 or greater. This means
that the content that includes a Secondary License clause may be combined
with content distributed under the terms of that Secondary License, and the
combined content can be then be collectively distributed under the terms of
that Secondary License.
Further,

Is EPL-2.0 with the Secondary License clause considered dual licensing?
It is extremely close to dual licensing. The EPL-2.0 is the only license,
until such time as it is combined and distributed with a work under the
Secondary License. After such time, any recipient of the combined work can
consider the content licensed under the Secondary License. The original work
remains under the EPL-2.0 and is never really dual-licensed. Once a
downstream adopter has received the content under the Secondary License,
they can modify and further distribute it solely under the terms of the
Secondary License.
Does this help?

I hope to make our FAQ public later today or earlier tomorrow. That may
provide further context.
Wayne:
This helps a lot to better understand the EPL terms.

My understanding:

I cannot use EPL 2.0-licensed code under a Secondary license
unless I combine it with some other code using that Secondary license.
And only its is only when I combine that the Secondary license terms may
apply to the combo. Otherwise, only the the EPL-2.0 applies.

My take is that a license expression can never replace nor capture all
the specific
details of licensing. This what the license texts are for. The license
expression is
just a concise, imperfect but mightily handy summary of the licensing.

Therefore, even though this may not be it exactly, I still think we
can use existing
license expressions OR constructs for this case and with no change needed.

An expression such as EPL-2.0 OR GPL-2.0 is enough to tell me there is some
choice. Then when I read the actual text and notice, I get the details
and specific
terms. If I elect the GPL-2.0 choice without reading the licensing
first then I am
foolish at best. We cannot prevent foolishness. If I build a tool that automates
such a choice, I can easily have a special case where the EPL-2.0 shows up
as a choice with another license and process this as a special case.

Be it here or in the much-talked-about case of FSF or-later-or-only-or-may-be
licensing nuances, an expression can never entirely replace the actual
license texts
and notices. I think this is just fine this way: a name alone can
never capture nor
convey all the nuances and attributes of a thing.

--
Cordially
Philippe Ombredanne