From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 460923857C5D for ; Fri, 25 Jun 2021 06:26:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 460923857C5D Received: from fencepost.gnu.org ([2001:470:142:3::e]:41752) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lwfIC-0005HH-8h; Fri, 25 Jun 2021 02:26:20 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4597 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lwfIB-0006Qg-Rr; Fri, 25 Jun 2021 02:26:20 -0400 Date: Fri, 25 Jun 2021 09:26:09 +0300 Message-Id: <83k0misbni.fsf@gnu.org> From: Eli Zaretskii To: Siddhesh Poyarekar Cc: libc-alpha@sourceware.org In-Reply-To: (message from Siddhesh Poyarekar on Fri, 25 Jun 2021 07:53:49 +0530) Subject: Re: Seeking input from developers: glibc copyright assignment policy. References: <4369849.fY2oj7UdlA@omega> <83sg17rrf6.fsf@gnu.org> X-Spam-Status: No, score=2.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 06:26:22 -0000 > Cc: libc-alpha@sourceware.org > From: Siddhesh Poyarekar > Date: Fri, 25 Jun 2021 07:53:49 +0530 > > On 6/25/21 1:00 AM, Eli Zaretskii wrote: > > AFAIU, the copyright assignment to the FSF doesn't contradict (2), > > because the assignment agreement explicitly grants the copyright back > > to you. Quote: > > > > (d) FSF agrees to grant back to Developer, and does hereby grant, > > nonexclusive, royalty free, fully paid up and non-cancellable > > worldwide rights to use the Works (i.e., Developer's changes and/or > > enhancements, not the Program that they enhance), as Developer sees > > fit; this grant back does not limit FSF's rights and public rights > > acquired through this agreement. > > A grant back is not nearly the same thing. I don't follow. You said: > (2) contributors who prefer to retain ownership of their content for > various reasons I'm showing text from the assignment agreement that IMO clearly says the developer retains all the rights. IOW, as long as the developer doesn't prevent the FSF from using the changes as they see fit, the developer can do anything with the changes, including distributing them under any license the developer wants. Why doesn't this satisfy your point (2)? > It still needs trust in the organization to represent my values. I think this is (3), not (2). And I don't really understand what values are being alluded to here. The FSF is an organization whose only purpose is supporting and promoting Free Software; as such, the only relevant values (or should I say "value", singular) is the support and promotion of Free Software. Anything else is not relevant to the FSF and our relations with it, and can only be some private values or views of some FSF members. What does this have to do with the copyright assignment for a contribution to a GNU project such as glibc? > > The DCO allows to make the presentation on behalf of third parties, > > which were involved in writing the code, but are not part of the > > contribution dialog. It also hand-waves over the need to involve the > > employer in the process, to make sure they won't claim the copyright. > > So the risk of admitting code whose copyright could later be > > challenged is greater. > > The assignment process does not *need* an employer's involvement so I'm > not convinced that a developer being dismissive or purposefully > dishonest won't do so in case of an assignment. The DCO text practically tells the developer not to worry about "this nonsense", and just say things "to the best of his/her knowledge". It doesn't even explain the purpose of the declarations in the DCO and how they will be used by the project. For example, the crucial importance of the information veracity for a possible future litigation is never mentioned. So even if the developer wants to DTRT, they won't know what is and isn't important in their declaration, and thus will not be able to make sure the important information is verified and correct.