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

Replacement for #551: New Exception: OpenJDK Assembly exception #625

Merged
merged 2 commits into from
Apr 5, 2018

Conversation

swinslow
Copy link
Member

This PR is meant to fix the build errors from #551. I'm submitting it as a separate PR solely because my Github skills aren't good enough for me to know how to add on to the existing PR at #551...

The content of the XML file for the OpenJDK assembly exception in this PR is identical to #551.
I've also made the following changes:

  • Changed the XML's filename to make "assembly" lowercase and to have version 1.0 in the filename, to mirror the licenseID in the XML.
  • Added a test file

<text>
<titleText>OpenJDK Assembly Exception</titleText>
<p>
The OpenJDK source code made available by Oracle America, Inc.
Copy link
Contributor

Choose a reason for hiding this comment

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

I still think that this text is closer to a grant than to exception text, with the exception text jusy being the “Linking this OpenJDK Code…” list item below. It sounded like @jlovejoy agreed, or at least felt that further discussion was warranted. Has that further discussion happened? Is the legal team on board with this text somehow being part of the exception and not part of the grant wording? Or do we have some other plan for resolving this issue?

Copy link
Contributor

@bradleeedmondson bradleeedmondson Apr 5, 2018

Choose a reason for hiding this comment

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

If by 'grant' you mean 'recommended license header', i.e. a shorter way for developers to adopt the license (useful prior to adopting SPDX identifiers in source), then I tend to agree. I will note that using 'grant' in this way tends to make lawyers' heads turn a bit, because we view the 'grant' as the legally operative language inside the license itself (e.g., "you are allowed to copy, distribute, modify, [etc.]"), and the header language as a sort of shorthand way (but still legally effective) to incorporate or adopt the full license text without reproducing it word-for-word.

The discussion on the legal call today was that whether the 'outer' text should have to be present for a match was an open question, but that we would do an initial merge now and resolve this question later.

Copy link
Member

Choose a reason for hiding this comment

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

we discussed whether to mark up the first and last paragraph as optional or not and went with leaving it as is for now - for the reasons of: it's easier to add markup later, rather than take it away and the text of the exception seems to only appear on that webpage (in other words, we did not see examples of just the middle two paragraphs in a license headers in source file, rather the license header refers to the webpage with the exception.
Btw, you keep referring to the "grant" in a way that is confusing: "grant" has legal meaning in that it is referring to the part of a license that grants rights to the licensee. The standard header or license notice (or various other names for the short-hand text that appears in actual source files, especially for longer licenses) is not a "grant" in the legal meaning of the word :)

Copy link
Contributor

Choose a reason for hiding this comment

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

Btw, you keep referring to the "grant" in a way that is confusing: "grant" has legal meaning in that it is referring to the part of a license that grants rights to the licensee. The standard header or license notice (or various other names for the short-hand text that appears in actual source files, especially for longer licenses) is not a "grant" in the legal meaning of the word :)

I don't mind “grant” meaning both a particular part of the license and the wording that associates the license with the content. And neither Wikipedia nor I are lawyers, but they seem to use that meaning as well, for example:

A license may be granted by a party…

A licensor may grant a license…

I'd rather not use “recommended license header” because that license ↔ content association text does not need to be in the header of the content file, it could be in a sibling file (e.g. LICENSE.md) or on the project website (as for this exception), etc.

I've be ok with “[license] notice”, but then I'm not clear on what the verb form should be (“Alice notices Bob this content under the MIT license” doesn't sound right ;).

Whatever we call it, I'm ok with “require this license ↔ content association text for now and possibly make it optional later”. I think it makes the technical meaning a bit strange, for example if Alice claimed this exception for source that she provided directly and not through openjdk.java.net, the strict interpretation would be a bit confusing (“does the exception apply to Alice's code, or just Oracle's?”). But even setting aside the license ↔ content association wording, I don't see how that usecase would work because of the “Oracle gives you permission” exception text. With everything wiggly for non-Oracle copyright holders, I'm fine punting on a license ↔ content association text cleanup until we can address non-Oracle copyright holders for this whole file. But it would be nice to have a ballpark for when we intend to resolve this by, otherwise my guess is “a few years down the road if/when someone else complains about it” ;).

Copy link
Member

Choose a reason for hiding this comment

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

people have generally referred to the text such as that suggested to be used at the end of the L/GPL and Apache-2.0 license as "license headers", "license notices" - and for SPDX, "standard headers" (where the license makes such an explicit delineation. We don't need to call it something else. Please simply take this advice - further discussion is not needed here.

Copy link
Contributor

Choose a reason for hiding this comment

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

Right, I agree with @jlovejoy and find using "grant" for this purpose at best inapt, and at worst irresolvably ambiguous. From a legal perspective, there is a difference between the "license text," by which we mean the language of the contract, and the "license" itself, which is legal permission to do something that would otherwise infringe an intellectual property right.

Casting this situation info programming parlance, you cannot call the grant operation on a "license text" object (aka contract), only on a license itself (legal permission). The legal field has a specific term for when someone says "this is the contract that applies to this situation" without spelling it out word-for-word, and that is incorporation by reference (sometimes called adoption or adoption by reference) of the contract.

When Alice says "0BSD applies to this software" and releases it to the public, she adopts the language of the 0BSD license text, which in turn grants the 0BSD-shaped permission (license) contained in the 0BSD license text (contract). But Alice's act of saying "0BSD applies to this software" is an incorporation-by-reference or an adoption (of the 0BSD license text/contract), not a grant. It's a legally effective statement that contains a license grant, but her act is bigger than a "grant", it's agreement to all the contract terms in the 0BSD license text, including the license grant, the termination provisions (which rescinds the license grant), the right to cure within a certain time frame (as under GPL 3), and whatever other terms are in the license text/contract.

In the SPDX framework, we typically only encounter this as license-author-recommended text paragraphs intended to incorporate the license by reference, which is why SPDX has traditionally thought of these statements as standard headers (that's how the license authors intended them to be used). While we may or may not think this is not the full story (from a legal point of view), one thing we're pretty sure of is that this kind of statement, saying "0BSD applies," is an incorporation by reference (of the license text/contract), which includes a grant; using/saying the statement "0BSD applies" is not itself a grant.

For reference, I'm using the following framework, since I understand this to follow the commonly used definitions in technology licensing and intellectual property law:

Term Meaning
Intellectual property legal right to prevent others from doing something (for copyright, copying/distributing/modifying/etc.)
License legal permission to perform act that would otherwise be infringement in an intellectual property right
Grant the legal operation of giving a license; the approximate opposite of license revocation or termination
Contract written (usually) agreement that can contain terms and conditions of a legal license
License text ambiguous; most commonly (a) the text of a contract granting a license (this is how it's commonly used, although from a legal analysis point of view, the contract is bigger than the license, since it contains the license as well as other contract promises and conditions); but possibly also (b) the text of the paragraph legally granting the license (independent of the other clauses in the contract).

Copy link
Contributor

Choose a reason for hiding this comment

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

So you'd prefer Wikipedia's current:

A licensor may grant a license…

to be:

A licensor may adopt a contract…

or:

A licensor my incorporation by reference a contract…

? I guess I can live with that ;).

In the SPDX framework, we typically only encounter this as license-author-recommended text paragraphs intended to incorporate the license by reference, which is why SPDX has traditionally thought of these statements as standard headers (that's how the license authors intended them to be used).

In some cases, yes. For example, Apache-2.0's “comment syntax” and “this file” wording is clearly expecting the header-comment approach. But the GPL-3.0 lists comment-headers as “the safest” way to “attach the … notice to the program”.

The GPL-3.0 also provides recommended wording for declaring the… adopted contract… in an interactive terminal. That information is filling the same role as the header-comment, but is designed for a different audience and channel. And the FSF's recommended wording is different from their header-comment recommendation.

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.

4 participants