From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from insect.birch.relay.mailchannels.net (insect.birch.relay.mailchannels.net [23.83.209.93]) by sourceware.org (Postfix) with ESMTPS id 13130385AC2C for ; Fri, 25 Jun 2021 08:57:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 13130385AC2C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id AE1CB321CC3; Fri, 25 Jun 2021 08:57:52 +0000 (UTC) Received: from pdx1-sub0-mail-a75.g.dreamhost.com (100-96-16-86.trex.outbound.svc.cluster.local [100.96.16.86]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 4EE74321C6F; Fri, 25 Jun 2021 08:57:52 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from pdx1-sub0-mail-a75.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.16.86 (trex/6.3.3); Fri, 25 Jun 2021 08:57:52 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Wide-Eyed-Zesty: 2c9a973a6e70c007_1624611472564_234374722 X-MC-Loop-Signature: 1624611472564:1406243112 X-MC-Ingress-Time: 1624611472564 Received: from pdx1-sub0-mail-a75.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a75.g.dreamhost.com (Postfix) with ESMTP id 0D1CD8C383; Fri, 25 Jun 2021 01:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gotplt.org; h=subject:to :cc:references:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; s=gotplt.org; bh=nk36Ly bNkGSW1ZlRTf1XdiVADeA=; b=HeMPYtve6YzDua78D99jMYRkDTUsRaVDMzcCJq V/m708TFOLP0ibcl29wCbHUT9vgcgaMdTtUeW2zmI+XH99SEI8y2psX4PsVwDOfG Xht8om7b+/+F29c3yMaGaJRTgc/K5DYmR8fYf9DtaFJCYqyKI5+OcGhGBZ9golPo knKTM= Received: from [192.168.1.134] (unknown [1.186.101.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a75.g.dreamhost.com (Postfix) with ESMTPSA id 5AF6F8C382; Fri, 25 Jun 2021 01:57:49 -0700 (PDT) Subject: Re: Seeking input from developers: glibc copyright assignment policy. To: Eli Zaretskii Cc: libc-alpha@sourceware.org References: <4369849.fY2oj7UdlA@omega> <83sg17rrf6.fsf@gnu.org> <83k0misbni.fsf@gnu.org> <3e0c8f21-422b-ffd6-d939-49f88f09cac7@gotplt.org> <83fsx6s9so.fsf@gnu.org> X-DH-BACKEND: pdx1-sub0-mail-a75 From: Siddhesh Poyarekar Message-ID: <2619fea4-4fb4-84cf-b9d2-f1ef21d40bcb@gotplt.org> Date: Fri, 25 Jun 2021 14:27:44 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <83fsx6s9so.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3029.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 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 08:57:56 -0000 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. >> 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. As for my views, I'm happy to share them in a separate thread if you wish because they're orthogonal to this discussion. >> 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. When the assignment is mandatory, code contributions are as good as an association with the copyright holding organization, hence there is an engagement. > 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. >>> 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. 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 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. >> 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. 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. Siddhesh