Richard, this seems to be fine -- but it is a largish change change. What do you think?
[1:text/plain Hide] Ping? [2:message/rfc822 Hide] From: Jan Nieuwenhuizen <[email protected]> To: "Alfred M. Szmidt" <[email protected]> Cc: Ineiev <[email protected]>, [email protected], [email protected] Subject: Re: Approving Dezyne, savannah task 16067 Organization: AvatarAcademy.nl Date: Sun, 08 Jan 2023 12:39:57 +0100 In-Reply-To: <[email protected]> (Jan Nieuwenhuizen's message of "Sun, 08 Jan 2023 12:24:41 +0100") Content-Type: multipart/mixed; boundary="====-=-=" [2/1:text/plain Hide] Jan Nieuwenhuizen writes: Fixed typo, made patch a bit smaller by undoing some whitespace changes @node Copyright Notices @section Copyright Notices @cindex copyright notices in program files You should maintain a proper copyright notice and a license notice in each nontrivial file in the package. As a rule of thumb, any interesting file more than ten lines long should be considered and could be nontrivial for this purpose. This includes header files and interface definitions for building or running the program, documentation files, and any supporting files. If a file has been explicitly placed in the public domain, then instead of a copyright notice, it should have a notice saying explicitly that it is in the public domain. Even image files, sound files, and other (ASCII) data files should contain copyright notices and license notices, if their format permits. Some formats do not reasonably have room for textual annotations, or adding a header would be very inconvenient; for such files, state the copyright and copying permissions in a @file{README} file, preferrably in the same directory. Change log files should have a copyright notice and license notice at the end, since new material is added at the beginning but the end remains the end. When a file is automatically generated from some other file in the distribution, it is useful for the automatic procedure to copy the copyright notice and permission notice of the file it is generated from, if possible. Alternatively, putting a notice at the beginning saying which file it is generated from, such as @example // Generated by tool-x from file file-y @end example is encouraged and preferred. If the format does not (easily) support such a comment, for example test baseline data, state the copyright and copying permissions in a @file{README} file, preferrably in the same directory. If a header can be added without any complications that is always preferred; please make a balanced choice here. The important thing to keep in mind is that there cannot be any discussion about the copyright and license status of any file. For example, a whole directory tree with a similar layout such as a test suite with generated baseline data should probably use one toplevel @file{README} file describing how to generate the test baseline data, instead of hundreds of similar or identical @file{README} files. Another example is small code snippets that are included verbatim in the (texinfo) documentation and can also be processed directly by the program being documented. Because the example is included as an integral part of the documentation, it is covered automatically by the copyright and license of the manual. Adding a @file{README} file in this case is encouraged. [2/2:text/x-patch Hide] Index: maintain.texi =================================================================== RCS file: /sources/gnustandards/gnustandards/maintain.texi,v retrieving revision 1.283 diff -u -r1.283 maintain.texi --- maintain.texi 27 Feb 2022 04:00:30 -0000 1.283 +++ maintain.texi 8 Jan 2023 11:38:29 -0000 @@ -5,7 +5,7 @@ @c For double-sided printing, uncomment: @c @setchapternewpage odd @c This date is automagically updated when you save this file: -@set lastupdate February 26, 2022 +@set lastupdate January 8, 2023 @c %**end of header @documentencoding UTF-8 @@ -675,18 +675,21 @@ @cindex copyright notices in program files You should maintain a proper copyright notice and a license -notice in each nontrivial file in the package. (Any file more than ten -lines long is nontrivial for this purpose.) This includes header files +notice in each nontrivial file in the package. As a rule of thumb, +any interesting file more than ten lines long should be considered and +could be nontrivial for this purpose. This includes header files and interface definitions for building or running the program, documentation files, and any supporting files. If a file has been explicitly placed in the public domain, then instead of a copyright notice, it should have a notice saying explicitly that it is in the public domain. -Even image files and sound files should contain copyright notices and -license notices, if their format permits. Some formats do not have -room for textual annotations; for these files, state the copyright and -copying permissions in a @file{README} file in the same directory. +Even image files, sound files, and other (ASCII) data files should +contain copyright notices and license notices, if their format +permits. Some formats do not reasonably have room for textual +annotations, or adding a header would be very inconvenient; for such +files, state the copyright and copying permissions in a @file{README} +file, preferrably in the same directory. Change log files should have a copyright notice and license notice at the end, since new material is added at the beginning but the end @@ -695,8 +698,33 @@ When a file is automatically generated from some other file in the distribution, it is useful for the automatic procedure to copy the copyright notice and permission notice of the file it is generated -from, if possible. Alternatively, put a notice at the beginning saying -which file it is generated from. +from, if possible. Alternatively, putting a notice at the beginning +saying which file it is generated from, such as + +@example +// Generated by tool-x from file file-y +@end example + +is encouraged and preferred. If the format does not (easily) support +such a comment, for example test baseline data, state the copyright +and copying permissions in a @file{README} file, preferrably in the +same directory. + +If a header can be added without any complications that is always +preferred; please make a balanced choice here. The important thing to +keep in mind is that there cannot be any discussion about the +copyright and license status of any file. For example, a whole +directory tree with a similar layout such as a test suite with +generated baseline data should probably use one toplevel @file{README} +file describing how to generate the test baseline data, instead of +hundreds of similar or identical @file{README} files. + +Another example is small code snippets that are included verbatim in +the (texinfo) documentation and can also be processed directly by the +program being documented. Because the example is included as an +integral part of the documentation, it is covered automatically by the +copyright and license of the manual. Adding a @file{README} file in +this case is encouraged. A copyright notice looks like this: [2/3:text/plain Hide] -- Jan Nieuwenhuizen <[email protected]> | GNU LilyPond https://lilypond.org Freelance IT https://JoyOfSource.com | Avatar® https://AvatarAcademy.com [3:text/plain Hide] -- Janneke Nieuwenhuizen <[email protected]> | GNU LilyPond https://LilyPond.org Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
