75596
|
1 Copyright (C) 2007 Free Software Foundation, Inc.
|
75776
|
2 See the end of the file for license conditions.
|
75596
|
3
|
|
4
|
75465
|
5 NOTES ON COPYRIGHTS AND LICENSES
|
|
6
|
|
7 Some terminology:
|
|
8
|
|
9 A "copyright notice" consists of one or a few lines of this format:
|
|
10 "Copyright (C) 2006, 2007 Free Software Foundation, Inc."
|
|
11
|
|
12 A "license notice" is a statement of permissions, and is usually much
|
|
13 longer, eg the text "GNU Emacs is free software...".
|
|
14
|
|
15
|
|
16 Every non-trivial file distributed through the Emacs CVS should be
|
|
17 self-explanatory in terms of copyright and license. This includes
|
|
18 files that are not distributed in Emacs releases (for example, the
|
|
19 admin/ directory), because the whole Emacs CVS is publicly
|
|
20 available.
|
|
21
|
|
22 The definition of triviality is a little vague, but a rule of thumb is
|
|
23 that any file with less than 15 lines of actual content is trivial. If
|
|
24 a file is auto-generated (eg ldefs-boot.el) from another one in the
|
|
25 CVS, then it does not really matter about adding a copyright statement
|
|
26 to the generated file.
|
|
27
|
75792
|
28 However, here is a quote from Matt Norwood (Software Freedom Law
|
|
29 Center) that suggests we should revise the above policy about trivial
|
|
30 files:
|
|
31
|
|
32 If FSF has a strong policy reason notices off of files it
|
|
33 considers "trivial", this will take a lot more bookkeeping; it
|
|
34 also runs the risk of these "trivial" files later growing into
|
|
35 non-trivial files, and being in the tree without any record of
|
|
36 authorship. All in all, I think it's a better policy to attach the
|
|
37 notice and let future authors decide if something is trivial when
|
|
38 they want to reuse it elsewhere.
|
|
39 [...]
|
|
40 In general, copyright law will step back and look at the overall "work"
|
|
41 consisting of all the assembled components working together as a system;
|
|
42 it will apply protection and permissions to this system, not to its
|
|
43 subcomponents. If parts of it are recombined into another system, it
|
|
44 will consider the protections and permissions for each of the source
|
|
45 components only in order to assess the overall status of the work again.
|
|
46 The assessment of whether a set of components is entitled to copyright
|
|
47 protection is the degree to which they display "creativity": not as
|
|
48 atomic units, but as parts of a system working in concert. Thus, several
|
|
49 "trivial" components working together in some coherent system might be
|
|
50 protectible.
|
|
51
|
75465
|
52 The years in the copyright notice should be updated every year (see
|
|
53 file "years" in this directory). The PS versions of refcards etc
|
|
54 should display copyright notices (an exception to the rule about
|
|
55 "generated" files), but these can just display the latest year. The
|
|
56 full list of years should be kept in comments in the source file. If
|
|
57 these are distributed in CVS, check in a regenerated version when the
|
|
58 tex files are updated.
|
|
59
|
|
60 Copyright changes should be propagated to any associated repositories
|
|
61 (eg Gnus, MH-E), but I think in every case this happens automatically
|
|
62 (?).
|
|
63
|
75776
|
64 All README (and other such text files) that are non-trivial should
|
|
65 contain copyright statements and GPL license notices, exactly as .el
|
|
66 files do (see e.g. README in the top-level directory). (Before 2007,
|
|
67 we used a simple, short statement permitting copying and modification
|
|
68 provided legal notices were retained. In Feb 2007 we switched to the
|
|
69 standard GPL text, on legal advice.)
|
75465
|
70
|
75776
|
71 For image files, the copyright and license details should be recorded
|
|
72 in a README file in each directory with images. (Legal advice says
|
|
73 that we need not add notices to each image file individually, if they
|
|
74 allow for that.)
|
75465
|
75
|
|
76 When installing a file with an "unusual" license (after checking first
|
|
77 it is ok), put a copy of the copyright and license in the file (if
|
|
78 possible. It's ok if this makes the file incompatible with its
|
|
79 original format, if it can still be used by Emacs), or in a README
|
|
80 file in the relevant directory.
|
|
81
|
|
82 The vast majority of files are copyright FSF and distributed under the
|
|
83 GPL. A few files (mainly related to language and charset support) are
|
|
84 copyright AIST alone, or both AIST and FSF. (Contact Kenichi Handa
|
|
85 with questions about legal issues in such files.) In all these cases,
|
|
86 the copyright years in each file should be updated each year.
|
|
87
|
|
88 There are some exceptions to the points in the previous paragraph, and
|
|
89 these are listed below for reference, together with any files where
|
|
90 the copyright needs to be updated in "unusual" ways.
|
|
91
|
|
92 If you find any other such cases, please consult to check they are ok,
|
|
93 and note them in this file. This includes missing copyright notices,
|
|
94 and "odd" copyright holders. In most cases, individual authors should
|
|
95 not appear in copyright statements. Either the copyright has been
|
|
96 assigned (check copyright.list) to the FSF (in which case the original
|
|
97 author should be removed and the year(s) transferred to the FSF); or
|
|
98 else it is possible the file should not be in Emacs at all (please
|
|
99 report!).
|
|
100
|
75791
|
101 Note that it seems painfully clear that one cannot rely on CVS logs,
|
|
102 or even ChangeLogs, for older changes. People often installed changes
|
|
103 from others, without recording the true authorship.
|
|
104
|
75465
|
105 [For reference, most of these points were established via email with
|
|
106 rms, 2007/1, "Copyright years".]
|
|
107
|
|
108
|
75596
|
109 lib-src/etags.c # print_version
|
|
110 lib-src/rcs2log # Copyright
|
|
111 lisp/calc/calc-help.el # calc-full-help
|
|
112 lisp/startup.el # fancy-splash-tail
|
|
113 mac/Emacs.app/Contents/Resources/English.lproj/InfoPlist.strings
|
|
114 mac/src/Emacs.r # resource 'vers'
|
|
115 src/emacs.c
|
|
116 - remember to change the latest copyright year in the --version output.
|
|
117 [Post-release, will automate this like set-version does for version.]
|
|
118
|
|
119
|
75465
|
120 <top-level>/install-sh
|
|
121 lispintro/install-sh
|
|
122 - this file is copyright MIT, which is OK. Leave the copyright alone.
|
|
123
|
|
124 etc/edt-user.doc
|
|
125 - update BOTH notices in this file
|
|
126
|
75791
|
127 etc/letter.pbm.letter.xpm
|
|
128 - trivial, no notice needed.
|
|
129
|
75539
|
130 leim/CXTERM-DIC/4Corner.tit, ARRAY30.tit, CCDOSPY.tit, ECDICT.tit,
|
|
131 ETZY.tit, PY-b5.tit, Punct-b5.tit, Punct.tit, QJ-b5.tit, QJ.tit,
|
|
132 SW.tit, TONEPY.tit, ZOZY.tit
|
75465
|
133 - leave the copyrights alone.
|
|
134
|
|
135 leim/MISC-DIC/CTLau-b5.html, CTLau.html, cangjie-table.b5, cangjie-table.cns,
|
75539
|
136 pinyin.map, ziranma.cin
|
75465
|
137 - leave the copyright alone.
|
|
138
|
|
139 leim/SKK-DIC/SKK-JISYO.L
|
|
140 ja-dic/ja-dic.el
|
|
141 (the latter is auto-generated from the former). Leave the copyright alone.
|
|
142
|
|
143 lib-src/etags.c
|
|
144 - this has a copyright Ken Arnold. We are still deciding what should
|
|
145 be done here (see below).
|
|
146
|
|
147 lib-src/getopt1.c, getopt_int.h
|
|
148 - these are from the GNU C library. Leave the copyrights alone.
|
|
149
|
75499
|
150 lisp/play/tetris.el
|
|
151 - no special rules about the copyright. We note here that we believe
|
|
152 (2007/1) there is no problem with our use of the name "tetris" or
|
|
153 the concept.
|
|
154 rms: "My understanding is that game rules as such are not copyrightable."
|
|
155 <http://lists.gnu.org/archive/html/emacs-devel/2007-01/msg00960.html>
|
|
156
|
75465
|
157 lispref/doclicense.texi
|
|
158 man/doclicense.texi
|
|
159 - leave the copyright alone in this imported file.
|
|
160
|
|
161 lisp/net/tramp.el
|
|
162 - there are also copyrights in the body of the file. Update these too.
|
|
163
|
|
164 msdos/is_exec.c, sigaction.c
|
|
165 - these files are copyright DJ Delorie. Leave the copyrights alone.
|
75763
|
166 Leave the Eli Zaretskii copyright in is_exec.c alone. See the
|
|
167 msdos/README file for the legal history of these files.
|
75465
|
168
|
|
169 src/gmalloc.c
|
75539
|
170 - contains numerous copyrights from the GNU C library. Leave them alone.
|
|
171
|
75766
|
172 src/acldef.h, chpdef.h, ndir.h
|
75765
|
173 - see comments below. These files are OK to be released with Emacs
|
|
174 22, but we may want to revisit them afterwards.
|
|
175
|
75586
|
176 [src/unexhp9k800.c - removed 2007/1/27]
|
75539
|
177 [src/m/sr2k.h - removed 2007/1/27]
|
|
178 - First file removed due to legal uncertainties; second file removed
|
|
179 due to dependency on first. Note that src/m/hp800.h is still needed on
|
|
180 hp800 arch.
|
75679
|
181 NB we would like to re-add this file if we can. Please let us know
|
|
182 if you can clarify its legal status.
|
75465
|
183
|
75765
|
184
|
|
185 *** These are copyright issues that need not be fixed until after
|
|
186 Emacs 22 is released (though if they can be fixed before, that is
|
|
187 obviously good):
|
|
188
|
|
189
|
|
190 Is it OK to just `cvs remove' a file for legal reasons, or is
|
|
191 something more drastic needed? A removed file is still available from
|
|
192 CVS, if suitable options are applied. (This CVS issue obviously does
|
|
193 not affect a release).
|
|
194 rms: will ask lawyer
|
|
195
|
|
196
|
|
197 REMOVED etc/orgcard.tex, orgcard.ps
|
|
198 Re-add these files if an assignment is received from Rooke.
|
|
199
|
75791
|
200 etc/images
|
|
201 Image files from GTK, Gnome are under GPLv2 (no "or later"?). RMS will
|
|
202 contact image authors in regards to future switch to v3.
|
|
203
|
75765
|
204
|
75766
|
205 src/acldef.h, chpdef.h, ndir.h
|
75765
|
206 On legal advice from Matt Norwood, the following comment was added
|
|
207 to these files in Feb 2007:
|
|
208
|
|
209 The code here is forced by the interface, and is not subject to
|
|
210 copyright, constituting the only possible expression of the
|
|
211 algorithm in this format.
|
|
212
|
|
213 With the addition of this notice, these files are OK for the
|
|
214 upcoming Emacs-22 release. Post-release, we can revisit this issue
|
|
215 and possibly add a list of all authors who have changed these files.
|
|
216 (details in email from Matt Norwood to rms, 2007/02/03).
|
|
217
|
|
218
|
|
219 REMOVED src/unexhp9k800.c
|
|
220 - we would like to re-add this file if possible. Please let us know
|
|
221 if you can clarify its legal status.
|
|
222 http://lists.gnu.org/archive/html/emacs-devel/2007-02/msg00138.html
|
|
223
|
|
224
|
|
225
|
75465
|
226 *** These are copyright issues still to be addressed:
|
|
227
|
|
228
|
75661
|
229 Maybe some relevant comments here?
|
|
230 <http://groups.google.com/group/linux.debian.legal/browse_thread/thread/123547ea95437a1f>
|
|
231
|
|
232
|
75465
|
233 All README (and other such files) that are non-trivial and were added
|
75776
|
234 by Emacs developers need copyright statements and copying permissions.
|
|
235 missed any?
|
75586
|
236 etc/BABYL?
|
75793
|
237 lisp/term/README?
|
75776
|
238 borderline "trivial" cases (see below)...?
|
|
239 These should use the standard GPL text (same as .el files), rather
|
|
240 than the short notices we have been using till now.
|
|
241 rms: "If a README file is under 60 lines long, using the long version
|
|
242 might be ugly. Please tell me if you encounter one that is under 60
|
|
243 lines."
|
75465
|
244
|
|
245
|
75791
|
246 Clarify the legal status of image files. It's not necessary to put a
|
|
247 notice in each image (where the format allows it). It's OK to put the
|
|
248 information in a README file in the associated directory. Files can be
|
|
249 listed in groups. See etc/README for an example.
|
|
250 Image files to consider:
|
|
251 etc/emacs.xbm, gnu.xpm # rms: ask fx at gnu.org
|
|
252 etc/emacs.icon
|
|
253 etc/images/info, mh-logo
|
|
254 etc/images/gnus/
|
|
255 etc/images/mail/repack, reply-from, reply-to
|
|
256 etc/images/smilies/
|
|
257 nt/icons/
|
|
258 rms: "Can you find this by searching for items in copyright.list that
|
|
259 assign images for Emacs?" [this suggests we ask Bill Wohler]
|
|
260
|
75768
|
261
|
75465
|
262 admin/check-doc-strings
|
|
263 Author is Martin Buchholz, but no assignment from him on file, and
|
|
264 rms has no way to reach him.
|
|
265 etc/ms-kermit - no copyright, but ms-7bkermit has one
|
|
266 etc/e/eterm-color.ti - no copyright
|
|
267 rms: "I think that is not copyrightable under the merger doctrine
|
|
268 because the entries are all forced. At least that is the case in the
|
|
269 US; I am not sure whether we can rely on that in general."
|
|
270
|
75656
|
271 For the above files, mail sent from rms to Matthew Norwood
|
75465
|
272 asking what to do (via Eben Moglen), 2007/1/22 ("Copyright years").
|
|
273
|
|
274
|
|
275 etc/sk-refcard.ps, pl-refcard.ps, cs-refcard.ps
|
|
276 These refcards need to be regenerated (by those with suitable TeX
|
|
277 setups) to get updated copyrights.
|
|
278
|
|
279
|
|
280 lib-src/etags.c - no 'k.* arnold' in copyright.list'
|
|
281 rms: "That is ok, in principle. I used free code released by Ken
|
|
282 Arnold as the starting point. However, it may be that we need to get
|
|
283 and insert whatever his license was for his code."
|
|
284
|
75586
|
285 - 1984 version of ctags, with no copyright, posted to net.sources:
|
|
286 http://groups.google.com/group/net.sources/msg/a21b6c21be12a98d
|
|
287
|
75465
|
288
|
|
289 lwlib/lwlib-int.h, lwlib.h - no copyright
|
|
290 lwlib/Makefile.in, lwlib-utils.c, lwlib.c - copyright Lucid
|
|
291 lwlib/lwlib-Xaw.c - copyright Chuck Thompson
|
|
292 lwlib/lwlib.c - copyright Lucid, but FSF copyright was added in 2002 -
|
|
293 was that correct?
|
|
294 rms: "I asked Matthew Norwood about these, I believe."
|
|
295
|
|
296
|
75768
|
297 man/back.texi
|
|
298 - what license is appropriate for this file? Seems not to be used by
|
75776
|
299 anything - just remove it? Actually seems to be part of the Emacs
|
75768
|
300 Lisp manual, not the Emacs manual.
|
75467
|
301
|
|
302
|
75465
|
303 oldXMenu/
|
|
304 - should there be any FSF copyrights at all in here? Some were added
|
|
305 in 2005, without licence notices. Was this right?
|
|
306 oldXMenu/Makefile.in, Makefile, Imakefile, descrip.mms, insque.c
|
|
307 - issues described in mail to rms, 2006/12/17.
|
|
308 rms: "I have asked for lawyer's advice about these."
|
|
309
|
|
310
|
75766
|
311 src/gnu.h
|
75465
|
312 src/m/mips4.h, news-r6.h, news-risc.h, pmax.h
|
|
313 src/s/aix3-2.h, bsd386.h, hpux8.h, hpux9.h, irix4-0.h, irix5-0.h,
|
|
314 isc2-2.h, netbsd.h, osf1.h, sol2-3.h, sunos4-0.h, umips.h, usg5-4-2.h
|
|
315 - all these (not obviously trivial) files are missing copyrights.
|
|
316 rms: "I should talk about these with Matthew Norwood."
|
75792
|
317 The current legal advice seems to be that we should attach FSF
|
|
318 copyright and GPL for the time being, then review post-release. But it
|
|
319 is still under discussion.
|
75776
|
320
|
|
321
|
|
322 This file is part of GNU Emacs.
|
|
323
|
|
324 GNU Emacs is free software; you can redistribute it and/or modify
|
|
325 it under the terms of the GNU General Public License as published by
|
|
326 the Free Software Foundation; either version 2, or (at your option)
|
|
327 any later version.
|
|
328
|
|
329 GNU Emacs is distributed in the hope that it will be useful,
|
|
330 but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
331 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
332 GNU General Public License for more details.
|
|
333
|
|
334 You should have received a copy of the GNU General Public License
|
|
335 along with GNU Emacs; see the file COPYING. If not, write to the
|
|
336 Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
|
|
337 Boston, MA 02110-1301, USA.
|