An archeaological dive through a software copyright concern

My friend Artemis wrote about unlicensed code finding its way into Linux distributions. How did this happen? Let’s do a little bit of software archaeology¹.

The unlicensed code in question² is a Go library for parsing unified diffs. tea, “the official CLI for Gitea”, uses this library to allow users to review pull requests from the command line. The feature was merged into tea at the end of 2020; the most recent commit to the library’s original repository is from 2016. An issue from someone who is likely the tea feature’s author asking for license clarification has gone unanswered.

We’ll discuss some background information, look at where various systems succeeded and failed, and finally ask whether any of this matters.

diff --git a/nexus/src/external_api/console_api.rs b/nexus/src/external_api/console_api.rs
index 1d1fa18c..119b19ea 100644
--- a/nexus/src/external_api/console_api.rs
+++ b/nexus/src/external_api/console_api.rs
@@ -586,7 +586,13 @@ pub async fn console_index_or_login_redirect(
     // otherwise redirect to idp

     // put the current URI in the query string to redirect back to after login
-    let uri = rqctx.request.lock().await.uri().to_string();
+    let uri = rqctx
+        .request
+        .lock()
+        .await
+        .uri()
+        .path_and_query()
+        .map(|p| p.to_string());
# Can you explain why this is necessary in your commit message?

     Ok(Response::builder()
         .status(StatusCode::FOUND)

On Aug 19, 2022 at 14:10, iliana etaoin <iliana@oxide.computer> wrote:
> -    let uri = rqctx.request.lock().await.uri().to_string();
> +    let uri = rqctx
> +        .request
> +        .lock()
> +        .await
> +        .uri()
> +        .path_and_query()
> +        .map(|p| p.to_string());

Can you explain why this is necessary in your commit message?

Why do we care about licensing?

In most countries, works are automatically copyrighted, and there are minimum standards for exclusive rights the author of that work retains. As someone living in a party to the Berne Convention, this blog post I wrote is automatically copyrighted, despite there being no notice informing you of this.

After making the logical leap necessary to apply those minimum standards to the software world, we can understand that software, by default, probably cannot be used, modified, or redistributed without a license from the copyright holder. There is significant case law on the copyrightability of software that we are not going to read, and there are a lot of open questions that we are not going to try to answer, but most of the important open questions have been solved: if you want to use someone’s software, you need a license, and if you want others to be able to use your software without asking permission, you need to grant a license.

The usual expectation is that you are publishing a copy of your software so that others can use it, but this is not necessarily true; licenses make that explicit. Some licenses, such as the MIT License, permit damn near everything as long as you include a notice from the copyright holder; some require more significant responsibility, such as the AGPL, which requires that you provide a copy of the software to anyone who can access it over a network³; some are purposefully restrictive, or desperately trying to keep megacorporations from destroying their business, or are jokes purporting to be a legal document.

The short version: you can’t really use software without someone giving you permission, and there are lots of widely-accepted ways to give people permission to use your software.

What does a Linux distribution do, exactly?

A Linux distribution distributes Linux, which is software. As a side effect, Linux distributions⁴ usually also distribute additional software that is compatible with Linux, so you can check that your copy of Linux is working correctly, and also so you can make use of it at all.

The groups of people who build and maintain Linux distributions have many goals, but they usually boil down to two things:

1. Ensure that they are allowed to distribute the software contained in the distribution.
2. Ensure that their users are allowed to distribute the software, too.

And so, being a Linux distribution maintainer involves a lot of reading software licenses and asking lawyers about them, if you’re lucky enough to have lawyers. The bureaucracy of Linux distros is overwhelming, and requires writing policy manuals, providing legal guidelines, and building automation to make what is usually a volunteer-driven system work at all (and licensing is somehow one of the least complex topics in distribution development).

Rigid systems are resistant to change

Go and other languages⁵ that statically compile dependencies prove to be difficult for many Linux distributions. A lot of distribution maintainers suggest that static linking creates security issues down the road, but this is really a tertiary problem; the explosive dependency trees, including using multiple versions of the same package at once, break the assumptions that Linux distributions made in past eras⁶. Perl and Python packaging are difficult, and the npm, Go, and Rust ecosystems exacerbate the fragility of Linux distribution infrastructure even further.

It is becoming more difficult each day to keep an eye on the license of every single piece of software that gets slurped into a distribution. Automation helps, but is expensive to write and maintain, and every ecosystem is subtly different with so, so many exceptions to the rules. For more popular distributions (such as Debian and Fedora) that ultimately feed into ecosystems that are sold to customers (such as Ubuntu and RHEL), policies and guidelines help, but other distributions might not have (or want!) the procedures necessary to ensure what they ship is properly licensed.

So. Where did these systems succeed?

• Someone wanted to use some unlicensed software, and asked the authors to clarify a license.
• Someone trying to package software for a distribution found the licensing problem.

Where did they fail?

• The person who wanted to use some unlicensed software used it anyway after the authors didn’t respond.
• Maintainers of tea did not check or inquire about the licensing issue (but I’m not really sure if that’s their responsibility).
• Packagers and maintainers for several distributions did not catch the problem, likely for a lack of tools or advice to check licenses of dependencies.
• Even when dependencies are licensed, attributions or notices required by the license aren’t always distributed with the final binary artifacts.
• I wrote this blog post instead of filing any issues with Gitea or the distributions that ship tea. (It sounds like a lot of work.)

Does any of this actually matter?

No.

Think about it. All of the distributors of this code tracked in Repology are community-operated, as is the Gitea project; the risk-reward ratio of theoretical copyright litigation is not good, especially when litigating against open source projects tends to paint a target on your back.

The larger distros with a focus on making redistribution painless are not shipping this code — not for any license auditing reasons, as far as I can tell; just that packaging is hard, there’s a lot of software, and not a lot of people who care to do the work.

Distros can mitigate the issue by removing the code review functionality from the CLI. Anybody could take a better-licensed unified diff parser and add comment support to replace the unlicensed code. Or nothing could happen at all, and it would probably be fine.