cc our friendly license enforcement lawyer @armijnhemel for his opinion

I am actually not a lawyer, but an engineer :-)

So not legal advise blah blah blah.

The idea doesn't look bad, but I would strongly suggest to start adopting SPDX short license identifiers in the Nix recipes:

https://spdx.org/ids

as that is picking up quite some steam these days.

But let's involve a real lawyer who understands nix @silverhook

Good news, license identifiers are already SPDX when possible, though they do not use the strings directly.

Actually, that list does not adhere to the latest SPDX standard:

https://spdx.org/licenses/

Quite a few license identifiers were deprecated when 3.0 was introduced in January or so.

Yes, I am very well aware of that :-)

What I could imagine is that there would be a top level COPYING or COPYING-NOTICE file (doesn't really matter that much, as long as it is clarified in the README) and that each recipe at the top has some SPDX identifier identifiying the license of the recipe itself. This can be complete independent from the declared license of the package. Document that in the README (and include the policy of what licenses are OK for recipes in nixpkgs) and it should be fine.

In my experience these things cannot be automated perfectly and just serve as a hint to help find possible license problems. Don't overthink or search for problems where there are none :-)

To be honest, I really don't understand the advantage of splitting this into two files, which seems like a strict pessimization (since it clutters the top-level directory even more and makes it possible that people see one file but not the other). So what if GitHub doesn't detect the license correctly? This file is intended for human consumption.

I think one of the main draws of the GitHub thing is that the legalese in these license files is not really intended for general human consumption, but rather for lawyers. Ours happens to be particularly simple to interpret, but I think most people's eyes glaze over as soon as they see anything resembling a license, especially if it has a bunch of all-caps nonsense down at the bottom 😄

Furthermore, most people who are aware of software licenses have a general picture of MIT/BSD/Apache/GPL and what they mean in broad strokes, but what's confusing is that the MIT license doesn't actually say MIT anywhere in the text. So unless you're very familiar with what it looks like, or your eyes don't glaze over when you read legalese, you don't actually know at a glance that this is an MIT-licensed project.

So I do actually think that the GitHub license explainer widget is far more useful than the raw text, which nobody ever reads, and only experienced FOSS contributors can recognize easily.

I agree with @armijnhemel that SPDX IDs are a great thing. BTW, REUSE.software are some good best practices (and scripts) for it. It doesn’t address the distro PoV much yet though – perhaps someone should post distros’ concerns/ideas to its issue tracker (hint hint).

Legally speaking it matters little whether you have the notice in the README or LICENSE or COPYING. I think it’s OK where it is, but it would just as well fit well in either README or even FAQ. Personally, I would keep license text canonical and add further info in README.

Regarding GitHub’s scanner, for any serious compliance work it completely oversimplifies the situation. But as a quick indication of what the (most probable) main outbound license of the project is, it can be quite useful.

Let’s not dive into how much people grasp the nuances between licenses – e.g. here’s a line-for-line analysis of the MIT license (only) from the US legal system’s PoV ;)

To sum up, I don’t see a huge need for the change; but if we’re doing it, I would expect the notice (as well as mention of MIT) in the README file.

Just putting the notice in README.md seems like a reasonable thing to me. People are more likely to read that than the COPYING file.

Similar idea merged in #48320