From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id vFuvFv+Chmf25g4AWB0awg (envelope-from ) for ; Tue, 14 Jan 2025 10:30:07 -0500 Received: by simark.ca (Postfix, from userid 112) id 46C761E100; Tue, 14 Jan 2025 10:30:07 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.0 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id CCB351E0FE for ; Tue, 14 Jan 2025 10:30:05 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 71AA5385B514 for ; Tue, 14 Jan 2025 15:30:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 71AA5385B514 Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 8134B3856951 for ; Tue, 14 Jan 2025 15:28:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8134B3856951 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 8134B3856951 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=45.83.234.184 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1736868532; cv=none; b=SKNbjJbZsYlUCqym83dxCwkTL1KcFA5Gt1xF+VwL5uii8+or1UozOOOotgmrrLiaymXEOKXygqmDCeUsP/0bGDdd/Inv0hGPU3+Mw5XTp7rnGjQtxfFzNfI1nlQGdeUwOday4+K+grCHxEQk5tSjsB59bwsocpR7O+iHhPNunM4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1736868532; c=relaxed/simple; bh=3AhJ72kjv16p4LE5TFBABhvVE7Af94iIQswYpNVVZE0=; h=Message-ID:Subject:From:To:Date:MIME-Version; b=PvmxuWudiMRssAiHCILsxSqGM8hMWlmIdAdTJmUR5k11iss22Qt4mj7OotlTNmPu/RMdjNpNL0BJ4SgFfgTP5FElq/wLTVukdvjxBg+FHR0w/1Qy7gOZCsIpqU02P9P6BGm6Pis4BiRSu8I8G4VPMVmvF24v8t2IrD7ejWY5SAM= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8134B3856951 Received: from r6.localdomain (82-217-174-174.cable.dynamic.v4.ziggo.nl [82.217.174.174]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 2C2283021E82; Tue, 14 Jan 2025 16:28:51 +0100 (CET) Received: by r6.localdomain (Postfix, from userid 1000) id B5116340166; Tue, 14 Jan 2025 16:28:50 +0100 (CET) Message-ID: <1fc456f48c4c6f8aa852c911c6234e219a356434.camel@klomp.org> Subject: Re: DCO: Was: Re: Contributing to gdb From: Mark Wielaard To: Andrew Burgess , Luis Machado , Tom Tromey , Guinevere Larsen Cc: Andrew Pinski , GDB Development , Eli Zaretskii , "Bradley M. Kuhn" , zoe@fsf.org, ksiewicz@fsf.org Date: Tue, 14 Jan 2025 16:28:50 +0100 In-Reply-To: <87tta2r5z2.fsf@redhat.com> References: <86538dac-6c3a-4b9e-9de9-3906e645fa4d@redhat.com> <87y16vwbzl.fsf@tromey.com> <74c8b867-f5bb-48f7-9849-11d06e63a3d7@arm.com> <87tta2r5z2.fsf@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.2 (3.54.2-1.fc41) MIME-Version: 1.0 X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" Hi, Adding some FSF and Conservancy people to the CC (see below for Fosdem related discussion). Bradley, Zoe, Krzysztof, full thread is here: https://inbox.sourceware.org/gdb/7ac6e62d-1969-41b9-be3f-a2f70344a3eb@simar= k.ca/T/#u On Mon, 2025-01-13 at 17:14 +0000, Andrew Burgess via Gdb wrote: > Luis Machado via Gdb writes: > > On 6/23/24 23:06, Tom Tromey wrote: > > > > > I just noticed that GDB (and binutils) are currently not acceptin= g > > > > > DCO's like both glibc > > > > > (https://sourceware.org/glibc/wiki/Contribution%20checklist#Copyr= ight_and_license) > > > > > and GCC (https://gcc.gnu.org/contribute.html#legal) are now accep= ting. > > > > > Has there been any talk about accepting DCOs for gdb and binutils= ? Or > > > > > has this not been brought up yet? > > >=20 > > > If gcc, glibc, and binutils accept it, then IMO gdb should as well. > >=20 > > Bumping this thread. I noticed there was a mention of aligning gcc/glib= c/binutils in terms > > of DCO text. That made me wonder where we stand regarding DCO for gdb [= 1], and if we really > > want to stray from the other toolchain projects by not making a decisio= n on whether we accept > > it or not. > >=20 > > [1] https://inbox.sourceware.org/binutils/24b26a75-3b3d-4a00-af92-0b7c3= 31e2db7@redhat.com/ >=20 > Based on nothing more than remaining consistent with gcc, binutils, and > glibc, I think we should make the switch to accepting DCO contributions > under the same terms that binutils uses[2] (as well as accepting FSF > assigned contributions). >=20 > I'm volunteering myself to add suitable words to the GDB wiki (based off > the binutils wording), unless anyone objects. Ideally I'd like a +1 > from a couple of other global maintainers with no serious objections, > and I'll go ahead and make the change. >=20 > I think that Eli believes the concerns with FSF assignment are > overblown, and given the information provided, I'm inclined to agree. > But at this point, with other components accepting DCO, I'm not sure > that's really relevant. Unless there's a super compelling reason why > GDB should diverge ... I think we should fall into line with the other > components. >=20 > [2] https://sourceware.org/binutils/wiki/HowToContribute I kind of agree with Eli. The current contribution policy is pretty clear. But people seem to be constantly confused about the exact "rules" of using a DCO and Copyright "ownership". Specifically what it means for company disclaimers. With the current process it is clear the FSF will take care of that. With a DCO it suddenly becomes the responsibility of the individual employees to make sure the company agrees to them submitting to the project. That doesn't mean we cannot use a DCO, but it should probably come with much more explanation and guidance (examples) than what is in the Binutils wiki. Are there people going to Fosdem? Krzysztof, the FSF Licensing and Compliance Manager is holding a panel with GNU maintainers on "Managing copyrights in free software projects" which seems really relevant to this discussion: https://fosdem.org/2025/schedule/event/fosdem-2025-5376-managing-copyrights= -in-free-software-projects-discussion-panel-with-gnu-maintainers/ Cheers, Mark