From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 375B11F5AE for ; Mon, 14 Jun 2021 22:47:26 +0000 (UTC) Received: from localhost ([::1]:38002 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lsvMb-0006oF-1s for normalperson@yhbt.net; Mon, 14 Jun 2021 18:47:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45628) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lsvMP-0006iR-2R for bug-gnulib@gnu.org; Mon, 14 Jun 2021 18:47:13 -0400 Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.221]:23338) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lsvMM-0003en-CV for bug-gnulib@gnu.org; Mon, 14 Jun 2021 18:47:12 -0400 ARC-Seal: i=1; a=rsa-sha256; t=1623710816; cv=none; d=strato.com; s=strato-dkim-0002; b=eFXhhMQHyfXXHaOpvVWszsicKiFYPjirESGvxnoE0ThIXtHlRNWaSezmTsr0En60y4 uLf8y19XJpLf9MwCT4p26bEW11O9lScTOYgzcx8xVlhRodwkH77qfEPv21FX+rJYvDay y0O3y3EnCchhQ71evKplsPgSov60T3h9azEw0jocge1VvlbvDeJc+fY8n9eSN8XAYHX9 nGCo7KsWLVnZPavJSehW2wkbAICYNQQxkxfB0/rgj0ppDdfx+qLwfMRcowu6qdEMNAkl 7WHgz94k8KJV+KFSmUZr12HQdX4nGuZR21BfzabLeEjUaRxlUtqVtl9c3g/JinwLKjvL Z16Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1623710816; s=strato-dkim-0002; d=strato.com; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=GaD1sycH4doRVcyJA5swQgK0AtQD1iyOg7A0Ibx9vEQ=; b=fdWQUUVmFt4DydNOB5/kPdsjqI6UtmhoA/1pbKyXTSGzf45s9HT5i+XopBdTNhhRLj fyYUZGno5aGo3ZWmeGleNyEyF12su9NM78p8H8tFGDx71JSYqiyfXIbu8rhUXM5ubmVN TygRTfeh3VLWpzCFjjOOu8TzdO0EiZ8D2XrmJQAHTTSinVaTjQaFMx8Pws0fETF4L5QS +s1zQwtpJa/r29Gpi8iiMj+NGGnM5fARHsUchz5urdLD1V/8nFT/xT9qR11Na/zYZFao DeZHPYmZJsEzSN7z7/Luj2j5t1IR9+89gpSjNfFTeMdq4fcz35hAJ+fjpgu6Z3t7k5x+ Ikwg== ARC-Authentication-Results: i=1; strato.com; dkim=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1623710816; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=GaD1sycH4doRVcyJA5swQgK0AtQD1iyOg7A0Ibx9vEQ=; b=brlV48SBs54NU1G9dm7rm5uqZSBSHfWbBHxeqJJCtMjP9SKBAzFD8qrx/0bt5hGAmf NrB7jmV8ookSKDgS9G3mxfm7tmq6mk9K4rvq9z4PolLbAgUJTr0Y93Yk8MP/i9jp1kG7 ApLHiz3r/lCrkGWB6Rok1FOT+PyjLjnU/Ytx3EQ2yYLyz738SoGybc0Pvb/8WPKSntZu 7efCR8RVGhVRhx8R8lfKjCFwLsbJlkQjcugIr6XQyFOWnvY4HtZ74iJHqhXmRmrAH0cP W7uuCDvemH2PzhzPvAe7t0mJUa1qDyXe2N/3DdZIrwdyW8Rq991yon0XCd2PcEi19JmN FBjA== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH+AHjwLuWOHqf3z5NW" X-RZG-CLASS-ID: mo00 Received: from bruno.haible.de by smtp.strato.de (RZmta 47.27.2 DYNA|AUTH) with ESMTPSA id q0869dx5EMktzNJ (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); Tue, 15 Jun 2021 00:46:55 +0200 (CEST) From: Bruno Haible To: bug-gnulib@gnu.org Subject: Re: Seeking input from developers: glibc copyright assignment policy. Date: Tue, 15 Jun 2021 00:46:54 +0200 Message-ID: <2203305.C5PEDERQmq@omega> User-Agent: KMail/5.1.3 (Linux/4.4.0-210-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <9b5fff12-c16f-799f-6178-000b2e667d24@cs.ucla.edu> References: <9b5fff12-c16f-799f-6178-000b2e667d24@cs.ucla.edu> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Received-SPF: none client-ip=81.169.146.221; envelope-from=bruno@clisp.org; helo=mo4-p00-ob.smtp.rzone.de X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.489, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Paul Eggert Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" Hi Paul, > A proposal to change the glibc copyright assignment policy is being > circulated on libc-alpha. The email thread starts at > , and > the text of the email seeking input is at the end of this message. > > I'm sending this to bug-gnulib because we copy some files directly from > glibc and eventually I expect these files to be affected. The simplest > approach I see for Gnulib is to adopt glibc's policy, at least for files > or code copied from glibc. The obvious benefit of GCC's and glibc's new contributions policy is that it will allow more contributions in the same time, and thus "boost" the projects. The drawbacks are not so easy to see, but they are important as well: * How to respond to contributors who withdraw their contribution, long after it was integrated? This happened to Linux libc5 at some point; H.J. Lu had to back out the contribution. If this happened today, in GCC or glibc, Red Hat would probably be able to spend lawyer investment or developer investment, to fix the damage. But Gnulib is more of a GNU project than a Red Hat project; I'm not sure Red Hat would protect Gnulib in case such a situation arises. * [1] brings up the argument of university students in the US, who have problem doing the copyright work with the FSF. If the new policy has the effect that such people now contribute _without_ the consent of their university, we have contributions that can be attacked in court. * How to respond to copyright violations? It is generally simpler to approach or sue the violator when there is only one copyright holder, see [2]. Even signalling a copyright violation to a company is simpler when there is only one copyright holder [3]. How is license enforcement going in practice when there are multiple copyright holders? And when one of them is already deceased? I think for this topic we should get input from the FSF, the Software Freedom Conservancy, and/or gpl-violations.org. * How to manage an upgrade to a license that is better suited in the future? Copyright laws change over the years, societies change, and packages that can adapt their license to changed realities are at an advantage. * Free Software has grown in economic importance over the last 10 years. Most software products now include a significant proportion of free software. Threats are therefore bigger than they were 10 years ago. In this situation, it appears to me that formal contracts provide a better legal basis than Signed-off-by messages. I don't think IBM would have won the legal battle against SCO [4] if there had not been formal contracts. In Gnulib, we (me included) haven't been very strict on this topic [5]. But switching to a different policy is a bigger change than just being lazy on a few files. That was my opinion. What is the Chief GNUisance's opinion? Bruno [1] https://sourceware.org/pipermail/libc-alpha/2021-June/127586.html [2] https://www.gnu.org/licenses/why-assign.en.html [3] https://www.oracle.com/de/legal/copyright.html [4] https://en.wikipedia.org/wiki/SCO%E2%80%93Linux_disputes [5] https://lists.gnu.org/archive/html/bug-gnulib/2021-05/msg00072.html