> I have uploaded a draft for my currently preferred approach to a
> branch on my GitLab fork.
Thanks for working on this!
> and copyright headers like this: [...]
>
> + This file was mainly authored by:
> + David Nalesnik
> + Thomas Morley
> + Dan Eble
> + Jonas
Jean Abou Samra writes:
> To summarizes, it changes `LICENSE` like this:
>
> ```
> @@ -1,3 +1,14 @@
> +GNU LilyPond is Copyright (C) 1996-2023 by the LilyPond authors, as
> defined below.
> +
> +LilyPond's Git repository is the authoritative source for copyright
> +attribution of each piece of co
Le lundi 13 février 2023 à 11:53 +0100, Jean Abou Samra a écrit :
> 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. If it means updat
Wol writes:
> On 15/02/2023 15:36, Werner LEMBERG wrote:
>> Code contributed to GNU LilyPond will*always* be under the GPL. You
>> can't change the license afterwards.
>
> Sorry. This is legal bullshit. If *I* contribute a file to lilypond,
> and *I* stick a *BSD* licence on it, the BSD licence
Le mercredi 15 février 2023 à 23:08 +, Wol a écrit :
> On 15/02/2023 17:05, David Kastrup wrote:
>
> > Wols Lists <[antli...@youngman.org.uk](mailto:antli...@youngman.org.uk)>
> > writes:
> >
> >
> > > On 15/02/2023 06:23, Werner LEMBERG wrote:
> > >
> > > >
> > >
> > >
> > > An individ
On 15/02/2023 17:05, David Kastrup wrote:
Wols Lists writes:
On 15/02/2023 06:23, Werner LEMBERG wrote:
An individual source file is an individual work.
Apparently you don't understand what licensing a work means. A license
is not something pervading files like copyright does. A licens
Wol writes:
> On 15/02/2023 17:08, David Kastrup wrote:
>> Wols Lists writes:
>>
>>> On 15/02/2023 02:01, David Kastrup wrote:
> Personally, I'd be happiest if everybody who updated a file was
> responsible for making sure the copyright date was updated
> appropriately,
>>>
Tha
Le mercredi 15 février 2023 à 22:12 +, Wol a écrit :
> On 15/02/2023 15:36, Werner LEMBERG wrote:
>
> > Code contributed to GNU LilyPond will*always* be under the GPL. You
> > can't change the license afterwards.
>
>
> Sorry. This is legal bullshit. If *I* contribute a file to lilypond, an
On 15/02/2023 15:36, Werner LEMBERG wrote:
Code contributed to GNU LilyPond will*always* be under the GPL. You
can't change the license afterwards.
Sorry. This is legal bullshit. If *I* contribute a file to lilypond, and
*I* stick a *BSD* licence on it, the BSD licence does *NOT* give *YOU*
On 15/02/2023 17:08, David Kastrup wrote:
Wols Lists writes:
On 15/02/2023 02:01, David Kastrup wrote:
Personally, I'd be happiest if everybody who updated a file was
responsible for making sure the copyright date was updated
appropriately,
That is going to work fantastically well, right?
Jean Abou Samra writes:
> Le mercredi 15 février 2023 à 18:05 +0100, David Kastrup a écrit :
>
>> No GNU program requiring a copyright assignment for working on it has
>> ceased doing so as far as I know,
>
> [Off-topic]
>
> Actually, both GCC and Guile have done so by now.
>
> [https://gcc.gnu
Le mercredi 15 février 2023 à 18:05 +0100, David Kastrup a écrit :
> No GNU program requiring a copyright assignment for working on it has
> ceased doing so as far as I know,
[Off-topic]
Actually, both GCC and Guile have done so by now.
[https://gcc.gnu.org/pipermail/gcc/2021-June/236182.html
Wols Lists writes:
> On 15/02/2023 02:01, David Kastrup wrote:
>>> Personally, I'd be happiest if everybody who updated a file was
>>> responsible for making sure the copyright date was updated
>>> appropriately,
>
>> That is going to work fantastically well, right? Distribute
>> responsibility
Wols Lists writes:
> On 15/02/2023 06:23, Werner LEMBERG wrote:
>>
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 n
Le mardi 14 février 2023 à 10:16 +0100, David Kastrup a écrit :
> I can understand this discussion about whitespace/formatting changes
> (`git blame -w` helps and can be set as the default behavior). For the
> grand replace, it seems like a nothingburger to me.
I spent nonzero ti
I support Werner's view that as part of a group we ought to stay in line
with the guidelines of the group.
However, if the guidelines permit doing SPDX-noyear, I believe it would be
an excellent move.
Luca
On Wed, Feb 15, 2023 at 5:46 PM Jean Abou Samra wrote:
> Le lundi 13 février 2023 à 23:50
Le lundi 13 février 2023 à 23:50 +0100, Han-Wen Nienhuys a écrit :
> it is weird, but so is doing the grand update. We could decide to trim
> our license headers to a smaller SPDX identifier without a year, but
> we still have another year to go before a decision would make a
> difference.
> An individual source file is an individual work.
I have almost stopped reading here – this assumption is simply
incorrect. Right now, there are 6322 files which in total represent
GNU LilyPond.
> What happens if I decide to add a file under a BSD licence?
Code contributed to GNU LilyPond wil
On 15/02/2023 02:01, David Kastrup wrote:
Personally, I'd be happiest if everybody who updated a file was
responsible for making sure the copyright date was updated
appropriately,
That is going to work fantastically well, right? Distribute
responsibility until nobody feels responsible for any
On 15/02/2023 06:23, Werner LEMBERG wrote:
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 l
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 simple
>> 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, thank
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
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
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
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
touch
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 bei
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 s
> 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 modest,
>> 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 do
odify what I find annoying in this practice: to
touch files even if they weren't changed in any way.
> If we stop doing grand-replace, does it mean we have to update the copyright
> noticed manually when we change a file?
No.
> Git, for example, does not have an equivalent of gr
On Mon, 2023-02-13 at 13:36 +0100, Janneke Nieuwenhuizen wrote:
> Han-Wen Nienhuys writes:
>
> Hey,
>
> > Every year, we go over the source code to update the copyright years
> > that are found in the source headers. I propose to stop this.
>
> +1
>
> > Also note that many other projects (eg. g
Han-Wen Nienhuys writes:
Hey,
> Every year, we go over the source code to update the copyright years
> that are found in the source headers. I propose to stop this.
+1
> Also note that many other projects (eg. git) seem to survive just fine
> without yearly exercise like this.
Yes. Of course,
> Also note that many other projects (eg. git) seem to survive just fine
> without yearly exercise like this. Also, at $dayjob, there are no
> instructions to do this, despite open source work being carefully
> overseen by lawyers.
If we stop doing grand-replace, does it
Hi there,
Every year, we go over the source code to update the copyright years
that are found in the source headers. I propose to stop this.
We started doing this because of the GNU standards which say
https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html
but we aren't following th
> To be clear, I do *not* plan to run grand-replace.py on the stable
> branch. Instead I'll "just" update the few user-facing strings, in
> lily/main.cc:273 and scripts/*.
OK. I misunderstood.
Werner
Am Donnerstag, dem 18.02.2021 um 17:41 +0100 schrieb Werner LEMBERG:
> > > We should run `make grand-replace` to update all copyright years.
> > > Since this is a completely mechanical thing to do, I suggest to
> > > submit the MR, wait until a build was success
>> We should run `make grand-replace` to update all copyright years.
>> Since this is a completely mechanical thing to do, I suggest to
>> submit the MR, wait until a build was successful, then immediately
>> merging and committing it, bypassing the normal reviewi
Am Mittwoch, dem 17.02.2021 um 08:25 +0100 schrieb Werner LEMBERG:
> We should run `make grand-replace` to update all copyright years.
> Since this is a completely mechanical thing to do, I suggest to
> submit
> the MR, wait until a build was successful, then immediately merging
>
Am 17.02.2021 um 14:11 schrieb Dan Eble:
On Feb 17, 2021, at 02:25, Werner LEMBERG wrote:
We should run `make grand-replace` to update all copyright years.
Since this is a completely mechanical thing to do, I suggest to submit
the MR, wait until a build was successful, then immediately merging
On Feb 17, 2021, at 02:25, Werner LEMBERG wrote:
>
> We should run `make grand-replace` to update all copyright years.
> Since this is a completely mechanical thing to do, I suggest to submit
> the MR, wait until a build was successful, then immediately merging
> and committing it
We should run `make grand-replace` to update all copyright years.
Since this is a completely mechanical thing to do, I suggest to submit
the MR, wait until a build was successful, then immediately merging
and committing it, bypassing the normal reviewing cycle. This should
minimize the hassles
> So go wild.
Thanks. Copyright years are now updated in staging.
Werner
Werner LEMBERG writes:
> It's January. This means we should run
>
> make grand-replace
>
> David K, do you have objections, especially w.r.t. cherry-picking?
Don't grand-replace in the stable branch (does not make a lot of sense
anyway), and the cherry-picks will be
It's January. This means we should run
make grand-replace
David K, do you have objections, especially w.r.t. cherry-picking?
Werner
On Sun, Jan 05, 2014 at 10:38:04AM +0100, Werner LEMBERG wrote:
>
> > I do not believe that there is a notion of "package" copyright in
> > most countries' laws.
>
> On page
> http://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html
> I see this:
>
> To update the list of year numbe
On 1/5/14 12:00 AM, "David Kastrup" wrote:
>According to Savannah, you still have push privileges (and I should be
>surprised if not). What did you try? What was the error message? Did
>you perhaps not use a member checkout?
>http://savannah.gnu.org/git/?group=lilypond>
Yes, that was the pr
> I don't think there is a mistake in the conversion script. I think
> this was a hypothetical, rather than an actual case where 2012
> turned to 2014. [...]
Very good, thanks for checking.
Werner
___
lilypond-devel mailing list
lilypond-devel@
her than an actual case where 2012 turned to 2014.
grep 2014 0001-Run-grand-replace-issue-3765.patch | grep -v - returned
nothing.
And we see the following:
carl@carl-lilydev ~/lilypond-git (dev/cds)$ grep 2013
0001-Run-grand-replace-issue-3765.patch
-Copyright (c) 1996--2013, The LilyPond authors (
Carl Sorensen writes:
> In response to issue 3765, I ran make grand-replace to update all copyright
> notices to 2014.
>
> It looks like I no longer have push privileges, so I couldn't push the
> patch to staging.
According to Savannah, you still have push privileges (and I
>> AFAIK, this is not correct. We have to make a distinction between
>> singular files and files that a part of a package. What matters
>> for us is the *package* copyright.
>
> I do not believe that there is a notion of "package" copyright in
> most countries' laws.
On page
http://www.gnu.
On Sun, Jan 05, 2014 at 09:37:30AM +0100, Werner LEMBERG wrote:
>
> > The purpose of listing the year is to give an indication of when the
> > copyright will expire.
>
> AFAIK, this is not correct. We have to make a distinction between
> singular files and files that a part of a package. What m
>> Looks like a mistake in the conversion script. `2012' should be
>> changed to `2012-2014', of course.
>
> The purpose of listing the year is to give an indication of when the
> copyright will expire. If the last copyrightable change to a
> document was in 2012, but the notice says 2014, then
On Sat, Jan 4, 2014 at 11:09 PM, Werner LEMBERG wrote:
> Looks like a mistake in the conversion script. `2012' should be
> changed to `2012-2014', of course.
The purpose of listing the year is to give an indication of when the
copyright will expire. If the last copyrightable change to a document
> "You can use a range (‘2008-2010’) instead of listing individual
> years (‘2008, 2009, 2010’) if and only if: 1) every year in the
> range, inclusive, really is a “copyrightable” year that would be
> listed individually; and 2) you make an explicit statement in a
> README file about this usage."
On Sun, Jan 05, 2014 at 08:42:59AM +0100, Werner LEMBERG wrote:
>
> >> Looks like a mistake in the conversion script. `2012' should be
> >> changed to `2012-2014', of course.
> >
> > GNU maintainer's guide discourages that:
> > http://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html#Co
>> Looks like a mistake in the conversion script. `2012' should be
>> changed to `2012-2014', of course.
>
> GNU maintainer's guide discourages that:
> http://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html#Copyright-Notices
What exactly does it discourage?
> However, it's also true
On Sun, Jan 05, 2014 at 08:09:45AM +0100, Werner LEMBERG wrote:
>
> > I'm not a lawyer, but the year in a copyright notice is supposed to
> > be the year of original publication. If you have a document first
> > published in 2012 with a "Copyright 2012" notice and you change the
> > year to 2014 w
> I'm not a lawyer, but the year in a copyright notice is supposed to
> be the year of original publication. If you have a document first
> published in 2012 with a "Copyright 2012" notice and you change the
> year to 2014 without making any other changes, [...]
Looks like a mistake in the conver
- Ben
On Sat, Jan 4, 2014 at 3:50 PM, Carl Sorensen wrote:
> In response to issue 3765, I ran make grand-replace to update all
> copyright notices to 2014.
>
> It looks like I no longer have push privileges, so I couldn't push the
> patch to staging.
>
> Anyway, here'
On Sun, Jan 08, 2012 at 09:53:16PM +, James wrote:
> http://lilypond.org/doc/v2.15/Documentation/contributor/unsorted-policies
thanks, run.
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilyp
Hello,
I noticed this command
http://lilypond.org/doc/v2.15/Documentation/contributor/unsorted-policies
:)
So I tried it...
Gosh... that command touches 'one or two' files doesn't it!
Umm.. I guess this is something that a 'senior' dev probably should do
as it also touches all the translate
62 matches
Mail list logo
