libstdc++: Update documentation about copyright and GPL notices in tests
Commit Message
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.
libstdc++-v3/ChangeLog:
* doc/xml/manual/test.xml: Remove requirement for copyright and
GPL notice in tests.
* doc/html/manual/test.html: Regenerate.
---
libstdc++-v3/doc/html/manual/test.html | 8 ++++++--
libstdc++-v3/doc/xml/manual/test.xml | 8 ++++++--
2 files changed, 12 insertions(+), 4 deletions(-)
Comments
> 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? 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.
paul
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).
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).
@@ -371,8 +371,12 @@ cat 27_io/objects/char/3_xin.in | a.out</pre></dd><dt><span class="term"><code c
directory and file name, given the organization as previously
described.
</p><p>
- All files are copyright the FSF, and GPL'd: this is very
- important. The first copyright year should correspond to the date
+ Historically all test files were copyright the FSF, and GPL licensed.
+ We no longer require that, because most tests are uninteresting
+ and contain no "original authorship", and so would not be protected
+ by copyright anyway.
+ If you do want to add the FSF copyright notice and GPL licence text,
+ then the first copyright year should correspond to the date
the file was checked in to version control. If a test is copied from
an existing file it should retain the copyright years from the
original file.
@@ -630,8 +630,12 @@ cat 27_io/objects/char/3_xin.in | a.out</programlisting>
</para>
<para>
- All files are copyright the FSF, and GPL'd: this is very
- important. The first copyright year should correspond to the date
+ Historically all test files were copyright the FSF, and GPL licensed.
+ We no longer require that, because most tests are uninteresting
+ and contain no "original authorship", and so would not be protected
+ by copyright anyway.
+ If you do want to add the FSF copyright notice and GPL licence text,
+ then the first copyright year should correspond to the date
the file was checked in to version control. If a test is copied from
an existing file it should retain the copyright years from the
original file.