[pacman-dev] [PATCH] Changed copyright to 2006 - 2015 in version info
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
- From 749dde01efdde4c69491c36c1244a112de54ce52 Mon Sep 17 00:00:00 2001
From: Robin de Rooij
On 20.01.2015 19:26, Robin de Rooij wrote:
From 749dde01efdde4c69491c36c1244a112de54ce52 Mon Sep 17 00:00:00 2001 From: Robin de Rooij
Date: Fri, 16 Jan 2015 22:36:00 +0100 Subject: [PATCH] Changed copyright to 2006 - 2015 in version info
Please use imperative mood in subject lines to stay in line with what tools like git merge and git revert do (Revert .., Merge ...), to make the verb shorter (Changed -> Change) and to make it more readable when being reverted (Revert "Changed .." -> Revert "Change ..").
The copyright notice still displayed: 2006 - 2014. I changed the version method to 2006 - 2015
Signed-off-by: Robin de Rooij
(Everyone knows the name of Google's email service, replace famousgoglemailhoster with Google's real email service
Your email address is already visible in the list archives so this is unnecessary. That said I'm very biased towards using good spam filters and against making life harder for users (which scrambling your email address is doing for everyone involved) so ymmv. Apart from that please use git-send-email to send patches in the future as this is yet another example of other software messing up whitespace and/or line breaks. In this case it's somewhat easy to fix because the patch is small. Also patchwork (patch tracking system) doesn't pick up this patch (likely because of the formatting issue) so it could get lost.
--- src/pacman/pacman.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/pacman/pacman.c b/src/pacman/pacman.c index 792c994..28df482 100644 --- a/src/pacman/pacman.c +++ b/src/pacman/pacman.c @@ -224,7 +224,7 @@ static void version(void) { printf("\n"); printf(" .--. Pacman v%s - libalpm v%s\n", PACKAGE_VERSION, alpm_version()); - printf("/ _.-' .-. .-. .-. Copyright (C) 2006-2014 Pacman Development Team\n"); + printf("/ _.-' .-. .-. .-. Copyright (C) 2006-2015 Pacman Development Team\n"); printf("\\ '-. '-' '-' '-' Copyright (C) 2002-2006 Judd Vinet\n"); printf(" '--'\n"); printf(_(" This program may be freely redistributed under\n"
Thanks for the feedback. I'm glad that this was a minor edit, otherwise
line formatting would be a big issue. I wasn't aware of the fact that
Thunderbird messed it up.
Your feedback is appreciated. To be honest, I've never helped developing
with projects in this manner (mailing lists, submitting patches instead of
just using GitHub), so I'm sorry for the messed up patch submission.
git-send-email will be used here in the future.
Oh, and sorry for scrambling my email address like that!
Kind regards,
Robin
On Tue, Jan 20, 2015 at 7:48 PM, Florian Pritz
On 20.01.2015 19:26, Robin de Rooij wrote:
From 749dde01efdde4c69491c36c1244a112de54ce52 Mon Sep 17 00:00:00 2001 From: Robin de Rooij
Date: Fri, 16 Jan 2015 22:36:00 +0100 Subject: [PATCH] Changed copyright to 2006 - 2015 in version info Please use imperative mood in subject lines to stay in line with what tools like git merge and git revert do (Revert .., Merge ...), to make the verb shorter (Changed -> Change) and to make it more readable when being reverted (Revert "Changed .." -> Revert "Change ..").
The copyright notice still displayed: 2006 - 2014. I changed the version method to 2006 - 2015
Signed-off-by: Robin de Rooij
(Everyone knows the name of Google's email service, replace famousgoglemailhoster with Google's real email service Your email address is already visible in the list archives so this is unnecessary. That said I'm very biased towards using good spam filters and against making life harder for users (which scrambling your email address is doing for everyone involved) so ymmv.
Apart from that please use git-send-email to send patches in the future as this is yet another example of other software messing up whitespace and/or line breaks. In this case it's somewhat easy to fix because the patch is small.
Also patchwork (patch tracking system) doesn't pick up this patch (likely because of the formatting issue) so it could get lost.
--- src/pacman/pacman.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/pacman/pacman.c b/src/pacman/pacman.c index 792c994..28df482 100644 --- a/src/pacman/pacman.c +++ b/src/pacman/pacman.c @@ -224,7 +224,7 @@ static void version(void) { printf("\n"); printf(" .--. Pacman v%s - libalpm v%s\n", PACKAGE_VERSION, alpm_version()); - printf("/ _.-' .-. .-. .-. Copyright (C) 2006-2014 Pacman Development Team\n"); + printf("/ _.-' .-. .-. .-. Copyright (C) 2006-2015 Pacman Development Team\n"); printf("\\ '-. '-' '-' '-' Copyright (C) 2002-2006 Judd Vinet\n"); printf(" '--'\n"); printf(_(" This program may be freely redistributed under\n"
On 21/01/15 04:26, Robin de Rooij wrote:
From 749dde01efdde4c69491c36c1244a112de54ce52 Mon Sep 17 00:00:00 2001 From: Robin de Rooij
Date: Fri, 16 Jan 2015 22:36:00 +0100 Subject: [PATCH] Changed copyright to 2006 - 2015 in version info The copyright notice still displayed: 2006 - 2014. I changed the version method to 2006 - 2015
This needs to be part of a larger patch that changes all our copyright years to the correct range. A
On Tue, Jan 20, 2015 at 4:36 PM, Allan McRae
On 21/01/15 04:26, Robin de Rooij wrote:
From 749dde01efdde4c69491c36c1244a112de54ce52 Mon Sep 17 00:00:00 2001 From: Robin de Rooij
Date: Fri, 16 Jan 2015 22:36:00 +0100 Subject: [PATCH] Changed copyright to 2006 - 2015 in version info The copyright notice still displayed: 2006 - 2014. I changed the version method to 2006 - 2015
This needs to be part of a larger patch that changes all our copyright years to the correct range.
We go through this seemingly silly exercise every year. Is it truly
necessary?
We have this kind of thing now:
/*
* pacman.c
*
* Copyright (c) 2006-2014 Pacman Development Team <
pacman-dev@archlinux.org>
* Copyright (c) 2002-2006 by Judd Vinet
On 20/01/15 06:38 PM, Dan McGee wrote:
On Tue, Jan 20, 2015 at 4:36 PM, Allan McRae
wrote: On 21/01/15 04:26, Robin de Rooij wrote:
From 749dde01efdde4c69491c36c1244a112de54ce52 Mon Sep 17 00:00:00 2001 From: Robin de Rooij
Date: Fri, 16 Jan 2015 22:36:00 +0100 Subject: [PATCH] Changed copyright to 2006 - 2015 in version info The copyright notice still displayed: 2006 - 2014. I changed the version method to 2006 - 2015
This needs to be part of a larger patch that changes all our copyright years to the correct range.
We go through this seemingly silly exercise every year. Is it truly necessary?
AFAIK, it does have meaning (extends the lifetime of the copyright, which expires N years after that date) but nothing stops you from treating the entire project as one work and only having a top-level license + copyright headers.
We have this kind of thing now:
/* * pacman.c * * Copyright (c) 2006-2014 Pacman Development Team < pacman-dev@archlinux.org> * Copyright (c) 2002-2006 by Judd Vinet
* If we did something like this instead, we can then have one central COPYRIGHT file perhaps?
/* * pacman.c * * See the COPYRIGHT file for individual attributions. *
COPYRIGHT would look something like this:
Portions of this codebase fall under various copyrights and authorships. As the code is a continual work in progress and has been moved around and reshaped over time, copyright assignment to individual files does not always reflect reality. Please use version control tools to better grasp the lineage and history of a given piece of code. Known copyright holders include the following:
* Copyright (c) 2001 by François Gouget
* Copyright (c) 2002-2006 by Judd Vinet * Copyright (c) 2005 by Aurelien Foret * Copyright (c) 2005-2006 by Christian Hamar * Copyright (c) 2005-2006 by Miklos Vajna * Copyright (c) 2006 by David Kimpe * Copyright (c) 2006 by Andras Voroskoi * Copyright (c) 2006 by Alex Smith * Copyright (c) 2007 by Aaron Griffin * Copyright (c) 2009 by Xavier Chantry * Copyright (c) 2006-2015 by Pacman Development Team < pacman-dev@archlinux.org> Thoughts? The copyright at file granularity concept seems super outdated to me.
It seems entirely useless if the project is under a unified license. If there are various licenses, then isolating them can make sense. A project might want to preserve liberal licensing for some files even though it primarily uses the GPL, or it might want to isolate some GPL code so the project can be liberally licensed if it is removed. None of that is applicable to Pacman AFAIK.
On Tue, Jan 20, 2015 at 6:52 PM, Daniel Micay
On 20/01/15 06:38 PM, Dan McGee wrote:
On Tue, Jan 20, 2015 at 4:36 PM, Allan McRae
wrote: On 21/01/15 04:26, Robin de Rooij wrote:
From 749dde01efdde4c69491c36c1244a112de54ce52 Mon Sep 17 00:00:00 2001 From: Robin de Rooij
Date: Fri, 16 Jan 2015 22:36:00 +0100 Subject: [PATCH] Changed copyright to 2006 - 2015 in version info The copyright notice still displayed: 2006 - 2014. I changed the version method to 2006 - 2015
This needs to be part of a larger patch that changes all our copyright years to the correct range.
We go through this seemingly silly exercise every year. Is it truly necessary?
AFAIK, it does have meaning (extends the lifetime of the copyright, which expires N years after that date) but nothing stops you from treating the entire project as one work and only having a top-level license + copyright headers.
Yeah, sorry I wasn't clear here - I meant the "update every file" exercise, not the "we should extend the copyright dates somewhere" bit.
We have this kind of thing now:
/* * pacman.c * * Copyright (c) 2006-2014 Pacman Development Team < pacman-dev@archlinux.org> * Copyright (c) 2002-2006 by Judd Vinet
* If we did something like this instead, we can then have one central COPYRIGHT file perhaps?
/* * pacman.c * * See the COPYRIGHT file for individual attributions. *
COPYRIGHT would look something like this:
Portions of this codebase fall under various copyrights and authorships.
As
the code is a continual work in progress and has been moved around and reshaped over time, copyright assignment to individual files does not always reflect reality. Please use version control tools to better grasp the lineage and history of a given piece of code. Known copyright holders include the following:
* Copyright (c) 2001 by François Gouget
* Copyright (c) 2002-2006 by Judd Vinet * Copyright (c) 2005 by Aurelien Foret * Copyright (c) 2005-2006 by Christian Hamar * Copyright (c) 2005-2006 by Miklos Vajna * Copyright (c) 2006 by David Kimpe * Copyright (c) 2006 by Andras Voroskoi * Copyright (c) 2006 by Alex Smith * Copyright (c) 2007 by Aaron Griffin * Copyright (c) 2009 by Xavier Chantry * Copyright (c) 2006-2015 by Pacman Development Team < pacman-dev@archlinux.org> Thoughts? The copyright at file granularity concept seems super outdated to me.
It seems entirely useless if the project is under a unified license.
If there are various licenses, then isolating them can make sense. A project might want to preserve liberal licensing for some files even though it primarily uses the GPL, or it might want to isolate some GPL code so the project can be liberally licensed if it is removed. None of that is applicable to Pacman AFAIK
Almost everything is under a unified license. There are a few exceptions as far as original source, and I believe this covers all of them. I would leave this subset of files alone and not include them in the unified COPYRIGHT file, as they come from PolarSSL originally: lib/libalpm/base64.{c,h} lib/libalpm/md5.{c,h} lib/libalpm/sha2.{c,h} Finally, this one is probably misleading and needs fixing anyway, as we have borrowed the code from rpm but didn't seem to preserve the copyright: lib/libalpm/version.c -Dan
On 21/01/15 11:06, Dan McGee wrote:
On Tue, Jan 20, 2015 at 6:52 PM, Daniel Micay
wrote: On 20/01/15 06:38 PM, Dan McGee wrote:
On Tue, Jan 20, 2015 at 4:36 PM, Allan McRae
wrote: On 21/01/15 04:26, Robin de Rooij wrote:
From 749dde01efdde4c69491c36c1244a112de54ce52 Mon Sep 17 00:00:00 2001 From: Robin de Rooij
Date: Fri, 16 Jan 2015 22:36:00 +0100 Subject: [PATCH] Changed copyright to 2006 - 2015 in version info The copyright notice still displayed: 2006 - 2014. I changed the version method to 2006 - 2015
This needs to be part of a larger patch that changes all our copyright years to the correct range.
We go through this seemingly silly exercise every year. Is it truly necessary?
AFAIK, it does have meaning (extends the lifetime of the copyright, which expires N years after that date) but nothing stops you from treating the entire project as one work and only having a top-level license + copyright headers.
Yeah, sorry I wasn't clear here - I meant the "update every file" exercise, not the "we should extend the copyright dates somewhere" bit.
At a minimum, alpm.h and alpm_list.h need a full copyright. I'd prefer that we added a make rule that does it automatically - many of the GNU toolchain software have done this. Allan
participants (5)
-
Allan McRae
-
Dan McGee
-
Daniel Micay
-
Florian Pritz
-
Robin de Rooij