-
Notifications
You must be signed in to change notification settings - Fork 278
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
Conversation
There was a problem hiding this 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
There was a problem hiding this 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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
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.
@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. |
On Tue, Dec 26, 2017 at 01:41:25PM -0800, Jilayne Lovejoy wrote:
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?
I am in favor of versioning it somehow. If you want to start out with
a 2.0 verison because it's designed for GPL-2.0-only, that's fine with
me. If you decide to release a new exception also targetting
GPL-2.0-only, you'd have OpenJDK-Assembly-exception-2.1 or whatever,
and you can release an exception that targets the GPL-3.0, etc., etc.
I'm also ok with calling this OpenJDK-Assembly-exception-1.0 (for “the
first release of this exception”).
I'd rather avoid our current W3C situation (with W3C, W3C-19980720,
and W3C-20150513) by assuming “we'll never cut another version of
this” and skipping a version number.
|
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. |
This PR should probably be tagged as a “new license/exception request” by someone with write access to this repository. |
This PR should probably be milestoned 3.1 to match #567 (it's currently milestoned “Immediate Release - 3.0”), although:
|
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> |
There was a problem hiding this comment.
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
.
add text tag
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 | ||
<http://www.gnu.org/copyleft/gpl.html> version 2 only |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
closing this, as a new PR #625 was made with the correct files so that one will be merged |
Replacement for #551: New Exception: OpenJDK Assembly exception
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.