Spdx-legal@lists.spdx.org | OpenJ9 license

Home Messages Hashtags Subgroups

Date Date 1 - 8 of 8

OpenJ9 license

Philippe Ombredanne #2009 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
More All Messages By This Member
Wayne Beaton #1975 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 toggle quoted message Show quoted text 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
More All Messages By This Member
J Lovejoy #1969 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 toggle quoted message Show quoted text 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
More All Messages By This Member
Philippe Ombredanne #1968 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
More All Messages By This Member
J Lovejoy #1965 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@... toggle quoted message Show quoted text 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
More All Messages By This Member
J Lovejoy #1940 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@... toggle quoted message Show quoted text 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
More All Messages By This Member
Wayne Beaton #1939 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 toggle quoted message Show quoted text 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
More All Messages By This Member
Dennis Clark #1938 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.
More All Messages By This Member

1 - 8 of 8

1

Previous Topic Next Topic

Home Hashtags Subgroups Terms