From: Jonathan Wakely <jwakely@redhat.com>
To: "Koning, Paul" <Paul.Koning@dell.com>
Cc: "libstdc++" <libstdc++@gcc.gnu.org>,
GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] libstdc++: Update documentation about copyright and GPL notices in tests
Date: Fri, 6 May 2022 14:44:43 +0100 [thread overview]
Message-ID: <CACb0b4mLqLttgJ_AsemJ3fMbNEbnRLUGwUEHkDL1e6r6E3HESQ@mail.gmail.com> (raw)
In-Reply-To: <CACb0b4nOdDB5rgWSGEBgd4KTjd9LjmUFC7gJ3+wAvkt2gdtk1Q@mail.gmail.com>
I've pushed this to trunk now.
On Thu, 28 Apr 2022 at 18:02, Jonathan Wakely <jwakely@redhat.com> wrote:
>
> On Thu, 28 Apr 2022 at 17:45, Koning, Paul via Libstdc++
> <libstdc++@gcc.gnu.org> wrote:
> >
> >
> >
> > > On Apr 28, 2022, at 8:37 AM, Jonathan Wakely via Gcc-patches <gcc-patches@gcc.gnu.org> 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).
prev parent reply other threads:[~2022-05-06 13:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-28 12:37 Jonathan Wakely
2022-04-28 16:44 ` Koning, Paul
2022-04-28 17:02 ` Jonathan Wakely
2022-05-06 13:44 ` Jonathan Wakely [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACb0b4mLqLttgJ_AsemJ3fMbNEbnRLUGwUEHkDL1e6r6E3HESQ@mail.gmail.com \
--to=jwakely@redhat.com \
--cc=Paul.Koning@dell.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=libstdc++@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).