pkg: make license declarations spdx compatible

[DanielLockau-MLPA]

Contribution description

• modify license declarations in packages' Makefiles to an SPDX identifier compatible format
• add scripts to validate the packages' license declarations

Testing procedure

The last commit contains the verification scripts. Using the check_packages.sh script on master will fail. Using the same script with all the commits from this PR will succeed.

Issues/PRs references

This PR is related to #21515.

[krzysztof-cabaj]

Thanks for help with SPDX licenses.

I think in Issues/PRs references its better to mentione PR #21515 which tracks SPDX related changes.

[riot-ci]

Murdock results

✔️ PASSED

fdfbc1e dist/tools/pkg_license_check: KISS

Success	Failures	Total	Runtime
11124	0	11124	12m:09s

Artifacts

• Documentation preview

[crasbe]

Empty licenses are currently not allowed by the pkg/pkg.mk Makefile:

RIOT/pkg/pkg.mk

Lines 23 to 25 in ad4cf17

	ifeq (,$(PKG_LICENSE))
	$(error PKG_LICENSE not defined)
	endif

Not sure what the best way forward is, because in general it makes sense to check for an empty license field.

[DanielLockau-MLPA]

This is a blocker I did not see because I only cared about valid information in SBOM generation perspective.

In my opinion, PKG_LICENSE should hold information about a valid license if provided by the author. If nothing is provided or licensing is very complex (e.g., when the license expression depends on the features actually used), I'd prefer the field to be empty. My personal preference would be to remove the static test as it cannot decide whether the information is correct. Having something may be worse than having nothing. The contents of PKG_LICENSE should be verified as part of the review process.

@maribu @krzysztof-cabaj Any ideas of how to resolve this?

[maribu]

Maybe we could have that set to public-domain anyway, and add special handling when processing this for SPDX?

I also took a look into the package and I think this package would also be a good candidate for removal / pushing it out of RIOT. That seems to implement https://link.springer.com/chapter/10.1007/978-3-319-70697-9_10 - which doesn't seem to be standard cryptography. I was only able to find some research publications by the author of the software. IMO this is highly relevant for researchers, but not for inclusion in a general purpose OS such as RIOT, as this IMO does not seem to have got the level of scrutiny from the crypto community it should have got before using this outside of experiments.

[maribu]

I opened a PR in #21657 to drop qDSA. So maybe the problem at hands will be solved this way.

However, interesting software declared as "public domain" is a thing. So we get around the problem by waiting for qDSA to be dropped (for other reasons than the use of public domain as license), the problem may just appear again later on.

So I guess we are be better of finding some way to handle public domain code now.

[DanielLockau-MLPA]

Unfortunately, the same issue is present for multiple packages. As I read the legal team comment from spdx, a piece of work must age to get into public domain. Nobody can declare it into this state. The result is simply a missing license declaration which can only be fixed by the copyright holder.

[DanielLockau-MLPA]

@maribu Sounds appealing to me.

@crasbe Would that be a way of moving forward for you? In the state variable, we could accommodate the mentioned legal states of "copyrighted", "public-domain" and "licensed" (combinations possible? license-protected probably extends copyright-protected). The license variable could then purely be used to hold license information.
The license checker script must be partially rewritten in that case.

[crasbe]

Sounds good to me. I don't think the license checker script needs thaaaat much of a change, just some "if this is empty, check the other one" magic.

[DanielLockau-MLPA]

@crasbe I'm getting back to the SBOM topic now. Sorry for the large delay. I have some new findings from the first (partly manual) rounds of our internal vulnerability management: We'll need some package identification data for all packages, in the form of PURLs, CPEs or SWIDs. I don't see this as in scope of this PR as this PR concerns license management but would directly follow up with that topic.

[DanielLockau-MLPA]

@crasbe I just pushed the changes which, in my interpretation conform to @maribu's proposal further up. I was unsure how to squash, hence the many, many tiny commits. My personal choice would be to leave license expression modifications for SPDX conformity in single commits and squash the legal status addition to all packages into a single commit.

I did modify pkg/pkg/mk and verified locally that the tests in tests/pkg/ still build.

There is some tooling added to dist/tools/pkg_license_check but not integrated anywhere.

[kfessel]

I am no lawyer

Note that public domain is not a licence. It is the absence of a copyright (as in Urheberrecht).

copyright ^= verwertungsrechte
in the US, Canada and in UK this is what Law will look at first (commons law jurisdictions)

Urheberrecht ^= authorship rights (moral rights)
in most of europe this is what Law will look at first (civil law jurisdiction)

the concept of moral rights exist in the US and Canada but there is little to no consequence -> focus on copyright.

not sure if you get rid of the moral rights by releasing into the public domain or if they are just of extreme low relevance that no one cares

At least for Canada (they codified moral rights) they can be waived by contract -> i assume that happens if something becomes PD.

E.g. in the USA it is absolutely legal to release something into the public domain. It would not be possible to license that afterwards, as one needs to be a copyright owner to licence stuff to others.

This is a bit misleading: if something declared public domain (the author declares or age) it itself can not be put under ownership -> copyright law cannot be applied and it might serve as an example of prior art (very similar things or parts of other things (eg by derivation) might are also not be legislated by copyright law or patent law) .
But it also comes with no obligations towards derived works -> you are allowed to derive own the copyright to that derived work and may add any license to that derived work and if that/these derived works passes the "Threshold of originality" that licenses need to be respected.

also very small changes might generate a derivates:

• in literature translation, respelling or typesetting are processes that generate a derivate
• in music performing, typesetting or recording a performance are derivatives
• even copying creates a derived work (collections are in themself often considered work of creativity)

those derivatives do not harm the original authors right -> the performer owns the right to the performance but the original author still has to be payed (or the license to be followed) unless the origin is PD.

e.g.:

• The works of Bach are public domain
• But if they are printed the print (the very layout on the page) usually carries a license (reason: someone owns copyright on something on that page (e.g. layout)).
• If you then copy the print you got to follow the license of that print (eg number of copies for your band)
• but if you derive from what Bach once wrote (eg retype the notes into your own typeset you do not need to follow (as that part is public domain) (assuming the book author did not further work than layout the page with the melody by Bach (if it is a specific arrangement (eg for different instruments that arrangement part also has a copyright attached))

So a program that contains public domain code can still carry another license and that license needs to be followed.

I am no lawyer