Re: Use SPDX license identifiers to indicate licenses?

[Lassi Kortela]

> I'm not sure chicken-install would be the right place to validate the
> license field, as it would add a dependency on the SPDX database to the
> core tools. 

Good point.

> Also, we'd need some code to interpret SPDX expressions,
> which to the best of my knowledge doesn't exist for Scheme (yet).

Göran has a SPDX library for R6RS: https://github.com/weinholt/spdx

It parses license expressions into the following S-expressions:

* (or expr0 expr1) — A choice between license expressions.
* (and expr0 expr1) — A requirement to comply with both license expressions.
* (with license exception) — A license identifier with a license 
exception identifier (both strings).
* (user-defined document-ref license-ref) — This is a user-defined 
license reference. The document is optional and #f if omitted, otherwise 
both are strings.
* (+ license-identifier) — Represents "(or later)". Example: (+ 
"GPL-3.0") represents "GNU GPL version 3 (or later)".
* license-identifier — A string identifying a license. Example: "GPL-3.0".

Chicken egg manifest files could use that S-expresion format.

Most eggs probably stick to a single license, in which the license 
expression would be just a string as it is now, just in a standard format.

> I think a good start would be recommending egg authors to use SPDX
> identifiers in the license field of their eggs.  We can progressively
> add more strict checks against the version identifiers in our daily test
> runs [1] as we get more tools to do that. By using that approach we'd
> also free the core tools from the dependency on the SPDX database.

Sounds wise.

> Our daily test runs already perform some very primitive checks related
> to licenses:
>
> * check whether the license field is specified at all (some eggs don't
>    even do that)
>
> * check whether we have GPL violations (e.g., a BSD egg which has a GPL
>    in its dependency chain) -- that's pretty much guessology, as we don't
>    have a standard to specify licenses.

This is a good example of a problem that machine-reading SPDX data can 
help with.

> Results of those checks are reported in the "Warnings" section of
> salmonella reports (e.g., [2] -- using the report for CHICKEN 4 eggs as
> example because it has a more diverse set of cases).
>
> Not really a check, but the license of eggs is also displayed in the
> graphical representation of the dependency graphs of eggs (e.g. [3]).
> That can be useful for egg users which are concerned about the licenses
> they use.

+1

> Indeed.  I think SPDX is probably the best standard if we do want to go
> in the direction of checking licenses.  In the exceptional cases where
> the license cannot be found in the SPDX database, we can always require
> the license file to be somehow linked to the identifier used in the
> `license` field in the .egg file.  Something like:
>
>    (license "MSL" "my-special-license.txt")
>
> Currently the format is
>
>    (license <id>)
>
> where <id> is a free string.  We could support a second field to specify
> a file that must exist in the source code of the egg, as checked out by
> chicken-install.

We could start by finding out how many eggs currently use an exotic 
license that doesn't have a standard identifier. If there are only a few 
of them and the authors are known, it could be easiest to ask if they'd 
like to switch to something more standard.

A ruby gem called "licensee" provides a command line tool to identify 
licenses by statistical text matching; maybe it can be run against the 
git repo with all eggs. Licensee is the gem that GitHub uses to show the 
name of the license in their web UI.

> > In fact, in SRFI we also have this problem: pretty regularly someone
> > is doing detective work trying to figure out where some file in a
> > reference implementation came from and how it is licensed.
>
> I asked John Cowan that question myself. :-)

Did this lead to a plan for SRFI? :) IMHO it would be a timesaver there 
as well.