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/
next prev parent 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