--On January 18, 2006 11:37:09 AM -0600 kfogel@collab.net wrote:
> I asked Mary Ann Moran, a lawyer at CollabNet, about updating all
> source files for 2006, versus just updating the ones that changed in
> 2006. Here's what she said:
>
> | Unfortunately, I think I have to say you need to update on a file
> | by file basis. Since each individual source code file has its own
> | copyright, if the work in that particular copyrighted file is not
> | modified in 2006, then there cannot be a 2006 copyright date. It
> | would be a misrepresentation of the copyright date to put 2006 in
> | that situation, for which I am not sure of the legal consequences,
> | but misrepresentation is never good. The date needs to be
> | whatever the year in which the most recent revision occurred.
> |
> | Sorry the answer could not have entailed less hassle.
FWIW, this matches the advice we've gotten from counsel over at the Apache
Software Foundation.
<http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200601.mbox/%3cc5e632550601100950r695ee46epd71e7b350ccd35f8@mail.gmail.com%3e>
(Cliff Schmidt is the ASF's VP of Legal Affairs and is responsible for
talking to the ASF's lawyers.)
> She also answered the infamous hyphen question once and for all:
>
> | To give notice that there is previously copyrighted works in the
> | revised works, the notice can state the date of first publication
> | of any of the subversion code, the current year and a hyphen to
> | indicate that revised works in between these dates are copyrighted
> | was well. For example (and I am assuming a 2000 date for first
> | publication of subversion, but it should be the actual date
> | whatever that is) "Copyright 2000-2006, (whomever is the copyright
> | owner)".
>
> So there we have it -- definitive answers. We need speculate no more.
On the last point with the hyphen, the ASF has received different advice on
that.
Upon advice of counsel (hinted at in Cliff's email), the ASF will likely be
removing all hyphens and going to a year of first publication only. See
[1] for the US's government advice on this - it's clear that it should only
be the year of first publication there. It also states that 'Copyright
(c)' is wrong - it's either 'Copyright' or '(c)' - not both!
The motivating rationale to just go to the first year goes like this:
open-source projects don't *really* care about when a copyright term hits
the public domain (after all, they're getting it for free today; 95 years
from today, they'll still get it for free and they can stop suing us). The
larger issue is the question of determining when a 'new' copyrightable
expression is created. That's a legal question that has some
counter-intuitive ideas behind it - IMHO, it's too much of a problem to
keep track of that and be legally correct.
Copyright notices are advisory only anyway, so it's better in some sense to
underclaim and then upward revise later if we need to do so in 95 years.
Downward revision is a big no-no.
> Although Mary Ann doesn't say it explicitly, I think I just realized
> why it's legally a Bad Thing to put "2006" in a source file that did
> not change in 2006.
Correct.
> Copyright terms are limited (in theory, anyway), and the timer starts
> ticking from the date the work was created. For a revised work, i.e.,
> a derived work, that is the date of the most recent revision. By
> putting some later date in the copyright notice, we would be
> fraudulently extending the term of the copyright, holding on to it
> longer than the law allows. That obviously can't be right.
Your analysis aligns with Cliff's here.
> (Irrelevant detail: it may be that the timer starts ticking from the
> date the work is "published", not "created", I don't know. Heck, I
> don't even know what "published" means in the era of the Internet,
> except perhaps that the text of the work becomes somehow publicly
> available, which I guess would make etymological sense. Anyway, in
> our case the creation date and publication date are the same, since
> our repository is public, so we don't need to resolve that question.)
FWIW, the advice the ASF has received on this point is that it only matters
when a project issues a release. Distribution usually needs an explicit
intent.
(Yes, you might be able to make a case that posting our internal artifacts
triggers distribution, but that triggers a lot of bad things for us.
Imagine if someone checked in some stolen code or whatever - we'd be liable
for infringement immediately. Bad. We want it triggered when we do a
release instead.)
HTH. IANAL, but I talk to too many of them. =) -- justin
1. <http://www.copyright.gov/circs/circ03.pdf>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 20 00:01:29 2006