etc,rustdoc: few changes

[adrientetar]

Closes#11985
Closes#4533

@huonw, @alexcrichton

[flaper87]

I guess this should be changed to 2014

[alexcrichton]

This looks fine to me, I'd want @brson's input to make sure we can just add a license to all these files.

[adrientetar]

They are all from Rust contributors so I think they are covered by the project-wide license.

[flaper87]

IMHO, the license should be updated. From my experience, once one of the fiels is modified, the license should reflect the year it was modified in. IANAL, though!

[adrientetar]

I don't follow this logic since it would mean that say in 2015 I could update the copyright claim year without changing the files contents but then what's the point of a claim by-years if it doesn't reflect the actual contents? --

[thestinger]

@adridu59: There's no reason to consider each file an individual work. The relevance of the date is when the copyright on the work will expire, so giving it as a range doesn't have any meaning. I don't think there would be any issue with updating every single one to the current year without an initial date, but it would have to be run by Mozilla's lawyers.

[adrientetar]

@thestinger Well, the GNU guidelines state otherwise.

[thestinger]

From the link you gave:

Sometimes a program has an overall copyright notice that refers to the whole program. It might be in the README file, or it might be displayed when the program starts up. This copyright notice should mention the year of completion of the most recent major version; it can mention years of completion of previous major versions, but that is optional.

The per-file copyright notice can just be a summary of the copyright across the whole work. Rust is already just including a reference to the list of copyright holders (all contributors) and the real license file. Third party projects included in the tree need to be dealt with separately, but there's no reason for each Rust file to be an independent work. It's just needless complexity.

[brson]

I feel comfortable adding the license header to these files - they've been around for a long time and are by contributors who are already contributing under the correct license, should have been converted long ago but weren't. There isn't much risk here.

Regarding dates, I've been told that the declared copyright date has very little legal weight, partly because it is completely obvious who wrote the code and when based on the project history. The advice I've been given is to just make a best effort and don't worry too much about whether a file says '2013', '2014' or '2013-2014'. Personally, I never bother to update dates when I edit a file.

[brson]

@adridu59 If you are interested in other tasks along these lines, #4534 is about making licenseck.py check more files. In particular we don't check the license on the test suite.

[alexcrichton]

I managed to seriously confuse bors, and I think that he'll pick up on this next, but to be extra sure, @adridu59 could you push a rebase on the current master?

[adrientetar]

@alexcrichton I rebased about 50 minutes ago, shall I do it again?

[alexcrichton]

Yeah just to get rid of the bors merge commit (sorry about that)

[adrientetar]

@alexcrichton It's there!

[adrientetar]

@alexcrichton np

[alexcrichton]

I interrupted the last set of tests because I believe that they were timing out and #12054 should fix the timeout.