From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id SkVwB4Sul2cwVRwAWB0awg (envelope-from ) for ; Mon, 27 Jan 2025 11:04:20 -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=KHFAyDQY; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 109671E105; Mon, 27 Jan 2025 11:04:20 -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=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 EC2CA1E08E for ; Mon, 27 Jan 2025 11:04:18 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7BAF8385829B for ; Mon, 27 Jan 2025 16:04:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7BAF8385829B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1737993858; bh=ECwFqdLrZSHVMtL/Rf+LbzaCJNibLmh5+e2bRQzJ9eg=; h=Date:To:Cc:Subject:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=KHFAyDQYfvO7p4Huqm2y6oijZjSCLzwDtOdTJOFJxztR/LHghFxR//cSDGeexyP5q EQVAMMihAY6q1kNRKFI43ktnt62s8QvWmhSJWfO7vfICx3W+LcUO2ZY06B6pTkKQ32 YcQfpprl8RS0TBQTLeSGYSDH2JV5krfY8BfKn23o= Received: from pine.sfconservancy.org (pine.sfconservancy.org [192.237.253.17]) by sourceware.org (Postfix) with ESMTPS id EACDC385801B for ; Mon, 27 Jan 2025 15:58:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EACDC385801B ARC-Filter: OpenARC Filter v1.0.0 sourceware.org EACDC385801B ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1737993486; cv=none; b=al8ZO0Y9MILEjB6Z8mGF6SE8paONjuIn39QYL7mq/osZASRTRmlWkd2d8Z8yDdx5L6jsBQ5aNhBRwJqsaY6oVLA0gHk+A3VeA+70uLWBwhNK5mU80mTIs6cpIy8bpfrTS2O3oGvpMDt2A8gMZvCI6GeWoJVKUKoydY8EnoCAti4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1737993486; c=relaxed/simple; bh=MEdYmswysxDxTpJD6mb5dVECcKsPcjVR+pt+M0h0W4Q=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=wiAc9nfTYE+HIADvEgOGLFUldoAToBD5LBgBhdIXfodNOhGGASEgah1I7i6uoJFEp/Xtyc7SW9IEUPKsUGFoPHDU/6rebVMJKXttytuQ73ukseuXl3FDPti7VuiTaOBx0Fdl0qdsmLOK+GAMrRTFAYv8s5v5cqI0pO6/0pJrVVU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EACDC385801B Received: from localhost (c-67-171-170-240.hsd1.wa.comcast.net [67.171.170.240]) (Authenticated sender: bkuhn) by pine.sfconservancy.org (Postfix) with ESMTPSA id 86361E7C1; Mon, 27 Jan 2025 15:58:04 +0000 (UTC) Date: Mon, 27 Jan 2025 07:55:42 -0800 To: GDB Development Cc: Mark Wielaard , Andrew Burgess , Luis Machado , Tom Tromey , Guinevere Larsen , Andrew Pinski , Eli Zaretskii , zoe@fsf.org, ksiewicz@fsf.org Subject: Re: DCO Message-ID: References: <86538dac-6c3a-4b9e-9de9-3906e645fa4d@redhat.com> <87y16vwbzl.fsf@tromey.com> <74c8b867-f5bb-48f7-9849-11d06e63a3d7@arm.com> <87tta2r5z2.fsf@redhat.com> <1fc456f48c4c6f8aa852c911c6234e219a356434.camel@klomp.org> <87jzatwwl0.fsf@oldenburg3.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87jzatwwl0.fsf@oldenburg3.str.redhat.com> 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: "Bradley M. Kuhn via Gdb" Reply-To: "Bradley M. Kuhn" Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" Hey GDB folks, I'm not on this list, but I'm a big fan of GDB and have been doing work adjacent to and in support of GDB and all the toolchain communities for some time. I read with interest this DCO thread you've been having; I'm grateful that you cc'ed me, as I do have some experience and knowledge about the situation that I think might be helpful. In the past, I have also been involved in these discussions from inside the FSF — but I haven't been affiliated with the FSF since 2019. As such, I can give perspective from having had different vantage points at different times. First of all, the DCO is a rather neat trick of legal hackery, and it works ok for Linux but the reason it works well in the Linux project is somewhat unique to Linux. The most important thing I want to draw the GDB community's attention to is that the DCO is specifically designed to shift the blame and burden for improperly licensed code ending up in the codebase *onto the individual developers personally*. This works great for companies, as it limits their liability. In practice, it's rare anyone gets sued, so Linux folks are ok with the legal hack. But I regularly urge developers to think carefully if they really want to take on such risk themselves. My position is nuanced: copyright assignment to a trusted non-profit is a really good tool for defending users' rights, but it has to be weighed against the convenience and ease of contribution, and that calculation is very hard to do. One of the huge benefits of the FSF's copyright assignment/disclaimer process is that it forces every developer to have a really important conversation with their employer that they often don't bother to have: (a) is it ok that I'm contributing this upstream?, and (b) what is the proper copyright holder arrangement for such contributions? , and (c) do we (employer/employee) all really agree about (b)? Those are painful conversations, but it's a good thing if they happen as early as possible. Also, those conversations should occur *even if* a developer isn't assigning copyright to a third party. By default, absent a separate agreement, an employee's copyrights will be assigned to their employer anyway via "Work for Hire" (as it's called in the USA, and there are similar doctrines around the world). Those are a few reasons why my usual recommendation is that a project adapt the Linux DCO text for the needs of a their specific project (i.e., one size does not always fit all). For example, the Samba Project decided to require in their Certificate that contributors explicitly license under a v3-group license. Samba did this for for various reasons — including that it protects the project and the developers better than the Linux DCO: https://gitlab.com/samba-team/devel/samba/-/blob/master/README.contributing Most importantly, my concern is that individual developers who don't want to assign to a charity (e.g., FSF or SFC) *push back* on their employers and instead demand employment contracts that let employees personally keep their own copyrights in the Free Software projects they contribute to. Ultimately, individuals make up Free Software projects, and I support the idea that a project have individual voices as part of its copyright holdings (i.e., I am sympathetic to those who don't want a projects' copyright assigned 100% to any organization, even if it's a charity.) But, I don't think an oligarchy of copyright holders — whereby the copyright is held mostly by for-profit employers — serves Free Software's community-oriented, charitable, and individual-developer-and-user-minded goals. We have observed that application of the DCO method of contribution (without a more comprehensive plan) often leads to that oligarchical outcome over time. I'm glad to discuss these topics more on this thread, offer my time to help GDB on how to implement a DCO-like solution effectively, and I also hope to reprise the licensing BoF at Cauldron this year to discuss these issues more. (We spent much of the time in the 2024 Licensing BoF discussing this very issue.) Also, IANAL, TINLA, and I also, as mentioned, I have not been affilaited with the FSF since 2019. Nevertheless, I suspect that FSF folks would agree with most (but not all) of my views above, and I see they're cc'ed and hope they'lll also comment sharing their views. Sincerely, -- Bradley M. Kuhn - he/them Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy ======================================================================== Become a Conservancy Sustainer today: https://sfconservancy.org/sustainer