Copyright © 2018 by Thomas E. Dickey



I originally thought that a single copyright notice with a computer program (a single creative work) was sufficient. But with experience, I found that people would copy the work and omit the copyright notice and related licensing information, along with other material that they found inconvenient.

Marking every file helps, perhaps.


To clarify, “originally” meant in the 1990s, when I began publishing my programs on the Internet.

When I began computer programming around 1970, copyright did not apply to computer programs. But computer manuals could be copyrighted. In one episode in 1976, I decided to copyright the manuals which I had written for a system of cross-assemblers and simulation tools.

Most programmers have seen the copyright symbol ©, but that is not part of the US-ASCII character set which was used on most terminals at the time. I (like more than one other person) decided to solve the problem by using (C), and marked the documents according. A few weeks after sending in a repository copy with the required fee, I received a reply saying that the mark was incorrect, and that the registration was denied.

By the way (according to my reading at the time), that was an irreparable error if the document was published without a valid copyright notice.

Things have changed since then, but I do not use the ASCII look-alike (C) except when dealing with people who rely upon folklore. Either the symbol © or the word “copyright” (or abbreviation “copr.”) can be used. The (C) has no basis in law (see the Copyright Office's Circular 3).

Amusingly enough, the recently published Compendium of U.S. Copyright Office Practices (third edition) lists that as one of several variants in Appendix A

A variant of the symbol © will be acceptable only where it resembles the © closely enough to indicate clearly that the copyright symbol is meant.

The given examples are a mixture of hand-drawn and typewriter copy. In most cases, you would find it difficult to agree that the depiction does in fact “indicate clearly” the intended symbol. Whether any of that is relevant is a moot point for this discussion, since clerks could (and likely did) ignore it.


Times change. The Berne Convention is not so rigid regarding proper notices (though (C) is still the wrong mark). What mattered in the mid-1990s and beyond were appropriate guidelines for copyright notices:

Those are few of the many questions I might have asked; there are many possible answers to those. There were different situations for different programs:

Keeping all of that in mind, it is basically an etiquette problem:

We could go on from there, but for freely-modifiable works, I would not add a notice to a file until I had changed about 20%.

If there is a single copyright notice for a collection of files, the year(s) listed should correspond to those when the collection was modified. It is easier to work with individual notices on each file because not all are changed in a given year.

The most recent years for content changes and copyright notices should agree. Adding a copyright notice should not alter the date of modification.

These are all commonsense guidelines. But “common sense ain't all that common” as Will Rogers said.

In practice

Project practice

Most programmers will not remember to add trivia such as copyright notices to source code. That is a task left until later. However, the people assigned to ensure that files have copyright notices usually are not both programmers and knowledgable about the legal nuances.

In 1989 I was working on a project that would run on VMS, and (looking at the sources for a Gould system, to possibly borrow its sed program) saw an example of this problem. Apparently someone had simply run a shell script over all of the sources, adding a line at the end for a copyright notice. It did not even have a “#” to keep a shell from interpreting it, and there was no provision for different types of source file such as C or nroff or shell. Perhaps Gould's copy of the source code did not have that notice applied.

A couple of years later, someone needed to mark up copyright notices on a collection of programs which had been developed at the Software Productivity Consortium, including some that I had helped with. Recalling the way Gould's source had been marked, I suggested making a program that would do this correctly. The result was copyrite.

Several years later (different place altogether), I was told about the need to add copyright notices to several thousand files. The sources were stored in PCVS on a Windows system, and were used for a web application:

I wrote a set of Perl scripts to

That took a few weeks, including review of the changes with the other developers.

Personal practice

I use scripts to check for consistency when releasing a program:


Copyright law does not require a notice. If there is no no explicit license granting permission, fair use only is permitted, even for web pages. Fair use as such always requires attribution, and is limited to small portions of a document.

Just to be helpful, a couple of FAQS from my website (ncurses and xterm) have permissive licenses.


There are several issues to mention; examples are suitable in a few cases.

Backdating copyrights

A copyright notice for an unpublished work is pointless. The notice is used for published works.

On occasion you may notice (pun intended) someone publishing a computer program and later adding copyright notices giving earlier dates than the first date it was made available. That of course is done to “prove” that the work was in development at some early date.

Updating the copyrights

I have noticed some developers “updating the copyrights” on works which have not changed in a given year. Do not do that. A copyright notice tells someone when a work was published. If you did not change the work, there is no reason to keep changing the dates.

Bulk updates

From “updating” to changing copyright notices in derived work is less of a jump than you might suppose. In October 1998, David Dawes sent a patch announcement to the XFree86 developer's mailing list which said in part (emphasis added):

This version consists almost exclusively of the merge of the X11R6.4
code into our source tree.  Changes that people have submitted since
3.9Ng are not included here.  I am hoping to have 3.9Ni ready later
today with those changes.  The diffs are large and it is important to
follow the patching instructions.

The bulk of the source diffs are changes in copyright notices, which
unfortunately obscures the real changes to some degree.  Although the
R6.4 license has been changed, the copyright notices in the source code
have not been changed back (yet).  In considering how to handle this we
decided to let the changes flow through naturally to minimise the impact
on the vendor branch in our CVS repository.  If it turns out that we
need to do something else about this prior to the 4.0 release, we'll do
that then.

The only document in TOG's X11R6.4 ftp area that has been updated for
the license reversion is the RELNOTES.TXT file that is outside the
tarballs.  We have updated the RELNOTES.{ms,PS,TXT} files in our source
tree accordingly so that they do have the correct copyright information.

3.9Nh has been build tested so far on FreeBSD, Linux and Solaris.  Past
experience has shown that there may still be some merge-related problems.
These can be simple typos from the manual parts of the merge, incompatible
changes between our code and the TOG code, local changes being
inadvertently backed out, new portability issues, etc.  If you find any
problems like this, please let me know.

A few areas were isolated from the merge.  Nothing in the hw/xfree86,
hw/xfree68 and hw/xfree98 directories was directly changed.  Same for
xterm and most of the Xaw and Xmu libraries.  For those who are might
need them, diffs between X11R6.3p2 and X11R6.4p3 can be found in
/pub/xf86/beta/R6.4diffs/.  It may be useful for the maintainers of our
xterm and Xaw/Xmu code to check if we need any changes in those areas.

The mail went on to explain where the patch could be obtained, and then gave an example of the typical change which was made. Here is a readable version of that change:

@@ -27,14 +27,9 @@ 
-Copyright (c) 1987, 1994  X Consortium 
+Copyright 1987, 1994, 1998  The Open Group 
-Permission is hereby granted, free of charge, to any person obtaining a copy 
-of this software and associated documentation files (the "Software"), to deal 
-in the Software without restriction, including without limitation the rights 
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 
-copies of the Software, and to permit persons to whom the Software is 
-furnished to do so, subject to the following conditions: 
+All Rights Reserved. 
 The above copyright notice and this permission notice shall be included in 
 all copies or substantial portions of the Software. 
@@ -42,13 +37,13 @@ 
-Except as contained in this notice, the name of the X Consortium shall not be 
+Except as contained in this notice, the name of The Open Group shall not be 
 used in advertising or otherwise to promote the sale, use or other dealings 
-in this Software without prior written authorization from the X Consortium. 
+in this Software without prior written authorization from The Open Group. 

That is, there were three aspects of the change:

The X11R6.4 sources had 6531 files; it is unclear why some files were not modified, unless the changes were done with a text editor rather than a specialized script (see my sccs-tools page for an example). Almost 90% of the files affected by this patch had only changes to the copyright notice. This is the amount of change that diffstat reports for the patch:

1569 files changed, 29434 insertions(+), 38053 deletions(-)

At the time, I reported to David Dawes:

The larger issue is whether XFree86 was obligated in any sense to modify copyright (and permissions) notices in sources it had already received with the previous license. Of course it was not, but David Dawes' message illustrates the confusion people may undergo in these situations.

While I ignored the change of permissions (since most of the X development was done by XFree86), that was the deciding factor for most people. The short term result of the change to permissions was that X11R6.4 was a failed release. A few years later, when its developers took a different tack, and the changes were reconsidered, I brought up those points again.

We revisited this in January 2002, with my posting to the XFree86 developer's mailing list:

Date: Tue, 1 Jan 2002 06:13:05 -0500
From: Thomas Dickey <>
Subject: xterm-164-current.patch

I noticed this yesterday: several files having new copyrights for TOG
There's a problem with that.  The name - ok.  The dates, no.  TOG hasn't
contributed any changes to any (except possibly main.c) of the files that
are touched.  So it's misleading.  (Citing a 1989 date for copyright by
TOG is also misleading).  Don't we have a suitable disclaimer for this

+++ xterm-164-current/ Mon Dec 31 09:15:34 2001
@@ -1,4 +1,4 @@
-.\" $Xorg:,v 1.3 2000/08/17 19:55:10 cpqbld Exp $
+.\" $Xorg:,v 1.4 2001/02/09 02:06:03 xorgcvs Exp $

The Wayback Machine has the CVS log for that file, but not the associated differences. Reading the log, the relevant change appears to be

Revision / (download) / (as text) - annotate - [select for diffs] , Tue Dec 18 17:13:56 2001 UTC (2 years, 10 months ago) by tsi
Branch: Domain-branch
Changes since 3.79: +15 -17 lines
Diff to previous 3.79

Another resync with HEAD branch.

There were some followups, as shown in the thread outline from mutt:

      1     01/01 Thomas Dickey   (1.7K) xterm-164-current.patch
      2 rs  01/01 Branden Robinso (1.3K) ├─>
      3     01/01 Thomas Dickey   (1.0K) │ └─>
      4  s  01/01 Branden Robinso (1.8K) │   └─>
      5     01/01 Jim Gettys      (0.6K) │     └─>
      6 r   01/01 Keith Packard   (0.6K) │       └─>
      7  s  01/01 Branden Robinso (2.0K) │         ├─>
      8     01/02 Keith Packard   (0.7K) │         │ └─>
      9     01/01 Thomas Dickey   (1.1K) │         ├─>
     10     01/01 David Dawes     (1.4K) │         └─>
     11 r   01/01 David Dawes     (0.7K) └─>
     12 r   01/01 David Dawes     (1.9K)   └─>
->   13     01/01 Thomas Dickey   (3.0K)     └─>

This message from David Dawes takes the various responses into account:

Date: Tue, 1 Jan 2002 16:30:46 -0500                                            
From: David Dawes <>                                  
Subject: Re: xterm-164-current.patch                                            
On Tue, Jan 01, 2002 at 12:16:04PM -0800, Keith Packard wrote:                  
>Around 11 o'clock on Jan 1, Jim Gettys wrote:                                  
>> So the copyright date should probably be 1984, rather than 1989!             
>> (unless the file has actually been entirely rewritten).                      
>Any substative changes would add a later year to that; one would expect a      
>copyright range of 1984 through 199x.  I suspect what was done, however,       
>was to re-copyright the entire distribution with the year the license was      
>fixed, and previously when the copyright was moved from the X Consortium,      
>Inc. to The Open Group.  I doubt the date change in either of those cases      
>was valid.                                                                     
I think that the main issue from our point of view is to not add copyright      
date updates to files for which we didn't incorporate any associated            
code updates.                                                                   
A lot of copyright notices were updated recently as part of a resync            
with X11R6.6.  In most cases this was little more than reverting them           
to the pre-R6.4 form so that the notices in the files match the actual          
licensing terms.  As Tom has noted, there were some unintended                  
side-effects, and we should fix them.                                           
David Dawes                                  Email:

While I do not know what changes were made through the XFree86 source-tree, in xterm, I noted the “resync” and established my policy to not “update” copyright notices when no substantiative changes were made. That was mentioned in the announcement of patch #165:

update language of copyrights in some files to reflect the fact that they were reassigned from X Consortium to The Open Group in 1998. Note that this xterm source is derived from the 1996 version from X Consortium, does not incorporate changes made by X Consortium or The Open Group after that date, hence we do not add The Open Group's 1998 copyright date to related files.

At the time I let stand the simple renaming of X Consortium to The Open Group where no change of copyright date was made, but in writing this, I made a to-do item to repair those as well.

Removing notices

Worse than manipulating dates is simply removing a copyright notice or pretending that the people who applied it had no right to do so.

For the former, there is an example in the ncurses FAQ. Someone copied one of ncurses's files, removing the copyright notice, and made a minor change without realizing that the program supported the feature they wanted without the change, and added a GPL notice to the code to replace the MIT-X11 notice removed. That provided a good example of the feature for the FAQ.

If their change had been useful, it would not have been used in ncurses due to the licensing restrictions.

The latter also is mentioned in the ncurses FAQ:

The facts do not support Raymond's statement. I noticed this long after:

Some readers may be unaware that the contracted work to translate termcap to terminfo is not purely mechanical, lacking expression, etc., and thus undeserving of copyright. As I point out in the header, half of the content of the terminfo source-file is commentary. Raymond copied that information from the SCO file, along with information from other sources.

The structure of the file also demonstrates creative effect, e.g., the building-blocks reused in many entries. For example, I asked in 1995 about klone+color, to which Raymond repled that it was something that “we” do to simplify reuse. From the way Raymond worded his reply, I understood that he was asserting that he was the author of that material. In fact, it came from the SCO file.

Beyond commentary and structure, the format of the file demonstrates creative effort (an aspect in which the BSD termcap files fall short). The SCO file used whitespace to make complex entries for color terminals more readable. Here are extracts for discussion:

Automatically formatting thousands of terminal descriptions is harder than you might suppose. In 1986 there probably were no tools. In 1995, Raymond had begun adapting Ross Ridge's mytinfo to mechanically translate between the two, but this work was incomplete. Raymond mentioned scripts to help with the task (which were never published). As a result, there were a few problems. If you look closely, there are errors in both the SCO file and Raymond's version:

I added the checks as part of the formatting option (-f) to tic, having in mind those manually-formatted entries:

Since Raymond did not copy the formatting aspect of the SCO file, he did not copy all of the original work. But one can certainly (mechanically) compare the original and Raymond's copy.

The AT&T and Berkeley people undoubtedly discussed the content of the material developed under contract. Raymond's copying from that work was copyright infringement, which the owners of the copyright could have complained about — up to the statutory limit of three years. That time limit expired just before we released ncurses 4.2 in March 1998.

That is one example of copyright infringement, which some people may confuse with plagiarism. The two are quite distinct. There is no statute of limitations for plagiarism (nor should there be). You may find these interesting to read:

Removing history

Back to the beginning, regarding whether it is necessary to mark every file, a few examples come to mind. In these cases, a developer copied all of the source code, omitting the change history and descriptive material, made minor changes, and reported their changes in a way which was designed to pretend that the elided change history was of less importance. Arguably that crosses the line into plagiarism:

You may find those examples useful when considering how to document your work.