On Tue, Jan 20, 2015 at 6:52 PM, Daniel Micay <[email protected]> wrote:
> On 20/01/15 06:38 PM, Dan McGee wrote: > > On Tue, Jan 20, 2015 at 4:36 PM, Allan McRae <[email protected]> > wrote: > > > >> On 21/01/15 04:26, Robin de Rooij wrote: > >>> From 749dde01efdde4c69491c36c1244a112de54ce52 Mon Sep 17 00:00:00 2001 > >>> From: Robin de Rooij <[email protected]> > >>> 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 < > > [email protected]> > > * Copyright (c) 2002-2006 by Judd Vinet <[email protected]> > > * > > > > 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 <[email protected]> > > * Copyright (c) 2005 by Aurelien Foret <[email protected]> > > * Copyright (c) 2005-2006 by Christian Hamar <[email protected]> > > * Copyright (c) 2005-2006 by Miklos Vajna <[email protected]> > > * Copyright (c) 2006 by David Kimpe <[email protected]> > > * Copyright (c) 2006 by Andras Voroskoi <[email protected]> > > * Copyright (c) 2006 by Alex Smith <[email protected]> > > * Copyright (c) 2007 by Aaron Griffin <[email protected]> > > * Copyright (c) 2009 by Xavier Chantry <[email protected]> > > * Copyright (c) 2006-2015 by Pacman Development Team < > > [email protected]> > > > > > > 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
