rust-sel4
rust-sel4 copied to clipboard
seL4
Update copyright dates for generated Cargo manifests
Copyright years should usually not be updated in bulk, at least not if the idea is to figure out the year of the most recent original copyright on the file. It doesn't renew automatically, only if there have been significant changes to the file.
Lots of people do this, but they are wrong ;-)
I'm aware of the general rules, but I thought this case might be different.
All Cargo.toml files in this repo are generated from adjacent Cargo.nix files. The Cargo.nix files have their own copyright lines. I have not changed any of those. However, their corresponding Cargo.toml files get their copyright lines from this snippet:
https://github.com/seL4/rust-sel4/blob/63ce236432c4970034a367dd5552d063762b5844/hacking/cargo-manifest-management/manifest-scope.nix#L84-L86
For this PR, I changed the year in that snippet and then ran the typical Cargo.toml re-generation script with make update-generated-sources.
What do you think about this particular case? The Cargo.toml files are new in the sense that they're freshly generated, but old in the sense that they are identical in content to older outputs of make update-generated-sources.
An alternative would be to include the year for the copyright line at the source-level in Cargo.nix files. That would feel a bit clunky, but would yield more control if such control were necessary.
What do you think about this particular case? The
Cargo.tomlfiles are new in the sense that they're freshly generated, but old in the sense that they are identical in content to older outputs ofmake update-generated-sources.An alternative would be to include the year for the copyright line at the source-level in
Cargo.nixfiles. That would feel a bit clunky, but would yield more control if such control were necessary.
The copyright of generated code would be a mix of the copyright of the input to the generator and the generator itself, but the year/time it is generated does not really enter into it. So I guess the correct thing would be to take the year of the input file on this one.
It's not really that big a deal, I confess I just saw the large number of files with the bulk update and reacted to that. If it is too much of a hassle, I'd actually just leave it. Generally you don't really gain anything from updating the copyright year anyway. I try to keep it current on the files with significant changes, but we probably should just really not bother, because by the time copyright runs out I hope we have shifted languages and maybe computing paradigms a few times :-)
If it is too much of a hassle, I'd actually just leave it. Generally you don't really gain anything from updating the copyright year anyway.
What about Cargo.toml files generated from Cargo.nix files that were created in 2024?
If it is too much of a hassle, I'd actually just leave it. Generally you don't really gain anything from updating the copyright year anyway.
What about
Cargo.tomlfiles generated fromCargo.nixfiles that were created in 2024?
Those would be fine
Those would be fine
By this, do you mean that it would be fine to label those with the year 2023?