[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 4233...

From: Daniel Berlin <dberlin_at_dberlin.org>
Date: 2003-01-03 17:26:23 CET

On Friday, January 3, 2003, at 02:18 AM, Blair Zajac wrote:

> Daniel Berlin wrote:
>> On Friday, January 3, 2003, at 01:29 AM, Brian Behlendorf wrote:
>>> On Thu, 3 Jan 2003, Greg Hudson wrote:
>>>> If we put "2000-2003" in files which were created after 2000, as
>>>> well
>>>> as
>>>> files which were not modified in 2003, then we're documenting
>>>> falsehoods, though not terribly important ones.
>>> I've always kinda wondered about ranges... why not just put "2003"?
>>> It's
>>> OK that some of that file was written before 2003; there are
>>> presumably
>>> copies of it floating about with that older date.
>> I'm not a lawyer, this isn't legal advice (sorry, I know it's
>> annoying,
>> but the various bar's are very touchy on the subject of "Unauthorized
>> practice of law")
>> As Yoda might say:
>> Later dates does often invalid a notice make.
>> Invalid notice = easier to claim you are an innocent infringer.
>> Don't bother putting an incorrect notice on files. Either use a
>> correct
>> one, or you are wasting your time.
>> You don't want to try to defend an invalid notice as valid in court.
>> You'll lose.
> Doesn't this all get very complicated if you start copying functions
> from one file to another?
No, but it can seem that way if you think in terms of computer
programming. :)

> Say you have
> file1.c created and copyrighted in 1999
> and
> file2.c created and copyrighted in 2000
> In 2001 you move the function file1() from file1.c to file2.c. file1()
> was initially copyrighted in 1999, so what does the copyright in file2
> become?
2000, 2001
> Do you need to back the date to 1999?
You've effectively published a new change to file2.c. The fact that the
change is *from* file1.c has no bearing.

Think of it this way:

If I copy a paragraph from a book I published in 1999 into my new book
, that doesn't change the copyright date on my new book. It's published
whenever it's published, regardless of where the *content* came from.

The copyright notice is supposed to have the year of first publication
of a work , thankfully.

Otherwise, you'd get into questions about when a work is fixated, etc,
which bear on copyrightability (which my spell checker tells me is "not
a word" (TM). Seems the farther i get in law school, the more this
happens. :P) itself.

The reason you see ranges is because each change arguably makes it a
new work, and thus, needs a new "first publication" date.
I say arguably because i've not found court cases where this was argued
(and decided either way), but I am pretty sure that's why they do it.
Lawyers will generally err on the side of being stupid, annoying, and
tedious, rather than wrong. It's much better from their perspective to
be stupid, annoying, and tedious, than to try to defend something in
court in a case of first impression (IE no one has litigated it before).

> Also, is it a good or bad idea to update the copyright year in files
> even though there were no other changes made to them?
It's pointless, but it doesn't make it invalid.
You've changed the word, and published a new version. Thus, you can
update the publication dates to include the new date.
Of course, that *was* your change, so from a code perspective it's
pointless (since you only updated the comments).
It's like printing a second edition of a book where the only change is
the copyright date. Pointless, but not invalid.
It's generally easier, when possible (it's not always possible or easy,
obviously), to think in terms of books when talking about copyright.
> Does the new
> copyright year only become "valid" when a change is made to the file
> in the new year?
A change to what is visually perceptible is a change, even if the
change itself has no actual value in software terms.
Your code is essentially a very boring published manuscript when it
comes to copyright, not a computer program.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 3 17:27:12 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.