This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: Copyright years
- To: gcc at gcc dot gnu dot org
- Subject: RE: Copyright years
- From: Axel Kittenberger <Anshil at gmx dot net>
- Date: Tue, 2 Jan 2001 09:25:31 +0100 (MET)
Hi,
now I'm seeing this I've a question that burns me already for years, and I
didn't yet find any answer for this.
Is there any legal issue behind the copyright years?
As I've seen the copyright year at almost every application ever seen.
like Copyright 1995-1999 babblebabble
What exactly do the years mean?
Okay, from the message below I now know now exactly what they mean :o)
but what are they really good for?
Has it any legal consequences if I've forgot them in my project?
> I've a
> ------- Forwarded Message
>
> -
------------------------------------------------------------------------> -----
> For those who haven't heard, the year is now 2001. That means that
> whenever you change a file with a copyright notice at the top, you
> should add 2001 to the list of copyrighted years.
>
> For those who work on GNU programs, I have appended the relevant
> extract from the GNU maintainer notes.
>
> When you update the copyright notice, make sure it looks reasonable.
> Specifically, if 2000 is not listed, but the file was changed in 2000
> (you can use `cvs log' to check this), go ahead and add 2000. We
> often forget to update the copyright notice when a change is made.
>
> Ian
>
> Copyright Notices
> =================
>
> You should maintain copyright notices in all files of the program. A
> copyright notice looks like this:
>
> Copyright 19XX, 19YY, 19ZZ COPYRIGHT-HOLDER
>
> The COPYRIGHT-HOLDER is usually the Free Software Foundation, Inc., but
> may be someone else.
>
> The list of year numbers should include each year in which you finished
> preparing a version which was actually released, and which was an
> ancestor of the current version.
>
> It is important to understand that rule carefully, much as you would
> understand a complicated C statement in order to hand-simulate it.
>
> This list is *not* a list of years in which versions were released. It
> is a list of years in which versions, later released, were *completed*.
> So if you finish a version on Dec 31, 1994 and release it on Jan 1,
> 1995, this version requires the inclusion of 1994, but doesn't require
> the inclusion of 1995.
>
> The versions that matter, for purposes of this list, are versions that
> were ancestors of the current version. So if you made a temporary
> branch in maintenance, and worked on branches A and B in parallel, then
> each branch would have its own list of years, which is based on the
> versions released in that branch. A version in branch A need not be
> reflected in the list of years for branch B, and vice versa.
>
> However, if you copy code from branch A into branch B, the years for
> branch A (or at least, for the parts that you copied into branch B) do
> need to appear in the list in branch B, because now they are ancestors
> of branch B.
--
Sent through GMX FreeMail - http://www.gmx.net