Re: LICENSE values for non-standard OSS licenses

[Adam Dinwoodie <adam@dinwoodie.org>]

On Wed, Oct 12, 2022 at 10:36:02AM +0200, Thomas Wolff wrote:
> 
> 
> Am 11/10/2022 um 22:13 schrieb Brian Inglis:
> > On Tue, 11 Oct 2022 09:37:23 +0100, Adam Dinwoodie wrote:
> > > I'm trying to upload a new version of git-filter-repo, and took the
> > > opportunity to set the LICENSE value in the cygport file.  The new value
> > > looks valid according to my reading of the SPDX specification, but is
> > > being rejected by calm.
> > > The license for git-filter-repo is a bit complicated, because different
> > > parts have different licenses, and several of them aren't "normal"
> > > licenses.  The license is described at [0] and files referenced / linked
> > > from there.
> > > [0]: https://github.com/newren/git-filter-repo/blob/main/COPYING
> > > I've encoded this as the somewhat verbose
> > >     LICENSE='(MIT OR LicenseRef-inherit-git OR
> > > LicenseRef-inherit-libgit2) AND (MIT OR LicenseRef-inherit-git OR
> > > LicenseRef-inherit-libgit2 OR LicenseRef-inherit-libgit2-examples)
> > > AND GPL-2.0-only'
> From a mere Boolean perspective, this looks redundant and should be
> simplified to
>     LICENSE='(MIT OR LicenseRef-inherit-git OR LicenseRef-inherit-libgit2)
> AND GPL-2.0-only'

Hmm.  You're obviously correct from a Boolean logic perspective, but my
aim was to provide something more information-rich than a purely Boolean
statement.

Specifically, each file within the packages produced by this cygport
script will be covered by one of the and-joined statements.  Some files
are GPLv2, some are MIT, "inherit-git" or "inherit-libgit2", and some
are MIT, "inherit-git", "inherit-libgit2" or "inherit-libgit2-examples".
Removing "inherit-libgit2-examples", as logically simplifying the
statement would do, in my mind implies that license isn't at all
relevant, even though it does apply to some parts of git-filter-repo.

Which version is preferable probably comes down to the intent of the
LICENSE value in the cygport file and in the various places that consume
that information, either now or in future.  If it's intended
significantly for human consumption, having the information-rich version
may be useful; if it's intended primarily for machine consumption, the
simplified version would probably be preferable.

From digging around the SPDX specifications and examples a bit, I think
we're already some distance away from the intent of SPDX.  If you look
at [0], for example, you can see detail is given separately for the
source and compiled code, and within each of those, the license
information is specified separately for each file.  Using a single
license string for -- potentially -- multiple packages means we're much
more likely to encounter this sort of problem, as it's much more likely
that different packages produced by the same cygport file, or different
files within each package, are going to be covered by different
licenses.

[0]: https://github.com/spdx/spdx-examples/tree/master/example4/spdx