Build System Integration

QMSTR integrates into the build systems to learn about the software products, their sources and dependencies.

DevOps CI/CD

Quartermaster integrates into DevOps CI/CD cycles and makes FOSS Compliance a quality metric for developers.

Command line toolchain

Developers can run QMSTR locally to verify outcomes, review problems, or integrate it into test suites.

Open Compliance Program

Quartermaster collaborates with the SPDX and OpenChain projects to streamline and complement the Open Compliance Program.

Powerful Integrations

Quartermaster provides APIs and hooks for free and commercial tools to perform analysis and implement metrics.

Free as in Freedom

Critical FOSS Compliance infrastructure needs to be FOSS, and collaboratively developed. That is why Quartermaster is distributed under a strict copyleft FOSS license.

Recent posts

Learn more about Quartermaster and FOSS Compliance tooling.

Quartermaster Milestone 2 Development Report: Python client modules, SPDX, more automation

on August 8, 2018

After another quarter of intense software development, we are proud to announce the availability of Quartermaster v0.2. Quartermaster is a toolchain that automates the analysis and documentation of Open Source license compliance. Software vendors - businesses as well as Open Source communities - deploy Quartermaster in their build pipelines to create compliance documentation while software package share being created. With the new version, Quartermaster learns to ingest SPDX formatted source code manifests, adds a client library for developing analyzer or reporter modules in the Python programming language, adds support for running multiple build processes on the same hardware concurrently, and much more. Quartermaster is Free and Open Source software and developed under a collaborative open governance model. Get the source code from Github while it is hot! Read more for all the details on the new release.

Continue reading

Quartermaster Milestone 1 Development Report: Voilà, a modular, extendable FOSS Compliance Toolchain

on April 25, 2018

Version 0.1 is here. After a proof-of-concept, plenty of drafting, feedback and discussions, a prototype, and finally three months of development focused on creating a useful product, we are tagging a first version of Quartermaster. The theme of the first version was to implement the toolchain basics: the compliance knowledge graph, the master container, the elemental workflow with a construction, analysis and reporting phase, and the APIs for modules to interact with the knowledge graph in each of these phases. There are public showcases that demonstrate the functionality implemented so far. After gathering functional and legal requirements, the team will now move on to milestone 2, where we will focus on making use of the building blocks from the first version to implement badly needed functions of generating license compliance documentation - an SPDX manifest analyzer, integration with Fossology, and features to aggregate analysis results from different sources into reports.

Continue reading

Quartermaster v0.1 development update #5: The reporting API and "Easy Mode"

on April 9, 2018

Spring is coming, and so is Quartermaster v0.1! One more sprint to get there. Sprint 5 saw the implementation of initial support for Gradle based Java projects, a finished definition of the reporting API, the introduction of “easy mode” (see below), improved author detection and more steps towards an automated HTML reporter. Sprint 5 was the last round of new features before Quartermaster v0.1 will be wrapped up for release. We will use the final sprint in this quarter to tie up loose ends, polish, containerise, document and demonstrate, and to prepare the v0.1 release. The first milestone will be concluded with the v0.2 requirements workshop on April 11.

Continue reading

Quartermaster v0.1 development update #4: Major refactoring, requirements workshop April 11

on March 22, 2018

After the basics of the Quartermaster toolchain are in place, we focused on a refactoring of the master APIs. The key goal is to make implementing modules for the three phases straightforward, composable and as simple as possible. All modules now run in separate processes that communicate with the master over the network. This decouples both the module and the master code, as well as the licensing models of the modules and the master. It is now possible to run multiple analysers configurable from the master. Analyzers may report multiple or overlapping findings of the same type, like copyright holders, without interfering with each other. Based on this, we can now implement modular reporters that generate HTML and SPDX, or notifications, or other kinds of feedback.

Continue reading