Re: grand copyright replacement

2019-01-25 Thread Werner LEMBERG
>> Assuming we are running `grand-replace' next year again this would >> be (in almost all cases) a one-time job. > > Would there be a way to automate it so the first build run in a new > year updates all the copyrights? Well, the *proper* way IMHO would be to use gnulib's `update-copyright' scr

Re: grand copyright replacement

2019-01-25 Thread David Kastrup
Matthias Kilian writes: > On Fri, Jan 25, 2019 at 07:43:10AM +0100, Werner LEMBERG wrote: >> I'm going to run `scripts/build/grand-replace' to update all copyright >> years. > > I'm not completely sure, but shouldn't the copyright year(s) in a work > only cover the years when the work was origina

Re: grand copyright replacement

2019-01-25 Thread Matthias Kilian
On Fri, Jan 25, 2019 at 07:43:10AM +0100, Werner LEMBERG wrote: > I'm going to run `scripts/build/grand-replace' to update all copyright > years. I'm not completely sure, but shouldn't the copyright year(s) in a work only cover the years when the work was originally written or modified? Ciao,

Re: grand copyright replacement

2019-01-25 Thread James Lowe
Hello, On Fri, 25 Jan 2019 12:48:51 +0100, David Kastrup wrote: > Werner LEMBERG writes: > > >>> I'm going to run `scripts/build/grand-replace' to update all > >>> copyright years. However, my test run shows that there are a bunch > >>> of files that aren't covered, for example > >>> `lily/pa

Re: grand copyright replacement

2019-01-25 Thread David Kastrup
Werner LEMBERG writes: >>> I'm going to run `scripts/build/grand-replace' to update all >>> copyright years. However, my test run shows that there are a bunch >>> of files that aren't covered, for example >>> `lily/part-combine-part-iterator.cc', which has the following >>> copyright notice: >>>

Re: grand copyright replacement

2019-01-25 Thread Karlin High
On 1/25/2019 5:16 AM, Werner LEMBERG wrote: Assuming we are running `grand-replace' next year again this would be (in almost all cases) a one-time job. Would there be a way to automate it so the first build run in a new year updates all the copyrights? -- Karlin High Missouri, USA __

Re: grand copyright replacement

2019-01-25 Thread Carl Sorensen
On 1/25/19, 4:16 AM, "lilypond-devel on behalf of Werner LEMBERG" wrote: So is it OK to simply update the missing cases? Assuming we are running `grand-replace' next year again this would be (in almost all cases) a one-time job. In my opinion, yes. Thanks for looking at this.

Re: grand copyright replacement

2019-01-25 Thread Werner LEMBERG
>> I'm going to run `scripts/build/grand-replace' to update all >> copyright years. However, my test run shows that there are a bunch >> of files that aren't covered, for example >> `lily/part-combine-part-iterator.cc', which has the following >> copyright notice: >> >> Copyright (C) 2015 Daniel

Re: grand copyright replacement

2019-01-25 Thread David Kastrup
Werner LEMBERG writes: > I'm going to run `scripts/build/grand-replace' to update all copyright > years. However, my test run shows that there are a bunch of files > that aren't covered, for example `lily/part-combine-part-iterator.cc', > which has the following copyright notice: > > Copyright

grand copyright replacement

2019-01-24 Thread Werner LEMBERG
I'm going to run `scripts/build/grand-replace' to update all copyright years. However, my test run shows that there are a bunch of files that aren't covered, for example `lily/part-combine-part-iterator.cc', which has the following copyright notice: Copyright (C) 2015 Daniel Eble Shall this