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@xxxxxxxxxx> 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 :| _______________________________________________ legal mailing list -- legal@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to legal-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/legal@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
