All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx+linux-man@kernel.org>
To: Carlos O'Donell <carlos@redhat.com>
Cc: Alejandro Colomar <alx@kernel.org>,
	 Xavier Leroy <Xavier.Leroy@inria.fr>,
	linux-man <linux-man@vger.kernel.org>,
	 Michal Schorm <mschorm@redhat.com>
Subject: Re: Two copyright notices missing in 6.20?
Date: Tue, 3 Nov 2026 16:28:02 +0100	[thread overview]
Message-ID: <aun6mEuYKQG-1IKv@devuan> (raw)
In-Reply-To: <0b9233b7-3c3f-4209-9d01-a1c94aaa8439@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 5930 bytes --]

Hi Carlos,

> Date: 2026-11-03 09:55:31-0500
> From: Carlos O'Donell <carlos@redhat.com>
>
[...]
> > Did I miss any?
> 
> Yes, 3, but I will also note the remaining 4 topics that came from the audit.
> 
> (1) Copyright statements for Michael Kerrisk
> 
> sync.2:
> \" Copyright (c) 1992 Drew Eckhardt (drew@cs.colorado.edu), March 28, 1992
> .\" and Copyright (c) 2011 Michael Kerrisk <mtk.manpages@gmail.com>
> 
> select.2:
> .\" This manpage is copyright (C) 1992 Drew Eckhardt,
> .\"     copyright (C) 1995 Michael Shields,
> .\"     copyright (C) 2001 Paul Sheer,
> .\"     copyright (C) 2006, 2019 Michael Kerrisk <mtk.manpages@gmail.com>
> 
> epoll_ctl.2:
> .\"  Copyright (C) 2003  Davide Libenzi
> .\"  Davide Libenzi <davidel@xmailserver.org>
> .\" and Copyright 2009, 2014, 2016, 2018, 2019 Michael Kerrisk <tk.manpages@gmail.com>
> 
> May you please add these 3 back for Michael?

Sure; thanks!  Will do tonight.

> (2) Removal of Linux Foundation copyright statements
> 
> There were ~116 of Linux Foundation copyright notices present that were removed.

I'm waiting for them to approve it formally.  I expect they will.

> e.g.
> a1eaacb1a5 man7/signal.7     (Alejandro Colomar    2022-11-09 16:36:36 +0100    1) '\" t
> ^fea681daf man7/signal.7     (Michael Kerrisk      2004-11-03 13:51:07 +0000    2) .\" Copyright (c) 1993 by Thomas Koenig (ig25@rz.uni-karlsruhe.de)
> f527d6fe30 man7/signal.7     (Michael Kerrisk      2020-11-12 16:36:34 +0100    3) .\" and Copyright (c) 2002, 2006, 2020 by Michael Kerrisk <mtk.manpages@gmail.com>
> 743bc3957a man7/signal.7     (Michael Kerrisk      2008-07-04 14:36:28 +0000    4) .\" and Copyright (c) 2008 Linux Foundation, written by Michael Kerrisk
> 743bc3957a man7/signal.7     (Michael Kerrisk      2008-07-04 14:36:28 +0000    5) .\"     <mtk.manpages@gmail.com>
> 
> a1eaacb1a5 man7/signal.7     (Alejandro Colomar    2022-11-09 16:36:36 +0100    1) '\" t
> 73ec1f03be man/man7/signal.7 (Alejandro Colomar    2025-11-21 01:08:05 +0100    2) .\" Copyright 1993, Thomas Koenig <ig25@rz.uni-karlsruhe.de>
> 73ec1f03be man/man7/signal.7 (Alejandro Colomar    2025-11-21 01:08:05 +0100    3) .\" Copyright 2002-2020, Michael Kerrisk <mtk.manpages@gmail.com>
> f99f884ddb man/man7/signal.7 (Alejandro Colomar    2025-05-17 15:18:26 +0200    4) .\" Copyright, the authors of the Linux man-pages project
> ^fea681daf man7/signal.7     (Michael Kerrisk      2004-11-03 13:51:07 +0000    5) .\"
> 
> Did the project get permission from the foundation for the removal?

Not yet.

> (3) Collapsed years
> 
> Michael's copyright status collapsed from 2002, 2006, 20220 to 2002-2020.
> 
> Were additional contributions made in the intervening years?

I don't know.  I suspect there are, even though he probably didn't
consider them worthy of copyright.

> If there were no such contributions then the years should be kept distinct.

I think I disagree.  The copyright dates are only meaningful as a start
and an end.  One could also argue that 2005 means 2005-01..2005-12, but
there might have been contributions only in 2005-07.  Is it legally
meaningful to say 2002, 2004 in a way that 2002-07, 2002-09, 2004-05
isn't?  And is it legally meaningful to say 2002-2004 instead of any of
the above?

> 
> Only ranges like 2002, 2003, 2004, 2005 etc. should be collapsed into a contiguous range e.g. 2002-2005.
> 
> May you please correct the collapsed ranges?

I'd really like to avoid this.

> (4) SPDX identifiers
> 
> With Linus' clause restored, the SPDX identifier for setreuid.2 is not correct.
> 
> The original text read:
> .\" Portions extracted from linux/kernel/sys.c:
> .\"             Copyright (C) 1991, 1992  Linus Torvalds
> .\"             May be distributed under the GNU General Public License
> 
> Which makes this SPDX identifier incorrect:
> .\" SPDX-License-Identifier: BSD-4-Clause-UC
> 
> Should include GPL?

Indeed.

> Likewise bind.2.
> 
> Likewise connect.2.
> 
> Likewise iopl.2 implied GPL.
> 
> Likewise subpage_prot.2 implied GPL.
> 
> May you please update 5 pages with GPL notices?

Thanks!  I'll GPL these files tonight.

> 
> Likewise signbit.3, significand.3, and memcpy.3 are GFDL derivatives.
> - These should be rewritten from scratch or GFDL front-matter invariant requirements apply.

Ouch!  Indeed.

> 
> The man-pages project should not copy from the glibc manual
> due to the GFDL front-matter invariant requirements, and that
> GFDL cannot be combined with GPL.

Agree.  I'll try to rewrite them from scratch.

memcpy(3) will be easier, because I know the page very well (and I've
already rewritten most of it from scratch; I guess the only remnants are
in CAVEATS).  The others, I'll need to learn about them before
rewriting.  I'll use the BSD pages to learn about these APIs.

> (5) Uncertain provenance
> 
> Restore the des_crypt.3 uncertain provenance header:
> 
> .\" However, the above header line suggests that this file in fact is
> .\" Copyright Sun Microsystems, Inc (and is provided for unrestricted use,
> .\" see other Sun RPC sources).
> 
> Or conclusively resolve the provenance issue.
> 
> I'd leave the SPDX-header as-is because Eric's statement can be seen as authoritative
> over the uncertain provenance.
> 
> Likewise login.3 uncertain GFDL.
> 
> Likewise remove.3 which should include copyright notices from unlink.2 as a derived work.
> 
> May we please add back the uncertain text notes?

Okay.

> 
> Were any of these uncertain notices resolved?

Some of them might have been resolved due to the affected text being
removed.  It's probably not worth the effort, so I think it might be
easier to just restore them (even if maybe not relevant anymore).


Cheers,
Alex

> 
> -- 
> Cheers,
> Carlos.
> 
> 

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2026-11-03 15:28 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-02 16:24 Two copyright notices missing in 6.20? Carlos O'Donell
2026-11-02 23:13 ` Alejandro Colomar
2026-11-03  7:10   ` Michal Schorm
2026-11-03 11:57     ` Alejandro Colomar
2026-11-03 14:55   ` Carlos O'Donell
2026-11-03 15:28     ` Alejandro Colomar [this message]
2026-11-03 18:02       ` Carlos O'Donell
2026-11-03 18:52         ` GPL/GFDL incompatibility (was: Two copyright notices missing in 6.20?) G. Branden Robinson
2026-11-03 16:54     ` copyright year ranges and "collapse" " G. Branden Robinson
2026-11-03 17:55       ` copyright year ranges and "collapse" Carlos O'Donell
2026-11-03 18:39         ` G. Branden Robinson
2026-11-03 21:40           ` Carlos O'Donell

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=aun6mEuYKQG-1IKv@devuan \
    --to=alx+linux-man@kernel.org \
    --cc=Xavier.Leroy@inria.fr \
    --cc=alx@kernel.org \
    --cc=carlos@redhat.com \
    --cc=linux-man@vger.kernel.org \
    --cc=mschorm@redhat.com \
    /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.