rust-lang repos that do not declare licenses

[brson]

It came up today that kate-config does not have a license file. I filed a PR to fix that, but there are others.

• crates.io-index - I'm not sure if this needs a copyright license since it isn't a work of creative expression, but it might still be worth putting something explicit in there just to fend off questions. Maybe there's some sort of 'open-data' license that's appropriate. https://github.com/rust-lang/crates.io-index/issues/3
• blog.rust-lang.org
• This repo needs LICENSE/COPYING, also README blog.rust-lang.org#63 CC-BY suggested
• regex - Declared in Cargo.toml but no accompanying license files. has dual Apache+MIT
• rfcs - This is a mess. It should have the MIT/ASL license per our other docs but we didn't have the foresight to do it. - Does this repo need a LICENSE or COPYING file? rfcs#1259
• rust-buildbot - now dual-licensed
• meeting-minutes - Doesn't matter probably.
• rust-www - This is tricky. It contains a COPYRIGHT file, but I believe we put it there to have a license to link to for Rust itself. We can probably argue that the entire website falls under that license.
• Add Apache and MIT license texts? prev.rust-lang.org#174
• rust.vim - Please add a LICENSE file rust.vim#45
• rust-mode - Please add a LICENSE file rust-mode#91
• rust-packaging - contains licenses now
  -[ ] gedit-config - dual-licensed repo abandoned
• rustup - rustup.sh itself contains the license, but not the rest. and repo contains both license files
• rust-installer - ditto
  - [ ] rust-wiki-backup - decommissioned partially because it was not properly licensed repo archived
• rust-guidelines - repo was decommissioned and moved
  - [ ] nano-config - Only contains copyright notice, not license Has both licenses repo archived
  -[ ] zsh-config - ditto repo archived

Update:

• docker-rust
• License the docker-rust repository under MIT/Apache-2.0 dual license docker-rust#207 - Adding License Statement (MIT and Apache) docker-rust#74
  [ ] docker-rust-nightly (the repository has been archived, the licensing is now being done in docker-rust)
• crater mentions a license in README, even though the license files are not included in the repo
• bors: bootstrap commit
• surveys
• License the surveys repository under the MIT/Apache-2.0 license surveys#267
• Add MIT/Apache-2.0 license surveys#266
• rustc-perf
• License the whole rustc-perf repository under the MIT license rustc-perf#1933
• Add top-level license file rustc-perf#1881
• fmt-rfcs: Add a license statement to README and add LICENSE-* files style-team#174
• .github
• rust-lang.github.io
  [ ] https://github.com/rust-lang/project-rfc-2229 (archived)
• https://github.com/rust-lang/wg-debugging
• https://github.com/rust-lang/wg-cargo-std-aware
• https://github.com/rust-lang/wg-allocators
• https://github.com/rust-lang/moderation-team
• https://github.com/rust-lang/wg-incr-comp
• https://github.com/rust-lang/compiler-team-prioritization
  - [ ] https://github.com/rust-lang/rustc-timing (archived)

[edunham]

• crates.io-index - I'm not sure if this needs a copyright license since it isn't a work of creative expression, but it might still be worth putting something explicit in there just to fend off questions. Maybe there's some sort of 'open-data' license that's appropriate. https://github.com/rust-lang/crates.io-index/issues/3
• blog.rust-lang.org This repo needs LICENSE/COPYING, also README blog.rust-lang.org#63 CC-BY suggested
• regex - Declared in Cargo.toml but no accompanying license files. has dual Apache+MIT
• rfcs - This is a mess. It should have the MIT/ASL license per our other docs but we didn't have the foresight to do it. Does this repo need a LICENSE or COPYING file? rfcs#1259
• rust-buildbot - now dual-licensed
• meeting-minutes - Doesn't matter probably.
• rust-www - This is tricky. It contains a COPYRIGHT file, but I believe we put it there to have a license to link to for Rust itself. We can probably argue that the entire website falls under that license. Add Apache and MIT license texts?  prev.rust-lang.org#174
• rust.vim Please add a LICENSE file rust.vim#45
• rust-mode Please add a LICENSE file rust-mode#91
• rust-packaging - contains licenses now
• gedit-config - dual-licensed
• rustup - rustup.sh itself contains the license, but not the rest. and repo contains both license files
• rust-installer - ditto
• rust-wiki-backup - decommissioned partially because it was not properly licensed
• rust-guidelines - repo was decommissioned and moved
• nano-config - Only contains copyright notice, not license Has both licenses
• zsh-config - ditto

[emberian]

@edunham CC0 seems suitable for the crates.io-index, if anything.

[eshellman]

Maybe I missed something, but this repo (rust-lang/rust) is also missing a license file.

[steveklabnik]

@eshellman https://github.com/rust-lang/rust/blob/master/LICENSE-APACHE and https://github.com/rust-lang/rust/blob/master/LICENSE-MIT

[eshellman]

Not sure how I missed that. not enough coffee yet.

[sanmai-NL]

I would like to take this issue up again.

What is the status?
Where is help needed?

Specifically on [licenses and copyright claims repeated in source code files](e.g. [mk/main.mk]%28https://github.com/rust-lang/rust/blob/a005b6785935d7e92e87774c8f585839ddd12e46/mk/main.mk#L1-L9%29), I hope we will soon make good improvement across the board. I propose that we remove them or reduce them to at most a single line.

Arguments

1. They hurt readability and conciseness;
2. They are a small extra hurdle to contributing changes (esp. from the GitHub web UI) since it makes you scroll down on every file;
3. Their use across source files violates the do-not-repeat-yourself principle;
4. Probably in large part due to the previous, they are undermaintained. E.g. something as basic as the year is messed up in a prominent place.

Issues, my positions on them
A. Who supports this position, that a single central license file in each repo should be used exclusively instead? I do, for sure. Only for GPL and/or mixed licensing it may be required to refer to the GPL again at the top of every file, but if we do then let us please use a one-line comment referring to the license file.

B. Who supports my position that a copyright claim is redundant, and that dating the copyright is even more redundant (certainly as the project keeps record using a VCS), and should be removed everywhere as a maintenance burden?

@brson: What has led to the situation that multiple licenses are applicable to the rust-lang code base? What can still be done to harmonize this to a single license?

[eshellman]

The copyright year only matters 95 years after the date of first publication (treating this as a work of corporate authorship). So this repo begins to enter the US public domain in 2098 under current law. Best practice is to maintain copyright notice in a single file and let VCS sweat the details.

[brson]

@sanmai-NL the issues you are raising seem to be different from this issue, which is about ensuring that individual rust-lang repos declare a license (and on that basis I think we can close this issue - most of the remaining undeclared repos are not worth the effort). So you might consider opening another issue if you think the Rust source copyright is not handled properly.

That said, the exact handling of the license declarations in this repo has been debated repeatedly over the years and I suspect there isn't much enthusiasm for re-litigating any aspect of it. The current scheme is as recommended by Mozilla legal long ago. It is true though that if we were to do it over with the benefit of hindsight I suspect we would push harder not to have the notice at the top of each file, nor to mention the copyright year. Here is an old discussion on the copyright year. We decided that mentioning the copyright year is useless, and that they should not be updated.

The primary Rust codebase is Apache licensed because we want a permissive license with a patent non-aggression clause; it is MIT licensed because the GPLv2 is not compatible with the Apache license. Other licenses apply because Rust includes source from other projects such as LLVM. None of this can be changed with any reasonable amount of effort.

[sanmai-NL]

@brson
Yeah it's a different issue but they are quite interrelated I think. This thread seemed to be the best to discuss the extra issue.

You wrote in that thread that the copyright notice at the top is not important legally, or so you had been advised (I assume by a legal professional). So I take it that removing them would be all right. I understand few will have appetite to consult legal professionals again though, if that's really what's needed.

Irrelevant or not, the top copyright notice, especially with years with typos etc., and if long, is a bit of a nuisance I think so I suggest you just get rid of it.

I wonder whether not declaring a license, even for small repos, is legally wise. Not just from a perspective of guarding against copyright infringement but also to foster re-use.

[edunham]

Back to the topic of this issue, I agree that it's almost ready to be closed. Actions that other contributors can help us with to wrap up the loose ends are:

• Find and PR some kind of open data license to crates.io-index (discuss this with @alexcrichton)
• PR a CC-BY license to the blog repo, and get sign-off from all contributors to that repo before merging (https://github.com/rust-lang/blog.rust-lang.org/graphs/contributors)
• Follow up on Does this repo need a LICENSE or COPYING file? rfcs#1259 -- research what other projects have done to sort out ambiguous copyright on standards, propose a suggestion to the core team.

[brson]

There's a thread open on irlo about the RFCs repo https://internals.rust-lang.org/t/relicense-the-rfcs-repo-under-the-cc-by-4-0-license/3870/3

[Mark-Simulacrum]

So the thread on IRLO went silent, and I don't think the RFCs repo ever got any form of license, among others. @brson If we still care about this (and we do, I think), we should probably have core team discuss and decide on a license for the RFCs repo and then move towards adding that.

[est31]

Opened an RFC with a proposal to settle the licensing situation of rust-lang/rfcs: rust-lang/rfcs#2044

[est31]

The RFC got merged and got a tracking issue #43461 .

[apiraino]

By looking at the checkbox list, can we say that this issue is now complete? Perhaps can be closed? thanks

[est31]

@apiraino since that comment, the github organization had new repos added to it. I went over the non-fork repos in the rust-lang organization and found the following repos without a top-level LICENSE file:

• docker-rust
  • License the docker-rust repository under MIT/Apache-2.0 dual license docker-rust#207
  • Adding License Statement (MIT and Apache) docker-rust#74
• docker-rust-nightly (the repository has been archived, the licensing is now being done in docker-rust)
• crater mentions a license in README, even though the license files are not included in the repo
• bors: bootstrap commit
• surveys
  • License the surveys repository under the MIT/Apache-2.0 license surveys#267
  • Add MIT/Apache-2.0 license surveys#266
• rustc-perf
  • License the whole rustc-perf repository under the MIT license rustc-perf#1933
  • Add top-level license file rustc-perf#1881
• fmt-rfcs: pull request
• .github
• rust-lang.github.io

Plus a bunch of workgroup/team repos:

• https://github.com/rust-lang/project-rfc-2229 (archived)
• https://github.com/rust-lang/wg-debugging
• https://github.com/rust-lang/wg-cargo-std-aware
• https://github.com/rust-lang/wg-allocators
• https://github.com/rust-lang/moderation-team
• https://github.com/rust-lang/wg-incr-comp
• https://github.com/rust-lang/compiler-team-prioritization
• https://github.com/rust-lang/rustc-timing (archived)

So this issue should very much not be closed, but thanks for pinging this issue because it motivated this mini-survey of mine.

[apiraino]

thanks @est31 for the important update :)

[sanmai-NL]

What about applying tooling that checks for such things as licensing and SPDX headers, etc.? Checking for top level licenses is rote work and does not cover every concern.

[sanmai-NL]

Even without a licensing tool for CI, you could query the GitHub API.

[est31]

@sanmai-NL yeah it would be nice to have some kind of automatted checking of this, and maybe every time there is a new repo being added, it would file a report to a dedicated github issue (or something like that).