Suggestion: Adopt REUSE (clearly indicate licensing of each file)

General
1

“REUSE was started by the Free Software Foundation Europe (FSFE) to provide a set of recommendations to make licensing your Free Software projects easier.”

This is really just to make you aware that this thing exists and start a discussion on whether you see this as goal worth pursuing; before many of our new repositories become so big that’s a hassle to start doing something like this.

I’m interested to hear what you think!

(Edit: In case this is something we would like to have, I’d of course prepare the relevant PRs.)

6 Likes
2

I think using REUSE for Aux projects is a good idea. But in a similar vein to Voting for a licence - #22 by isabel, it can only be used on Aux created projects. Which I think should be fine.

3 Likes
3

As a note in this, what we do with our open sourced projects at our small dev shop is we maintain files in simple, clean, format and then when CI pushes a version live it:

  • Drops a LICENSE file in the repo root, with the license text (MIT in our case, but could ofc. be whatever).
  • Prefixes the same license text to all source files in the repo.

Not sure if that is relevant for aux as we have a clean internal/external split, where I’m not sure such a thing makes sense for aux, but I figured it was worth mentioning.

3 Likes
4

so the idea is every file needs copyright stuff at the top?

2 Likes
5

Any file not pulled from current nix yes

6

not to be overly dismissive but that sounds like a lot of boilerplate / chore. what’s wrong with just a LICENSE in the relevant folder?

3 Likes
8

That’s a valid point.

There are several reasons I can currently think of (in no particular order; but numbered so that each can be specifically referred to):

  1. accurately depict the actual license of the file across license changes
  2. clarify the license in mixed license setups, e.g.:
    • mixed docs & code (with different license for docs)
    • incorporating code that originally belongs to projects with a different license (one possible example being patches included as part of packaging, which usually are seen as derivative works of the original project, and therefore have the project’s license)
  3. make it easier to copy stuff from the repo, since just scrolling to the top of the file gives all needed information
4 Likes
9

What use-case is there to license docs differently from code? I don’t think I’ve ever seen that done in a project I have worked on.

10

Eg: If you want a program under GPLv3 or 0BSD or something, docs for the program will always have to be in MIT to be contributed back to nix, unless you don’t want the docs contributed back to nix, however we are trying to make sure to push back what we can to it.

2 Likes
11

my main issue with including license/copyright info in the header of files is that it becomes an annoying extra step. it’s a lot of boilerplate for not a lot of benefit.

for the case of mixed licenses for docs and whatnot, other projects (k8s iirc) have dealt with this in much simpler ways, such as maintaining a file noting what licenses cover which parts of the projects (i.e. “docs is licensed under CC-BY-whatever, src is some license, some marketing material is copyrighted by whomever”)

i suppose there’s a benefit specifically for aux, as derivations could be lifted directly and used elsewhere, but even then wouldn’t we want a license that permits that (at least within reason)?

3 Likes
12

That’s a totally valid concern.

I believe this could be solved by bulk-licensing directories, which is basically the thing you said: maintaining a file noting which parts have which license (but in a standardized format).

3 Likes