Sector 7G's Learning Center

Articles • Tips • Tutorials

License Compliance: Pre- and Post-Composition

Mar 12, 2022 | Greg Butler

Topics: Open Source

Audience & Level: Non-Technical & Intermediate

Intro
2021 saw increased OSS license compliance attention including Gartner and Forrester reports and volumes of other, related information. Most content was, and continues to be, directed at left-shifted integration using various compliance assessment tools. While certainly important, a purely left-shifted focus may not address all code under compliance scrutiny. The remainder explains pre-composition (“shift-left”) and post-composition License Composition Analysis in a manner similar to code vulnerability testing.

Terminology
Audit: Used here, License Composition Analysis on an existing, post-composition codebase including formal “audit” for virtually any reason, SBOM support, or simply wishing to know the OSS license terms in one’s apps (or litigation discovery, but let’s hope not…).

LCA: License Composition Analysis, including inventorying, potential incompatibilities, and other factors (see Top OSS License Issues: Part 1 and Top OSS License Issues: Part 2).

Post-composition and Pre-composition: “Pre-composition” and “post-composition” are used for consistency with “SCA” (Software Composition Analysis), of which LCA is a sub-discipline. In addition, much discourse addressing OSS license compliance refers to the broader SCA category.

  • Post-: The application has reached or completed the package/deploy stage.
  • Pre-: The application has not reached the package/deploy stage.

Pre-Composition and Post-Composition
Pre-composition
Consider the following abstract depiction of a typical workflow with pre-composition highlighted in yellow including integrated and automated checks, builds, tests, and other tasks as the work is being composed. Some occur far left, others farther right, some both, but “where” is immaterial for this discussion since, regardless, these sentinels share a common purpose: Protect the composition.

A typical LCA tool is not unlike a code vulnerability assessment tool–in fact, LCA/license compliance vendors have leveraged their code vulnerability products to also perform license analysis. The following illustrative sequence may therefore be familiar:
  1. A developer subjects an OSS component to first-pass LCA assessment, perhaps by referencing a GitHub repo or scanning a local copy.
  2. Assuming it passed, the same tool’s integration features perform LCA review, but more comprehensively accounting for, e.g., potential license term incompatibilities.
  3. Additional automation, and again like vulnerability assessment, reevaluates the codebase regularly in the event that, for example, license terms changed (it happens…), a problematic component has been upgraded with satisfactory terms, and so on. Once again, very similar to continuous vulnerability assessment.
Simple enough, right? Essentially we dual-purposed vulnerability assessment to also perform LCA and, presto, license compliance. However, while the above sequence depicts how today’s software is being created, it does not necessarily represent the volume of software that has been created. More specifically, and while unquestionably beneficial, it focuses on DevOps stage/pre-composition but not post-composition analysis. Post-composition Assume an organization has amassed a portfolio of applications but OSS specifics are absent. Also assume that none of the applications have been subject to any LCA, including the pre-composition flow described previously. Lastly, assume the organization is facing an audit—perhaps regulatory or for merger, funding, or vendor diligence. As with any such endeavor, compliance is critical, but when our subject entity is requested to produce license compliance information, they may not know where to start other than here:

A post-composition LCA effort is both a software and license decomposition exercise: The software is decomposed to reveal licensing, licensing is decomposed to reveal terms, owners, and related attributes, and the cycle repeats since license details may reveal additional components, thereby requiring both its own and its licensing decomposition, and so on until the inventory of components and applicable licenses are reasonably ascertained.

The manner in which post-composition audits are conducted varies greatly and are highly code-, organizational-, and context-specific. At one extreme, third party software audit specialists may be required. At the other, the same tool for pre-composition LCA may suffice (with legal, risk, and compliance input), but mileage here may vary since many vendors, at least as of Q4 2021, do not necessarily distinguish pre-composition from post-composition (the latter, as mentioned, a potentially deep exercise) or focus only on pre-composition. Nevertheless, certain events–such as increased attention from market researchers, legal profession articles, and M&A activity–may be signaling a shift whereby pre-composition/DevOps LCA is integrated, but not conflated, with post-composition/audit LCA.

Final Thoughts

OSS license compliance automation, namely post-composition, while still in relative infancy is quickly emerging. Expect 2022+ to see advances not only in pre-composition, but especially more so in post-composition and subject matter focus.

Nevertheless, it may stand to reason that both ISVs and non-ISVs should incorporate LCA tools. Reasons include:

  • Current LCA tools are not required to be integrated; none featured by Gartner and Forrester in 2021 are incapable of assessing local-only codebases (e.g., raw files on disk) and related artifacts. As a result, compliance analysis tools aren’t necessarily prohibitive for non-ISVs or teams performing no development.
  • Integrated or not, and referencing a prior statement, LCA tools act as sentinels thereby, and presumably, reducing the “unknown” whether resembling the fictitious scenario described above or virtually any variation.
  • The tools output a variety of composition (and, therefore, not only compliance) reports, whether dashboards or exportable formats including SBOMs. Although the complete picture may not be painted for an audit, pulling back some of the curtain is better than none.
  • Vulnerability analysis: If a development team is not using code vulnerability analysis tooling, it should, and as stated license analysis more than likely is a feature. Likewise, teams having already integrated code vulnerability checks potentially have a head start by enabling and configuring the tool’s license compliance capabilities.

DISCLAIMER
Sector 7G Consulting LLC (“Sector 7G”) does not provide, nor should anything from Sector 7G be construed as, legal advice nor the establishment of legal representation or attorney-client privilege. Additionally, Sector 7G strongly encourages reviewing all licensing and OSS analysis work product with their legal counsel.

Cyber Defense: Information and Parity
The Hitchhiker's Guide to SCA and SAST