From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id LlNzJ/zBl2dXYhwAWB0awg (envelope-from ) for ; Mon, 27 Jan 2025 12:27:24 -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=Z0aC2PIb; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 928CB1E105; Mon, 27 Jan 2025 12:27:24 -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 C6C081E08E for ; Mon, 27 Jan 2025 12:27:23 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 621533858430 for ; Mon, 27 Jan 2025 17:27:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 621533858430 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1737998843; bh=4zlHimER82DOzwlnJN1AYLVTeedHFAxPTJGk7mgNQGM=; 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=Z0aC2PIbX6qRghrQsvAAVx7D6+kTjm02ZCkpgNANZQfrJ2G/YWzEO6jCcbeQLmB8+ ijEYt9roVRy6WQ4ANQ8Sw+TslPVCasD72Oux6kpgur1Xp7L3D7Go49/58GAs7CBDIN jvKUasmdLsT6ikPoo89E+dc2tq6O+ivWrHY/4YEU= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id BDAB93858415 for ; Mon, 27 Jan 2025 17:23:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BDAB93858415 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org BDAB93858415 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1737998589; cv=none; b=h9oIzkJhM2cQq907WMTKTS+uRKoJ1UaT7Ft5En6zIC/n7sf9n/V6XsN1/d8Qda/9W3g1pXImrAbox70CbwTfNagvdgwu1ZNpnhEP1O6FtzSMTCfBBKzCKnlfF5fUTDURfTnWtKMUIfb/zi/Kxw4+yyojBaCh8FG2IckWnbtyaRc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1737998589; c=relaxed/simple; bh=O4JUxUoHXMxZLwnjvr6N63yDcCWNKsCNM0gVhQcOk8Q=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=Za7aG+hjGAyQ2jzaSY74lWmSQ8jdqf52NTiI7AY8lso6moxnBiX6euq1O5FFKmUefOlAP0MaymUoc2As1Jwh1hlWwyRq4FWaLzFPQguyt+hAAk21ptVD6/3l/VzkOWJjNFbJ5UhFDmxXveulhn10bx3WN0QnBj/cuJNXE9BMNAk= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BDAB93858415 Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-299-PuMaron0OpKdmhLUDdf_0A-1; Mon, 27 Jan 2025 12:23:01 -0500 X-MC-Unique: PuMaron0OpKdmhLUDdf_0A-1 X-Mimecast-MFC-AGG-ID: PuMaron0OpKdmhLUDdf_0A Received: by mail-qk1-f198.google.com with SMTP id af79cd13be357-7b6ee0af16dso778251685a.3 for ; Mon, 27 Jan 2025 09:23:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737998581; x=1738603381; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4zlHimER82DOzwlnJN1AYLVTeedHFAxPTJGk7mgNQGM=; b=hazp52hW9JYuNAwyGmTLu0fOi65Jpm3ZklqkbcmikQ9VvgpA2iup9yUXBrD3hiZOJk BuF6V5xvaYWSCBzi6sjD8ZHdQU7Mpl2G5DElnHOPt6oHnSnilfJD32vwq2xb+RysOKCk FNcALj0AA0CWsniR1AxjY1ilIS7brmit+Xqx3NAoloHpLStgtSzPFq0km+N4QY5bpF2F h6GW3+EWelenRTVgLcDSI7GQDArfQYcOgUSV3FfYkvcBUfucwNbCL1gxXemorQEtcXNo oH0zDVyKAPBwskblyhTA+pTXKaDRfhBkt1yyyczv0jaTaN/AaHTJxPa1NGO6DQAd+b2A o2ZA== X-Forwarded-Encrypted: i=1; AJvYcCUUkLYGiS7BqlBK+f4qlQDVYuDtAxTs1Cdx7S7lElmjs7drF78MIQx46IxFKMH2ovMt1NE=@sourceware.org X-Gm-Message-State: AOJu0YzzTRzaPpk7OajZg5AFIpMA0vqYUAFAUKUZocmcHD1waIoCttXg djI5Xw3XvgSZl8w66GiDPxonpHHh3ro7M2UKE864e+4ygP+Ip9Rr7/Aq2YTldK+XqArA+laQs2T wVr1bXuh9dE943x6s4rXEUVoxb9FMlXVGZHWHrJpocsJfraTX X-Gm-Gg: ASbGnctEUSKvwYZJeCQQ8prFZ+og/kDXQ6roWuoJUfymTOeS0TXO+iM4bVDOQpCmpIn 1S9zUOzkj3n5w0xGoEykHRU81KUcEjFwJ0B2zPB/cz8P/dmb+TUUiGmhdPJ3OEENbwm51sPs+Tj 5W+/L9beHnFW+UWz2D4vIdjOkIzDksCiVjQuAlm4iHneg8wKNN26tVEmmGDeZpawgLt4E453Yna 1eX8jAJbdKPkyjDksPs0L02uKjCChIMw2tQAXoqnSv7MoXGuEhxm1z32nYpns2JsNmyrKFEm3ig NHcjJf/YCytl/UXp X-Received: by 2002:a05:620a:15a:b0:7be:8343:df2b with SMTP id af79cd13be357-7be8343df99mr2828242485a.10.1737998580971; Mon, 27 Jan 2025 09:23:00 -0800 (PST) X-Google-Smtp-Source: AGHT+IGoWdX6WdVKxHc0iaNN/s1weiepOEjpbdFZFpG1IdG7F1QbrKa07o4C1GEkMITvIHF2TVf4uQ== X-Received: by 2002:a05:620a:15a:b0:7be:8343:df2b with SMTP id af79cd13be357-7be8343df99mr2828239885a.10.1737998580596; Mon, 27 Jan 2025 09:23:00 -0800 (PST) Received: from ?IPV6:2804:14d:8084:9a69::1000? ([2804:14d:8084:9a69::1000]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7be9ae975a3sm408777285a.49.2025.01.27.09.22.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Jan 2025 09:23:00 -0800 (PST) Message-ID: <867b733b-e2fa-4e44-9105-82444100de08@redhat.com> Date: Mon, 27 Jan 2025 14:22:57 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: DCO To: "Bradley M. Kuhn" , GDB Development Cc: Mark Wielaard , Andrew Burgess , Luis Machado , Tom Tromey , Andrew Pinski , Eli Zaretskii , zoe@fsf.org, ksiewicz@fsf.org 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> In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: sHkPKhchmsLFumqPldwUNRNfCR6wjhWbUsUYff2-7TY_1737998581 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: Guinevere Larsen via Gdb Reply-To: Guinevere Larsen Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" On 1/27/25 12:55 PM, Bradley M. Kuhn wrote: > 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. There is another factor that you did not include in your calculation, which is the user actually finding the FSF a trusted non-profit. Regardless of any personal opinions I can have on the matter, I know that several programmers don't think that, and some of them are potential contributors to the GDB project (a personal acquaintance of mine has said so explicitly, and more than one implicitly). By only having the copyright assignment we are implicitly reducing the pool of contributors to those that trust the FSF. > 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. Another option for relaxing the need for CA could be that, if a user is doing contributions in their free time and unrelated to any work, they could use DCO, while someone contributing in a professional capacity would need to sign the CA. This would be enforced through emails: If it is something that looks professional (ie something that looks like emailcompanyTLD) we'd know this goes through their employment, while something that looks end-user (ie, something like whatevergmail/yahoo/universitycom), DCO would suffice, and for emails that we can't be sure, we could just ask the user. This would lower the bar immensely for students or unemployed people, while not allowing for-profit companies to have most of the copyright of the project. We should still incentivize people who are employed but contributing in their free time to talk to their employer, but I think it isn't standard practice for employers to have copyright over things you do in your free time (at least not in Brazil), so I would think that DCO would still be acceptable in that case. > > 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 > -- Cheers, Guinevere Larsen She/Her/Hers