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 7C06D3857C6B for ; Fri, 25 Jun 2021 07:06:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7C06D3857C6B Received: from fencepost.gnu.org ([2001:470:142:3::e]:42554) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lwfv2-0002OP-Oj; Fri, 25 Jun 2021 03:06:28 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3238 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 1lwfv2-0005yj-C2; Fri, 25 Jun 2021 03:06:28 -0400 Date: Fri, 25 Jun 2021 10:06:15 +0300 Message-Id: <83fsx6s9so.fsf@gnu.org> From: Eli Zaretskii To: Siddhesh Poyarekar Cc: libc-alpha@sourceware.org In-Reply-To: <3e0c8f21-422b-ffd6-d939-49f88f09cac7@gotplt.org> (message from Siddhesh Poyarekar on Fri, 25 Jun 2021 12:17:57 +0530) Subject: Re: Seeking input from developers: glibc copyright assignment policy. References: <4369849.fY2oj7UdlA@omega> <83sg17rrf6.fsf@gnu.org> <83k0misbni.fsf@gnu.org> <3e0c8f21-422b-ffd6-d939-49f88f09cac7@gotplt.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 07:06:31 -0000 > Cc: libc-alpha@sourceware.org > From: Siddhesh Poyarekar > Date: Fri, 25 Jun 2021 12:17:57 +0530 > > On 6/25/21 11:56 AM, Eli Zaretskii wrote: > > 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)? > > Sorry I should have been clearer, I meant to say that an assignment with > a grant back implies a shared ownership, which is different from wanting > exclusive ownership. It's perfectly reasonable for someone to be picky > about who they share ownership with. I don't see how the above means shared ownership. My interpretation is that the developer owns the changes, and the FSF owns the changes contributed to the project, but they each one own their separate copy separately and independently. "Shared" means what one owner does affects the other, whereas in this case the text of the assignment explicitly says there's no such dependencies. > > 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? > > That's for me to decide, no? :) It's for you to decide, but when you promote those decisions for others to follow, and actively convince GNU projects to stop requiring the CLA, presumably for those same reasons, it is only reasonable for me and others to ask about the details of your views on this, no? > Different people take a different view of the kinds of values they > would attach to an engagement and it may differ with the nature of > engagement. There's no engagement here. You give the FSF some extra rights related to the code, that's all. Those rights don't mean anything tangible for the developers anyway. If you _really_ don't want any engagement, don't contribute your code at all. Because the code contribution is the important part here. > > 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. > > I don't think that difference matters in practice Based on what? Are you a lawyer who is proficient in this area? I'm not, so I listen to those who are, and they say it does matter. > definitely not enough to create an elaborate mechanism that is > similarly leaky. We are in the business of engineering, not exact science. Engineering is a discipline based on compromises: perfect solutions are rarely available, so we choose the least imperfect ones. "Similarly leaky" may be rigorously accurate, but if one is less "leaky" than the other, the sensible solution is to prefer the less "leaky" one.