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

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>