Scott Peterson’s recent article, Making Compliance Scalable in a Container World, is a good explanation of some challenges and opportunities in open source compliance for software is delivered via containers. The article advocates the use of container registries to store and deliver portable compliance information. Also, it reminds us that container continue to be a challenge for open source compliance.
Today, much software is delivered via containers. A container is a standalone, executable package of software that includes everything needed to run an application: the application software, libraries for the operating system or language platforms, system tools, and configuration settings. Containerization is the “plug-and-play” way of running software, without complicated or time-consuming installation.
Most computer users are familiar with installing applications on a desktop or laptop computer. It takes a while to install them, and for an application to work, the computer must already have a variety of standard software that the application needs in order to run on the computer platform. If installing an application is like making a recipe, creating a container is opening a takeout box.
A container registry is a service that facilitates delivery of container images. It helps developers build and manage containers, and decide who can access them. So, a registry can be used to deliver containers and track information about them.
Show Me the Code
A lot of open source compliance is about managing information. Complying with open source licenses requires you to know what open source software is in your product (its bill of materials), and what licenses cover all of it.
The average software application installation on your desktop or laptop copies software into local directories, and once installed they are relatively easy to examine. In these old-style installations, it is not too difficult to figure out which binaries correspond to the source code that generated them. So, if you needed to know what open source software was included, you might be able to figure that out from an installed software directory.
But containers are opaque; once they are created, it is nearly impossible to “unpack” them to determine their bill of materials. And it turns out that associating binaries with source code is one of the keys to open source compliance.
Delivering source code upfront, where feasible, is always the best way to comply with open source license notice requirements. That is because the license notices are “baked in” to the source code. In contrast, delivering object code only, without the source code, is more work – requiring distributors to pick out the license notice files and pass them along.
Many companies struggle with providing notices for containerized software, in part because the notice requirements of the major licenses are outdated. For example:
- GPL2 requires that redistributors “give any other recipients of the Program a copy of this License along with the Program.”
- BSD requires notices to be “in the documentation and/or other materials provided with the distribution”
- MIT requires a copy of the license “in all copies or substantial portions of the Software”
These notice requirements were all written before the web came into common use, much less containers, so they presume a means of delivering software that is about 25 years out of date.
The question of how to deliver the notices “along with” or “provided with” or “in all copies” of a container can be complicated. Every year, notice delivery gets harder to accomplish, given the increasing number of open source components, and the way software is deployed in the real world – often with no user interface and with containers being spun up and down on demand. There seems little appetite for revising the licenses to include more workable notice requirements, so many users are left in a quandary about how to do the right thing.
Using Containers as a Force for Good
“We should build a container ecosystem with compliance that is portable across registries.”
Scott K Peterson (Red Hat)
Mr. Peterson’s article goes into some detailed suggestions about how to use container registries and automated tooling to help with compliance by preserving the information that associates containerized code with its source code. However, any solution using container registries needs to ensure that the means of delivery will actually fulfill the notice requirements for the licenses, and that may be a difficult problem to solve with tooling.
Fortunately, most community open source enforcers do not pursue foot foul violations when the source code has been made freely available in an effective manner, such as posting it on a publicly available web page – or, presumably, delivering information via a container registry. Such notices may or may not be in the copy or along with the software, exactly, but they help users get access to the source code nonetheless. That fulfills the spirit of the open source license, if not necessarily its exact conditions.
Is there a way to bring best practices in lines with literal license requirements by leveraging container registries? Not exactly, or at least not yet. But more information is always better than less, and more automation is the only realistic way to pursue open source compliance properly. Tooling developments in this area are worth tracking.
