Update MAINTAINERS file with details about accepting DCO signed contributions.

	* MAINTAINERS: Add section on patches, copyright and DCO.

diff --git a/binutils/ChangeLog b/binutils/ChangeLog
index 02c667a2762dd534903637f8df441a9dd571eb4f..807ac82a02fefd187c30d598e7d57b187acd1877 100644 (file)
--- a/binutils/ChangeLog
+++ b/binutils/ChangeLog
@@ -1,7 +1,11 @@
+2022-10-19  Nick Clifton  <nickc@redhat.com>
+
+       * MAINTAINERS: Add section on patches, copyright and DCO.
+
 2022-10-12  Nick Clifton  <nickc@redhat.com>
 
        PR 29665
-       * objcopy.c (copy_object): Use the input filename when 
+       * objcopy.c (copy_object): Use the input filename when
        reporting that a .gnu_debuglink section already exists.
 
 2022-10-03  Nick Clifton  <nickc@redhat.com>

diff --git a/binutils/MAINTAINERS b/binutils/MAINTAINERS
index 3b60ac745f892c99fd6894c66ba042af15bfb2bc..36c495e5a508c23120867c6d91377e4a01c46dd0 100644 (file)
--- a/binutils/MAINTAINERS
+++ b/binutils/MAINTAINERS
@@ -212,6 +212,35 @@ also blatantly obvious), and so on.  Obvious fixes should always be
 small, the larger they are, the more likely it is that they contain
 some un-obvious side effect or consequence.
 
+Obvious fixes should not be "legally significant", as defined here:
+
+  https://www.gnu.org/prep/maintain/maintain.html#Legally-Significant
+
+     --------  Patches and Copyright  ---------
+
+If a patch is non-obvious, its copyright must be considered.  There
+are two ways to handle this.  The first is to assign the copyright
+of the FSF.  This ensures that if problems with the authorship of the
+patch arise, the FSF will be able to deal with them.
+
+The list of already assigned copyrights can be obtained from
+fencepost.gnu.org in the file: /gd/gnuorg/copyright.list. 
+
+New copyright assignments can be obtained by completing one of the
+forms found here and sending it off to the FSF:
+
+  https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=tree;f=doc/Copyright
+
+The alternative is to sign off the contribution by agreeing to the
+Developer's Certificate of Origin (version 1.1 or later) and adding a
+line to the end of the contribution that looks something like this:
+
+  Signed-off-by: Random J Developer <random@developer.example.org>
+
+The details of the Developer's Certificate or Origin can be found here:
+       
+  https://developercertificate.org/
+
     --------- Branch Checkins ---------
 
 If a patch is approved for check in to the mainline sources, it can