Notes




🏭 web#56 LICENSE

Date

Description

Author

2023-12-20

Refactor research from issue here

@yala

[TOC]

I—What is a good open source license to choose?

It is common practice to put a LICENSE(.md) file at the root of the repository. The GitHub documentation mentions this in two places.

Files in the expected location will receive honour by the GUI of the forge with extended visibility. GitHub displays it as a license badge, and GitLab offers to create one with a click:

Add a LICENSE button in GitLab

Add a LICENSE button in GitLab


When such a file is present at the canonical location, it will be considered by meta data scanners and crawlers as well.

According to https://lab.allmende.io/ecobytes/web/-/blame/dev/package.json?ref_type=heads#L10 we've inherited MIT from PhilDL philippe.lattention@hotmail.fr, but I'm also fine with a lesser permissive licence such as AGPL without CLA.

How to determine compatibility with licenses from dependencies?

The Wikipedia page about License compatibility (Yes, that exists! But unfortunately not (yet) in German.) shows a nice graph on how common licenses relate to each other:


This graph is also explained in the article License Compatibility: Combining Open Source Licenses | Mend.

There's a lot more to learn about Comparison of free and open-source software licenses at Wikipedia, but of which much is written too much in legalese for me to be put well into context right now.

It appears we'd do good in discussing this on the basis of empirical evidence, and seek to understand which licenses are involved in the dependency tree of this project, and the live server implementation.

Reconsidering the most restrictive open source license, the AGPL, I

It might be that using AGPL comes with considerations. The article Open Source Software Licenses 101: The AGPL License on FOSSA.com puts it quite well:

Compatibilit
\nAGPL isn’t technically compatible with other licenses, including the GPL v3. However, as explained on GNU.org, a developer can combine separate source files and/or modules licensed under GPL v3 and AGPL into a single program
Use of the AGPL Licens
Because the AGPL is quite restrictive when it comes to the reuse of the licensed code, developers must think long and hard about how they want others to interact with their software before selecting this license. Are they hoping for widespread adoption of their code by other companies? Do they want any changes to their code to remain public or “open source” in its purest sense
\nThe GNU Project recommends that any programmer looking to build software that would generally be run over a network consider the AGPL. However, making this decision does come with potential drawbacks. In choosing this particular license, a developer is basically ensuring that no future versions can be made proprietary, which might not make their code popular among commercial software enterprises. (For example, Google has a strict policy prohibiting any use of AGPL-licensed code.) And, with the growing popularity of SaaS as a business model, that developer might be cutting themselves out of a large swath of the market.

Considering permissive licenses and the Creative Commons in the public domain

In other times, we have also preferred permissive and even public domain licences, such as MIT or WTFPL. A contemporary hack and quite an equivalent to white voting when dropping in an empty ballot sheet to have it counted as participation, but not for consideration, could be to assign CC0, which is compatible with GPL.

May I apply CC0 to computer software? If so, is there a recommended implementation?

Yes, CC0 is suitable for dedicating your copyright and related rights in computer software to the public domain, to the fullest extent possible under law. Unlike CC licenses, which should not be used for software, CC0 is compatible with many software licenses, including the GPL. However, CC0 has not been approved by the Open Source Initiative and does not license or otherwise affect any patent rights you may have. You may want to consider using an approved OSI license that does so instead of CC0, such as GPL 3.0 or Apache 2.0.

via CC0 FAQ - Creative Commons (annotation)

Unfortunately I have no experience with the mentioned Apache 2.0 license, and cannot comment on it.

Reconsidering the AGPL, II

multi licensing - Usage and compatibility of AGPL in the context of permissive licensed dependencies - Open Source Stack Exchange has it quite clear about using AGPL:

My question is, in this case, is it possible to apply the AGPL license on my code [...]?

Yes, it is possible to apply the AGPL license to your code. All of your dependencies allow you to use them under a (A)GPL-compatible license.

I don't know anything about a NOTICES file that is mentioned further down, to be able to make a qualified choice about it. But I like how Wikipedia speaks about the role of potential application service providers (ASPs) with regards to the "ASP loophole" in the AGPL:

ASP-Schlupfloch

Bei der GNU General Public License (GPL) gibt es die als ASP-Schlupfloch (englisch ASP loophole) bezeichnete LĂĽcke, nach der Unternehmen, die eine GPL-Software nur im Hosting bzw. als Application Service Provider (ASP) anbieten, den Quelltext nicht weitergeben mĂĽssen. Dadurch hat das Unternehmen ein Monopol auf alle Erweiterungen und Verbesserungen, die es in die Software einbaut, da weder Konkurrenten noch Nutzer, die die Software selbst betreiben wollen, einen Rechtsanspruch auf sie haben. Bei der GPL besteht nur bei der Weitergabe der ausfĂĽhrbaren Datei ein Rechtsanspruch auf den Quelltext.

Die AGPL schließt dieses Schlupfloch, indem sie auch den Anwendern, die die Software über ein Netzwerk nutzen, eine Downloadmöglichkeit für den Quelltext garantiert.

That said, to continue with license scanning of our upstreams, we'd need to figure something that GitHub offers to all and GitLab offers to enterprise customers only:

The Gitlab documentation for their Secure and Govern service offer also mentions the method that will help us to replicate the same feature in our GitLab CI, namely: SBOM, a Software Bill of Materials.

They explain the higher levels of the concept as part of their marketing PR in The ultimate guide to SBOMs (2022)

In an SBOM, software licenses are usually identified by an software package data exchange (SPDX, spdx.dev) identifier.

The article What Is The SPDX Standard and How Is It Helping The Software Industry? (2022) gives a good summary of using SPDX for SBOM. It also mentions actual tools to generate the package profile. Interestingly, most of these tools work on immutable containers, which will also be of subject in #50, in so the integrity of the content-addressable artifact can be guaranteed and cryptographically signed.

Eine AusfĂĽhrliche Darstellung des Themas auf Deutsch findet sich auf Software Package Data Exchange (SPDX): Wie SPDX bei der Compliance-PrĂĽfung von OSS-Lizenzen hilft (2017).

Ein "Fact Sheet" bietet SPDX vom Open-Source Guru.

Let's take a look at practical consequences of generating an SBOM with SPDX identifiers for the dependency tree and our own source code in the next section.

II—Software Bill of Materials (SBOM) and the Software Package Data Exchange (SPDX)

grafik

grafik


When characterising SBOMs from the perspective of data at first (data-first), there are two main format specifications that inform the discussion around SBOM representations, CycloneDX and SPDX.

As they spring from different ecosystems, eras and learnings, they bring different tooling with them. For the previous reasons of assuming a container-native development environment in #50, we will focus on the cloud-native approach with SPDX here.

Remarks on the SBOM platform choice


An example pipeline in the OWASP example with dashboard is given with:

Licence compatibility tooling is possible with standardised formats and methods. This does not mean that there are other approaches to solving the riddle.

A notable addition is flict, a license compatibility tool. It integrates the OSADL matrix and allows for computational inferrence of the actual compatibility.

Its vendor also offers an integrated container with multiple tools, which is sufficiently up to date.

Programs on the image

For people who feel tempted to learn more about the actual implementations, the go-license-detector has a readme section about the quality of source code license classifiers, and they keep an analysis of documentation practices that lead to detection failure. The Ninka link is broken here, but the project is on GitHub.

This collection of compliance tools could be considered canonical for some use cases. We will have to come up with our own requirements and answers to them later.

Exploring the SPDX ecosystem

The SPDX ecosystem springs around the idea of Handling License Info with SPDX. Conventional practices in the field are combined in FSF's REUSE initiative that proposes to write one line with a small license header into every source code file.

From an even higher level, license compatibility can be seen as a specific case of licence compliance, esp. in governmental and corporate environments, and REUSE offer a Comparison of license compliance projects. In addition, the SPDX initiative holds a list of Open Source Tools, from validating CLI tools via SPDX generators in various languages to large-scale license auditing platforms for repositories in internal and public source code forges and artifact stores.

Hommage Ă  l'ascendance: OWASP, CycloneDX and DependencyTrack


The SPDX community builds on previous experience in enterprise compliance and license management. This list is not exhaustive, and does not contain (legacy) platforms like ClearlyDefined or FOSSology recommended by REUSE.

Screening SPDX tooling and further resources

SPDX generators

The main work of SPDX generation is automated by CLI tooling that is employed in CI pipelines. These are common projects built on different language platforms. Choosing a compiled language will greatly decrease execution time, as no script interpreter is involved. The effect adds up upon multiple runs, why emphasis on speed is good here.

Visualisation

There are other projects for visualising SPDX data, either in a browser workbench, or as DOT files for graphviz graphs.

SPDX platforms

More integrated management of SPDX for large numbers of repositories is possible with dedicated platforms.

Cloud-native vulnerability scanning, including SPDX SBOM

The whole story around more standardised SBOMs emerged in parallel with discussions on vulnerability scanning in immutable, cloud-native environments. Microsoft lead the way here around SPDX and put a lot of effort in supporting this in the Azure cloud, while the ecosystem eventually catched up. But others like Snyk (commercial) and Aqua Security Trivy (FLOSS) were already concerned with automatic scanning of software artifacts, but with regards to security. It was only natural for them to also acquire the capability to generate SBOMs.

Trivy, the most common FLOSS tool employed in this area, has widespread integration with other platforms, e.g. the container and OCI artifact registry Harbor, as well as CI pipelines.

As we can witness, most cloud-native tooling is written in Go.

Auxiliary resources

Notable findings in the SPDX ecosystem

While technical and corporate in nature, we can extract some practical and theoretical knowledge from the context provided here. First, there is a simple web app that allows to display and analyse the content of SPDX records. Second, we find an exhaustive tutorial by an author of another CC content on the subject of license compatibility, written ten years later. It subsumes many of the discussions around SPDX, and what it is used for. Third we also find a reference to Nix, which has native support for deriving SPDX records from its more sophisticated data model about software.

Web app

The SPDX initiative offers a web application to analyse and modify SPDX documents further.


Tutorial

This piece from 2016 onwards is written by the author of the licence compatibility chart on Wikipedia from 2007 above and very exhaustive, including actual reasoning about license recommendations. It is the most permissive OSI license MIT, our current one, which is preferred there. The AGPL doesn't find a mention.

Adjacent Nix theory about The Purely Functional Software Deployment Model

grafik

grafik


edolstra.github.io/pubs/phd-thesis.pdf at master · edolstra/edolstra.github.io

More on what this means for us and what we can do with that information now in the last part.

III—What to build an SPDX inventory in GitLab CI with?

As a sketch, because another question than choosing a license was to find an answer on license compatibility, we can ask how to create an SPDX SBOM of this project with GitLab CI for license transparency, and then comparison. There are several paths that we can take:

  1. Repurposing GitLab's already available free Trivy integration for security scanning to also supply SBOMs

  2. Using the Go Syft to create an SBOM

  3. Using the Kotlin ORT to create an SBOM

  4. Using the flict compliance-tools image to not only create the SBOM, but also to programmatically evaluate the license compatibility.

Other SPDX tools, like tern, scancode, sbom-tool or spdx-sbom-generater, are left out of discussion for lack of documented GitLab examples.

1. Trivy

GitLab has native integration of Container Scanning via Trivy or Grype, exposed as a reusable components made up of CI/CD templates in the CI/CD catalogue. The capabilities of the free version are naturally limited here, but we can work around that fact with using other components available for the standard that is used.

The Dependency Scanning and the visual Dependency list features in GitLab may be restricted, but the side-effect of Trivy generating a dependency list is not.

The restriction can be found around visualisation- and compliance-related behaviours. The official SPDX web app will be sufficient to provide little interactive framing of what we have at hands here, while other interfaces from the ecosystem remain available.

For Node.js, Trivy supports dependency resolution via the PNPM lock file, and license resolution via package.json.

The GitLab documentation suggests to Enable Container Scanning through an automatic merge request, which happens on the Security configuration · ecobytes / web · GitLab page, which was previously disabled.

Who'd known they'd walk in a workaround without UI to their commercial offer.

More reference about the Trivy integration in GitLab can be found upstream at both vendors:

Ultimately we want to Scan a Docker container for vulnerabilities (Tutorial) | GitLab, but Export [a] dependency list in SBOM format (Tutorial) | GitLab as we would with enterprise features.

2. Syft

In case the Trivy approach does not work out as expected, we can try to implement this with syft alongside these introductions to manually scan container images:

Including a pipeline that starts off from something along the lines of this:

3. ORT

With backing by the FSFs REUSE initiative, there is sufficient reason to also consider ORT as a viable option.

4. flict compliance tools

When we have sufficient reason to believe that a license conflict exists, i.e. by inspection of a SPDX report in one of the workbenches, we could consider mobilising flict and family from the compliance-tools container to provide additional evidence, and programmatic reevaluation of the possible confict with using the OSADL matrix. We may want to rist another peek into that any way.

Just clicking the Configure with a merge request button for Static Application Security Testing (SAST) will currently unfortunately yield the error: "Something went wrong. Please refresh the page, or try again later." Not to mention that a reload does not solve the regression. This may be due to a missing container in the package registry in the first place.

All of this will be a nice experiment, another time.