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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 19F953847818 for ; Fri, 3 Sep 2021 20:56:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 19F953847818 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-439-SDs4rLJ5P8KlsoCgOZP58A-1; Fri, 03 Sep 2021 16:55:58 -0400 X-MC-Unique: SDs4rLJ5P8KlsoCgOZP58A-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0738E80198A for ; Fri, 3 Sep 2021 20:55:58 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.194.140]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5DF5B5D9FC for ; Fri, 3 Sep 2021 20:55:57 +0000 (UTC) From: Florian Weimer To: libc-alpha@sourceware.org Subject: Re: Copyright header for localedata files contributed under DCO References: <87pmtq54hs.fsf@oldenburg.str.redhat.com> Date: Fri, 03 Sep 2021 22:55:55 +0200 In-Reply-To: (Mike Frysinger's message of "Fri, 3 Sep 2021 21:06:10 -0400") Message-ID: <87czpp4bvo.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.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Fri, 03 Sep 2021 20:56:04 -0000 * Mike Frysinger: > On 03 Sep 2021 12:37, Florian Weimer via Libc-alpha wrote: >> The localedata files currently contain this: >> >> % This file is part of the GNU C Library and contains locale data. >> % The Free Software Foundation does not claim any copyright interest >> % in the locale data contained in this file. The foregoing does not >> % affect the license of the GNU C Library as a whole. It does not >> % exempt you from the conditions of the license if your use would >> % otherwise be governed by that license. >> >> I think the wording is less than satisfying because it's unclear whether >> the patch submitter (or someone else) retains any copyright claims to >> the file. With localedata patches submitted under the DCO, this becomes >> even more confusing. >> >> Therefore, I proposed to >> >> comment_char % >> escape_char / >> >> % Copyright The GNU Toolchain Authors. >> % This file is part of the GNU C Library. >> % >> % 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. >> % >> % The GNU C Library is distributed in the hope that it will be useful, >> % but WITHOUT ANY WARRANTY; without even the implied warranty of >> % MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU >> % Lesser General Public License for more details. >> % >> % You should have received a copy of the GNU Lesser General Public >> % License along with the GNU C Library; if not, see >> % . >> >> >> The main reason is to keep the contribution process simple. For >> example, we do not need to argue with the submitter whether they >> actually can disclaim copyright or database protection rights. >> >> Since the FSF disclaims copyright, we can also apply this header to >> mixed FSF/DCO files once the need arises. > > imo this is going in the wrong direction > > if we want to enforce it, we can add a test to check the header of the file. > if a contributor doesn't agree, then we don't accept their patch. i don't > see why we need to bend over backwards for this. Do you mean we should accept patches without FSF copyright assignment that carry the FSF disclaimer? The problem is that the FSF disclaimer does not mean anything (and is therefore very misleading) if the patch has nothing to do with the FSF. Thanks, Florian