Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: "Joseph S. Myers" <joseph@codesourcery.com>,
	binutils@sourceware.org,	gdb-patches@sourceware.org,
	gcc-patches@gcc.gnu.org
Subject: Re: copyright dates in binutils (and includes/)
Date: Fri, 28 Feb 2014 13:08:00 -0000	[thread overview]
Message-ID: <20140228130844.GA4893@adacore.com> (raw)
In-Reply-To: <20140228085652.GI14922@bubble.grove.modra.org>

> Joseph, do you know why implicitly adding years to the claimed
> copyright years is a problem?  I'm guessing the file needs to be
> published somewhere for each year claimed.

IANAL, but from 2 discussions with copyright-clerk:

  1. We start claiming copyright the year the file as committed
     to a medium (hard drive), not the year it was published.

  2. As long as we have evidence of a copyrightable change each year,
     we can include that year in the list of copyright years in
     all files' headers.

For (2), this is how I asked the FSF:

> My question is: As we have evidence of copyrightable changes to the
> GDB project every year since 1986, is it acceptable fix the copyright
> headers to add the missing holes? And if yes, is it acceptable to go
> straight to the next step, which is reducing the copyright years to
> a single range, even if the original list had holes in it? (we will
> make sure that the first year of the range is always 1986 or later,
> or else investigate to make sure that the range is correct).
>
> For example, we would reduce:
>
> > Copyright (C) 1986, 1988-1989, 1991-1993, 1999-2000, 2007-2012 Free
> > Software Foundation, Inc.
>
> into:
>
> > 1986-2012 Free Software Foundation, Inc.
>
> Naturally, if the initial year was 1995, then it would be the year
> used as the start of the range!

... to which they answered that it would be acceptable.

Does it mean that the sources needed to be made public that year for
us to be able to claim copyright that year? It did not seem so to me.
But you could ask the FSF (copyright DASH clerk AT fsf DOT org).

-- 
Joel


  reply	other threads:[~2014-02-28 13:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-27  4:50 Alan Modra
2014-02-27 13:25 ` Joel Brobecker
2014-02-27 18:47   ` Joseph S. Myers
2014-02-28  8:57     ` Alan Modra
2014-02-28 13:08       ` Joel Brobecker [this message]
2014-02-28 18:22         ` Joseph S. Myers
2014-03-03  3:45           ` Alan Modra
2014-03-03  4:16             ` Alan Modra
2014-03-03 13:33               ` Richard Sandiford
2014-03-05 12:34                 ` Alan Modra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140228130844.GA4893@adacore.com \
    --to=brobecker@adacore.com \
    --cc=binutils@sourceware.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=joseph@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox