Merge pull request #14 from CAM-Gerlach/fix-deploy-action-tag

Fix version tag of GitHub Pages deploy action to resolve #11

Fix version tag of GitHub Pages deploy action to resolve #11

Add Github Actions workflows to build, test and deploy site (#9)

* Add Github Actions workflows to build, test and deploy site

Signed-off-by: C.A.M. Gerlach <CAM.Gerlach@Gerlach.CAM>
* Copy index and nojekyll assets into output dir on CIs

* Move dir empty check to modular script and improve error messages

Update README and CONTRIBUTING docs (#7)

* Update links to point to the SPDX github pages

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>
* Fix broken link in README per https://github.com/wking/fsf-api/pull/23

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>
* Update CONTRIBUTING.md file

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>
* Update copyright date

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>
* Apply suggestions from code review

General clean up of the README file

Co-authored-by: CAM Gerlach <CAM.Gerlach@Gerlach.CAM>
* Remove the gh-pages pull request information - this will soon be done in the CI

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>
* Add (Expat) to the MIT license title per suggestion

Co-authored-by: CAM Gerlach <CAM.Gerlach@Gerlach.CAM>
* Cleanup CONTRIBUTING.md per suggestions

Co-authored-by: CAM Gerlach <CAM.Gerlach@Gerlach.CAM>
Co-authored-by: CAM Gerlach <CAM.Gerlach@Gerlach.CAM>

Merge pull request #5 from spdx/apache2override

Override Apache-2.0 to remove gpl-2-compatible tag

Override Apache-2.0 to remove gpl-2-compatible tag

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Merge pull request #4 from spdx/apibase

Update github.io page reference to spdx

Update github.io page reerence to spdx

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Merge pull request #2 from CAM-Gerlach/fix-xml-parsing

Fix XML parsing, add a basic CLI and resolve a number of minor code quality, best practice and style issues

Merge pull request #1 from spdx/bsd-3-clause

Add BSD-2-Clause to the FreeBSD GNU Identifier

Add basic CLI and allow passing source and target URIs as args

Add basic docstrings to all functions and the module itself

Apply code style fixes

Fix other minor code quality issues

Avoid shadowing builtin names

Move top-level code into main function

Remove old workarounds for obselete Python versions & upgrade syntax

Add explict encoding argument to open to ensure correct behavior

Add hack to normalize HTML named entities to still parse as XML

Add BSD-2-Clause to the FreeBSD GNU Identifier

Based on the SPDX matching guidelines, BSD-2-Clause-FreeBSD, BSD-2-Clause-NetBSD and BSD-2-Clause are equiv. licenses. Resolves https://github.com/spdx/license-list-data/issues/52

pull: Map the FSF's new EUPL-1.2 identifier

Apparently they posted their opinion on the EUPL-1.2 last week:

On Tue, Jul 03, 2018 at 05:34:22AM -0700, Patrice-Emmanuel Schmitz wrote [1]:
> Richard M Stallman wrote on June 29: I'm sorry it took so long, but
> we've recorded that the EUPL 1.2 is a free license."

And, unfortunately for anyone using the FSF IDs, they've renamed their
old EUPL ID to EUPL-1.1.  At least they still support their old anchor:

  $ curl -s 'https://www.gnu.org/licenses/license-list.html#EUPL' | grep '"EUPL"'
  <dt><a id="EUPL"></a> <!-- old id, leave for compatibility -->

[1]: https://github.com/spdx/license-list-XML/issues/638#issuecomment-402140195

pull: Remove obsolete "not in license-list-XML" comment for EPL2

The comment was current when it was added in 66d83402 (pull: Add a
script to scrape FSF license IDs, names, and tags, 2017-10-20), but
the EPL-2.0 license was part of the 3.0 license list [1].

[1]: https://github.com/spdx/license-list-XML/blob/v3.0/src/EPL-2.0.xml

pull: Split SILOFL into SILOFL-1.0 and SILOFL-1.1

The title and linked text are for 1.1, but the description includes
[1]:

  The Open Font License (including its original release, version 1.0)
  is a free copyleft license for fonts...

as reported by Donald Robertson [2].

It would be nice if the FSF had separate identifiers or at least
linked to their version of the 1.0 text; for now I'm just minting my
own versioned identifiers in SPLITS and allowing the SILOFL-1.0 JSON
to include the link to the 1.1 text in its 'uris' property.

[1]: https://www.gnu.org/licenses/license-list.en.html#SILOFL
[2]: https://github.com/wking/fsf-api/issues/7#issuecomment-391093115

README: Fix "field" -> "fields" typo in caveat section

This snuck in with 954a3468 (pull: Update to the SPDX License List
3.0, 2017-12-29, #9), which added "tags" to the sentence but forgot to
make "field" plural.

README: Fix Markdown typos (e.g. [non-free][])

These had snuck in with 954a3468 (pull: Update to the SPDX License
List 3.0, 2017-12-29, #9).

pull: Add sort_keys=True for license.jsonld

I'd missed this in 8398a357 (pull: Add JSON-LD markup, 2018-01-04,
#12).  Adding it here reduces unnecessary churn in the gh-pages
branch.

pull: Add deprecated SPDX identifiers

These identifiers are deprecated, but they haven't yet been dropped
from the SPDX spec.  That means that, although they're not
recommended, they're still valid identifiers to use where you can use
other License List 3.0 identifiers.  Listing them here makes it easy
for folks using the deprecated identifiers to look up the associated
FSF metadata.

An alternative approach would be to stick with only non-deprecated
SPDX identifiers here and have users hit the SPDX API to resolve those
before coming to this API.  But the SPDX API does not currently expose
obsoletedBy migration recommendations [1].

[1]: https://github.com/spdx/LicenseListPublisher/issues/12

pull: Add JSON-LD markup

This should help with forward/backward compatibility, because
consumers can use JSON-LD to extract the semantic meaning regardless
of how I lay out the data.  From [1]:

  This information allows developers to re-use each other's data
  without having to agree to how their data will interoperate on a
  site-by-site basis.

There's a framing spec in the works [2] to support "request your own
layout" in an API.

I had to cludge a bit to support FSF IDs in licenses-full.json.  The
released JSON-LD 1.0 has index maps, but [3]:

  Note how the index keys do not appear in the Linked Data below, but
  would continue to exist if the document were compacted or
  expanded...

which isn't very useful for folks who are parsing the file as JSON-LD
and who need access to the FSF IDs.  To work around that, I've used
the FSF IDs as both the 'licenses' keys and as 'id' entries in the
'licenses' values.

We might be able to specify the semantics of the object keys with the
unreleased 1.1 [4] and its ID maps [5], but I've left that off for
now.

There is some background on classifying non-URI identifiers in [6].
Currently I'm not classifying my identifiers.

I'm using HTTPS identifiers for schema.org, because that's the
long term target [7].

I've tested the output JSON-LD in [8], and the compacted
licenses-full.json looks like:

  {
    "http://tremily.us/fsf/schema/license.jsonld": [
      {
        "@index": "ACDL",
        "https://schema.org/identifier": "ACDL",
        "https://schema.org/keywords": "libre",
        "https://schema.org/name": "Apple's Common Documentation License, Version 1.0",
        "https://schema.org/url": {
          "@list": [
            "https://www.gnu.org/licenses/license-list.html#ACDL",
            "http://fedoraproject.org/wiki/Licensing/Common_Documentation_License"
          ]
        }
      },
      {
        "@index": "AGPLv1.0",
        "https://schema.org/identifier": [
          "AGPLv1.0",
          {
            "@index": "spdx",
            "@value": "AGPL-1.0"
          }
        ],
        "https://schema.org/keywords": "libre",
        "https://schema.org/name": "Affero General Public License version 1",
        "https://schema.org/url": {
          "@list": [
            "https://www.gnu.org/licenses/license-list.html#AGPLv1.0",
            "http://directory.fsf.org/wiki/License:AGPLv1"
          ]
        }
      },
      ...
    ]
  }

[1]: https://www.w3.org/TR/2014/REC-json-ld-20140116/#h3_the-context
[2]: https://json-ld.org/spec/latest/json-ld-framing/
[3]: https://www.w3.org/TR/2014/REC-json-ld-20140116/#data-indexing
[4]: https://json-ld.org/spec/latest/json-ld/#changes-since-1-0-recommendation-of-16-january-2014
[5]: https://json-ld.org/spec/latest/json-ld/#node-identifier-indexing
[6]: http://meta.schema.org/docs/datamodel.html#identifierBg
[7]: http://schema.org/docs/faq.html#19
[8]: https://json-ld.org/playground/

pull: Add the FSF ID to per-license files as 'id'

This allows you to convert an SPDX ID back to a FSF ID:

  $ curl -s https://wking.github.io/fsf-api/spdx/MIT.json | jq -r .id
  Expat

without scraping the information out of 'uris'.

Merge branch 'spdx-list-3.0'

* spdx-list-3.0:
  pull: Convert 'uri' to the plural 'uris'
  pull: Update to the SPDX License List 3.0

pull: Convert 'uri' to the plural 'uris'

There are enough hacks here that we should make it easy for folks to
go back and double-check our calls.

pull: Update to the SPDX License List 3.0

As released 2017-12-28 [1].  The main change here is that the same
license can now have multiple license-list entries, with each entry
covering a common grant.  I think conflating licenses with grants is
unfortunate, and would have preferred continuing to handle version
grants with the + license expression operator [2] and possibly a new
"-ONLY" operator [3].  But that ship seems to have sailed.

This commit converts the SPDX identifiers into lists, so we can list
as many identifiers as we want for each FSF license ID.  It also adds
property docs, so folks understand the significance of the identifier
ordering.

Even before 3.0, the SPDX used per-grant identifiers for MPL-2.0 and
MPL-2.0-no-copyleft-exception [4].  But my reading of [5] gives me the
impression that the FSF's GPL-compatibility ruling hinges on section
3.3, which is what the MPL-2.0-no-copyleft-exception is turning off.
So I've left mapping at FSF MPL-2.0 -> SPDX MPL-2.0, instead of
growing it to [MPL-2.0, MPL-2.0-no-copyleft-exception].

I cheat a bit on the fsf-list-practical link, because the FSF hasn't
put an anchor on that header.  Instead, I'm using the first entry
underneath the header.

[1]: https://github.com/spdx/license-list-XML/releases/tag/v3.0
[2]: https://spdx.org/spdx-specification-21-web-version#h.jxpfx0ykyb60
[3]: https://lists.spdx.org/pipermail/spdx-legal/2017-August/002126.html
     Subject: Re: minutes, summary, next steps
     Date: Thu, 17 Aug 2017 14:37:22 -0700
     Message-ID: <20170817213722.GK23356@valgrind.tremily.us>
[4]: https://github.com/spdx/license-list-XML/issues/441
[5]: https://www.gnu.org/licenses/license-list.html#MPL-2.0

pull: Unify ccbynd with CC-BY-ND-4.0

[1] is associating 'CC-BY-ND' with "Creative Commons Noderivatives,
any version" and the 'non-free' tag.  This is a bit odd, because the
CC title for the BY-ND license is "Attribution-NoDerivatives" [2].
I'm not sure why the FSF left out "Attribution" here, but since the CC
doesn't have a ND-only license (all of their licenses besides CC0
include BY [3]), I'm assuming it's just FSF oversight.

[4] is associating 'ccbynd' with "Creative Commons
Attribution-NoDerivs 4.0 license (a.k.a. CC BY-ND)" and the
'viewpoint' tag.

[1]: https://www.gnu.org/licenses/license-list.en.html#CC-BY-ND
[2]: https://creativecommons.org/licenses/by-nd/4.0/
[3]: https://creativecommons.org/licenses/
[4]: https://www.gnu.org/licenses/license-list.en.html#ccbynd

Merge branch 'spdx-hardlinks'

* spdx-hardlinks:
  pull: Add licenses-full.json with all the information
  pull: Add {scheme}/{id}.json hardlinks

Merge branch 'splits-identifiers'

* splits-identifiers:
  pull: Add TAG_OVERRIDES and distinguish gpl-2-compatible from gpl-3-compatible
  pull: Associate FSF's Ruby with SPDX's Ruby
  pull: Associate FSF's PythonOld with SPDX's Python-2.0 (and others)
  Update identifiers and splits

pull: Add licenses-full.json with all the information

I prefer the minimal index (as I explain in the previous commit), but
some consumers need details on multiple licenses and prefer to collect
data with a single network request.  Even with all the data in one
endpoint, I don't expect this to grow to a point where it would be
expensive to serve.  And at the moment, GitHub is donating the server
bandwidth anyway.

Also add anchors to the README so folks can link to the docs for a
specific endpoint.  We need to use the explicit closing tag (vs.
<a name="..." />) to get GitHub to render Markdown in the remainer of
the license-list paragraphs.

pull: Add {scheme}/{id}.json hardlinks

Putting additional metadata in the licenses.json index is a
slippery-slope.  This commit strips it down to an array of IDs, and
*all* per-license metadata must be fetched via a single-license
endpoint.

The new per-scheme links allow folks to retrieve per-license metadata
using their chosen scheme (assuming they trust the mapping maintained
in this API) without having to iterate over licenses.json retrieving
{FSF-id}.json until they find a match.  The OSI API uses the same
approach [1], although they currently have a fatter index [2,3,4,5].

os.link is implemented on Unix and Windows [6].  The ** recursive glob
pattern is new in Python 3.5 [7]; for older Pythons I'm falling back
to two non-recursive glob calls.

[1]: https://github.com/OpenSourceOrg/api/blob/c903651ef26c35202d6561b61b97d29ead1e08c5/doc/endpoints.md#licenseschemeidentifier
[2]: https://github.com/OpenSourceOrg/api/blob/c903651ef26c35202d6561b61b97d29ead1e08c5/doc/endpoints.md#licenses
[3]: https://github.com/OpenSourceOrg/api/blob/c903651ef26c35202d6561b61b97d29ead1e08c5/api.go#L52
[4]: https://github.com/OpenSourceOrg/api/blob/c903651ef26c35202d6561b61b97d29ead1e08c5/reload.go#L28
[5]: https://github.com/OpenSourceOrg/api/blob/c903651ef26c35202d6561b61b97d29ead1e08c5/license/license.go#L67
[6]: https://docs.python.org/3.6/library/os.html#os.link
[7]: https://docs.python.org/3.6/library/glob.html#glob.glob

README: Slug (non-numeric) link references

These are easier to maintain as links are inserted into, removed from,
or reordered in the text.

pull: Add TAG_OVERRIDES and distinguish gpl-2-compatible from gpl-3-compatible

From [1]:

  Unless otherwise specified, compatible licenses are compatible with
  both GPLv2 and GPLv3.

For AGPLv3.0 [2]:

  Please note that the GNU AGPL is not compatible with GPLv2.  It is
  also technically not compatible with GPLv3 in a strict sense: you
  cannot take code released under the GNU AGPL and convey or modify it
  however you like under the terms of GPLv3, or vice versa.  However,
  you are allowed to combine separate modules or source files released
  under both of those licenses in a single project, which will provide
  many programmers with all the permission they need to make the
  programs they want.

I'm not clear on what the idea with "technically not compatible" was.
The vice versa thing sounds is certainly not true for Expat,
etc. either, and Expat is listed as compatible without qualifications.

For ECL2.0 [3]:

  This is a free software license, and it is compatible with
  GPLv3... This patent license and the indemnification clause in
  section 9 make this license incompatible with GPLv2.

For freetype [4]:

  This is a free software license, and compatible with GPLv3.  It has
  some attribution requirements which make it incompatible with GPLv2.

For GNUGPLv3 [5]:

  Please note that GPLv3 is not compatible with GPLv2 by itself.
  However, most software released under GPLv2 allows you to use the
  terms of later versions of the GPL as well.  When this is the case,
  you can use the code under GPLv3 to make the desired combination.

For GPLv2 [6]:

  Please note that GPLv2 is, by itself, not compatible with GPLv3.
  However, most software released under GPLv2 allows you to use the
  terms of later versions of the GPL as well.  When this is the case,
  you can use the code under GPLv3 to make the desired combination.

So what they really mean is that GPL-2.0+ is GPL-3.0-compatible.
GPL-2.0 (only) is GPL-3.0-incompatible.

For LGPLv3 [7]:

  Please note that LGPLv3 is not compatible with GPLv2 by itself.
  However, most software released under GPLv2 allows you to use the
  terms of later versions of the GPL as well.  When this is the case,
  you can use the code under GPLv3 to make the desired combination.

[1]: https://www.gnu.org/licenses/license-list.html#Introduction
[2]: https://www.gnu.org/licenses/license-list.html#AGPLv3.0
[3]: https://www.gnu.org/licenses/license-list.html#ECL2.0
[4]: https://www.gnu.org/licenses/license-list.html#freetype
[5]: https://www.gnu.org/licenses/license-list.html#GNUGPLv3
[6]: https://www.gnu.org/licenses/license-list.html#GPLv2
[7]: https://www.gnu.org/licenses/license-list.html#LGPLv3

pull: Associate FSF's Ruby with SPDX's Ruby

The FSF name isn't specific [1], but the FSF links [2] which contains
exactly the same text as [3].

[1]: https://www.gnu.org/licenses/license-list.html#Ruby
[2]: https://directory.fsf.org/wiki/License:Ruby
[3]: https://github.com/spdx/license-list-XML/blob/e5da40e25becb0aa7626d3f62649d2387284a623/src/Ruby.xml

pull: Associate FSF's PythonOld with SPDX's Python-2.0 (and others)

The FSF label for PythonOld is "License of Python 1.6b1 through 2.0
and 2.1" [1].  They link to the 1.6b1 text [2].  This set does not
include 1.6a2 and earlier versions [3], and also does not include
2.0.1, 2.1.1, and newer versions [4].  I believe the splits are
exhaustive, based on:

* [5], which mentions 1.6.1, 2.0, 2.1 in this range.
* [6], which mentions no releases in this range.
* [7], which mentions 1.6.1 in this range.

[1]: https://www.gnu.org/licenses/license-list.html#PythonOld
[2]: https://directory.fsf.org/wiki/License:Python1.6b1
[3]: https://www.gnu.org/licenses/license-list.html#Python1.6a2
[4]: https://www.gnu.org/licenses/license-list.html#Python
[5]: https://docs.python.org/3/license.html#history-of-the-software
[6]: https://www.python.org/downloads/
[7]: https://www.python.org/download/releases/

Update identifiers and splits

pull: Add unused-SPLITS check

pull: Add unused-IDENTIFIERS check and fix FDL1.1 -> FDLv1.1, etc.

CONTRIBUTING: Link to LICENSE.md

LICENSE: Add the MIT license text

This is available in a number of places [1,2,3].  I'm not entirely
clear what *its* license is, but presumably copying it verbatim with
changes to the copyright statement is allowed :p.

[1]: https://github.com/spdx/license-list-XML/blob/e5da40e25becb0aa7626d3f62649d2387284a623/src/MIT.xml
[2]: https://opensource.org/licenses/MIT
[3]: https://directory.fsf.org/wiki/License:Expat

pull: Fix FreeBSD SPDX identifier (to BSD-2-Clause-FreeBSD)

Based on Kate's list [1].  Looking more closely, the FSF's FreeBSD
text [2] includes the "The views and conclusions..." paragraph that is
unique to the BSD-2-Clause-FreeBSD [3].  The FSF's FreeBSD page [2]
also links [4].

[1]: https://github.com/spdx/license-list-XML/pull/453#issuecomment-338411910
[2]: https://directory.fsf.org/wiki?title=License:FreeBSD
[3]: https://github.com/spdx/license-list-XML/blob/e5da40e25becb0aa7626d3f62649d2387284a623/src/BSD-2-Clause-FreeBSD.xml#L38-L40
[4]: https://www.freebsd.org/copyright/freebsd-license.html

README: Document this project

SPDX-License-Identifier: MIT

pull: Use sets of licenses in TAGS

Because the FSF considers GPL- and FDL-compatible licenses
free-as-in-libre as well.

pull: Resolve relative URIs relative to the FSF base

E.g. we want:

  "uri": "https://www.gnu.org/licenses/agpl.html"

in our output JSON, not:

  "uri": "/licenses/agpl.html"

pull: Add a script to scrape FSF license IDs, names, and tags

We want to use this to lookup FSF tags associated with a given SPDX
license.  The FSF is intestested [1], but maybe not enough to maintain
their own API.  Until they do maintain their own API, stub out a mock
API on their behalf, which we can hand over to them when they're
ready for it.

[1]: https://lists.spdx.org/pipermail/spdx-legal/2017-October/002281.html
     Subject: Issues added based on this weeks Legal Call
     Date: Fri, 13 Oct 2017 10:20:33 -0700
     Message-ID: <021801d34447$9443e280$bccba780$@com>