As the maintainer of the Tern container inspection tool, I’m happy to report that we recently released Tern 0.4.0. Although this isn’t a general availability (GA) release, it is significant because it supports SPDX documents.
SPDX is a standard language for communicating license information for a build artifact. You can find a detailed specification for SPDX at spdx.org. It’s impressively comprehensive, although it can be a little hard to understand if you don’t have a lot of experience in open source compliance.
With our 0.4.0 release, Tern lets you print SPDX documents for container images. That means you can generate a standardized document describing any container image, which you can use to communicate OSS compliance information.
This is a function that isn’t natively supported by container build tools. Because containers are built imperatively, it has been easy for developers to ignore the need to generate compliance information. The general sentiment is that this is either not important, or that the maintainers of the dependency containers will provide that information.
But as containers become more central to the operation of more major business services, developers are finding that they are required to share compliance information about what they have built. SPDX can be a huge help in this regard. Not only does it tell you what your dependencies are but also what licenses govern the distribution of the container image in one go.
Last year, Tern joined the Linux Foundation’s Automated Compliance Tooling (ACT) project, which is an effort looking to find a common way of communicating information about artifacts. SPDX is one standard the group is using. Organizations developing other compliance tools have also committed to using SPDX, increasing its utility as a standard for unifying information about artifacts.
It’s also worth noting that SPDX documents give you a very good sense of what kind of metadata should be included in a container image manifest. Now that the community has started to consider a standardized way to describe the bill of materials for container images, it can look to SPDX as a model. In the more near term, the OCI community is considering adding an ‘index’ type to support additional artifacts. An SPDX document could be one of those artifacts.
While Tern isn’t fully production-ready, it is functional, and I invite you to try out the SPDX function. You can do that by running: tern -l report -i <docker image> -m spdxtagvalue -f spdx-container-image.txt.
In addition to SPDX support, Tern release 0.4.0 adds:
- Support for Arch Linux-based container images
- Support for rpm-based container images
- Prospector as a development tool to check for linting errors
- Making Tern pip installable
- Ground work for dynamically loadable reporting templates
Thanks, in particular, to Michael Rohan for cleaning up Tern’s code style and enabling the workflow for contributors to check for linting errors. Santiago Torres also did a lot of work towards making Tern pip installable.
Next up will be a small 0.5.0 Tern release, focusing mostly on enabling CI/CD as we switch from Travis CI to Circle CI. We’re also working on a build and release pipeline so we can start distributing pip-installable Python packages and Docker images.
Stay tuned to the Open Source Blog and follow us on Twitter (@vmwopensource) for more updates and information on Tern.
