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 ESMTPS id BFDBA3857428 for ; Thu, 28 Apr 2022 17:02:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BFDBA3857428 Received: from mail-yw1-f197.google.com (mail-yw1-f197.google.com [209.85.128.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-78-TLBdpDbTPue384eHy3B-Og-1; Thu, 28 Apr 2022 13:02:29 -0400 X-MC-Unique: TLBdpDbTPue384eHy3B-Og-1 Received: by mail-yw1-f197.google.com with SMTP id 00721157ae682-2f7d4addafdso51489757b3.6 for ; Thu, 28 Apr 2022 10:02:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dxfcn2WWaT84WfCKoCYS9Jmt83Xhq+aUC7cbPcpNkQE=; b=jXRWI60x9tLW0iWouVCP88OddHHFU4GbdF9mdPR3ay47mz/c4+/7WIX9nyGvzCcYEI GGV9ATYydlt3a1PIv8MML/pcToV+aafhsrR7TrjlEvxlDDozGwfcFaIDpzpL8PAK3nGb zoN+OfNpxpkAV8g67iYXlttQWgcZ3LoohI5UP9JTYPIU/oxIEQEIIJy6ErupEGTzpOgp sDbGf9wnScpUHvkRwuUzJI10Z5FNIFO0P4xcrnbHXU0OC3G7Ooo/DhRZ02VBqnEO1LR7 3mgQx5XwVUb8F1pjYrr6yHXeZRKoqhJS3kYPVJBWnP6BHwDc91iXjThurD9SEM/6fuRK bwwA== X-Gm-Message-State: AOAM532/VliW/C3jtqstnD3cbG+wzEkndKG9DAMsJGxSs/VV2iMHjMrk H6/l8yCu9lpglh3xuoPBiShcxpO/ukkMHxoXbCBrZaaBvKdRxXZvql/jImDfuLg/gfkVo43K/I1 qZQTKFsHavV+x+61sOPEpciMrWxDsqyU= X-Received: by 2002:a25:858a:0:b0:648:dfcd:ac60 with SMTP id x10-20020a25858a000000b00648dfcdac60mr7601428ybk.320.1651165348274; Thu, 28 Apr 2022 10:02:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxk7z0uAeHEYCxYdZZn0nS2qzfSq6BWkdUlqehOAtR0uESo9yVbFCObv7lse1sFLMgXf12wIB5aNeMaOtKys2M= X-Received: by 2002:a25:858a:0:b0:648:dfcd:ac60 with SMTP id x10-20020a25858a000000b00648dfcdac60mr7601375ybk.320.1651165347794; Thu, 28 Apr 2022 10:02:27 -0700 (PDT) MIME-Version: 1.0 References: <20220428123725.2354675-1-jwakely@redhat.com> In-Reply-To: From: Jonathan Wakely Date: Thu, 28 Apr 2022 18:02:16 +0100 Message-ID: Subject: Re: [PATCH] libstdc++: Update documentation about copyright and GPL notices in tests To: "Koning, Paul" Cc: "libstdc++" , GCC Patches X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-4.6 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, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=unavailable autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2022 17:02:31 -0000 On Thu, 28 Apr 2022 at 17:45, Koning, Paul via Libstdc++ wrote: > > > > > On Apr 28, 2022, at 8:37 AM, Jonathan Wakely via Gcc-patches wrote: > > > > I intend to commit this patch soon. This isn't changing the policy, just > > adjusting the docs to match the current policy. > > > > I'm open to suggestions for better ways to phrase the second sentence, > > clarifying that our tests generally have nothing novel or "authored". > > > > -- >8 -- > > > > There is no need to require FSF copyright for tests that are just > > "self-evident" ways to check the API and behaviour of the library. > > This is consistent with tests for the compiler, which do not have > > copyright and licence notices either. > > So is the theory that "self-evident" documents are in the public domain for that reason? Yes. Let's look at a test I added this week: libstdc++-v3/testsuite/30_threads/packaged_task/cons/deduction.cc It has a copyright notice because (as I said in the commit log) it was copied from an existing test that has one. But what part of that file constituted original authorship? That code does nothing useful, it doesn't even link. All it does is construct objects and verify that the compiler deduced the correct type, which verifies that the library has defined the deduction guides correctly. Let's look at another one: libstdc++-v3/testsuite/20_util/unique_ptr/comparison/constexpr.cc What part of this is copyrightable? Is it where I create some variables, or performs a series of repetitive and redundant comparisons on them, or both? This could almost be machine generated, and I assert that it's not meaningful or useful or sensible to consider it as a copyrighted work. So I didn't bother putting the notices on this one. > Or is the policy that for such file it is fine for the copyright to be held by the author (which is the default when no assignment is made)? And a similar question applies to the license aspect also. > > I think I understand the intent, and that seems to make sense, but I'm wondering if it has been verified by the appropriate FSF IP lawyers. If there's a concern, why haven't they raised it for the compiler's own testsuite? Why should libstdc++ tests have copyright notices or GPL notices when gcc tests don't? I count 83 *.[cChm] files under gcc/testsuite with a GPL notice, out of some 64 THOUSAND files. The number with FSF copyright notices is around 1100, e.g. gcc/testsuite/gcc.target/sparc/ultrasp2.c is copyright FSF, but that seems ludicrous (yes, I know it says it's simplified from another file which is copyright FSF, but so what ... a left shift operation is not copyrightable).