Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc (ABI comparison) and various other fixes #287

Closed
wants to merge 8 commits into from
Closed

doc (ABI comparison) and various other fixes #287

Changes from 1 commit
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
1754b39
doc: qbarray.h: fix garbled Doxygen markup
jnpkrn Jan 4, 2018
d300b7f
build: follow-up for and fine-tuning of a rushed 6d62b64 commit
jnpkrn Jan 4, 2018
1e7c85a
build: prune superfluous Makefile declarations within tests directory
jnpkrn Jan 4, 2018
e0bc8b1
maint: check abi: fix two issues with abi-compliance-checker/libstdc++
jnpkrn Jan 9, 2018
1646253
maint: check abi: switch to abi-dumper for creating "ABI dumps"
jnpkrn Jan 10, 2018
3107df1
Low: qblist.h: fix incompatibility with C++ & check it regularly
jnpkrn Jan 4, 2018
7634529
tests: check_list.c: start zeroing in on the gaps in tests' coverage
jnpkrn Jan 4, 2018
fb45f66
tests: print_ver: make preprocessor emit "note" rather than warning
jnpkrn Jan 21, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions tests/print_ver.c
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
/*
* Copyright (c) 2016 Red Hat, Inc.
* Copyright 2018 Red Hat, Inc.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A digression about copyrights:

The goal of a copyright notice is to show priority, not currency, so the initial year of creation should always be listed. If there is ever a dispute over who created the work, it establishes a claim for when it was created (earliest wins). It can also imply the date the work enters the public domain (which varies by country, but is a certain amount of time after the work's creation or the author's lifetime).

There is no universal form for how copyright notices on frequently-updated works should be written, but my personal preference is a year range, e.g. "Copyright 2016-2018 ...".

The "(c)" is indeed irrelevant from the perspective of copyright law and can be dropped.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the age of git, I suppose solely newest date makes the most sense,
it provides a basic estimate and if anyone needs exact legal dispute,
git provides exact data easily.

Copy link
Contributor Author

@jnpkrn jnpkrn Jan 22, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I should have said "worst case estimate", which makes whole a lot of sense,
at least to me.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the age of git, I suppose solely newest date makes the most sense,
it provides a basic estimate and if anyone needs exact legal dispute,
git provides exact data easily.

Certainly, the git history provides a good claim to priority, but the copyright notice here is not valid.

See the U.S. Copyright Office's "Compendium of U.S. Copyright Office Practices" [ https://www.copyright.gov/comp3/ ], particularly "Chapter 2200: Notice of Copyright", sections 2205.1(A) and 2205.1(F), or for a much more readable summary:

https://techwhirl.com/updating-copyright-notices/

The original date of publication must be in the notice for it to be valid. Giving a year range indicates that portions of the work were added in different years, though it cannot say which portions are which -- that is where the git history comes in handy.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See the footer on redhat.com main page, then (sigh)

Copy link
Contributor Author

@jnpkrn jnpkrn Jan 23, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking deeper in your linked article:

What happens when the manual is revised? Interestingly, the
Copyright Act doesn’t directly say. But the commonly accepted
practice is to include multiple years in the copyright notice,
indicating the various years in which various material in the
overall work was first published.

It may make sense for the material without rigorously tracked
history, but again, it's not the case with VCS-tracked project
(unless it's history got unclear on the initial import, which
is, again, not the case with libqb).

Furthermore, per
https://www.copyright.gov/help/faq/faq-definitions.html#notice:

While use of a copyright notice was once required as a condition
of copyright protection, it is now optional.

So I see no contradiction when using mere single date (newest), making
it an estimate (version control will always have the last say) when
the given file at the current form goes out of copyright protection
(country-dependent as mentioned) and putting negligible (because of
VCS) onus on figuring out the exact data about its parts to anyone
wanting to use them beyond copyright-granted protection packed with
LGPL-granted provisions (that should be enough in most cases anyway).
Fair deal, isn't it?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Purely as a matter of style I prefer the date "from-to" format as it gives some idea how long the file has been there without having to dig into the VCS history. Also, when things have been moved from one repo to another the dates can get unreliable. I'm not saying that's happened here, but if you keep the dates inside the file then you can be sure that it doesn't get lost ... unless someone removes it ;-)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The legal form of the copyright notice is intentionally ambiguous to allow variety, but one point it is always clear on is that the original date of publication must be listed. The initial part may be "Copyright", "Copr.", or the copyright symbol, and the year may be in just about any recognizable form (numerals, spelled out, Roman numerals, etc.), but it must specify the year of initial publication. The git history is good for determining which portions of the work were created in which years, but the copyright notice should list the original year, the original year plus later years of modification, or a range from the original year to the year of latest modification.

*
* All rights reserved.
*
Expand Down Expand Up @@ -38,5 +38,5 @@ main(void)
semicolon intentionally omitted so as to avoid unnecessary message
source diagnostics (bug or feature?) with some GCC versions (5.3.1) */
#define MSG QB_PP_STRINGIFY( \
GCC warning QB_PP_STRINGIFY(VERSION parsed as: QB_VER_STR))
_Pragma(MSG)
message (QB_PP_STRINGIFY(VERSION parsed as: QB_VER_STR)))
_Pragma(MSG);