4:56 a.m.
On Sat, Oct 28, 2023 at 12:05:06PM -0400, Richard Fontana wrote:
On Mon, Aug 21, 2023 at 7:04 AM Florian Weimer
<fweimer(a)redhat.com> wrote:
> Below, I'm collecting a list of observations of what I believe is the
> current approach in this area, as taken by package maintainers carrying
> out the SPDX conversion. To me, it strongly suggest that the SPDX
> identifiers we derive today do not accurately reflect binary RPM package
> licensing, even when lots of package maintainers put in the extra effort
> to determine binary package licenses.
I recently noticed something that could be added to this list. There's
a package that generates a '-docs' subpackage using Doxygen.
Apparently Doxygen injects various pieces of minified JavaScript
(mostly from the jQuery ecosystem, mostly MIT-licensed) in a way that
is not obvious from analyzing the source code of the package that uses
Doxygen. I assume this must be compliant with Fedora packaging
guidelines -- although I could not verify this from reading Fedora
guidelines on bundling and JavaScript.
FWIW, in my recent re-reviews of packages I came across one that
was shipping doxygen generted content in its tarball, including
jquery JS.
Anyway, I would guess no Fedora package maintainer of a package that
has a Doxygen docs subpackage is taking this issue into account when
thinking about License: tags. Should they? I am having trouble seeing
why the licensing of the Doxygen pieces should be deliberately
ignored.
The act of copying content from one RPM build dependancy package into
the RPM output is a more general problem that Doxygen, with static
linking being the poster-child for it. This static linking happens
continually with some languages like Rust/Go/Ocaml, and AFAICT the
license tags implications have been essentially ignored.
I doubt that maintainers of packages with static linked libraries are
remembering to copy any needed the license info from all the depenedent
static libs they link against either.
But I also am not sure if a Fedora package maintainer
should
realistically be expected to know that this situation occurs.
For Doxygen the copying is certainly very subtle, so trivial to overlook.
When considering licensing I think maintainers are generally only looking
at the source tarball contents, and not even thinking about files copied
into the output RPMs from other RPMs.
I was
moving toward the view that if the package build process results in
the inclusion of some licensed material from another package, this can
be ignored if (a) the inclusion occurs in huge numbers of Fedora
packages and (b) most normal Fedora installs will have the other
package. I was thinking that would take care of Florian's gcc and
glibc statically-linked startup code examples, but surely neither (a)
nor (b) apply to the Doxygen case which seems sort of analogous.
There is a practicality question for expressing copied content in
the License tag. Even if developers identify copied contet, which
is certainly not easy in many cases, watching deps forever more to
see if the copied content gains/losses licenses is even harder.
When we bundle content from multiple upstream source tarballs in a
source package, via fake provides:
$ rpm -qa --provides | grep bundle | head -10
bundled(python3dist(appdirs)) = 1.4.3
bundled(python3dist(importlib-metadata)) = 4.11.1
bundled(python3dist(importlib-resources)) = 5.4
bundled(python3dist(jaraco-text)) = 3.7
bundled(python3dist(more-itertools)) = 8.8
bundled(python3dist(ordered-set)) = 3.1.1
bundled(python3dist(packaging)) = 21.3
bundled(python3dist(pyparsing)) = 3.0.9
bundled(python3dist(tomli)) = 2.0.1
bundled(python3dist(typing-extensions)) = 4.0.1
if we want to keep track of copied content (either static linked libraries
or simply copied file like doxygen), perhaps we should do so via another
kind of fake provides tag:
eg for the doyxgen case
copied(doxygen)
eg for qemu-user-static which static links glibc and glib2
copied(glibc)
copied(glib2)
Then if any tool needs to cnosider the full binary license, then it
can follow the fake 'copied' Provides tags. The downside is that
is not as precise - we are not copying the whole of doxygen, just the
query files, so potentially some of the Doxygen.spec license may be
inappropriate.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|