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