[binutils-gdb] Update MAINTAINERS file with details about accepting DCO signed contributions.

[binutils-gdb] Update MAINTAINERS file with details about accepting DCO signed contributions.

[Nick Clifton]

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f2ba47d69ea5f0b7c16b9373b0c4c8942c7252aa

commit f2ba47d69ea5f0b7c16b9373b0c4c8942c7252aa
Author: Nick Clifton <nickc@redhat.com>
Date:   Wed Oct 19 12:39:20 2022 +0100

    Update MAINTAINERS file with details about accepting DCO signed contributions.
    
            * MAINTAINERS: Add section on patches, copyright and DCO.

Diff:
---
 binutils/ChangeLog   |  6 +++++-
 binutils/MAINTAINERS | 29 +++++++++++++++++++++++++++++
 2 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/binutils/ChangeLog b/binutils/ChangeLog
index 02c667a2762..807ac82a02f 100644
--- 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 3b60ac745f8..36c495e5a50 100644
--- 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