gnustandards maintain.texi

[Richard M. Stallman]

CVSROOT:        /sources/gnustandards
Module name:    gnustandards
Changes by:     Richard M. Stallman <rms>       19/08/13 14:44:12

Modified files:
        .              : maintain.texi 

Log message:
        Verifying an assignment covers new files.
        (New file as change): New node.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/gnustandards/maintain.texi?cvsroot=gnustandards&r1=1.272&r2=1.273

Patches:
Index: maintain.texi
===================================================================
RCS file: /sources/gnustandards/gnustandards/maintain.texi,v
retrieving revision 1.272
retrieving revision 1.273
diff -u -b -r1.272 -r1.273
--- maintain.texi       28 Apr 2019 06:06:58 -0000      1.272
+++ maintain.texi       13 Aug 2019 18:44:12 -0000      1.273
@@ -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 April 28, 2019
+@set lastupdate August 13, 2019
 @c %**end of header
 @documentencoding UTF-8
 
@@ -130,7 +130,6 @@
 This release of the GNU Maintainer Information was last updated
 @value{lastupdate}.
 
-
 @node Getting Help
 @chapter Getting Help
 @cindex help, getting
@@ -285,6 +284,7 @@
 
 @menu
 * Copyright Papers::
+* New file as change::
 * Legally Significant::
 * Recording Contributors::
 * Copying from Other Packages::
@@ -458,6 +458,18 @@
 small, but a disclaimer is acceptable if the contributor insists on
 handling the matter that way.
 
+When a copyright holder has signed an assignment for all future
+changes to the package, and contributes a change made up of new files
+which require no change to any of the old files, we want to avoid any
+uncertainty about whether these files are intended as a change to the
+package and thus covered by that assignment.  The way to do this is to
+ask the contributor to say so in a message to you --- for instance,
+``My modules `frog' and `kangaroo' are intended as changes to the
+program Hoppers.''  Forward the message to @email{assign@@gnu.org},
+who will save it permanently.  A variation on this procedure: the
+contributor who wrote the new files can send copies of the new files
+which contain such a message.
+
 If a contributor wants the FSF to publish only a pseudonym, that is
 ok.  The contributor should say this, and state the desired pseudonym,
 when answering the @file{request-} form.  The actual legal papers will
@@ -786,6 +798,7 @@
 * Canonical:     Canonical License Sources.
 * Code:          License Notices for Code.
 * Documentation: License Notices for Documentation.
+* Examples:      License Notices for Code Examples.
 * Other:         License Notices for Other Files.
 @end menu
 
@@ -972,6 +985,19 @@
 set up to be printed and published only together.  Therefore, it is
 usually simplest to include the GFDL in each manual.
 
+@node License Notices for Code Examples
+@subsection License Notices for Code Examples
+
+When a code example in documentation is more than two or three lines,
+and specific enough that people might want to copy and adapt it, we
+suggest putting a copy of the example in a file of code and releasing
+that under some free software license.  That means it will be
+released under two different licenses: in the manual under the GFDL,
+and in the code example file under a software license.
+
+If the example is important and nontrivial, and 40 lines or more, we
+suggest releasing the code copy under the same license as the program
+it pertains to.  Otherwise, we recommend releasing it under the X11 license.
 
 @node License Notices for Other Files
 @subsection License Notices for Other Files