Time for a January License Review

Here's a quick pitch to the builders and leaders in development, IT and product management for a "January License Review". This might sound a bit like changing the batteries in your smoke detectors at home - important but not a lot of fun. In business terms, the review serves a similar purpose to protect against disasters. Most software-based solutions are built on scores or even hundreds of different components, some of which are "nested" in other components. Even for those whose solutions leverage closed-source technologies exclusively, it is likely that some of your infrastructure and ops tools are using open-source components. Closed-source tools probably utilize open-source components also, warranting a separate discussion on whether the licensing agreements provide adequate protection for your firm (a question for IP counsel).

Over the last year, a number of solution providers switched to a Business Source License, bringing different conditions and terms-of-use. HashiCorp did this in August (check out their announcement from last August), as one notable example that had broad impact in devops circles particularly (Terraform, Consul, Vault, etc). Acknowledging the controversy sometimes associated with these licenses, the reality is providers of open-source packages often face a "freeloading" problem where large enterprises use their packages in (possibly competing) offerings without contributing to the platform. For today's message, though, the focus is on our solutions rather than licensing strategies for platforms. We must understand the terms-of-use for these components to be sure each is consistent with our usage.

Over the last few years, we've seen the term SBOM (Software Bill of Materials) come into broader use (see below for some follow up links). Knowing what components make up your solution (including the operating tools and infrastructure elements you manage) is crucial to what I call product continuity planning. We are taking up a series on this later in the quarter, covering not only licensing but also other business continuity elements such as source integrity and disaster recovery.

For now, here's a suggestion. Ask your devops team to share that SBOM and make sure the licenses match for your use cases. If your firm has to build an SBOM manually, I'd suggest looking at a solution like FOSSA that can help you automate in a way that scales cost-wise for both small and large projects. Even if you have automation, review the SBOM and check on the licenses at least twice yearly to help maintain your product continuity! And don't forget to discuss findings with your IP counsel as matters of license suitability may warrant legal review and possible changes in your approach.

For an introduction on the SBOM concept, see this CircleCI post at or this CrowdStrike post as good starting points.

For an introduction to BSL from perspective of an implementer, see this excellent post by MariaDB , whom most acknowledge as the first to implement the concept.