From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from purple.birch.relay.mailchannels.net (purple.birch.relay.mailchannels.net [23.83.209.150]) by sourceware.org (Postfix) with ESMTPS id 0B85A383B433 for ; Wed, 23 Jun 2021 03:19:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0B85A383B433 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 CA4594023BF; Wed, 23 Jun 2021 03:19:31 +0000 (UTC) Received: from pdx1-sub0-mail-a62.g.dreamhost.com (100-96-11-21.trex.outbound.svc.cluster.local [100.96.11.21]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 43FAD402387; Wed, 23 Jun 2021 03:19:31 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from pdx1-sub0-mail-a62.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.11.21 (trex/6.3.3); Wed, 23 Jun 2021 03:19:31 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Decisive-Slimy: 29b62ae51f74eed2_1624418371560_2898709540 X-MC-Loop-Signature: 1624418371560:1370864948 X-MC-Ingress-Time: 1624418371560 Received: from pdx1-sub0-mail-a62.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a62.g.dreamhost.com (Postfix) with ESMTP id 0873F8C6B6; Tue, 22 Jun 2021 20:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gotplt.org; h=subject:to :references:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; s=gotplt.org; bh=sZ6hwI VWnKPXm+BlmQeOLXFC99s=; b=vuSBcxl+UuYt6K2KM3D/PL+hM5US8DegsLJzx1 cO0+SxVMCOHXkB3CK0ZLssZJBEZen7Mj0z5nzCGxx7vp0x1dMp7ZUYAOpUyUpSDp yIArdVEWNVh+sQuvxjiRc/9VBPiQKdiJwg9jJDnUgFOJS7FDMCcC/XbUEd6hetbd PIEtY= 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-a62.g.dreamhost.com (Postfix) with ESMTPSA id 2A84A89601; Tue, 22 Jun 2021 20:19:28 -0700 (PDT) Subject: Re: Seeking input from developers: glibc copyright assignment policy. To: Bruno Haible , libc-alpha@sourceware.org References: <4369849.fY2oj7UdlA@omega> X-DH-BACKEND: pdx1-sub0-mail-a62 From: Siddhesh Poyarekar Message-ID: Date: Wed, 23 Jun 2021 08:49:24 +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: <4369849.fY2oj7UdlA@omega> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3030.0 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: Wed, 23 Jun 2021 03:19:34 -0000 On 6/23/21 6:34 AM, Bruno Haible wrote: > Accepting DCO-based contributions has legal risks (see [1] and others). > > The cited advantage of the DCO policy is that it promises "future growth > and vibrancy" [2]. > > How would this advantage work in practice? It would mean that an > occasional contributor, after contributing a patch, would not have to > wait a longer time until their patch is accepted. Thus increasing the > motivation of the contributor to contribute again. > > So, you have occasional contributors, for whom the DCO can be an > advantage. And you have regular contributors, who can be expected to > do the paperwork with the FSF; it's a one-time thing. For me it is inclusion of (1) occasional contributors who may fix a bug that's bothering them and walk away (2) contributors who prefer to retain ownership of their content for various reasons and (3) contributors who do not wish to assign copyright to the FSF for various reasons. I, as a regular contributor belong to a mix of 2 and 3. I would generally prefer to retain copyright to my work unless it is done at the behest of my employer (in which case they deservedly own it since they pay me for it) but can be persuaded to assign copyright to an organization I trust to represent my values. > Occasional contributors will typically not start their journey with > contributions to the dynamic loader, the thread library, or the regex > engine. If only that were true. In my experience we have had more occasional contributors fixing problems that bother them in various 'core' components rather than tests and documentation. > Here is a proposal to keep the advantage for most occasional contributors, > while at the same time reducing legal risk for the important parts of > glibc. > > 1) Define a "core" of glibc to be the set of files which you would not > want to see as the subject of "this file contains a copyright violation, > you must remove it" claim by some company, university, or ill-behaving > individual. > > 2) Allow DCO contributions only to non-core files of glibc. > > This means, occasional contributors would be able to contribute with DCO > to things like unit tests, iconv conversion modules, assembly-language > implementations for functions, the nscd daemon, and such. > But would be required to exchange papers for legally significant [3] > contributions to "core" areas (that IMO would include the dynamic loader, > the thread library, and the regex engine). > > Such a policy would provide a balance between > - motivating contributors during their first contributions, and > - avoiding legal risk. All of this assumes that a copyright assignment is somehow superior to DCO when it comes to legal defense and that the latter is just a compromise. I am not convinced that it is. Siddhesh