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.

Sign up for GitHub

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

*GPL -or-later and -only in sidebar instructions #563

Merged
merged 5 commits into from
Apr 24, 2018
Merged

*GPL -or-later and -only in sidebar instructions #563

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
f3988a7
SPDX license list 3.0 uses -or-later and -only over + and no modifier
mlinksva Dec 31, 2017
bcdc738
Merge branch 'gh-pages' into only-or-later
mlinksva Jan 27, 2018
4f16e29
Merge branch 'gh-pages' into only-or-later
mlinksva Apr 24, 2018
5aa36a3
update apache-2.0 examples to pass tests
mlinksva Apr 24, 2018
278bae2
test handle repo name with . in it
mlinksva Apr 24, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions _includes/sidebar.html
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
<div class="sidebar">

<a href="#" data-clipboard-target="#license-text" data-proofer-ignore="true" class="js-clipboard-button button">Copy license text to clipboard</a>

<div class="how-to-apply">
<h3>How to apply this license</h3>
<p>
Expand All @@ -14,7 +14,7 @@ <h3>How to apply this license</h3>
{% endif %}
{% assign xgpl = false %}
{% if page.spdx-id contains 'GPL' %}{% assign xgpl = true %}{% endif %}
<p class="note"><strong>Optional: </strong> Add <strong><code>{{ page.spdx-id }}</code>{% if xgpl %}+{% endif %}</strong>{% if xgpl %} (or <strong><code>{{ page.spdx-id }}</code></strong> to disallow future versions){% endif %} to your project's package description, if applicable (e.g., <a href="https://docs.npmjs.com/files/package.json#license">Node.js</a>, <a href="http://guides.rubygems.org/specification-reference/#license=">Ruby</a>, and <a href="http://doc.crates.io/manifest.html#package-metadata">Rust</a>). This will ensure the license is displayed in package directories.</p>
<p class="note"><strong>Optional: </strong> Add <strong><code>{{ page.spdx-id }}{% if xgpl %}-or-later{% endif %}</code></strong>{% if xgpl %} (or <strong><code>{{ page.spdx-id }}-only</code></strong> to disallow future versions){% endif %} to your project's package description, if applicable (e.g., <a href="https://docs.npmjs.com/files/package.json#license">Node.js</a>, <a href="http://guides.rubygems.org/specification-reference/#license=">Ruby</a>, and <a href="http://doc.crates.io/manifest.html#package-metadata">Rust</a>). This will ensure the license is displayed in package directories.</p>
Copy link
Contributor

Choose a reason for hiding this comment

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

I haven't checked all of these locations, but the package.json docs explicitly call for SPDX 2.0:

If your package is licensed under multiple common licenses, use an SPDX license expression syntax version 2.0 string, …

although it's not clear to me how strongly they mean that. In any case, I think it's probably best to continue to recommend SPDX license expressions use the old identifiers, at least until consumering tools have had some time to update. It's also not entirely clear to me how the license list is supposed to interact with the spec. Does the 2.1 spec's inclusion of the 2.5 license list limit SPDX 2.1 license expressions to those IDs? In spdx/spdx-spec#37, I'm suggesting explicitly pinning the license-list version. If that sounds like a possible interpretation of the current spec, you may want to wait at least until the next SPDX spec release before recommending the 3.0 license list identifiers.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I assumed the there is no intent to have the spec version imply a license list version. Surely that intent would be clearly expressed places like:

The following table contains the full names and short identifiers for the SPDX License List, v2.5 which was released July 2016. For the full and most up-to-date version of the SPDX License List as well as other related information, please see http://spdx.org/licenses/

Not to mention in the definitions of various license declared/concluded/data license fields.

I'll leave this open pending more information, and subscribe to the issue you point out. Thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Meant to mention: there's an optional LicenseListVersion field in the SPDX spec, which is a pretty strong implication that a spec version isn't tied to a license list version, though a producer can explicitly specify one.

Copy link
Contributor

Choose a reason for hiding this comment

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

…there's an optional LicenseListVersion field in the SPDX spec…

That sounds useful when you have an SPDX file, although the spec doesn't seem to discuss the default value. The package.json docs don't either, and there's no way to specify a license-list version there. License-expression consumers would seem to need both an SPDX-spec version for the license-expression syntax and (if it is intended to float independently, as LicenseListVersion implies) a license list version.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

until consumering tools have had some time to update

ex: rust-lang/cargo#4888

Copy link
Contributor

Choose a reason for hiding this comment

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

The Rust docs seem to have moved to https://doc.rust-lang.org/cargo/reference/manifest.html#package-metadata:

$ curl -s http://doc.crates.io/manifest.html | grep moved
This page has moved. Click <a href="https://doc.rust-lang.org/cargo/reference/manifest.html">here</a> to go to the new page.

And those docs do not yet contain rust-lang/cargo#4898. Perhaps they only update them after Cargo releases?

And the Ruby docs seem to have a similar issue to the old Rust/Cargo /, with licenses that does not distinguish between AND and OR and a lack of clarity about the SPDX (list) versions and whether license takes license expressions or just short identifiers. I think pulling the Rust declarations forward is going to absorb my available free time, so I'll leave pulling Ruby forward to someone else ;).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@wking I think I found where for Ruby: rubygems/rubygems#2152

Copy link
Contributor Author

Choose a reason for hiding this comment

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

(I mean where rubygems gets its list of licenses; lack of support for license expressions and/or use instead of ambiguous licenses I haven't looked into, and doesn't impact this PR.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For my own memory, npm/npm#19558 is probably what will be closed when npm uses the updated license list.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

npm 6, released today, includes updated license list support.

</div>

{% if page.source %}
Expand Down