Re: Options for metadata license identifiers


Alexios Zavras
 

As a single data point, we (Intel) use the mentioned:

# SPDX-License-Identifier: MIT
LICENSE = "GPLv2 & bzip2-1.0.4"

under the understanding that the comment "SPDX-License-Identifier" applies only to the file the line is in.

-- zvr

-----Original Message-----
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of Richard Purdie
Sent: Thursday, 18 March, 2021 12:12
To: SPDX-legal <Spdx-legal@...>
Subject: Options for metadata license identifiers

Hi,

I wondered if I might seek advice/opinions on a dilemma Yocto Project is facing with license identifiers.

First, some background. We build software components from source and combine them together to make up an operating system (most often Linux). As such we have metadata we refer to as "recipes" which are basically lists of instructions on where to get a piece of software, how to configure it and so on. Our core layer has around 800 recipes (http://git.yoctoproject.org/cgit.cgi/poky/tree/).

In addition we also store patches alongside the recipes which are applied to the source code as part of the build process.

Where we have normal code for the build process, license identifiers are easy and we've added them to our code/scripts as we're aligned with SPDX and believe in what it is doing. Where we have concern is the recipes.

The recipes already have our own license identifiers in them for the software being built, for example the busybox recipe has:

$ cat meta/recipes-core/busybox/busybox.inc | grep LIC LICENSE = "GPLv2 & bzip2-1.0.4"
LIC_FILES_CHKSUM = "file://LICENSE;md5=de10de48642ab74318e893a61105afbb \
file://archival/libarchive/bz/LICENSE;md5=28e3301eae987e8cfe19988e98383dae"

What this means is that the busybox source/binaries are under the listed licenses and that the two files mentioned contain license information.
We have a checksum there so that when we upgrade to a new version of busybox, if the checksums change, we know we need to re-evaluate the license field. Its not a perfect check but it does catch basic mistakes and we can easily check and reject patches where it hasn't been re-evaluated.

Our license handling predates SPDX, we are trying to align to SPDX identifiers.

My question is what to put in the recipe to identify the license?

We can easily put a "# SPDX-License-Identifier:" into the recipe but there is a lot of concern about how people might interpret this. Our top level license says unless otherwise stated, recipe metadata is MIT licensed so the license is relatively clear. The worry is something like:

# SPDX-License-Identifier: MIT
LICENSE = "GPLv2 & bzip2-1.0.4"

makes for very confusing reading and can be badly interpreted.

I have some ideas about what we might have to do to make this really clear but they have downsides. I wondered if there was any advice here on how best to handle this? Once we know how to do it, marking up the recipes is relatively straightforward, we just need to establish what makes sense.

Also, there is a secondary problem of which license any patches we have are under and what license identifier (if any) we should put in those.
Those would likely need to match the upstream project source they're patching I'd imagine but I don't know if we want to mark up all the patches or not.

Cheers,

Richard







Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Join Spdx-legal@lists.spdx.org to automatically receive all group messages.