[pacman-dev] [PATCH] Changed copyright to 2006 - 2015 in version info

[Dan McGee]

On Tue, Jan 20, 2015 at 6:52 PM, Daniel Micay <danielmicay at gmail.com> wrote:

> On 20/01/15 06:38 PM, Dan McGee wrote:
> > On Tue, Jan 20, 2015 at 4:36 PM, Allan McRae <allan at archlinux.org>
> wrote:
> >
> >> On 21/01/15 04:26, Robin de Rooij wrote:
> >>> From 749dde01efdde4c69491c36c1244a112de54ce52 Mon Sep 17 00:00:00 2001
> >>> From: Robin de Rooij <rderooij685 at famousgoglemailhoster.com>
> >>> 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 at archlinux.org>
> >  *  Copyright (c) 2002-2006 by Judd Vinet <jvinet at zeroflux.org>
> >  *
> >
> > 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 <fgouget_at_codeweavers.com>
> > * Copyright (c) 2002-2006 by Judd Vinet <jvinet at zeroflux.org>
> > * Copyright (c) 2005 by Aurelien Foret <orelien at chez.com>
> > * Copyright (c) 2005-2006 by Christian Hamar <krics at linuxforum.hu>
> > * Copyright (c) 2005-2006 by Miklos Vajna <vmiklos at frugalware.org>
> > * Copyright (c) 2006 by David Kimpe <dnaku at frugalware.org>
> > * Copyright (c) 2006 by Andras Voroskoi <voroskoi at frugalware.org>
> > * Copyright (c) 2006 by Alex Smith <alex at alex-smith.me.uk>
> > * Copyright (c) 2007 by Aaron Griffin <aaronmgriffin at gmail.com>
> > * Copyright (c) 2009 by Xavier Chantry <shiningxc at gmail.com>
> > * Copyright (c) 2006-2015 by Pacman Development Team <
> > pacman-dev at 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