> 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
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 updating those years manually
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
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
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
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,
>>>
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,
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.
>
>
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.
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
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 time (not a
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 à
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
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
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
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
>> 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,
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
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
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
> 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
>> 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
On Mon, Feb 13, 2023 at 11:53 AM Jean Abou Samra wrote:
>
> Le lundi 13 février 2023 à 11:07 +0100, Han-Wen Nienhuys a écrit :
>
> 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
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.
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
Le lundi 13 février 2023 à 11:07 +0100, Han-Wen Nienhuys a écrit :
> 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
>
>
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
35 matches
Mail list logo
