I am not a lawyer. Today I wanted to package the tea command line utility, which is a CLI frontend for the gitea git forge. Gentoo’s guidelines for Go helpfully states: “Since Go programs are statically linked, it is important that your ebuild’s
LICENSE= setting includes the licenses of all statically linked dependencies. So please make sure it is accurate”. Naturally, I’m happy to oblige. So you know, I go looking at the licenses for
tea’s dependencies, and it turns out one of those dependencies doesn’t have a license at all! I’m no expert, but this may violate the GNU Free System Distribution Guidelines that distributions like parabola strive to adhere to. Oh fun.
UPDATE 2022-08-22: I didn’t expect to get as big of a response to this post as I did. But I’m glad everyone has discovered the joys of licensing software. Personally in my day to day life, when I’m not doing stuff for work, I’m not regularly checking software licenses. I also actively encourage individuals (not companies!) to steal my unlicensed code for their own uses. I usually add a license only once I get to the point of “yeah someone packaging this for a distro wouldn’t be a mistake”. If you’re running a community-based linux distribution, you probably get to be this lax too unless someone actually invokes their copyright power, and generally speaking, if you haven’t made anyone angry, who will? I’ve made this post more bombastic than the topic deserves, but in the process I hope I’ve introduced you to the legal webs of copyright we’ve woven for ourselves. Go read iliana’s post for a more toned down and technical version. Anyway, the post as-written continues:
And this isn’t a targeted dig at parabola. Looking at repology’s list of distributions that package tea, we see Arch in there, Alpine, nixpkgs. It seems like “MIT” is the most common license that distros are listing this as. Everyone seems oblivious to the fact that this binary is a license turducken several times over. (EDIT: it’s 30 minutes after posting and there is now an issue on alpine’s aports about this.)
So what is this unlicensed package? Well according to
🚫 gitea.com/noerw/unidiff-comments <license not found or detected>
Checking gitea.com/noerw/unidiff-comments, we see that this is actually just a mirror (fork?) of github.com/seletskiy/godiff, just repackaged a bit for go modules. And there’s an open issue on the original repo, by the owner of the unidiff-comments repo on gitea, with no response:
lmao. So basically, someone forked seletskiy/godiff, wrapped it up into a module, imported it in
tea for a couple lines of functionality, and now every distro is claiming that this binary is licensed under a license it almost certainly is not, and probably redistributing it illegally. You can’t just do this. When a source code doesn’t have a license, you don’t just get to decide you want to use it anyway, and if you do, people certainly can’t go around distributing binaries of it.
But it gets worse. Let’s take a look at another go package, Restic. At least all the code for this one is licensed. But looking at the repos for debian and arch, they don’t even agree on which license it’s using! It seems like basically every go package is listed under the license of ONLY the top-level project rather than including the dependency tree, and at least one of them is getting THAT wrong too. Meanwhile, restic uses software licensed under MIT, BSD, Apache, and whatever fresh hell is going on over here.
I checked the Debian Policy Manual, which states:
the copyright notices for any files which are compiled into the object code shipped in the binary package must all be included in /usr/share/doc/PACKAGE/copyright when the license requires that copyright information be included in all copies and/or binary distributions, as most do.
Which is definitely not what’s going on here. And if you thought this just affected go packages, compare
cargo license against debian’s
copyright file for ripgrep:
$ rg 'License:' /usr/share/doc/ripgrep/copyright 8:License: Unlicense or MIT 12:License: BSD-3-clause 18:License: Unlicense or MIT 20:License: MIT 39:License: Unlicense 63:License: BSD-3-clause # The N/A here is because the version of encoding_rs in the dep-tree had their # license specified in a way that confused `cargo license`, don't worry about # that part. $ cargo license Apache-2.0 OR BSL-1.0 (1): ryu Apache-2.0 OR MIT (36): base64, bitflags, bstr, bytecount, cc, cfg-if, crossbeam-channel, crossbeam-utils, encoding_rs_io, fnv, glob, hermit-abi, itoa, jemalloc-sys, jemallocator, jobserver, lazy_static, libc, log, memmap2, num_cpus, once_cell, proc-macro2, quote, regex, regex-syntax, serde, serde_derive, serde_json, syn, thread_local, unicode-width, unicode-xid, winapi, winapi-i686-pc-windows-gnu, winapi-x86_64-pc-windows-gnu MIT (5): atty, clap, fs_extra, strsim, textwrap MIT OR Unlicense (16): aho-corasick, globset, grep, grep-cli, grep-matcher, grep-printer, grep-regex, grep-searcher, ignore, memchr, regex-automata, ripgrep, same-file, termcolor, walkdir, winapi-util N/A (1): encoding_rs
So, to recap, we’ve got distributions of a go package that includes entirely unlicensed code. We’ve got a host of go packages that may not be complying with the terms of the license (iamnotalawyer), when the distributions can even agree what the license is. And it’s apparently not limited to just go. Is this normal? Is this legal? I don’t really know. Can someone please tell me what the fuck is going on with licensing because I am losing my goddamn mind.