Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Krzysztof Siewicz via Gdb <gdb@sourceware.org>
To: GDB Development <gdb@sourceware.org>
Cc: Mark Wielaard <mark@klomp.org>,
	Andrew Burgess <aburgess@redhat.com>,
	Luis Machado <luis.machado@arm.com>, Tom Tromey <tom@tromey.com>,
	Guinevere Larsen <blarsen@redhat.com>,
	Andrew Pinski <pinskia@gmail.com>, Eli Zaretskii <eliz@gnu.org>,
	zoe@fsf.org, Craig Topham <craigt@fsf.org>,
	"Bradley M. Kuhn" <bkuhn@sfconservancy.org>
Subject: Re: DCO
Date: Mon, 27 Jan 2025 17:36:58 +0100	[thread overview]
Message-ID: <605f81a2-000e-42a3-b5fd-1854e92c56b7@fsf.org> (raw)
In-Reply-To: <Z5esfoH+wMxmDyRP@ebb.org>

Hello,

Thank you Mark for CCing the FSF on that thread. I'm the FSF's licensing 
and compliance manager and let me please also add Craig Topham, FSF's 
copyright and licensing associate so that our complete Licensing Team 
can participate in the discussion. We are not on this list and it took 
us some time to catch up with your conversation.
We at the FSF have once promised to accept DCOs and to draft variant(s) 
of theDCO that would best serve the needs of the GNU project. So we are 
happy that this discussion takes place and that so many people 
communicate their needs and have informed opinions about ways for having 
the needs met. Since the last Cauldron, we have been meaning to look at 
the DCO again, and we're happy to work with people at GDB to help 
implement something directly.

I hope it is OK for you if I present the FSF's position and rationale 
towards copyright assignments, and what guides us when considering DCOs.

DCOs sound like a great tool for cutting bureaucratic overhead in a 
project, but it comes at a cost that should be well understood and risks 
that should be managed. For the time being, copyright assignments bring 
a lot of certainty and security, but with an overhead, so perhaps we 
should focus on minimizing the overhead instead of dropping assignments 
altogether. I explain in detail below why:
The FSF's copyright handling policy is designedwithenforcement of the 
GNU GPLvia copyright actionsin mind. Other goals are: to give FSF 
explicit permission to include the material in a GNU package, to make it 
possible to add additional permission to specific pieces of code, and to 
protect the community from employers' surprise claims (including patent 
claims).
The FSF asks contributors for two kinds of legal papers: copyright 
assignments, and employer copyright disclaimers. Sometimes, for small 
parts of programs we also accept placing them in the public domain or 
giving the FSF an unlimited perpetual nonexclusive license.
Employer disclaimers are important, including for effective GPL 
enforcement. If we accepted a copyright assignment but it turned out 
that copyrights had been actually held by the employer, the copyright 
assignment would not transfer any rights to the FSF. The employer 
disclaimer used by the FSF also addressesthe employer's patents and 
interface copyrights that might cover the contributor's code.

 From what we know, projects collecting DCOs do not require separate 
employer disclaimers, but this looks less burdensome for developers only 
at first glance. AsBradley noted in his post, the Linux DCO text simply 
shifts all the burden for these important tasks onto the individual 
developer. The developer must personallymake sure that the employer 
won't claim copyrights or patents on the code. Also, DCOs are issued by 
employees, not employers. So even if a DCO includes a statement of the 
employee that no employer can claim rights on the code, it is hardly 
equivalent to such a statement made directly by the employer. Whatever 
the contributor agreed with the employer might be not enforceable by the 
project or users, and they are definitely more legally secure if the 
employer issues a disclaimer towards the project and its users directly.
Copyright assignment by its nature includes a transfer of standing to 
bring copyright claims undera license and to add additional permissions. 
We believe that GPL enforcement via copyright is very important for the 
future of software freedom. Thus, the FSF is and will remain committed 
to holding copyrights to preserve software freedom. This is not 
guaranteed for projects where copyrights are assigned toorganizations 
with no commitment to uphold the GPL for the community, e.g. to 
for-profit employers of the developers, that could as well be 
incentivized to relicense the code under a nonfree license.
I hope this is helpful. This is not legal advice as the FSF cannot give 
legal advice, but it is intended to clarify our policy approach. We are 
open to hearing any ideas for improving our copyright handling policy. 
FSF is also hosting a panel at FOSDEM in the Legal and Policy DevRoom 
about some of these issues in a few weeks and I welcome those interested 
to find us there H.1301 (Cornil) on Saturday at 12:30: 
https://fosdem.org/2025/schedule/event/fosdem-2025-5376-managing-copyrights-in-free-software-projects-discussion-panel-with-gnu-maintainers/
If you have any questions, do not hesitate to contact us.

Best regards,


-- 
Krzysztof Siewicz | Licensing and Compliance Manager, Free Software Foundation
GPG Key: 6DC9 E663 36DB 9588 81AB 7E43 2671 24EF FC9C D84E
https://fsf.org

We moved! The FSF changed address, find us at:https://www.fsf.org/about/contact

Free software is important for a free society!
Build a better world with us by matching the average donation of USD $46.22
https://donate.fsf.org

Give the gift of an FSF associate membership:
https://my.fsf.org/gift-a-membership

Follow the FSF on Mastodon:https://hostux.social/@fsf

Sign up for the FSF's newsletter:https://www.fsf.org/fss

US government employee? Use CFC charity code 63210 to support us through
the Combined Federal Campaign.https://cfcgiving.opm.gov/

  reply	other threads:[~2025-01-27 17:14 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-14 21:52 Contributing to gdb shaunak saha via Gdb
2024-06-17 12:21 ` Guinevere Larsen via Gdb
2024-06-17 15:00   ` DCO: Was: " Andrew Pinski via Gdb
2024-06-17 15:57     ` Guinevere Larsen via Gdb
2024-06-17 16:07       ` Jan Beulich via Gdb
2024-06-17 16:32       ` Eli Zaretskii via Gdb
2024-06-17 16:37         ` Guinevere Larsen via Gdb
2024-06-17 16:45           ` Eli Zaretskii via Gdb
2024-06-17 18:18             ` Guinevere Larsen via Gdb
2024-06-17 18:24               ` Andrew Pinski via Gdb
2024-06-17 19:57                 ` Eli Zaretskii via Gdb
2024-06-17 19:37               ` Eli Zaretskii via Gdb
2024-06-17 19:48                 ` Guinevere Larsen via Gdb
2024-06-18 12:25                   ` Eli Zaretskii via Gdb
2024-06-27 17:48                     ` Thiago Jung Bauermann via Gdb
2024-06-27 19:03                       ` Eli Zaretskii via Gdb
2024-06-29  3:27                         ` Thiago Jung Bauermann via Gdb
2024-06-17 19:15           ` Arsen Arsenović via Gdb
2024-06-18 11:54             ` Eli Zaretskii via Gdb
2024-06-28  0:43               ` NightStrike via Gdb
2024-06-28  6:08                 ` Eli Zaretskii via Gdb
2024-06-21 13:20       ` Nick Clifton via Gdb
2024-06-23 22:06       ` Tom Tromey
2024-12-02  8:56         ` Luis Machado via Gdb
2025-01-13 17:14           ` Andrew Burgess via Gdb
2025-01-13 17:32             ` Eli Zaretskii via Gdb
2025-01-17 10:37               ` Florian Weimer via Gdb
2025-01-17 10:44                 ` Luis Machado via Gdb
2025-01-17 13:01                 ` Eli Zaretskii via Gdb
2025-01-21 19:10                   ` Guinevere Larsen via Gdb
2025-01-13 17:42             ` Simon Marchi via Gdb
2025-01-14 15:17               ` automated coding style tool (was: RE: DCO: Was: Re: Contributing to gdb) Aktemur, Tankut Baris via Gdb
2025-01-14 17:11                 ` automated coding style tool Tom Tromey
2025-01-14 17:14                   ` Luis Machado via Gdb
2025-01-14 17:23                     ` Simon Marchi via Gdb
2025-01-14 23:04                       ` Tom Tromey
2025-01-15  6:03                         ` Maciej W. Rozycki
2025-01-18 18:39                           ` Tom Tromey
2025-01-22 22:36                             ` Maciej W. Rozycki
2025-01-15 10:20                         ` Luis Machado via Gdb
2025-01-15 12:24                           ` Aktemur, Tankut Baris via Gdb
2025-01-17 13:42                           ` Andrew Burgess via Gdb
2025-01-17 15:13                             ` Joel Brobecker via Gdb
2025-01-17 15:55                               ` Simon Marchi via Gdb
2025-01-17 17:36                                 ` Phi via Gdb
2025-01-17 19:27                                   ` Simon Marchi via Gdb
2025-01-18 18:56                           ` Tom Tromey
2025-01-20 11:30                             ` Luis Machado via Gdb
2025-01-14 17:15                   ` Simon Marchi via Gdb
2025-01-14  9:49             ` DCO: Was: Re: Contributing to gdb Luis Machado via Gdb
2025-01-14 13:56               ` Eli Zaretskii via Gdb
2025-01-14 15:10               ` Simon Marchi via Gdb
2025-01-14 15:28                 ` Luis Machado via Gdb
2025-01-14 15:47                   ` Simon Marchi via Gdb
2025-01-14 16:33                     ` Luis Machado via Gdb
2025-01-14 16:42                     ` Eli Zaretskii via Gdb
2025-01-15 11:49                       ` Mark Wielaard
2025-01-14 16:46               ` Andrew Burgess via Gdb
2025-01-15 11:25                 ` Mark Wielaard
2025-01-15  6:20               ` Maciej W. Rozycki
2025-01-15 11:05               ` Mark Wielaard
2025-01-14 15:28             ` Mark Wielaard
2025-01-17 10:42               ` Florian Weimer via Gdb
2025-01-17 13:09                 ` Eli Zaretskii via Gdb
2025-01-19 16:37                 ` Mark Wielaard
2025-01-27 15:55                 ` DCO Bradley M. Kuhn via Gdb
2025-01-27 16:36                   ` Krzysztof Siewicz via Gdb [this message]
2025-01-27 17:22                   ` DCO Guinevere Larsen via Gdb
2025-01-31 19:36                     ` DCO Mark Wielaard
2024-06-18 13:32     ` DCO: Was: Re: Contributing to gdb Michael Matz via Gdb
2024-06-19  7:38   ` shaunak saha via Gdb
2024-06-19 12:07     ` Guinevere Larsen via Gdb
2024-06-25 22:27       ` shaunak saha via Gdb
2024-06-26 17:38 ` Tom Tromey
2024-06-28  7:23   ` shaunak saha via Gdb

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=605f81a2-000e-42a3-b5fd-1854e92c56b7@fsf.org \
    --to=gdb@sourceware.org \
    --cc=aburgess@redhat.com \
    --cc=bkuhn@sfconservancy.org \
    --cc=blarsen@redhat.com \
    --cc=craigt@fsf.org \
    --cc=eliz@gnu.org \
    --cc=ksiewicz@fsf.org \
    --cc=luis.machado@arm.com \
    --cc=mark@klomp.org \
    --cc=pinskia@gmail.com \
    --cc=tom@tromey.com \
    --cc=zoe@fsf.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox