From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 1OxqLiaHhmeG6w4AWB0awg (envelope-from ) for ; Tue, 14 Jan 2025 10:47:50 -0500 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=RaQKn0Qj; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id AF9081E105; Tue, 14 Jan 2025 10:47:50 -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.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=unavailable 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 025551E05C for ; Tue, 14 Jan 2025 10:47:50 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9717F385694C for ; Tue, 14 Jan 2025 15:47:49 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9717F385694C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1736869669; bh=OF6KNia4T1jAb7MybR0PJ1NJR6qrMeMw0HwE8xP9v8Q=; h=Date:Subject:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=RaQKn0QjOhPndD6efRXamvYJtLS2I5kstWABfFkvxYoMbUyQr7WcCSrg5q3aVWujB M2e9Bu8Q+885lfa9N6NfXOh5fGD+ndCkigBG1Dt8c/H62IYRGww/W30IaSvpEVpQwa ZfvCC077wtm8y9YPeUAeKfF1J/WW1QMdMjRHp9vg= Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id EB345385694C for ; Tue, 14 Jan 2025 15:47:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EB345385694C ARC-Filter: OpenARC Filter v1.0.0 sourceware.org EB345385694C ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1736869628; cv=none; b=crtM+LMTUFAjfETAL+bIkCWEBvFDckaDsdv3OOspvlwNXFk3yywORE5icrd6S4HqVOquGOAr6rrS/TPMlfZ1FttJbkolscssWGGsbtZQUulrhE3l6qU4jcmFVrO0bRS9VlaIxLWNr4o/tgGgM2xk0x3ZfF08JUIUeOkSFu8v61w= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1736869628; c=relaxed/simple; bh=T+bXNC9+rrT5rfgrV6u8Tua2SXQPiNpu0AySqoecXJM=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:To:From; b=coHWHTBg+FxAO8Hf75KRB7ZXWPq2s99sSaZVOOgHjlstLFZCcxSJoZsnKNYTZtn5PvyB50ighsBFUkl4Eo+GLfLw667/BDTJwv6k1tYaYjwMF3zUllR39rPOnOAjzxaCne9r83hae6zcLXoODL8m58spkMQ44mcOXAYW+jGGKWA= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EB345385694C Received: by simark.ca (Postfix, from userid 112) id 9809D1E116; Tue, 14 Jan 2025 10:47:07 -0500 (EST) Received: from [10.0.0.11] (modemcable238.237-201-24.mc.videotron.ca [24.201.237.238]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id D90BD1E05C; Tue, 14 Jan 2025 10:47:03 -0500 (EST) Message-ID: <5505f680-159b-450c-adac-c5e5f3e5a98c@simark.ca> Date: Tue, 14 Jan 2025 10:47:03 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: DCO: Was: Re: Contributing to gdb To: Luis Machado , Andrew Burgess , Tom Tromey , Guinevere Larsen Cc: Andrew Pinski , GDB Development , Eli Zaretskii , Pedro Alves , Nick Clifton References: <86538dac-6c3a-4b9e-9de9-3906e645fa4d@redhat.com> <87y16vwbzl.fsf@tromey.com> <74c8b867-f5bb-48f7-9849-11d06e63a3d7@arm.com> <87tta2r5z2.fsf@redhat.com> <00ba936a-6aa9-4d1d-8b1a-b5459b696289@arm.com> <7ac6e62d-1969-41b9-be3f-a2f70344a3eb@simark.ca> <4ec99ea7-fc48-49ed-a75a-a5a06370d6ad@arm.com> Content-Language: en-US In-Reply-To: <4ec99ea7-fc48-49ed-a75a-a5a06370d6ad@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: , From: Simon Marchi via Gdb Reply-To: Simon Marchi Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" On 2025-01-14 10:28, Luis Machado wrote: > On 1/14/25 15:10, Simon Marchi wrote: >> >> >> On 2025-01-14 04:49, Luis Machado via Gdb wrote: >>> While I agree having gdb be the sole bureaucratic entity not accepting DCO >>> with the other GNU tools projects accepting it (in particular because we >>> share code with binutils, so technically we'd have to make a joint decision), >>> DCO's don't seem to come for free, as we need to track each and every one of >>> those contributions so we can refer back to them when/if we ever decide to >>> update/switch licenses or if a legal problem arises. >>> >>> The contributions are not gdb's, they are still owned by their contributors, >>> but those are granted the right to be distributed by gdb under the GPL, if I >>> understand it correctly. >>> >>> That is potentially a lot of work, and really needs to be taken seriously if >>> we really want to do things by the book. Makes me wonder how we're supposed >>> to track this. >> >> My understanding is that the tracking is done using the "Signed-off-by" >> git trailer. I don't know of any project tracking contributions more >> extensively than that. >> >> Simon > > That's what I see as well. But my understanding is that the identifier used > in the Signed-off-by needs to translate to a reachable entity/person. If ever > there is a problem with a particular contribution, whether it needs to be > reverted or the code ownership is being challenged, that person needs to > be reachable so appropriate action could be taken to rectify the situation. > > Also, if the project ever wants to do a change/move to new licensing terms, > the project will need the approval of these contributors. Hence my observation > that this seems like a significant amount of work (for the project) that needs to > be done to ensure these contributors are always known and reachable. It is just not possible for all contributors to stay reachable forever. For instance, people die. My interpretation is that once we adopt DCO contributions and there are enough of them in, we accept that the license will never be changed, as it would be too practically complicated. This is the reality for pretty much all projects with a wide spectrum of contributors, like the Linux kernel. > > From reading things about DCO, it seems to rely on country-specific > interpretations and legal systems. The Signed-off-by git tag may or > may not be enough guarantee compared to CLA's. > > Obvious disclaimer, this is from doing some research on the topic. I don't > have a background in legal. But it doesn't seem to me like DCO's are as simple > as just adding tags to git commits as some seem to assume. "not as simple" I suppose. For some large projects (like the Linux kernel) it seems that easy, so I keep thinking "if it works for them, with a gazillion more contributions and big greedy compagnies having stake in it (so the potential for litigation), why wouldn't it work for us". But yeah, my opinion is absolutely not legally informed either, I am really just interested in simplifying the process, and reducing the unnecessary proces differences between us and binutils/gcc. At the end of the day, I personally don't care who owns the copyright. I understand the risks that somebody might claim they hold the copyright when they don't. I'm not sure how that differs from the contribution assignment though. Someone could sign the copyright assignment contract when they don't really own the copyright in the first place. If a company claims ownership of some code contributed by some individual who signed a copyright assignment but didn't have the right to contribute it, what would we do today? Wouldn't we have to go and delete that code? Simon