Re: Two copyright notices missing in 6.20?

[Alejandro Colomar <alx+linux-man@kernel.org>]

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

Hi Carlos,

> Date: 2026-11-03 13:02:01-0500
> From: Carlos O'Donell <carlos@redhat.com>
>
[...]
> > > (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.
> 
> Thank you.
> 
> If you need any help there please just ask and I'll see what I can do.

I emailed some contact a few days ago about this.  He'll be back from
vacation in a few days, so let's see what he says.  If he doesn't solve
it quickly, I'll ping you.

[...]
> > > Did the project get permission from the foundation for the removal?
> > 
> > Not yet.
> 
> Until that approval arrives would you consider reinstating the copyright notices
> that belong to the Linux Foundation?

I'll not do it right now, but I'll do it before the next release, in
case they haven't replied before the release.

> > > (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?
> 
> I've responded to Branden on this topic downthread.

As Branden said, a copyright notice stating the years are 2002, 2004
is useless, because it doesn't identify which text corresponds to 2002
and which to 2004.  So, unless one has the git(1) log, one can't use
that information at all.  And if one has git(1), that information
becomes irrelevant.

> I leave this with you to decide.

I'll maintain the collapsed ranges.  I don't see the usefulness of
non-collapsed years.  Moreover, it might seem funny, but some copyright
notices stated the exact days in which the author worked.  IIRC, I saw
in a copyright notice two different days of the same year.

> > > 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.
> 
> Thank you!

Done.

> > > 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.
> 
> Yes, these are problematic and we should move towards compliance.
> 
> > > 
> > > 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.
> 
> Thank you!
> 
> > 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.
> 
> Perfect.

Actually, I've looked at memcpy(3), and the text I thought might have
come from glibc is not present in the glibc manual, so I guess it's
from this project only.  The text from glibc might have been replaced
entirely over time.

Now we have a Ship of Theseus problem here.  The page doesn't seem to
contain any copyrighted text, but are we allowed to just drop that
license notice?  Any suggestions about memcpy(3)?

> I will go publicly on the record as saying I do not like the GFDL for the
> glibc manual, the invariant section, and choice of incompatibility with
> the LGPLv2+ means we can't even copy comments into the manual without
> having someone who can relicense them. This is a process mistake that we've
> been trying to fix for a long time.
> 
> > > (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).
> 
> Thank you very much for your help in getting everything to point where
> we can publish this in Fedora.

Thank you!


Have a lovely night!
Alex

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

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