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: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id C80631F8C6 for ; Thu, 29 Jul 2021 14:22:05 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9896E39B2847 for ; Thu, 29 Jul 2021 14:22:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9896E39B2847 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1627568524; bh=dFUWadD7e2TpeVu/BL/qt8Rtwfgus13qETdktcmVK6I=; h=To:Subject:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=NVTwYS1x163lZVO47tZC6mcRjYNrfCfFelD6MYFrrmeGg9zP5uMH7ueqa+BF3r9Nw 3sezy1nZTRqOImuzi8hgvHnRx+v/S/FEdf8pwDfbmT1LCODxC5PGEpYzQc2otloLRR Zz7FTfaIqL4LlHOACkoF2qOANwROQdB/y4NKy9E4= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 651F43889C18 for ; Thu, 29 Jul 2021 14:21:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 651F43889C18 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-335-vVv2KzBeOYqycAWVGUG32Q-1; Thu, 29 Jul 2021 10:21:43 -0400 X-MC-Unique: vVv2KzBeOYqycAWVGUG32Q-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6534D80196C; Thu, 29 Jul 2021 14:21:42 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-112-7.ams2.redhat.com [10.36.112.7]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 78D831B49E; Thu, 29 Jul 2021 14:21:36 +0000 (UTC) To: Carlos O'Donell via Libc-alpha Subject: Re: Update to glibc copyright assignment policy References: <24208780-9ae8-3af2-3da9-8f57ef12e68a@redhat.com> Date: Thu, 29 Jul 2021 16:21:35 +0200 In-Reply-To: (Carlos O'Donell via Libc-alpha's message of "Thu, 29 Jul 2021 09:58:28 -0400") Message-ID: <874kcd2ob4.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: , From: Florian Weimer via Libc-alpha Reply-To: Florian Weimer Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" * Carlos O'Donell via Libc-alpha: > On 7/29/21 6:25 AM, Siddhesh Poyarekar wrote: >> On 7/29/21 1:20 AM, Carlos O'Donell via Libc-alpha wrote: >>> branches. Code shared with other GNU packages via Gnulib will >>> continue to require assignment to the FSF. >>=20 >> Does that mean we cannot touch the code shared with gnulib if we do >> not assign copyright to the FSF? Or does it mean that if/when that >> happens, we will stop syncing those bits with gnulib? > > The code shared with gnulib carries with it an existing obligation > to the gnulib community that we maintain the existing copyright > protocol for those files to honour that obligation. > > My suggestion is that we as a community in glibc need to decide, > on a file-by-file basis what we are going to do. I'm open to other > alternatives too, the following 2 steps are just my suggestion. I'm worried that this obligation means that we cannot use glibc-specific facilities in code shared with gnulib. For example, look at how the scratch buffer mechanism landed in gnulib. If we had DCO contributions for that mechanism, that wouldn't be possible=E2=80=94and that facility sta= rted out with the firm idea that it would never end up in gnulib. Thanks, Florian