When updating an R package version, should you update the licence year too?

davidhodge931 · February 21, 2024, 8:02pm

When you first make the R package, you tend to make the licence with that initial year of the first version.

I was wondering if you should update the year in the licence when you release an update after that? Or what is best practice here?

E.g. my licence in my R package is 2022 when I first created it. Now I am about to release a major new version. Should I update it 2024?

Gabor · February 21, 2024, 9:48pm

Yes, update it to 2022--2024.

davidhodge931 · February 21, 2024, 9:57pm

Cool, thanks @Gabor Tidyverse packages often seem to have a single year though, rather than a range?

davidhodge931 · February 21, 2024, 10:52pm

github.com

r-lib/usethis/blob/main/LICENSE.md

# MIT License

Copyright (c) 2020 usethis authors

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE

This file has been truncated. show original

github.com

tidyverse/dplyr/blob/HEAD/LICENSE.md

# MIT License

Copyright (c) 2023 dplyr authors

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE

This file has been truncated. show original

github.com

tidyverse/stringr/blob/HEAD/LICENSE.md

# MIT License

Copyright (c) 2023 stringr authors

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE

This file has been truncated. show original

github.com

r-lib/scales/blob/main/LICENSE.md

# MIT License

Copyright (c) 2023 scales authors

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE

This file has been truncated. show original

jdblischak · February 22, 2024, 2:53am

I recently tried to find an authoritative source on whether to use the current date or a range when asserting copyright (I also mentioned this in the related thread Package's annual maintenance - #2 by jdblischak). I found lots of conflicting advice online. I've always used date ranges, but more and more I see only the current date. As a concrete example, the footer on the GitHub website only states "2024"

Gabor · February 22, 2024, 10:56am

Yeah, we should do a better job with this.

jdblischak · February 22, 2024, 4:24pm

I did some more searching. From what I can tell, including the original date is important because it helps determine when the copyright will expire.

https://www.gnu.org/licenses/gpl-howto.html#copyright-notice

davidhodge931 · February 22, 2024, 10:43pm

Thanks @jdblischak and @Gabor

Seems like all approaches are valid. Therefore, I lean towards just leaving it as original_year to avoid the hassle/complexity of continually updating it

system · February 29, 2024, 10:44pm

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.

If you have a query related to it or one of the replies, start a new topic and refer back with a link.