Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New Exception: OpenJDK Assembly exception #551

Closed
wants to merge 3 commits into from

Conversation

waynebeaton
Copy link
Contributor

At least two Eclipse projects use the Open JDK Assembly exception. I'd like to add it to the exception list.

I've labelled it 2.0 because it is an exception specifically to the GPL-2.0. I am hopeful that this was the right thing to do.

I'll address this to the SPDX legal mailing list.

Copy link
Member

@goneall goneall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks OK from a technical review

Copy link
Contributor

@wking wking left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there any source repositories that explicitly mention this exception? For example, this random Amber file only explicitly mentions Classpath-exception-2.0.


<list>
<item>
<p>Linking this OpenJDK Code statically or dynamically with
Copy link
Contributor

@wking wking Dec 26, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't looked at our existing exceptions for precedent here, but to me it feels like the text you've included in the <list> element is the legal text of the exception. The earlier “The OpenJDK source code made available…” paragraph sounds like part of a grant that associates the exception with a particular set of code (much like a GPL header at the beginning of a file associates the GPL license with the code in the file). The final “As such, it allows licensees and sublicensees…” seems like a combination of non-normative notes and a contributor license agreement.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Eclipse OMR and Eclipse OpenJ9 projects both use the OpenJDK assembly exception. I'm not happy with their LICENSE files and will get them to update them.

e.g.

https://github.com/eclipse/openj9/blob/master/jcl/src/openj9.dataaccess/share/classes/com/ibm/dataaccess/ByteArrayMarshaller.java

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://github.com/eclipse/openj9/blob/master/jcl/src/openj9.dataaccess/share/classes/com/ibm/dataaccess/ByteArrayMarshaller.java

The Eclipse OpenJ9 project seems to cover the grant association in their per-file header, which seems like it make's the “The OpenJDK source code made available…” paragraph superfluous for that file. And they cover the contributor license agreement section with an explicit CLA and sign-off requirement. So at least some parts of the upstream exception page seem redundant/misleading in that context. For OpenJ9 (which is not available under openjdk.java.net?), the exception seems to allow folks to link OpenJ9 against the designated exception modules, but it's the copyright holder (not always Oracle) granting the exception. A generic form of the exception would be closer to:

Linking this OpenJDK Code statically or dynamically with other code is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License http://www.gnu.org/copyleft/gpl.html version 2 only ("GPL2") cover the whole combination.

As a special exception, the copyright holders and contributors give you permission to link this OpenJDK Code with certain code as indicated at http://openjdk.java.net/legal/exception-modules-2007-05-08.html ("Designated Exception Modules") to produce an executable, regardless of the license terms of the Designated Exception Modules, and to copy and distribute the resulting executable under GPL2, provided that the Designated Exception Modules continue to be governed by the licenses under which they were offered by Oracle.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@waynebeaton - @wking has a good point: considering the inbound policy is DCO sign-off (not sure what the need for the ECA is on top of that, but that's another story), all contributors retain their copyright. Thus the exception shouldn't be specific to Oracle. I don't know the history here is and maybe it was appropriate at one time to only come from Oracle if they were the only copyright holder (I believe, they use an assignment agreement for contributions to their project, so this could have worked under that paradigm). But given the Eclipse Foundation licensing policy this exception may need to be updated.

@jlovejoy jlovejoy added this to the Immediate Release - 3.0 milestone Dec 26, 2017
@jlovejoy
Copy link
Member

@waynebeaton as for the numbering - I just had a review of all our existing exceptions: for the most part they have a number if the exception itself is versioned, or if there was more than one version of the exception and a number was needed to differentiate (even if the exception text didn't necessarily denote this). There are a couple that don't completely follow this pattern.
In this case, it doesn't seem like it really needs a number - there is only one version of this exception out there, is that correct?

@wking
Copy link
Contributor

wking commented Dec 26, 2017 via email

@waynebeaton
Copy link
Contributor Author

It does seem intuitive that having some sort of version number will help avoid confusion later.

Version 2.0 isn't confusing when it matches against GPL-2.0, but will become confusing when/if the exception is updated. e.g. what does it mean to have version 2.1 of the exception matched against the GPL-2.0?

I'm thinking that the version number should apply to the exception itself, and that we should make it 1.0.

@wking
Copy link
Contributor

wking commented Dec 27, 2017

This PR should probably be tagged as a “new license/exception request” by someone with write access to this repository.

@jlovejoy jlovejoy changed the title Add OpenJDK Assembly exception New Exception: OpenJDK Assembly exception Dec 27, 2017
@wking
Copy link
Contributor

wking commented Dec 27, 2017

This PR should probably be milestoned 3.1 to match #567 (it's currently milestoned “Immediate Release - 3.0”), although:

  • I'm not clear on why we need a separate issue at all. We could always open a new issue if/when someone decides to carry this PR, but as far as I can tell the current plan is to work on this PR until it's ready.

  • I'm not clear on why we're using 3.0 for the next release. I'd be fine with this landing in 3.0 if that happened to be a later release.

updating version numbering as per @waynebeaton comment. Removed space b/w Open and JDK - to reflect consistent naming
<crossRef>http://openjdk.java.net/legal/assembly-exception.html
</crossRef>
</crossRefs>
<titleText>OpenJDK Assembly Exception</titleText>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is <titleText> outside of <text>, which is why you're getting “This element is not expected”. You need to add wrapping <text> like 4af4402 did for LLVM-exception.

The OpenJDK source code made available by Oracle America, Inc.
(Oracle) at openjdk.java.net ("OpenJDK Code") is distributed
under the terms of the GNU General Public License
&lt;http://www.gnu.org/copyleft/gpl.html&gt; version 2 only
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps this link should be to (or at least allow) https://www.gnu.org/licenses/old-licenses/gpl-2.0.html? Currently https://www.gnu.org/copyleft/gpl.html has the v3 text, and you have to click through “Old versions of the GNU GPL” and “GNU General Public License, version 2” to get from there to the v2 text.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also allowing https as well would be nice (like we do in the GPL licenses themselves since #450).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@wking I like allowing http|https matches (let's encrypt! and all that), but that's broader than just this license. Let's open a separate issue for that.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like allowing http|https matches (let's encrypt! and all that), but that's broader than just this license. Let's open a separate issue for that.

With this sort of thing, I think the easiest approach is to gate-keep new submissions to hold the new standards while slowly chipping away at the existing instances. Landing new code that violates our intended approach just makes the existing issues more trouble to fix ;). This lets you solve the issues incrementally without having huge-change flag-days.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can see the case for that, but we don't want to hold up substantive additions to the license list while deciding. Also, if we want to systematically change this, there wouldn't appear to be much effort difference in (N licenses affected) vs. (N-1 licenses affected).

Set up in #633 to address systematically later.

@jlovejoy
Copy link
Member

jlovejoy commented Apr 5, 2018

closing this, as a new PR #625 was made with the correct files so that one will be merged

@jlovejoy jlovejoy closed this Apr 5, 2018
jlovejoy added a commit that referenced this pull request Apr 5, 2018
Replacement for #551: New Exception: OpenJDK Assembly exception
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants