From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 177CD3851C29 for ; Tue, 15 Jun 2021 20:09:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 177CD3851C29 Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-154-njx6IT8BN6WzHR9R_xS-rA-1; Tue, 15 Jun 2021 16:09:01 -0400 X-MC-Unique: njx6IT8BN6WzHR9R_xS-rA-1 Received: by mail-qt1-f197.google.com with SMTP id z17-20020ac86b910000b0290244cba55754so10110060qts.19 for ; Tue, 15 Jun 2021 13:09:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=qfZw8HLdiUSr8hLmRp1DxiIWbwaVzMlqyBr26FcirYE=; b=dPJY8BMse0bXROT/dI2/JB85IUE9JWzVNKl7FsC6YGLxbIWYJx2eEo0xRI4195qq4M REHvn/t0kqGnrxdsjeodUxSVJiNXM+N4+GmywFpvPZpRTIWT0i9L632GsYR5y7N8rsxL Fq8TdUvonBxXTiHUbSGcpNnWMO9zM9MzUtlmwUcYhywQJ416QqdnazrysPxq/rssq5bh k5ljF9cfmiFgIIbrLJXcdFUCKa46f/oH9nFsW7aV92MXCQqEqnY9TL6CrK1tHHbdVaj4 XzqpgjVb1sd+zMjE2hWfMmtLgttSc2XnGEl035HAQ/2fVhvWPGZzQ3d5ZTG17Ud3CQpr XK1Q== X-Gm-Message-State: AOAM5315F2zEm7NWDMWTwrjFCV7yMpRFKoU0hKgotR0e3WPzIsPBtUDi MrVhL6u3OOLnx1ZfJRXlpVE/SqG6OhlYtScJk5PRfqJarlQDU3Ti8iTU2oYSLL1jCWqnof7dXj3 pQpmGGQ3NfQfHBFHbNJZRhb0wCERNnbuFbHXKRIL1d6xanopY9rlYI6Pr/BUYzcS3LhE5Wg== X-Received: by 2002:a05:622a:8e:: with SMTP id o14mr1410123qtw.102.1623787741114; Tue, 15 Jun 2021 13:09:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzEya8amge5LS7nK+VU5jfk6EZ1oqrrfAQwinlGjc17ue3htYsY0lH0DIAuGYCzK5ToUbu5YA== X-Received: by 2002:a05:622a:8e:: with SMTP id o14mr1410091qtw.102.1623787740712; Tue, 15 Jun 2021 13:09:00 -0700 (PDT) Received: from [192.168.1.16] (198-84-214-74.cpe.teksavvy.com. [198.84.214.74]) by smtp.gmail.com with ESMTPSA id x7sm78903qke.62.2021.06.15.13.08.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Jun 2021 13:09:00 -0700 (PDT) Subject: Re: Seeking input from developers: glibc copyright assignment policy. To: Paul Eggert , DJ Delorie Cc: libc-alpha@sourceware.org References: <1b2ac4c8-0bbf-b7a7-8b05-03d5a71d46f4@cs.ucla.edu> From: Carlos O'Donell Organization: Red Hat Message-ID: Date: Tue, 15 Jun 2021 16:08:59 -0400 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: <1b2ac4c8-0bbf-b7a7-8b05-03d5a71d46f4@cs.ucla.edu> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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: Tue, 15 Jun 2021 20:09:04 -0000 On 6/15/21 3:35 PM, Paul Eggert wrote: > On 6/15/21 12:12 PM, DJ Delorie wrote: >> A future glibc could distribute under the terms of LGPL4+, but a >> future glibc could NOT change the license to "LGPL4+". > > So, are you saying that in string/strcpy.c we could not change the > "2.1" to 3 in the following comment: This changes the license of the code. > The GNU C Library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public License as > published by the Free Software Foundation; either version 2.1 of the > License, or (at your option) any later version. > > and redistribute the result, assuming strcpy.c has some DCO'ed code? > We've routinely been doing such replacements for years in other Gnu > code. Gnulib even automates the practice. You should contact legal counsel to determine if you have the right to relicense that code. > If true, it's a significant argument against going with DCO'ed code. Why is it a significant argument against DCO? Yes, does make it more difficult to relicense the project (it is not impossible), other than to a later version of the GPL. We are a mature collection of projects and our users and developers depend on the project to retain the existing license for long term planning. Users and developers contribute to our projects because of our values and principles and those are tied to the license that we are using. Telling our users and developers that we will never change the license has value. > Certainly we couldn't accept DCO'ed material in any Glibc code shared > with Gnulib, as Gnulib code is shared among many GNU projects that > don't do DCO and do such rewriting. And even if we ignore Gnulib, > this could be a real problem if copyright law were to change in a way > that adversely affects free-software principles, so that we'd really > need an LGPL 4. Can you quantify this risk of not being able to move to LGPLv4? Can you quantify the risk of using DCO? What license would we change to? Does the LGPLv4 exist today? What do our users expect? The problem is that risk quantification is difficult and neither side has a clear advantage against all costs and benefits. The clearest advantage to DCO is the future growth and vibrancy of the GNU Toolchain. The GNU Toolchain deserves the brightest future we can provide. In practice glibc contains a fair bit of code unassigned to the FSF for which the license cannot be easily changed without legal discussions (Intel, IBM, Sun Microsystems, SGI, Oracle, Carnegie Mellon University, DEC, ISC, University of California, University of Cambridge, ORNL, Unicode Consortium, and various authors). And some companies no longer exist. There are approximately 704 files that have copyright owners other than the FSF, and if the FSF does have copyright ownership by other contractual means then that isn't clear and subject to complex legal discussions for relicensing. The reality of the GNU Toolchain copyright ownership is different from expectation. The DCO is in keeping with the reality of the GNU Toolchain and opens up opportunities for further contributions. > Have the Red Hat lawyers looked into this issue specifically? This is a known issue with DCO. If there is a specific question you have then we can start a thread to discuss the issue. -- Cheers, Carlos.