Re: RFC: stop doing "grand replace" updates to copyright years

2023-02-14 Thread Luca Fascione
I do think this is a very sensible stance, actually: staying in line with your surrounding context I feel is very important and has a strong overriding power. On Tue, Feb 14, 2023 at 11:27 AM Werner LEMBERG wrote: > Please bear in mind that LilyPond is a GNU project. > [...] > IMHO, it's

Re: RFC: stop doing "grand replace" updates to copyright years

2023-02-14 Thread Werner LEMBERG
>> IMHO it's even simpler - is it fraud? (I don't know the answer, but >> it feels like it, and we shouldn't do it without legal advice). > > The GPL is used for licensing works _as_ _a_ _whole_, so it is > definitely not fraud to update the license headers in lockstep. > [...] Well said,

Re: RFC: stop doing "grand replace" updates to copyright years

2023-02-14 Thread David Kastrup
Wol writes: > On 13/02/2023 22:50, Han-Wen Nienhuys wrote: >>> which sounds like exactly the opposite. > >> I read it again, and you are right. The instructions say to update >> each file even if the file itself wasn't changed in that year. I guess >> the instructions codify what I find annoying

Re: RFC: stop doing "grand replace" updates to copyright years

2023-02-14 Thread David Kastrup
Wol writes: > On 14/02/2023 10:27, Werner LEMBERG wrote: >> >>> I have proposed before to move to a system based on SPDX before for >>> the same reason, it reduces busywork that brings no advantage. And >>> as it's been suggested before in the thread, the bulk advantage of >>> accurate/updated

Re: RFC: stop doing "grand replace" updates to copyright years

2023-02-14 Thread Wol
On 14/02/2023 10:27, Werner LEMBERG wrote: I have proposed before to move to a system based on SPDX before for the same reason, it reduces busywork that brings no advantage. And as it's been suggested before in the thread, the bulk advantage of accurate/updated copyright years is likely to be

Re: RFC: stop doing "grand replace" updates to copyright years

2023-02-14 Thread Wol
On 13/02/2023 22:50, Han-Wen Nienhuys wrote: which sounds like exactly the opposite. I read it again, and you are right. The instructions say to update each file even if the file itself wasn't changed in that year. I guess the instructions codify what I find annoying in this practice: to

Re: RFC: stop doing "grand replace" updates to copyright years

2023-02-14 Thread Luca Fascione
FWIW, my perspective on this is more that we should take it as an act of periodic maintenance that all forms of little, mindless busywork should be eliminated from the group's rituals and routines. If it's not necessary, don't do it, and to quote Sutter: don't sweat the small stuff. The problem

Re: RFC: stop doing "grand replace" updates to copyright years

2023-02-14 Thread David Kastrup
Werner LEMBERG writes: >>> If accepting this proposal just means no more grand-replace, I'm >>> fine with it, but it would seem a bit weird to keep "Copyright >>> 1995-2023" at the top of all files even in 2025. >> >> it is weird, but so is doing the grand update. > > Honestly, I don't see

Re: RFC: stop doing "grand replace" updates to copyright years

2023-02-14 Thread Werner LEMBERG
> I have proposed before to move to a system based on SPDX before for > the same reason, it reduces busywork that brings no advantage. And > as it's been suggested before in the thread, the bulk advantage of > accurate/updated copyright years is likely to be somewhere between > small and

Re: RFC: stop doing "grand replace" updates to copyright years

2023-02-14 Thread Werner LEMBERG
>> If accepting this proposal just means no more grand-replace, I'm >> fine with it, but it would seem a bit weird to keep "Copyright >> 1995-2023" at the top of all files even in 2025. > > it is weird, but so is doing the grand update. Honestly, I don't see anything weird with doing `make