Licensing Support by Build Systems and What Remains To Be Done
summary
Build systems (Yocto, ELBE, ISAR) reliably produce images, source archives and disclosure artifacts but license metadata is often incomplete: a kernel scan finds 102 unique license expressions, package-level manifests miss file-level notices, and copyright texts are frequently absent. File-level SPDX output via Yocto create_spdx plus integrated scanners (e.g. ScanCode/FOSSology integration using meta-spdx-scanner) improves coverage but needs manual review; meta-oselot pulls curated data from the meta-oselot / Oselot database (≈200 packages now) to reduce duplicate effort.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 2:55License compliance obligations
- 7:12Yocto and license info
- 12:52File-level SPDX compliance
- 17:12License scanners in Yocto
- 20:25Meta-OSELOT project
- 24:18Yocto disclosure support
- 25:41Debian license compliance
- 31:07Binary and source approaches
- 33:16Build systems compared
- 35:03Key takeaways
- 36:50Shared compliance need
- 37:32Q&A
related talks
49mLicensing Support by Build Systems and What Remains To Be Done
46mSPDX Generation via Yocto and the New LID code License Scanner
10mSPDX for Better License Statements
53mTooling Up for SPDX Software Package Data Exchange
26mThe FOSSology Project – Open Source Software for Open Source License Compliance
25mEnsuring OSS License Compliance the Easy Way
26mThe FOSSology Project – Open Source Software for Open Source License Compliance
53mAdvancing Transparency and Security in Software: A Deep Dive into SBOM and SPDX