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>