RFC: Accepting SPDX-License-Identifier? (Bug 28007)

RFC: Accepting SPDX-License-Identifier? (Bug 28007)

[Carlos O'Donell]

Community,

Bug 28007 [1] is about adding SPDX-License-Idenfier [2] to glibc sources.

My position is that I would accept and review patches to add
SPDX-License-Identifier on a per-file basis for the glibc project in addition
to the existing notifications.

The SPDX identifiers increase our maintenance cost because they need to be
kept in sync with the existing license information. I believe the cost is small
enough for the benefit of having identifiers match the kernel's own uses of
the identifiers.

The upstream Linux kernel has 60,000+ such per-file identifiers in use today
to facilitate downstream license checking.

glibc headers and kernel headers are used together to constitute the
implementation of required headers. My suggestion is that we follow the same
process that the kernel has used and accept and review patches to implement
per-file identifiers.

Is there any reason we would not accept such identifiers?

Florian, You raised some good points on the bug, would you like to expand on
those here in the thread?

-- 
Cheers,
Carlos.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=28007
[2] https://spdx.github.io/spdx-spec/using-SPDX-short-identifiers-in-source-files/#e2-format-for-spdx-license-identifier

Re: RFC: Accepting SPDX-License-Identifier? (Bug 28007)

[Florian Weimer]

* Carlos O'Donell:

> glibc headers and kernel headers are used together to constitute the
> implementation of required headers. My suggestion is that we follow the same
> process that the kernel has used and accept and review patches to implement
> per-file identifiers.

In your opinion, what was the process that the kernel followed?

> Florian, You raised some good points on the bug, would you like to
> expand on those here in the thread?

I have a few major concerns with this.

If we accept patches that at SPDX identifiers, they might be seen as an
implied promise that the SPDX identifiers are correct.  The various
licenses under which parts of glibc are licensed try to disclaim any
liability whatsoever, but it is not immediately obvious whether this
extends to implied claims regarding the applicable licenses themselves.

It requires significant project resources to come with accurate per-file
SPDX identifiers in several areas.  We may have to interview former
contributors and try to acquire any historic records they might have.
Clarifying the state of files that have been extensively modified after
they were added to glibc may need consultation with lawyers.  Tracking
the evolution of files shared with gnulib seems also complicated.

All our licenses have notification requirements, and the cheapest way to
comply with them is to publish all glibc source code.  I don't think
there is value in enabling someone to drop this or that source file
because we said it's not covered by the LGPL.  They would still have to
extract the full license header from this file and include it with the
binaries anyway (an SPDX identifier does not meet the license
notification requirements, which typically cover copyright statement,
conditions, and the following disclaimer).

The example given in the bug (showing lack of dependency on GPL code) is
not really relevant to glibc because the FSF as the majority copyright
owner clearly states that the library is under the LGPL.  The SPDX
identifiers will not change that (even if they say GPL for some library
source files).  It should be clear to everyone that it is impossible to
avoid the LGPL when building against glibc.  But the LGPL is the most
scary (to some) license in the mix.  So fine-grained licensing
information cannot provide any additional value to the proprietary
software crowd because it will always indicate LGPL.

Maybe we can reach a deal with the FSF to simplify the licensing
situation somewhat, e.g. relicense the programs under the LPGL as well.
Then we could add a single string of SPDX identifiers to <stdc-predef.h>
and have the analysis tooling do the rest.  But once we start discussing
licensing, we could be told to that we have to upgrade to the LPGL 3.0.
Would we want to do that?  I don't know.

Thanks,
Florian