X-Git-Url: https://code.delx.au/gnu-emacs/blobdiff_plain/6ce26337da5b58e359fb84b1a15b5ac45404e768..03e30ce84758eb96f2b947fac20288688bcb9781:/admin/notes/copyright diff --git a/admin/notes/copyright b/admin/notes/copyright index 259e45b3b6..91bf87f3b0 100644 --- a/admin/notes/copyright +++ b/admin/notes/copyright @@ -13,6 +13,31 @@ A "license notice" is a statement of permissions, and is usually much longer, eg the text "GNU Emacs is free software...". +Summary for the impatient: + +1. Don't add code to Emacs written by someone other than yourself +without thinking about the legal aspect. Even if the changes are +trivial, consider if they combine with previous changes by the same +author to make a non-trivial total. If so, make sure they have an +assignment. If adding a whole file adjust the copyright statements in +the file. + +2. When installing code written by someone else, the ChangeLog entry +should be in the name of the author of the code, not the person who +installs it. I think it is helpful to put the author (if not yourself) +in the CVS log as well; and to not install any of your own changes in +the same commit. + +3. With images, add the legal info to a README file in the directory +containing the image. + +4. If you add a lot of text to a previously trivial file that had no +legal notices, consider if you should add a copyright statement. + +5. Please don't just add an FSF copyright without checking that is the +right thing to do. + + Every non-trivial file distributed through the Emacs CVS should be self-explanatory in terms of copyright and license. This includes files that are not distributed in Emacs releases (for example, the @@ -25,38 +50,17 @@ a file is auto-generated (eg ldefs-boot.el) from another one in the CVS, then it does not really matter about adding a copyright statement to the generated file. -However, here is a quote from Matt Norwood (Software Freedom Law -Center) that suggests we should revise the above policy about trivial -files: - - If FSF has a strong policy reason notices off of files it - considers "trivial", this will take a lot more bookkeeping; it - also runs the risk of these "trivial" files later growing into - non-trivial files, and being in the tree without any record of - authorship. All in all, I think it's a better policy to attach the - notice and let future authors decide if something is trivial when - they want to reuse it elsewhere. - [...] - In general, copyright law will step back and look at the overall "work" - consisting of all the assembled components working together as a system; - it will apply protection and permissions to this system, not to its - subcomponents. If parts of it are recombined into another system, it - will consider the protections and permissions for each of the source - components only in order to assess the overall status of the work again. - The assessment of whether a set of components is entitled to copyright - protection is the degree to which they display "creativity": not as - atomic units, but as parts of a system working in concert. Thus, several - "trivial" components working together in some coherent system might be - protectible. - -RMS feels, though, that in trivial files (eg etc/FTP), having a -license notice looks odd. Matt Norwood has confirmed it is not -_necessary_ to have licenses in such files, so we are sticking with -the policy of no licenses in "trivial" files. - -NB consequently, if you add a lot of text to a small file, consider -whether your changes have made the file worthy of a copyright notice, -and if so, please add one. +Legal advice says that we could, if we wished, put a license notice +even in trivial files, because copyright law in general looks at the +overall work as a whole. It is not _necessary_ to do so, and rms +prefers that we do not. This means one needs to take care that trivial +files do not grow and become non-trivial without having a license +added. NB consequently, if you add a lot of text to a small file, +consider whether your changes have made the file worthy of a copyright +notice, and if so, please add one. + +It can be helpful to put a reminder comment at the start of a trivial +file, eg: "add a license notice if this grows to > 10 lines of code". The years in the copyright notice should be updated every year (see file "years" in this directory). The PS versions of refcards etc @@ -127,19 +131,31 @@ mac/Emacs.app/Contents/Resources/English.lproj/InfoPlist.strings mac/src/Emacs.r # resource 'vers' src/emacs.c - remember to change the latest copyright year in the --version output. - [Post-release, will automate this like set-version does for version.] + `set-copyright' in admin.el will do all the above. /install-sh lispintro/install-sh - this file is copyright MIT, which is OK. Leave the copyright alone. -admin/check-doc-strings src/m/news-r6.h public domain, leave alone. +etc/BABYL, ms-kermit + no notices (see below). + etc/edt-user.doc - update BOTH notices in this file +etc/emacs.csh + - written by Michael DeCorte, who has no assignment. But trivial + enough to not need license. + +etc/future-bug + - doesn't need a humourless disclaimer, because Karl Fogel says we + can consider it part of Emacs, and he has a blanker disclaimer for + Emacs changes. (email to rgm "[Emacs-commit] emacs/etc future-bug", + 2007028) + etc/letter.pbm,letter.xpm - trivial, no notice needed. @@ -154,17 +170,15 @@ WHY-FREE licenses that they have. They are distributed with Emacs but they are not part of Emacs." +etc/HELLO + standard notices. Just a note that although the file itself is not + really copyrightable, in the wider context of it being part of + Emacs (and written by those with assignments), a standard notice is + fine. + etc/MAILINGLISTS rms: simple license is fine for this file -etc/images/icons/* -nt/icons/emacs21.ico -src/gnu.h - Note that Andrew Zhilin has a copyright assignment on file (confirmed - by fsf-records), even though it doesn't seem to show up in - copyright.list for some reason (at time of writing, 2007/02). - http://lists.gnu.org/archive/html/emacs-devel/2005-11/msg00349.html - leim/CXTERM-DIC/4Corner.tit, ARRAY30.tit, CCDOSPY.tit, ECDICT.tit, ETZY.tit, PY-b5.tit, Punct-b5.tit, Punct.tit, QJ-b5.tit, QJ.tit, SW.tit, TONEPY.tit, ZOZY.tit @@ -173,14 +187,37 @@ SW.tit, TONEPY.tit, ZOZY.tit leim/MISC-DIC/CTLau-b5.html, CTLau.html, cangjie-table.b5, cangjie-table.cns, pinyin.map, ziranma.cin - leave the copyright alone. +Note that pinyin.map, ziranma.cin (and hence the generated +leim/quail/PY.el, ZIRANMA.el) are under GPLv1 or later. leim/SKK-DIC/SKK-JISYO.L ja-dic/ja-dic.el (the latter is auto-generated from the former). Leave the copyright alone. lib-src/etags.c - - this has a copyright Ken Arnold. We are still deciding what should - be done here (see below). + Copyright information is duplicated in etc/ETAGS.README. Update that + file too. + + Until 2007 etags.c was described as being copyright FSF and Ken Arnold. + After some investigation in Feb 2007, then to the best of our + knowledge we believe that the original 1984 Emacs version was based + on the version in BSD4.2. See for example this 1985 post from Ken Arnold: + + I have received enough requests for the current source to ctags + to post it. Here is the latest version (what will go out with + 4.3, modulo any bugs fixed during the beta period). It is the + 4.2 ctags with recognition of yacc and lex tags added. + + See also a 1984 version of ctags (no copyright) posted to net.sources: + + Version of etags.c in emacs-16.56 duplicates comment typos. + + Accordingly, in Feb 2007 we added a 1984 copyright for the + University of California and a revised BSD license. The terms of + this require that the full license details be available in binary + distributions - hence the file etc/ETAGS.README. The fact that the + --version output just says "Copyright FSF" is apparently OK + from a legal point of view. lib-src/getopt1.c, getopt_int.h - these are from the GNU C library. Leave the copyrights alone. @@ -191,6 +228,7 @@ lisp/play/tetris.el the concept. rms: "My understanding is that game rules as such are not copyrightable." + rms: Legal advice is that we are ok and need not worry about this. lispref/doclicense.texi man/doclicense.texi @@ -199,10 +237,136 @@ man/doclicense.texi lisp/net/tramp.el - there are also copyrights in the body of the file. Update these too. -msdos/is_exec.c, sigaction.c - - these files are copyright DJ Delorie. Leave the copyrights alone. - Leave the Eli Zaretskii copyright in is_exec.c alone. See the - msdos/README file for the legal history of these files. + +lwlib/ +rms (2007/02/17): "lwlib is not assigned to the FSF; we don't consider +it part of Emacs. [...] Therefore non-FSF copyrights are ok in lwlib." + +NB don't change the GPL version used for lwlib .c and .h files (see +below). + +FSF copyrights should only appear in files which have undergone +non-trivial cumulative changes from the original versions in the Lucid +Widget Library. NB this means that if you make non-trivial changes to +a file with no FSF copyright, you should add one. Also, if changes are +reverted to the extent that a file becomes basically the same as the +original version, the FSF copyright should be removed. + +In my (rgm) opinion, as of Feb 2007, all the non-trivial files differ +significantly from the original versions, with the exception of +lwlib-Xm.h. Most of the changes that were made to this file have +subsequently been reverted. Therefore I removed the FSF copyright from +this file (which is arguably too trivial to merit a notice anyway). I +added FSF copyright to the following files which did not have them +already: Makefile.in, lwlib-Xaw.c, lwlib-int.h (borderline), +lwlib-utils.c (borderline), lwlib.c, lwlib.h. + +Copyright years before the advent of public CVS in 2001 were those +when I judged (from the CVS logs) that non-trivial amounts of change +had taken place. I also adjusted the existing FSF years in xlwmenu.c, +xlwmenu.h, and xlwmenuP.h on the same basis. + +Note that until Feb 2007, the following files in lwlib were lacking +notices: lwlib-int.h, lwlib.h, lwlib-Xaw.h, lwlib-Xlw.h, lwlib-utils.h + +The following files did not list a Lucid copyright: xlwmenu.h, +xlwmenuP.h. + +To the best of our knowledge, all the code files in lwlib were +originally part of the Lucid Widget Library, even if they did not say +so explicitly. For example, they were all present in Lucid Emacs 19.1 +in 1992. The exceptions are the two Xaw files, which did not appear +till Lucid Emacs 19.9 in 1994. The file lwlib-Xaw.h is too trivial to +merit a copyright notice, but would presumably have the same one as +lwlib-Xaw.c. We have been unable to find a true standalone version of +LWL, if there was such a thing, to check definitively. + +To clarify the situation, in Feb 2007 we added Lucid copyrights and +GPL notices to those files lacking either that were non-trivial, +namely: lwlib-int.h, lwlib.h, xlwmenu.h, xlwmenuP.h. This represents +our best understanding of the legal status of these files. We also +clarified the notices in Makefile.in, which was originally the +Makefile auto-generated from Lucid's Imakefile. + +As of Feb 2007, the following files are considered too trivial for +notices: lwlib-Xaw.h, lwlib-Xlw.h, lwlib-utils.h. + +The version of lwlib/ first installed in Emacs seems to be the same as +that used in Lucid Emacs 19.8 (released 6-sep-93); except the two Xaw +files, which did not appear till Athena support was added in Lucid +Emacs 19.9. In Lucid Emacs 19.1, all files were under GPLv1 or later, +but by Lucid Emacs 19.8, lwlib.c and xlwmenu.c had been switched to v2 +or later. These are the versions that were first installed in Emacs. +So in GNU Emacs, these two files have been under v2 or later since +1994. + +It seems that it was the intention of Lucid to use v1 or later +(excepting the two files mentioned previously); so this is the license +we have used when adding notices to code that did not have notices +originally. Although we have the legal right to switch to v2 or later, +rms prefers that we do not do so. + + +man/*.texi - All manuals should be under GFDL, and should include a +copy of it, so that they can be distributed separately. faq.texi has +a different license, for some reason no-one can remember. +http://lists.gnu.org/archive/html/emacs-devel/2007-04/msg00583.html +http://lists.gnu.org/archive/html/emacs-devel/2007-04/msg00618.html + + +msdos/is_exec.c, sigaction.c - these files are copyright DJ Delorie. +Leave the copyrights alone. Leave the Eli Zaretskii copyright in +is_exec.c alone. See the msdos/README file for the legal history of +these files. + + +oldXMenu/ + Keep the "copyright.h" method used by X11, rather than moving the + licenses into the files. Note that the original X10.h did not use + copyright.h, but had an explicit notice, which we retain. + +If you make non-trivial changes to a file which does not have an FSF +notice, add one and a GPL notice (as per Activate.c). If changes to a +file are reverted such that it becomes essentially the same as the +original X11 version, remove the FSF notice and GPL. + +Only the files which differ significantly from the original X11 +versions should have FSF copyright and GPL notices. At time of writing +(Feb 2007), this is: Activate.c, Create.c, Internal.c. I (rgm) +established this by diff'ing the current files against those in X11R1, +and when I found significant differences looking in the ChangeLog for +the years they originated (the CVS logs are truncated before 1999). I +therefore removed the FSF notices (added in 200x) from the other +files. There are some borderline cases IMO: AddSel.c, InsSel.c, +XMakeAssoc.c, XMenu.h. For these I erred on the side of NOT adding FSF +notices. + +With regards to whether the files we have changed should have GPL +added or not, rms says (2007-02-25, "oldXmenu issues"): + + It does not make much difference, because oldXmenu is obsolete + except for use in Emacs (and it is not normally used in Emacs any + more either). + + So, to make things simple, please put our changes under the GPL. + +insque.c had no copyright notice until 2005. The version of insque.c +added to Emacs 1992-01-27 is essentially the same as insremque.c added +to glic three days later by Roland McGrath, with an FSF copyright and +GPL, but no ChangeLog entry: + +To the best of his recollection, McGrath (who has a copyright +assignment) was the author of this file (email from roland at frob.com +to rms, 2007-02-23, "Where did insque.c come from?"). The FSF +copyright and GPL in this file are therefore correct as far as we +understand it. + +Imakefile had no legal info in Feb 2007, but was obviously based on +the X11 version (which also had no explicit legal info). As it was +unused, I removed it. It would have the same MIT copyright as +Makefile.in does now. + src/gmalloc.c - contains numerous copyrights from the GNU C library. Leave them alone. @@ -211,17 +375,24 @@ src/acldef.h, chpdef.h, ndir.h - see comments below. These files are OK to be released with Emacs 22, but we may want to revisit them afterwards. -[src/unexhp9k800.c - removed 2007/1/27] -[src/m/sr2k.h - removed 2007/1/27] - - First file removed due to legal uncertainties; second file removed - due to dependency on first. Note that src/m/hp800.h is still needed on - hp800 arch. - NB we would like to re-add this file if we can. Please let us know - if you can clarify its legal status. - ** Some notes on resolved issues, for historical information only +etc/TERMS +rms: "surely written either by me or by ESR. (If you can figure out +which year, I can probably tell you which.) Either way, we have papers +for it." It was present in Emacs-16.56 (15-jul-85). rms: "Then I +conclude it was written by me." + +etc/ulimit.hack + Very obsolete file removed March 2007. Doesn't say who the author +is, but web-search suggests Karl Kleinpaste, who has no Emacs +assignment. Trivial anyway. +http://groups.google.com/group/comp.unix.shell/browse_thread/thread/bf3df496994\ +9f1df/7e5922c67b3a98fb +http://groups.google.com/group/comp.unix.questions/msg/cc7e49cacfd1ccb4 + (original 1987 source) + lisp/term/README - had no copyright notice till Feb 2007. ChangeLog.3 suggests it was written by Eric Raymond. When asked by rms on 14 Feb 2007 he said: @@ -234,14 +405,53 @@ lisp/term/README Accordingly, FSF copyright was added. +src/unexhp9k800.c (and dependent src/m/sr2k.h) + http://lists.gnu.org/archive/html/emacs-devel/2007-02/msg00138.html + - briefly removed due to legal uncertainly Jan-Mar 2007. The + relevant assignment is under "hp9k800" in copyright.list. File was + written by John V. Morris at HP, and disclaimed by the author and + HP. So this file is public domain. + + +K Rodgers changes + It was pointed out that K Rodgers only had assigments for VC and + ps-print, but had changed several other files. We tried to contact + him for a general assignment, but he proved uncommunicative (despite + initially indicating to rms he would sign an assignment). As a result, his + changes were removed and/or rewritten independently. For details, see + threads: +http://lists.gnu.org/archive/html/emacs-devel/2007-04/msg00225.html +http://lists.gnu.org/archive/html/emacs-devel/2007-04/msg00257.html + + But then an assignment arrived before the release of Emacs 22: +http://lists.gnu.org/archive/html/emacs-devel/2007-04/msg01427.html + + +lisp/progmodes/python.el +Dave Love alerted us to a potential legal problem: +http://lists.gnu.org/archive/html/emacs-pretest-bug/2007-04/msg00459.html + +On consultation with a lawyer, we found there was no problem: +http://lists.gnu.org/archive/html/emacs-devel/2007-05/msg00466.html + ** Issues that are "fixed" for the release of Emacs 22, but we may wish to revisit later in more detail +admin/check-doc-strings + File says it's in the public domain, but that might not make it so. + +etc/BABYL + File written long ago by authors with no assignment. Keep them + without notices for now, try and contact authors if possible. Be + ready to remove these files if the authors ever object. + +etc/ms-kermit +etc/e/eterm-color.ti src/acldef.h, chpdef.h, ndir.h On legal advice from Matt Norwood, the following comment was added - to these files in Feb 2007: + to these files in Feb/Mar 2007: The code here is forced by the interface, and is not subject to copyright, constituting the only possible expression of the @@ -252,6 +462,21 @@ src/acldef.h, chpdef.h, ndir.h and possibly add a list of all authors who have changed these files. (details in email from Matt Norwood to rms, 2007/02/03). +etc/ms-7bkermit + Says it was written by Andy Lowry and Joel Spolsky. No entry for +either in copyright.list. NB this file is not "constrained" like +ms-kermit (rms: "We know it isn't. A comment at the front says it has +other bindings which might be handy."). File removed March 2007. +Re-add if clear up status at some point. + +etc/Xkeymap.txt + No info on author. File removed March 2007. rms: "It says it is +RLK's way of remapping his keyboard, so it is not constrained. I think +it was written by RLK. Let's delete it; if we contact RLK again, we +can put it back." Actually, RLK == Robert Krawitz has an Emacs +assignment. So this could be restored if it is still useful, but Jan Djärv +says it is obsolete: + src/m/mips4.h, news-risc.h, pmax.h src/s/aix3-2.h, bsd386.h, hpux8.h, hpux9.h, irix4-0.h, irix5-0.h, @@ -311,6 +536,11 @@ sol2-3.h aix3-2.h, bsd386.h, hpux8.h, hpux9.h, netbsd.h, sunos4-0.h started trivial, grown in tiny changes. +netbsd.h: +Roland McGrath said to rms (2007/02/17): "I don't really remember +anything about it. If I put it in without other comment, then probably +I wrote it myself." + Someone might want to tweak the copyright years (for dates before 2001) that I used in all these files. @@ -341,13 +571,10 @@ Make sure that all files with non-standard copyrights or licenses are noted in this file. -etc/BABYL - File says it was written in 1983 by Eugene Ciccarelli, who has no - assignment. RMS: "The lawyer said we can keep BABYL." - - -REMOVED etc/orgcard.tex, orgcard.ps - Re-add these files if an assignment is received from Rooke. +REMOVED etc/gnu.xpm, nt/icons/emacs21.ico, nt/icons/sink.ico + - Restore if find legal info. emacs21.ico is not due to Davenport. + Geoff Voelker checked but could not find a record of where it came + from. etc/images @@ -355,110 +582,21 @@ etc/images contact image authors in regards to future switch to v3. -REMOVED src/unexhp9k800.c - - we would like to re-add this file if possible. Please let us know - if you can clarify its legal status. - http://lists.gnu.org/archive/html/emacs-devel/2007-02/msg00138.html - - -*** These are copyright issues still to be addressed: - -NB apart from switching the TUTORIALs to GPL, I think there is nothing -here that anyone can work on without further input from rms. - - -Maybe some relevant comments here? - - - -etc/gnus-logo.eps, gnus-booklet.ps, gnus-refcard.ps - just to be safe, papers are on the way for the "Gnus logo", even - though it is very similar to the already-assigned "Emacs logo". - - -etc/emacs.csh - does rms want simple license restored for this? - - -etc/ms-kermit - no copyright, but ms-7bkermit has one -etc/e/eterm-color.ti - no copyright - rms: "I think that is not copyrightable under the merger doctrine - because the entries are all forced. At least that is the case in the - US; I am not sure whether we can rely on that in general." - - -etc/TUTORIAL.eo - - remove non-FSF copyright, merge years into FSF, add 2007. - - etc/TUTORIAL* (translations) switch to GPL (see english TUTORIAL) rms: "We can leave the TUTORIAL translations alone until their maintainers update them." + Can adapt short license text from end of GPL translations at: + http://www.gnu.org/licenses/translations.html + Only a few sentences around the license notice need changing from + previous version. +Done: TUTORIAL.eo -lib-src/etags.c - no 'k.* arnold' in copyright.list' - rms: "That is ok, in principle. I used free code released by Ken - Arnold as the starting point. However, it may be that we need to get - and insert whatever his license was for his code." - - under GPL, so OK? - - - 1984 version of ctags, with no copyright, posted to net.sources: - http://groups.google.com/group/net.sources/msg/a21b6c21be12a98d - - -lwlib/lwlib-Xaw.c - copyright Chuck Thompson; but under GPL, so OK? - -lwlib/lwlib-Xlw.c, lwlib-Xm.c, lwlib-Xm.h, xlwmenu.c - copyright lucid and FSF, but under GPL, so OK? - FSF copyrights were added in 200x, was that right? - -lwlib/lwlib-int.h, lwlib.h, lwlib-Xaw.h, lwlib-Xlw.h, lwlib-utils.h - no copyright. last three trivial? - suspect these must have been part of the "Lucid Widget Library", - which is under GPL. Can't find an original version of this to check. - -lwlib/Makefile.in - "some parts" copyright Lucid, no license - -lwlib/lwlib-utils.c, lwlib.c - copyright Lucid, Inc; but under GPL, so OK? - -lwlib/xlwmenu.h, xlwmenuP.h - part of 'Lucid Widget Library', but only FSF copyright (when files - were first checked into RCS, there were no copyrights). Was it right - to add FSF copyright? - should we add a 1992 Lucid copyright? - -lwlib/* - should we: - 1) ensure all files that were originally in the "Lucid Widget - Library" have 1992 Lucid copyright? - 2) add or remove FSF copyrights to any files we have made non-trivial - changes to since 1992? - - -oldXMenu/ - - should there be any FSF copyrights at all in here? Some were added - in 2005, without licence notices. Was this right? - Eg don't think copyright.h should have FSF copyright! - Should add copyright details for X11R1 to the README file. (see - copyright.h). I suggest we remove copyright.h and add the notices - directly into the files. - - -The general issue is, as with some of the Lucid code in lwlib, suppose -file foo.c is Copyright (C) 2000 John Smith, and released under the -GPL. We check it into Emacs CVS and make non-trivial changes to it. -Should we add a FSF copyright or not? Can we add such a notice as soon -as we check it check it in to CVS? +*** These are copyright issues still to be addressed: +None known. -oldXMenu/Makefile.in, Makefile, Imakefile, descrip.mms, insque.c - - issues described in mail to rms, 2006/12/17. -rms: "I have asked for lawyer's advice about these." This file is part of GNU Emacs.