[Bug libc/28007] New: Add SPDX license identifiers

[Bug libc/28007] New: Add SPDX license identifiers

[dje at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28007

            Bug ID: 28007
           Summary: Add SPDX license identifiers
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: dje at sourceware dot org
                CC: codonell at redhat dot com, drepper.fsp at gmail dot com
  Target Milestone: ---

Add appropriate SPDX license identifiers to GNU libc source code files.

https://spdx.org/licenses/

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/28007] Add SPDX license identifiers

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28007

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #1 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to David Edelsohn from comment #0)
> Add appropriate SPDX license identifiers to GNU libc source code files.
> 
> https://spdx.org/licenses/

I agree that we should do this. It would make downstream compliance easier.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/28007] Add SPDX license identifiers

[Martin.Jansa at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28007

Martin Jansa <Martin.Jansa at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Martin.Jansa at gmail dot com

--- Comment #2 from Martin Jansa <Martin.Jansa at gmail dot com> ---
Agreed, mapping various sections in LICENSES file to actual source files isn't
in some cases trivial, having the SPDX identifiers directly in source files
would be very helpful downstream.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/28007] Add SPDX license identifiers

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28007

--- Comment #3 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Martin Jansa from comment #2)
> Agreed, mapping various sections in LICENSES file to actual source files
> isn't in some cases trivial, having the SPDX identifiers directly in source
> files would be very helpful downstream.

Yes, and some files have multiple licenses, so the SPDX identifiers gets
complex. I'm happy to help enable this work to move forward if there is a
downstream sponsor interested in this work being committed upstream.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/28007] Add SPDX license identifiers

[richard.purdie at linuxfoundation dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28007

richard.purdie at linuxfoundation dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |richard.purdie@linuxfoundat
                   |                            |ion.org

--- Comment #4 from richard.purdie at linuxfoundation dot org ---
I would love to see this as it would significantly improve license identifier
coverage of our code. Yocto Project uses the debug symbol/file information to
work out which files contribute to a given binary and if those have SPDX    
identifiers, we can give a reasonable indication of the license for the binary.

Is this something you'd accept incremental work on over time? Resolving the
files which aren't the "standard" license would be particularly beneficial but
wider coverage would be great too.

Have you given thought to what format would you want these changes in? In some
projects (including our own Bitbake/OpenEmbedded-Core) we ended up replacing
the license boilerplate with the SPDX-License-Identifier as it simplified and
made things really clear. In some projects they just add the identifier and
leave the existing license declaration. I'm not sure which glibc would prefer?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/28007] Add SPDX license identifiers

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28007

--- Comment #5 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to richard.purdie from comment #4)
> I would love to see this as it would significantly improve license
> identifier coverage of our code. Yocto Project uses the debug symbol/file
> information to work out which files contribute to a given binary and if
> those have SPDX     identifiers, we can give a reasonable indication of the
> license for the binary.
> 
> Is this something you'd accept incremental work on over time? Resolving the
> files which aren't the "standard" license would be particularly beneficial
> but wider coverage would be great too.

Absolutely, I think incremental progress would be the way to go.

> Have you given thought to what format would you want these changes in? In
> some projects (including our own Bitbake/OpenEmbedded-Core) we ended up
> replacing the license boilerplate with the SPDX-License-Identifier as it
> simplified and made things really clear. In some projects they just add the
> identifier and leave the existing license declaration. I'm not sure which
> glibc would prefer?

I would start by *adding* the identifer and leaving existing license
declarations. The addition of the identifiers is something we could more easily
approve.

The removal of license declarations can always happen as a second phase
cleanup, and would require more rigorous review.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/28007] Add SPDX license identifiers

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28007

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com
              Flags|                            |security-

--- Comment #6 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to richard.purdie from comment #4)
> I would love to see this as it would significantly improve license
> identifier coverage of our code. Yocto Project uses the debug symbol/file
> information to work out which files contribute to a given binary and if
> those have SPDX     identifiers, we can give a reasonable indication of the
> license for the binary.

Why is this important to you?

The bulk of glibc is under the LGPL. Providing just an SPDX identifier does not
comply with the LGPL notification requirements, and requirements to provide
source code and enable relinking. Even the glibc parts not licensed under the
LGPL (as far as they even exist) were originally released under licenses that
have notification requirements. You need to include the entire notices, not
just SPDX identifiers, and presently the only way to do this is to include the
entire source code. These permissive licenses typically say “provided that the
above
copyright notice and this permission notice appear in all copies” or “must
retain the above copyright notice, this list of conditions and the following
disclaimer”, and not “provided that you include an SPDX identifier for a text
substantially similar to this notice”.

Without better understanding the use case, I don't think it's a good idea to
spend glibc project resources on figuring out what the appropriate SPDX
identifier for a file like resolv/res_query.c or resolv/compat-gethnamaddr.c
should be.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/28007] Add SPDX license identifiers

[dje at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28007

--- Comment #7 from David Edelsohn <dje at sourceware dot org> ---
Carlos never should have suggested removing the FSF mandated license
declarations.  That was not well thought out and is an unnecessary confusion /
distraction.

Many security tools now are looking for SPDX license identifiers and the lack
of the clear information in SPDX license identifier format is a growing
inhibitor to GLIBC.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/28007] Add SPDX license identifiers

[richard.purdie at linuxfoundation dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28007

--- Comment #8 from richard.purdie at linuxfoundation dot org ---
(In reply to Florian Weimer from comment #6)
> Why is this important to you?

I think you mean why is this important to Yocto Project. We have a lot of
diverse users of the project and they have different legals departments and
uses of the project. One thing they need to know is the software license the
components of system they're building are under. As such, Yocto Project recipes
advertise the license we believe a given piece of software is under.

We don't make any comment on what people should/shouldn't do with that
information but I think we can agree that having correct information is
important. For some project users it is particularly important where they need
to avoid things like GPL-3.0 for example (rightly or wrongly, I make no comment
on that).

Recently it was brought to our attention that glibc isn't just under GPL-2.0
but also has other license components and as such our overall license for glibc
wasn't correct. We looked into it and found that we do need to tweak our
metadata. Had there been SPDX license identifiers, we'd likely have avoided
that issue in the first place and also been able to detect that it had
happened. In this case I don't think it changes decisions people should be
making but we want our license information to be complete so people have
confidence in it. The identifiers help with that.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/28007] Add SPDX license identifiers

[richard.purdie at linuxfoundation dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28007

--- Comment #9 from richard.purdie at linuxfoundation dot org ---
(In reply to David Edelsohn from comment #7)
> Carlos never should have suggested removing the FSF mandated license
> declarations.  That was not well thought out and is an unnecessary confusion
> / distraction.
> 
> Many security tools now are looking for SPDX license identifiers and the
> lack of the clear information in SPDX license identifier format is a growing
> inhibitor to GLIBC.

Just to be clear, I'm not saying they should be removed, I'm simply noting that
projects have taken different approaches and I'm asking which approach is
appropriate for glibc. If that is to add the identifier and leave everything
else, that is fine by me. I do have opinions on that but it isn't my place to
say in this case.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/28007] Add SPDX license identifiers

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28007

--- Comment #10 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to David Edelsohn from comment #7)
> Many security tools now are looking for SPDX license identifiers and the
> lack of the clear information in SPDX license identifier format is a growing
> inhibitor to GLIBC.

I'm worried that adding those identifiers gives an implied promise about their
correctness.

There is also the impediment to future development because we have to discuss
whether we need to copy SPDX identifiers as well when copying code around, and
if a file has multiple such identifiers, if all should be copied, or just those
pertaining to the code being copied.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/28007] Add SPDX license identifiers

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28007

--- Comment #11 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to richard.purdie from comment #8)
> (In reply to Florian Weimer from comment #6)
> > Why is this important to you?
> 
> I think you mean why is this important to Yocto Project. We have a lot of
> diverse users of the project and they have different legals departments and
> uses of the project. One thing they need to know is the software license the
> components of system they're building are under. As such, Yocto Project
> recipes advertise the license we believe a given piece of software is under.
> 
> We don't make any comment on what people should/shouldn't do with that
> information but I think we can agree that having correct information is
> important. For some project users it is particularly important where they
> need to avoid things like GPL-3.0 for example (rightly or wrongly, I make no
> comment on that).
> 
> Recently it was brought to our attention that glibc isn't just under GPL-2.0
> but also has other license components and as such our overall license for
> glibc wasn't correct. We looked into it and found that we do need to tweak
> our metadata. Had there been SPDX license identifiers, we'd likely have
> avoided that issue in the first place and also been able to detect that it
> had happened. In this case I don't think it changes decisions people should
> be making but we want our license information to be complete so people have
> confidence in it. The identifiers help with that.

Based on that, I don't think you actually need per-file SPDX identifiers. One
file with all the identifiers that to pertain to any code in glibc should be
sufficient for analysis tooling to pick them up.

I think this would avoid the future maintenance burden. We can also clarify
that we (as the project maintainers) believe that the SPDX identifiers are a
convenient approximation to the actual licensing state of glibc for use with
SPDX tools, but may not be completely accurate.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/28007] Add SPDX license identifiers

[richard.purdie at linuxfoundation dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28007

--- Comment #12 from richard.purdie at linuxfoundation dot org ---
(In reply to Florian Weimer from comment #11)
> (In reply to richard.purdie from comment #8)
> Based on that, I don't think you actually need per-file SPDX identifiers.
> One file with all the identifiers that to pertain to any code in glibc
> should be sufficient for analysis tooling to pick them up.
> 
> I think this would avoid the future maintenance burden. We can also clarify
> that we (as the project maintainers) believe that the SPDX identifiers are a
> convenient approximation to the actual licensing state of glibc for use with
> SPDX tools, but may not be completely accurate.

We did deal with a project where every source file was licensed with GPL-2
except for one file that was GPL-3.0. We could prove programmatically which
output binaries had that GPL-3.0 file and which did not. We are being asked
similar questions about the glibc output binaries now it is under multiple
licenses.

We (as in Ycoto Project) can make our best guesses about what license files are
under but it would be nice to share that information with others in the
upstream rather that everyone making guesses. We're being asked to accept it
within Yocto Project so that multiple users don't maintain it themselves.

I'd hope the burden on developers isn't high, in general licenses tend to be
more straight forward now and more consistent within projects. I'd hope it
actually encourages that over time.

FWIW I can also speak as a maintainer of projects which have adopted them and I
find it does simplify things a lot from my perspective.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/28007] Add SPDX license identifiers

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28007

--- Comment #13 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to David Edelsohn from comment #7)
> Carlos never should have suggested removing the FSF mandated license
> declarations.  That was not well thought out and is an unnecessary confusion
> / distraction.

I agree that we should focus on the the first step which is adding
SPDX-License-Identifier.

> Many security tools now are looking for SPDX license identifiers and the
> lack of the clear information in SPDX license identifier format is a growing
> inhibitor to GLIBC.

Agreed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/28007] Add SPDX license identifiers

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28007

--- Comment #14 from Carlos O'Donell <carlos at redhat dot com> ---
Raised the issue on libc-alpha to reach a wider audience with an RFC:
https://sourceware.org/pipermail/libc-alpha/2022-May/139167.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/28007] Add SPDX license identifiers

[rwmacleod at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28007

Randy Macleod <rwmacleod at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rwmacleod at gmail dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.