Re: OpenJ9 license

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!


SPDX Legal Team co-lead

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).


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

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.

Dennis Clark
nexB Inc.

Spdx-legal mailing list

Wayne Beaton
Director of Open Source Projects
The Eclipse Foundation
Spdx-legal mailing list

Join { to automatically receive all group messages.