From: Alejandro Colomar <alx@kernel.org>
To: Carlos O'Donell <carlos@redhat.com>
Cc: "Andries E. Brouwer" <aeb@cwi.nl>,
linux-man@vger.kernel.org, linux-kernel@vger.kernel.org,
libc-alpha@sourceware.org
Subject: Re: man-pages-6.14 released
Date: Sun, 8 Feb 2026 23:04:10 +0100 [thread overview]
Message-ID: <aYkHSQthFKL9TBxV@devuan> (raw)
In-Reply-To: <u2ogua4573d2xm2p2oiuna67kydkr3e26pt6lixeidezdw34dg@nvn64na3cptt>
[-- Attachment #1: Type: text/plain, Size: 3710 bytes --]
Hi Carlos,
On 2025-06-27T01:14:47+0200, Alejandro Colomar wrote:
> Hi Carlos,
>
> On Thu, Jun 26, 2025 at 07:01:24PM -0400, Carlos O'Donell wrote:
> > > Well, we got express permission for a third of the copyright holders in
> > > the last few months. Also, we got no express notices in the contrary,
> > > so around two thirds have remained silent.
> >
> > You should track down the copyright holders and get written approval,
> > or restore the copyright notices.
> >
> > This is exactly the difficulty in maintaining such written notices.
> >
> > And why they are no longer recommended.
> >
> > > We could restore those that haven't expressely granted permission...
> >
> > Yes please.
> >
> > May I suggest doing a new release with the copyrights restored?
> >
> > > The thing is, as someone else mentioned, removals happen also implicitly
> > > by moving text from one page to another and not copying copyright
> > > notices, so how much does it matter an intentional rewrite of the
> > > copyright notices into a different form (but which keeps their
> > > copyright, as part of the AUTHORS file), compared to an unintentional
> > > removal of copyright by moving the text (these do actually remove
> > > copyright, so these are the problematic ones).
> >
> > Both are legally mistakes.
> >
> > The common utterance is "As compliance approaches 100% cost approaches
> > infinity" :-)
> >
> > However, you should not deny anyone the right to have their copyright
> > directly noted in the file, but you can encourage the generic use of
> > "Copyright the Foo Authors." You can deny the contribution entirely if
> > you wish on grounds that maintaining copyright statements is too much
> > work.
>
> Sure, if anyone explicitly wants to retain a copyright notice, I'll do
> so (if it was old), or refuse to accept the patch (if it is new).
>
> > > By rewriting the copyright notices, we'd actually be honoring the
> > > copyright, even when text is moved from page to page. I think that is
> > > more important. And since all explicit notices have granted us
> > > permission, even if some have remained silent (in some cases, their
> > > email probably isn't monitored anymore), I think we should go forward.
> >
> > I agree, but you need permission from the authors.
> >
> > I disagree that man-pages should go forward with the current changes.
> >
> > May you please restore the copyright notices and cut a new release?
>
> Hmmm, it'll take some time. I need to stop and compare the both lists,
> which are rather long. I don't promise it will happen soon, but I'll
> keep it in a TODO list. I'll also try to do it at least after
> September, when I'll be meeting Michael in person, where I'll ask him
> about his copyright notices (which represent a huge percentage of the
> copyright notice lines). That will reduce the work significantly.
> So, it might happen around the end of this year.
I have finished working on this. I've restored old copyright notices
from contributors (individuals and otherwise) who have not expressed
content with the unified notices.
I've pushed to a branch for now:
<https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/log/?h=license>
I'll work on the new release for the next few days, and will include
that commit in the release.
Have a lovely night!
Alex
>
> Once I start doing that, I'll do another round of asking the remaining
> people about their copyright notices. Hopefully, there'l l be few of
> them.
>
>
> Have a lovely day!
> Alex
>
> --
> <https://www.alejandro-colomar.es/>
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-02-08 22:04 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-08 23:15 man-pages-6.14 released Alejandro Colomar
2025-05-09 11:26 ` Andries E. Brouwer
2025-05-09 12:02 ` Alejandro Colomar
2025-05-09 12:14 ` Andries E. Brouwer
2025-05-09 12:28 ` Alejandro Colomar
2025-05-09 12:48 ` Vincent Lefevre
2025-05-09 12:57 ` Alejandro Colomar
2025-05-09 13:11 ` Vincent Lefevre
2025-06-26 20:41 ` Carlos O'Donell
2025-06-26 21:04 ` Alejandro Colomar
2025-06-26 23:01 ` Carlos O'Donell
2025-06-26 23:14 ` Alejandro Colomar
2025-06-27 0:08 ` Andries E. Brouwer
2025-06-27 0:45 ` Alejandro Colomar
2026-02-08 22:04 ` Alejandro Colomar [this message]
2025-06-27 0:20 ` Vincent Lefevre
2025-06-27 4:23 ` Alejandro Colomar
2025-06-27 7:49 ` Vincent Lefevre
2025-06-27 13:09 ` Alejandro Colomar
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=aYkHSQthFKL9TBxV@devuan \
--to=alx@kernel.org \
--cc=aeb@cwi.nl \
--cc=carlos@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.