RE: Copyright years

RE: Copyright years

[Richard Kenner]

    Is there any legal issue behind the copyright years?

Copyrights have an expiration date and the year the work was written (the
"copyright year") is what starts the clock.

    Has it any legal consequences if I've forgot them in my project?

The law changed in this area recently and I believe the answer now is "no, if
you can prove the year by some other method".  But the copyright notice
is the best way to establish copyright.

RE: Copyright years

[dewar]

I sent a message to RMS asking for specific input on this point. I suggested
the possibility that the legal advice he has been relying on here may be
stale at this point (as I noted earlier, either that is the case, or the
advice is plain wrong :-)

RE: Copyright years

[Gerald Pfeifer]

On Tue, 2 Jan 2001 dewar@gnat.com wrote:
> I would definitely vote for allowing the range of dates to be used (that's
> what GNAT uses by the way, and always has).

It's not long ago (read: a couple of months) that RMS explicitly asked
us to do what has already been described by others.

If the situation has changed or you have different information than he
has, it would be good to check that explicitly with him...

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Copyright years

[Jeffrey A Law]

  In message < 20010102102625V.mitchell@codesourcery.com >you write:
  > 
  > Jeff --
  > 
  >   Do you know if we're allowed to break lines when the copyright list
  > gets really, really long?  I realized that I need to update the dates
  > on tree.def; the copyright line is now 94 characters long.  Can we use
  > two lines?  Does anyone know the answer?
Hmmm, good question.  I don't know the answer.

Since we're working on GNU software, the FSF is the final authority on this
kind of thing.  I recommend you ping RMS directly on this issue.

jeff

Re: Copyright years

[Joseph S. Myers]

On Mon, 1 Jan 2001, Jeffrey A Law wrote:

> 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.

Also note:

* The manuals have overall copyright dates for the whole manuals in
gcc.texi and g77.texi, which it may be necessary to update when changing
other parts of the manual.

* --version output from some programs includes a copyright year, which
according to the GNU coding standards should be the most recent copyright
year only.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Copyright years

[dewar]

<<  Do you know if we're allowed to break lines when the copyright list
gets really, really long?  I realized that I need to update the dates
on tree.def; the copyright line is now 94 characters long.  Can we use
two lines?  Does anyone know the answer?
>>

Sounds like we really should address this requirement, these long lines
are seen an unnecessary and useless burden.

Re: Copyright years

[Mark Mitchell]

Jeff --

  Do you know if we're allowed to break lines when the copyright list
gets really, really long?  I realized that I need to update the dates
on tree.def; the copyright line is now 94 characters long.  Can we use
two lines?  Does anyone know the answer?

  Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Copyright years

[dewar]

<<The first year is the year of first delivery/release of the module and the
second year is the year of first delivery/release of the latest
substantial changes.  Using a dash to span years is ambiguous and I have
been told that it does not have a legal meaning in this context.  Given
that the GCC public development continually releases snapshots, the recent
date continually needs to be updated.
>>

None of these notices have legal meaning under the current copyright
act, at least that is my understanding from having been involved in
several court cases involving copyrights.

<<        RMS has said that he has been advised to list each year of any
substantial change individually.  Because the Free Software Foundation
holds title to GCC, we follow their request for handling copyright
updates, regardless of IBM and Microsoft policy.
>>

I am pretty sure this advice predates the change in the copyright law.
If not, it is incorrect advice :-)

Re: Copyright years

[David Edelsohn]

>>>>> dewar  writes:

dewar> The form of a range (as in 1995-1999) is pretty standard, and used by both
dewar> IBM and Microsoft (whose lawyers presumably understand these issues). As
dewar> time goes by, the unnecessary insistance on a list of dates indeed becomes
dewar> burdensome, and I think the range is far preferable.

	The official recommendation is to list two dates separated by a
comma:

Copyright (C) Acme Corp. 1966,2001.  All Rights Reserved.

The first year is the year of first delivery/release of the module and the
second year is the year of first delivery/release of the latest
substantial changes.  Using a dash to span years is ambiguous and I have
been told that it does not have a legal meaning in this context.  Given
that the GCC public development continually releases snapshots, the recent
date continually needs to be updated.

	RMS has said that he has been advised to list each year of any
substantial change individually.  Because the Free Software Foundation
holds title to GCC, we follow their request for handling copyright
updates, regardless of IBM and Microsoft policy.

David

RE: Copyright years

[dewar]

<<I think recent legal changes (dealing with "compilation copyright") has made
the practice of listing years where no changes were made just because a
release was made as dubious.
>>

Indeed, very dubious, as in quite wrong! If no actual text was authored in
a given year, it is quite wrong to create that any copyrightable elements
were created in that year.

RE: Copyright years

[dewar]

<<The law changed in this area recently and I believe the answer now is "no, if
you can prove the year by some other method".  But the copyright notice
is the best way to establish copyright.
>>

The last statement is most definitely incorrect. The best way to establish
copyright is to register the copyright. Such registration is required to
file any course of copyright action. Furthermore, failure to register a
copyright can have unfortunate consequences. Yes, you can register it
later than the date of copyright, but if you wait more than five years,
then the presumption of originality is lost (i.e. the burden of proof that
something is original shifts -- if you register in five years, the defendant
in a copyright action must prove non-originality, if you delay, then the
plaintiff must prove originality). 

I assume that most GPL'ed software does NOT have registered copyrights,
and that is unfortunate (the cost of registering copyrights is minimal).

However, Richard is certainly right that it is better to have a copyright
notice than not in any document.

As for the range vs enumeration issue

1995,96,98  vs 1995-1998

The important issue in any copyright action is the year in which copyright
was established by auhorship. The first notation implies that copyrightable
elements were created in the year mentioned (by the way, there is absolutely
nothing in the copyright law that would require release of a gcc version to
make something copyrightable). 

The range implies that copyrightable elements were created starting in
1995 and ending in 1998.

If a course of copyright action were litigated, then the issue would be
the exact year in which the copied piece of the system was authored.

If there is an issue as to whether this occurred in 1996 vs 1998 (pretty
unlikely, since this could not be an issue until the year 2070 or something
like that), then neither form creates any presumption. The only function of
the list of dates form is to clearly declare that no copyrightable elements
were created in 1997, but of what use is that to the copyright holder?
Answer -- none at all.

By the way, we have found it useful in the GNAT context to have our checkin
mechanism verify that the copyright notice includes the current year, and
reject any checkins where this is not the case.

RE: Copyright years

[dewar]

<<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
>>

There is no legal issue here at all. The form of a copyright message on
the document itself has no legal significance in any case (the copyright
exists whether or not there is any notation in the document, and the term
of the copyright is statutory, and unaffected by anything that appears in
the document.

The form of a range (as in 1995-1999) is pretty standard, and used by both
IBM and Microsoft (whose lawyers presumably understand these issues). As
time goes by, the unnecessary insistance on a list of dates indeed becomes
burdensome, and I think the range is far preferable.

Note that the situation I state above in the first paragraph has not always
been the case, at least in the US. It used to be the case that a properly
stated copyright notice was important.

Robert Dewar

P.S. A consequence of this is that if you receive a document with no notice
on, you can *NOT* assume that it is public domain. Everything is copyrighted
automatically, and it is up to you to establish that something really is in
the public domain before assuming it is not. Indeed if you recive a document
that says it is in the public domain, then that's not decisive (the notice
might have been put there by other than the copyright holder).

I would definitely vote for allowing the range of dates to be used (that's
what GNAT uses by the way, and always has).

RE: Copyright years

[Richard Kenner]

    > 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.

    Does this mean we have to remove the year 2000 everywhere, because we
    didn't issue an actual release of GCC in that year ?

No.  It says "should include", meaning that even if a file wasn't changed
in a specific year, but there was a release that year, the file should
include that date, not that *only* release years should be listed.  However,
I think recent legal changes (dealing with "compilation copyright") has made
the practice of listing years where no changes were made just because a
release was made as dubious.

RE: Copyright years

[Toon Moene]

Axel Kittenberger wrote:

> 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?

An even more interesting question is implied by this sentence from the
original memo:

> 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.

Does this mean we have to remove the year 2000 everywhere, because we
didn't issue an actual release of GCC in that year ?

Or do we cop out and consider Red Hat's 7.0 "2.96" compiler a "release
which was an ancestor of the current version" ?

1/2 :-)

--
Toon Moene, KNMI, PO Box 201, 3730 AE De Bilt, The Netherlands.
Tel. +31302206443, Fax +31302210407,  e-mail moene@knmi.nl
URL: http://www.knmi.nl/hirlam

RE: Copyright years

[Axel Kittenberger]

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

Copyright years

[Jeffrey A Law]

------- 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.



------- End of Forwarded Message