| 40 min | Continuous Compliance - An Introduction to Quartermaster | Mirko Boehm (Endocode) | Abstract Free and open source license compliance is a thorny topic - it is at the same time a rigid obligation to vendors, an important hygiene factor in communities, and dauntingly complex to achieve and constantly maintain. Ensuring license compliance requires adequate business processes as defined in OpenChain, a common license data exchange format provided by SPDX, and tools to automate license compliance requirements integrated into the engineering workflow - Quartermaster. The presentation demonstrates how Quartermaster can be used to automatically create up-to-date and correct compliance documentation. It explains the concept and philosophy behind the toolchain, the history of the project and how Quartermaster develops bridges between free and open source developers, legal practitioners and open source program offices. Slides | View file |
|---|
| name | 036 OSS tooling 20190731 FOSSology and SW360 updates 02.pdf |
|---|
| height | 250 |
|---|
|
Notes from talk - Quartermaster runs in your build environment, typically in CI/CD environment, to collect license information about packages during build process.
- We built Quartermaster because there was a hole in the compliance ecosystem -- no industry standard for open source compliance toolchains.
- Who it's for: ideally, communities will use Quartermaster to provide compliance manifests with their code; vendors can use it to create documentation and manifests when producing software and distributing it; distributions, like Linux.
- Project is led by Endocode, a German company bringing open source into traditional industries. Currently funded by a grant from the European Commission.
- Quartermaster also pulls in security information. Project has 3-year roadmap starting in 2019.
- How it works: during construction, collects info on config, metadata, build graph, and history. During analysis, collects info on contributors, copyright, licenses, implements policies and metrics, and produces knowledge. During reporting, generates bill of materials, CI feedback, alerts, and a license catalog. Runs every time you build a project: every commit can change dependencies, what goes into the build, configuration, etc.
- Software QTRMSTR uses: cmake, config files, make, git, scancode, cregit, custom policy code, ClearlyDefined, HTML, SPDX, Slack, and GitHub badges.
- Architecture: master process, toolchain specific build system instrumentation, gRPC/protobuf module APIs, no file formats, modular command toolchain, integration API in master, runs on Linux, OSX, and Windows on the client side -- master runs in container. Allows integration of proprietary tools into the toolchain.
- The data model is licensed under the Open Data License, toolchain under GPLv3, modules are separate processes communicating with the master, paradigm: toolchian is FOSS, as are core modules. Proprietary integrations are possible.
- Current milestone: validation. Suppliers can hand over compliance documentation, and customer can run validator against the package to ensure the manifest contains information about all components in the package. Result is a delivery receipt going back to the supplier.
|