From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.219]) by sourceware.org (Postfix) with ESMTPS id 4A07C3844019 for ; Wed, 23 Jun 2021 01:04:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4A07C3844019 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=clisp.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=clisp.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1624410247; s=strato-dkim-0002; d=clisp.org; h=Message-ID:Date:Subject:To:From:Cc:Date:From:Subject:Sender; bh=SPHtvt4i40oc9YoRgzzDPKpuKT/tf4Dz4p88MdrqL28=; b=F9q/voX1oJGHEryIfKnkpJ7R1h8oovM8BX3o8W/hupmAgFx8B73Q30etYqIBIV3kMM 1O2h+W5ggcKx/yAxqq2cflPi6+N0x5FHeJgFwznx6rzwOUp/CgRXKBAk3eA+FTccV1Zh xGFBjJR9oQFCk2XwqJquEd1RHAhh6vKAERqyG2Dpqc418Ma772ZEDd1kr3RzaauBhkb8 XL/E/frJ+fXU3hfQ5IiBKcqxhoAvzRtFeEteGBWBgDlaYfdxQA98qfSHlqyk5MqSoafM AG+2UIV3Urc/Rn3jKAnEeXRzZ4AbFQKACvXGgiUu/5g0oKxAnIT6lIX+nFqxR7cQb6VG gYlw== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH+AHjwLuWOGKf9yfs=" X-RZG-CLASS-ID: mo00 Received: from bruno.haible.de by smtp.strato.de (RZmta 47.27.3 DYNA|AUTH) with ESMTPSA id 401b97x5N146N2R (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve X9_62_prime256v1 with 256 ECDH bits, eq. 3072 bits RSA)) (Client did not present a certificate); Wed, 23 Jun 2021 03:04:06 +0200 (CEST) From: Bruno Haible To: libc-alpha@sourceware.org Subject: Re: Seeking input from developers: glibc copyright assignment policy. Date: Wed, 23 Jun 2021 03:04:06 +0200 Message-ID: <4369849.fY2oj7UdlA@omega> User-Agent: KMail/5.1.3 (Linux/4.4.0-210-generic; KDE/5.18.0; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FAKE_REPLY_A1, KAM_SHORT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_NONE, 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 01:04:11 -0000 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. Occasional contributors will typically not start their journey with contributions to the dynamic loader, the thread library, or the regex engine. 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. Bruno [1] https://lists.gnu.org/archive/html/bug-gnulib/2021-06/msg00080.html [2] https://sourceware.org/pipermail/libc-alpha/2021-June/127616.html [3] https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html