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.
• blog.rust-lang.org
• regex - Declared in Cargo.toml but no accompanying license files.
• 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.
• rust-buildbot
• 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.
• rust.vim
• rust-mode
• rust-packaging
• gedit-config
• rustup - rustup.sh itself contains the license, but not the rest.
• rust-installer - ditto
• rust-wiki-backup - decomissioned partially because it was not properly licensed
• rust-guidelines
• nano-config - Only contains copyright notice, not license.
• zsh-config

[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 rust-lang/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. rust-lang/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. rust-lang/prev.rust-lang.org#174
• rust.vim rust-lang/rust.vim#45
• rust-mode rust-lang/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

[cmr]

@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 rust-lang/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 .