What is a good open source license to choose?

allmende
1

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

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

According to Blame · package.json · dev · ecobytes / web · GitLab 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:

CompatibilityAGPL 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 LicenseBecause 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?The 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:

Secure and Govern service offer

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.

Wikipedia has our back, bilingually this time.

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.