public inbox for libstdc++@gcc.gnu.org
 help / color / mirror / Atom feed
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).


      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).