FAQ
The copyright year cannot be arbitrarily extended for a series of
files like that.

You can certainly add a new year when some other content in the file
also gets changed, but you can't just go through and say "I now have
released these files in 2003" if they are otherwise identical to the
ones you released in 2002.

While it makes bookkeeping a bit harder, it's the Right Thing to do.
Without that, you might as well erase the copyrights, because you're
not following the rules.

Sure, you might end up with stuff that isn't updated in some year, so
your copyright looks like "(c) 1998-2000,2002-2003", but I'm sure
you've see that, and that's why. No change was made in 2001, so you
*cannot* include that in the range.

The reason is that the list of years is the first year that *some
part* of the file was published... and to prove copyright forward to a
particular year, for a chunk of the file, you should be able to show
changes to that chunk in that year that were copied.

Just another guy who has made a living from copyrighted material for
the last 25 years,

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Search Discussions

  • Gurusamy Sarathy at Mar 2, 2003 at 10:32 pm

    On 02 Mar 2003 13:57:07 PST, Randal L. Schwartz wrote:
    The copyright year cannot be arbitrarily extended for a series of
    files like that.

    You can certainly add a new year when some other content in the file
    also gets changed, but you can't just go through and say "I now have
    released these files in 2003" if they are otherwise identical to the
    ones you released in 2002.

    While it makes bookkeeping a bit harder, it's the Right Thing to do.
    Without that, you might as well erase the copyrights, because you're
    not following the rules.

    Sure, you might end up with stuff that isn't updated in some year, so
    your copyright looks like "(c) 1998-2000,2002-2003", but I'm sure
    you've see that, and that's why. No change was made in 2001, so you
    *cannot* include that in the range.
    I think this way Too Much Work for no conceivable gain. Is what
    you've described merely conventions that you use, or are they
    rules set down by copyright law?

    I much prefer to treat the copyright notices in individual files
    as a boilerplate statement asserting copyright over the whole
    work (or distinct parts thereof), not just a particular file.


    Sarathy
    gsar@ActiveState.com
  • Hv at Mar 2, 2003 at 10:35 pm
    Randal L. Schwartz wrote:
    :The copyright year cannot be arbitrarily extended for a series of
    :files like that.

    Ok, I did this to find the last change date for the modified files:

    p4 describe -s 18801 | perl -nle 'print $1 if m{//depot/perl/(.*?)#}' | xargs perl -wle 'for$f(@ARGV){@a=`p4 filelog -m2 $f`;$s=[map m{change.*?on (\d+/\d+/\d+)}?$1:(),@a]->[1];print "$f: $s"}'

    .. which gave the list below. I then reversed the patch for all
    those files which didn't show a 2003 edit as change #18807.

    Note that the files listed below with a 2002/01/23 date probably didn't
    change in 2002 either - that's the date the previous copyright update
    was applied. Also, I think some of these files were created more
    recently than 1997 but just copied the "1997-...." copyright from
    another file. If someone would like to supply a patch to sort out other
    copyright problems I'd be happy to apply it, but I'm not going to spend
    more time on this myself right now.

    Is there some way we could replace all this mess with a single
    copyright notice? It seems to me that the perl sources can reasonably
    be described as a single work, and as such it is clear that it has
    been changed each year since it first became available.

    Hugo
    ---
    EXTERN.h: 2002/01/23
    INTERN.h: 2002/01/23
    README: 2002/02/23
    XSUB.h: 2003/02/02
    av.c: 2003/01/22
    av.h: 2002/08/17
    cc_runtime.h: 2002/01/24
    cop.h: 2003/02/03
    cv.h: 2003/02/16
    deb.c: 2002/10/19
    doio.c: 2003/02/09
    doop.c: 2002/10/09
    dosish.h: 2002/10/19
    dump.c: 2003/02/16
    embed.h: 2003/03/02
    embed.pl: 2003/02/17
    embedvar.h: 2003/02/24
    fakesdio.h: 2003/01/20
    fakethr.h: 2002/01/24
    form.h: 2002/01/23
    global.sym: 2003/03/02
    globals.c: 2002/02/20
    gv.c: 2003/02/15
    gv.h: 2002/05/02
    handy.h: 2002/09/26
    hv.c: 2003/01/08
    hv.h: 2002/05/17
    keywords.h: 2002/08/05
    keywords.pl: 2002/11/19
    locale.c: 2003/02/17
    mg.c: 2003/03/02
    mg.h: 2002/10/01
    miniperlmain.c: 2002/10/19
    nostdio.h: 2003/01/20
    numeric.c: 2002/09/08
    op.c: 2003/02/25
    op.h: 2003/01/26
    opcode.h: 2003/02/19
    opcode.pl: 2003/02/19
    opnames.h: 2003/01/03
    pad.c: 2003/01/29
    pad.h: 2002/12/17
    patchlevel.h: 2003/02/19
    perl.c: 2003/03/02
    perl.h: 2003/03/02
    perlapi.c: 2002/11/05
    perlapi.h: 2003/02/26
    perlio.h: 2003/01/22
    perlsdio.h: 2002/05/03
    perlsfio.h: 2002/06/14
    perlvars.h: 2002/12/03
    perly.y: 2002/12/23
    pp.c: 2003/03/02
    pp.h: 2002/10/19
    pp_ctl.c: 2003/03/02
    pp_hot.c: 2003/02/25
    pp_pack.c: 2003/02/19
    pp_sort.c: 2003/01/07
    pp_sys.c: 2003/02/24
    proto.h: 2003/02/26
    reentr.c: 2003/01/16
    reentr.h: 2003/01/16
    reentr.pl: 2003/01/16
    regcomp.c: 2003/02/16
    regcomp.h: 2002/03/20
    regexec.c: 2003/02/26
    regexp.h: 2003/02/16
    run.c: 2002/01/23
    scope.c: 2003/01/03
    scope.h: 2002/12/17
    sv.c: 2003/02/26
    sv.h: 2003/02/24
    taint.c: 2002/12/08
    thrdvar.h: 2003/02/16
    thread.h: 2002/12/02
    toke.c: 2003/02/26
    universal.c: 2003/02/12
    unixish.h: 2002/01/24
    utf8.c: 2003/02/22
    utf8.h: 2002/04/06
    utfebcdic.h: 2002/05/30
    util.c: 2003/03/02
    util.h: 2002/12/17
    x2p/EXTERN.h: 2002/01/23
    x2p/INTERN.h: 2002/01/23
    x2p/a2p.c: 2002/01/23
    x2p/a2p.h: 2002/06/06
    x2p/a2p.y: 2002/01/23
    x2p/hash.c: 2002/04/22
    x2p/hash.h: 2002/01/23
    x2p/proto.h: 2002/01/23
    x2p/str.c: 2002/08/23
    x2p/str.h: 2002/01/23
    x2p/util.c: 2002/01/23
    x2p/util.h: 2002/01/23
    x2p/walk.c: 2002/04/22
    xsutils.c: 2003/02/16
  • Jarkko Hietaniemi at Mar 2, 2003 at 10:45 pm

    On Sun, Mar 02, 2003 at 10:37:39PM +0000, hv@crypt.org wrote:
    merlyn@stonehenge.com (Randal L. Schwartz) wrote:
    :The copyright year cannot be arbitrarily extended for a series of
    :files like that.
    Not to start any silly legal argument since none of us is really an
    IPR layer-- but do you have some reference for that? Personally I
    view the source of Perl as a single piece of work and therefore do
    not find making a $year++ strange at all, but IANAL and all the std
    disclaimers. Remember to consider in your reply the facts that the
    master copy of the source is physically located in Canada and the
    submitters come from Europe, US, Canada, and India :-)

    --
    Jarkko Hietaniemi <jhi@iki.fi> http://www.iki.fi/jhi/ "There is this special
    biologist word we use for 'stable'. It is 'dead'." -- Jack Cohen
  • Randal L. Schwartz at Mar 2, 2003 at 11:23 pm
    "Jarkko" == Jarkko Hietaniemi writes:
    Jarkko> Not to start any silly legal argument since none of us is really an
    Jarkko> IPR layer-- but do you have some reference for that? Personally I
    Jarkko> view the source of Perl as a single piece of work and therefore do
    Jarkko> not find making a $year++ strange at all, but IANAL and all the std
    Jarkko> disclaimers. Remember to consider in your reply the facts that the
    Jarkko> master copy of the source is physically located in Canada and the
    Jarkko> submitters come from Europe, US, Canada, and India :-)

    Well, I just stared at the Berne Convention documents for the past
    20 minutes, and did some google searching before that.

    Apparently, the law itself doesn't talk about any notice except a single
    year. It's been by "convention" that multi-year ranges were allowed.
    And that "convention" means, yup... "up to the lawyers and judges".

    Here's what one lawyer has to say in
    <http://www.raycomm.com/techwhirl/magazine/writing/lawyer_copyrightnotices.html>:

    What happens when the manual is revised? Interestingly, the
    Copyright Act doesn't directly say. But the commonly accepted
    practice is to include multiple years in the copyright notice,
    indicating the various years in which various material in the
    overall work was first published. So, if the manual was originally
    published in 1998 and new copyrightable content was added in 2000,
    the year portion of the copyright notice might be "1998, 2000." If
    new material was added in 1998, 1999, and 2000, the year date might
    be "1998, 1999, 2000"--or, more simply, "1998-2000." (Unfortunately,
    this practice defeats one underlying purpose of the copyright
    notice--to let the public know when copyright protection
    began--because it's often impossible to determine what portions of
    the manual, for example, were first published in 1998 and which in
    2000. That's why some attorneys might recommend that single-year
    notices be used and placed at different locations throughout the
    manual. Or that additional descriptive information be provided along
    with the copyright notice. But that's the subject of another
    column!)

    You might be tempted to ask: Why not just change the date to the
    most recent year and delete the earlier date(s)? Well, first of all,
    you'd be creating an inaccurate copyright notice. (Not all of the
    material was first published in the most recent year, right?) And,
    more importantly, the law will punish you for doing so. According to
    the U.S. Copyright Act, if "the year date [in the copyright notice]
    is more than one year later than the year in which publication first
    occurred, the work is considered to have been published without any
    notice...." The consequences, though not fatal to copyright
    protection, can be significant, so it's important to use care when
    deciding what date(s) to include in your copyright notice.

    So, while I cannot tell you that by statute we need to leave 2003 (and
    2002) out of the list if there are no changes, I can tell you that
    I've worked for at least one company that insisted that this was the
    policy, according to *their* lawyers.

    Since the protection extends to (gulp) the end of Larry's life plus 50
    years, maybe we don't care whether someone claims this as their own at
    that point.

    But maybe the very safest thing would be to roll back all the
    copyright dates to be just the *date of first publication*, and no
    ranges. Sure, there were changes made later, but do they really need
    the additional 5 to 10 years of protection, when the protection
    doesn't apply to the base docuement? :)

    IANAL either... even though I've paid enough to lawyers to have paid
    for a JD. :)

    --
    Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
    <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
    Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
    See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
  • Abigail at Mar 3, 2003 at 12:09 am

    On Sun, Mar 02, 2003 at 03:23:24PM -0800, Randal L. Schwartz wrote:
    "Jarkko" == Jarkko Hietaniemi <jhi@iki.fi> writes:
    Jarkko> Not to start any silly legal argument since none of us is really an
    Jarkko> IPR layer-- but do you have some reference for that? Personally I
    Jarkko> view the source of Perl as a single piece of work and therefore do
    Jarkko> not find making a $year++ strange at all, but IANAL and all the std
    Jarkko> disclaimers. Remember to consider in your reply the facts that the
    Jarkko> master copy of the source is physically located in Canada and the
    Jarkko> submitters come from Europe, US, Canada, and India :-)

    Well, I just stared at the Berne Convention documents for the past
    20 minutes, and did some google searching before that.

    Apparently, the law itself doesn't talk about any notice except a single
    year. It's been by "convention" that multi-year ranges were allowed.
    And that "convention" means, yup... "up to the lawyers and judges".

    Indeed. The copyright notice itself doesn't carry much legal weight.
    The only thing that is required to create the work - from that moment on,
    it's copyrighted. The notice is just a notice - it lets others know who
    owns the copyright, and when the work was created. The work doesn't lose
    its copyright if the notice isn't there.

    Here are some other URLs:

    http://www.templetons.com/brad/copyright.html
    http://www.templetons.com/brad/copymyths.html
    http://www.eff.org/IP/

    http://www.eff.org/IP//copyright.faq says the proper notice is:

    A proper copyright notice consists of three things: 1) the letter "C" in
    a circle (called, logically enough, the "copyright symbol"), or the word
    "Copyright," or the abbreviation "Copr."; 2) the year of first
    publication; 3) the name of the copyright owner. 17 U.S.C. 401(b).

    Point 2 suggests that you should use a single year.




    Abigail

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl5-porters @
categoriesperl
postedMar 2, '03 at 9:57p
activeMar 3, '03 at 12:09a
posts6
users5
websiteperl.org

People

Translate

site design / logo © 2022 Grokbase