This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [commit/6.2] Fix lib (C)s; Was: src/gdb/testsuite ChangeLog lib/insight-suppor ...



On Jul 19, 2004, at 9:07 PM, Andrew Cagney wrote:


Given that the boilerplate "work" is stolen from COPYING and that has a
(C) of 1989,1991 why should you not instead be adding those dates (and have those dates through out all of GDB's files)?
If I had infinite time, I would.

Lets consult the resident expert then :-) http://sources.redhat.com/ml/gdb-patches/2004-07/msg00211.html

Daniel,

the patch changes the (C) from Red Hat to FSF. The year 2003 was added as a change was made then. Michael's asking that 2004 be also added as that's the year.

If the only thing that changed was the copyright notice or license text, i wouldn't do it, because you haven't changed any of the actual copyrighted work, and thus, have not created a new derivative work. Though some sufficiently anal retentive lawyer might tell you otherwise.


It all comes down to whether you consider the license part of the original work or not (since that is what you changed, if it's part of the work, than you've made a derivative).

Let me explain why :

Copyright notice dates are dates of first publication, not dates of change.
In our (distributed free software development) case, they are somewhat similar.
This is because
1. You are supposed to use the date of first publication of each derivative work in that derivative works copyright notice (In other words every new derivative work gets a new publication date added to the copyright notice.)
and
2. Every time we make a change to actual code, and publish it to the public cvs server (and the web, and the ftp server), and thus, the world, we are effectively creating a new published derivative work as of the date/time you commit the change.


Thus,
3. the copyright date gets updated, because you've created a new derivative work, and are publishing it, and thus, add the new date of publication to the copyright notice.


So if you consider the license part of the protected work, and thus, changing just the license text to be creating a new derivative work, then you need to update the copyright date.
If you don't, you don't need to update the copyright date.


Given all of that:

Unless you think that changing only the license text creates a new derivative work (i don't, because i doubt that legalese is a protectible part of the work), you don't need to update the copyright date.
As i said, some sufficiently anal retentive lawyer might tell you that it does create a new derivative work, and thus, you should update the copyright notice.


However, the worst that happens if you get this wrong on the side of not a late enough date is that the protection date is calculated from the earlier date. So you'd lose a year of copyright protection on the protectible part of that derivative version (derivative copyrights cover mainly the new work added to the derivative). None of us will be alive when this code comes out of copyright in any case (in fact, your kids will probably be dead as well), so it's probably not worth worrying about in this case, unless someone official tells you to do it.
:).



BTW, the answer to every legal question ever is "it depends". --Dan



Thoughts?
Andrew




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]