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 E759A39BB62A for ; Fri, 25 Jun 2021 11:31:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E759A39BB62A Received: from fencepost.gnu.org ([2001:470:142:3::e]:36728) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lwk3B-0002Vp-7i; Fri, 25 Jun 2021 07:31:09 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3643 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 1lwk3A-00031X-S0; Fri, 25 Jun 2021 07:31:09 -0400 Date: Fri, 25 Jun 2021 14:30:58 +0300 Message-Id: <83bl7urxjh.fsf@gnu.org> From: Eli Zaretskii To: Siddhesh Poyarekar Cc: libc-alpha@sourceware.org In-Reply-To: <2619fea4-4fb4-84cf-b9d2-f1ef21d40bcb@gotplt.org> (message from Siddhesh Poyarekar on Fri, 25 Jun 2021 14:27:44 +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> <83fsx6s9so.fsf@gnu.org> <2619fea4-4fb4-84cf-b9d2-f1ef21d40bcb@gotplt.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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 11:31:11 -0000 > Cc: libc-alpha@sourceware.org > From: Siddhesh Poyarekar > Date: Fri, 25 Jun 2021 14:27:44 +0530 > > On 6/25/21 12:36 PM, Eli Zaretskii wrote: > > 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. > > Fair enough, I can redact 'shared' to align with your interpretation > because we're otherwise talking about the same thing. It still doesn't > change the crux of my point, that it is perfectly reasonable for someone > to be picky about who they assign copyright to. Anyone can be picky about anything, but it is important that others realize that people are picky for reasons that only make sense to those picky people. That's why this discussion is important: to encourage others invest their own thought and considerations into their own decisions about this. > >> 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? > > Nope, you've got it the other way around. By making copyright > assignment optional, we're stepping away from promoting anything at all. > The proposal does not discourage people from assigning code to the > FSF; FSF assigned contributions are as welcome as those assigned to SFLC > or the SFC or for that matter, using DCO. > > We're not trying to convince GNU projects to stop requiring assignments > either. Other projects are free to operate the way they wish. I agree > Gnulib is in a bit of a sticky situation with the code that is shared > with glibc, but it's not the first time that a GNU project would end up > with code bases with multiple owners that are not FSF. In fact, glibc > is already in that situation. That's tongue-in-cheek, Siddhesh. I've read enough of your posts on this subject to conclude that they are not really neutral. Even in this thread, you are clearly saying that the DCO isn't inferior to the CLA, which actually means it is better, because it's easier to use. > > 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. > > When the assignment is mandatory, code contributions are as good as an > association with the copyright holding organization, hence there is an > engagement. No. You contribute code to a project, not to the FSF. The FSF are the ones who do the clerical work, that's all. > > If you _really_ don't want any engagement, don't contribute your code > > at all. Because the code contribution is the important part here. > > That's the thing; there are many who choose not to contribute for this > precise reason and "we're better off without them" is not something I > endorse in this context. IME, many people who choose not to contribute for this reason don't understand the essence of the CLA, and sometimes are brainwashed. They've never read the actual CLA text, let alone thought about its meaning and effects. Patiently educating these people about the facts goes a long way towards eliminating their objections. Yes, it's easier to just remove the requirement for the CLA, but doing so comes with risks that aren't negligible. > >> 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. > > Lawyers are not a collective, IP lawyers, less so. I have spoken to and > listened to multiple legal experts over the years to get their opinion > on the subject and in my experience the opinion is quite divided and > definitely more nuanced than A > B. I made that conclusion for myself > based on those opinions. I'm quite sure you've heard some say CLA > DCO, and others CLA ≅ DCO. I don't think you've heard anyone saying DCO > CLA. If your conclusion is based on any unbiased considering of such opinions, the result should be obvious, and it isn't "the difference doesn't matter", let alone "doesn't matter in practice". > I think you're misconstruing my personal decision (which is what I have > been stating all along) as the voice of the project. I am not giving > legal advice when stating my preference of DCO over copyright > assignment, I am giving my preference. The voice of the project, as the > governance model stands now, is that of consensus with the final > decision resting with the FSF stewards (based on majority) if consensus > cannot be reached. > > In other words, as a member of the glibc project I am voicing my opinion > to contribute to the process of building consensus around the proposal. That is an important clarification, and I wish that you (and others, including myself) repeated it more frequently in these discussions. Our opinions may have significant weight when we talk about software development of our respective projects, but their weight in matters of legal paperwork and moral values is not higher (nor lower) than those of any other person. We have no real authority in these matters, not unless we can present some relevant credentials which say otherwise. When such credentials are absent, people should not follow our views just because we have a high commit count in our repositories, they should make up their own minds based on the information they seek and find, not based on our views and opinions. > > 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. > > I don't think there's any real evidence to claim that assignments are > less leaky than DCO. Just because one process involves reams of paper > doesn't mean that it's better. I think it's easy to see that the CLA is less leaky by reading the text, and also based on the form that the contributors are requested to fill.