I think Richard said that he would start a thread like this, but it hasn't happened, so I feel like should get this off my chest now. <https://docs.fedoraproject.org/en-US/legal/license-field/#_no_effective_l... starts with this: | No “effective license” analysis | | The License: field is meant to provide a simple enumeration of the | licenses found in the source code that are reflected in the binary | package. No further analysis should be done regarding what the | "effective" license is, such as analysis based on theories of GPL | interpretation or license compatibility or suppositions that | “top-level” license files somehow negate different licenses appearing | on individual source files. This is contradictory. I think there are two aspects here: * Determine possible licenses that end up in the binary package. * Perform algebraic simplifications on the license list. Both analyses are forms of effective licensing analysis. Of course, you cannot derive an SPDX identifier without doing any analysis. However, I strongly believe that the first approach (determining the binary package license) is itself a form of effective licensing analysis, and similar reasons for package maintainers not doing this applies. The derived SPDX identifier will reflect both the package source code and what went into the build system.

* Some package maintainers, when translating to SPDX, merely translate the existing License: line as best as they can, without looking at the actual sources or produced binaries.

In the light of this, I would like to suggest updating the guidelines in the following way: The License: line should be based on the sources only. Using a tool such as Fossology to discover relevant licenses and their SPDX tags is sufficient. No analysis how licenses from package source code or the build environment propagate into binary RPMs should be performed. Individual SPDX identifiers that a tool has listed should be separated by AND. Package maintainers are encouraged to re-run license analysis tooling on the source code as part of major package rebases, and update the License: tag accordingly. To me, that seems to be much more manageable.

* Daniel P. Berrangé: > On Mon, Aug 21, 2023 at 01:04:29PM +0200, Florian Weimer wrote: >> I think Richard said that he would start a thread like this, but it >> hasn't happened, so I feel like should get this off my chest now. >> >> <https://docs.fedoraproject.org/en-US/legal/license-field/#_no_effective_l... >> starts with this: >> >> | No “effective license” analysis >> | >> | The License: field is meant to provide a simple enumeration of the >> | licenses found in the source code that are reflected in the binary >> | package. No further analysis should be done regarding what the >> | "effective" license is, such as analysis based on theories of GPL >> | interpretation or license compatibility or suppositions that >> | “top-level” license files somehow negate different licenses appearing >> | on individual source files. >> >> This is contradictory. I think there are two aspects here: >> >> * Determine possible licenses that end up in the binary package. >> >> * Perform algebraic simplifications on the license list. >> >> Both analyses are forms of effective licensing analysis. Of course, you >> cannot derive an SPDX identifier without doing any analysis. However, I >> strongly believe that the first approach (determining the binary package >> license) is itself a form of effective licensing analysis, and similar >> reasons for package maintainers not doing this applies. The derived >> SPDX identifier will reflect both the package source code and what went >> into the build system. > > It could perhaps be worded better, but I don't see this as contradictory, > it is just a matter of what you consider "effective analysis" to refer to. > The last sentance expands on this to say that 'effective' in this context > is refering to the analysis of license compatibility that Fedora previously > recommended. I think it goes beyond terminology. I think determining the binary RPM licenses has similar complexities than the license algebra. I can't imagine consensus emerging around that. There's just no firm reasoning why we ignore header files and dynamic linking in the License: tag, the glibc startup code, but not static linking in general. I think coming up with a consistent rules is even more complicated than some sort of license algebra, or rules for ignoring certain copyright files. So I think the perceived simplification of the rules fell short, and the present rules are still unworkable.

> What I'm not a fan on with this approach is that it would cause us > to include licenses that are clearly irrelevant for Fedora binary > packages. If we consider the "license" tag to be something for end > users to look at, I think this will be misleading. We can come up with something that looks at the state of the tree after %prep, or something like that. The problem with dropping stuff arbitrarily is that it makes it again impossible to rely on tooling.

> For example in one package I reviewed there is kernel code that is > only built on Solaris which is under the CDDL. Including that in > the Fedora binary RPM license feels totally wrong. I disagree. Upstream may have copied code from the CDDL part of the tree to other parts without updating the license. If we ignore the CDDL license, we say that hasn't happened, and I doubt we are in the position to make such a certification for most packages.

Of course someone may have copied code from a Stackoverflow answer (which is generally available under incompatible license terms), and we wouldn't know about that either. But suppressing license information actually present in the source package (although in a supposedly unused location) seems different.

> I might suggest adding an extra sentance to make it more explicit > that the binary RPM license is not a perfect representation of > the binary content, as may sometimes include extra licenses from > source files that were not relevant. This would reflect the somewhat > pragmatic approach that I think maintainers already take in practice I would welcome that. And update the Rust guidelines accordingly, to clarift that the kind of buildroot-to-binary-RPM propagation that the tooling performs is optional and not required by (the spirit of) the Fedora guidlines.

On Mon, Aug 21, 2023 at 9:30 AM Daniel P. Berrangé <berrange(a)redhat.com <mailto:berrange@redhat.com>> wrote: On Mon, Aug 21, 2023 at 01:04:29PM +0200, Florian Weimer wrote: > I think Richard said that he would start a thread like this, but it > hasn't happened, so I feel like should get this off my chest now. > > <https://docs.fedoraproject.org/en-US/legal/license-field/#_no_effective_l... <https://docs.fedoraproject.org/en-US/legal/license-field/#_no_effective_l... > starts with this: > > | No “effective license” analysis > | > | The License: field is meant to provide a simple enumeration of the > | licenses found in the source code that are reflected in the binary > | package. No further analysis should be done regarding what the > | "effective" license is, such as analysis based on theories of GPL > | interpretation or license compatibility or suppositions that > | “top-level” license files somehow negate different licenses appearing > | on individual source files. > > This is contradictory.  I think there are two aspects here: > > * Determine possible licenses that end up in the binary package. > > * Perform algebraic simplifications on the license list. > > Both analyses are forms of effective licensing analysis.  Of course, you > cannot derive an SPDX identifier without doing any analysis.  However, I > strongly believe that the first approach (determining the binary package > license) is itself a form of effective licensing analysis, and similar > reasons for package maintainers not doing this applies.  The derived > SPDX identifier will reflect both the package source code and what went > into the build system. It could perhaps be worded better, but I don't see this as contradictory, it is just a matter of what you consider "effective analysis" to refer to. The last sentance expands on this to say that 'effective' in this context is refering to the analysis of license compatibility that Fedora previously recommended. The 'license compatibility' aspect is what is meant by the process here.  Previously Fedora carried a large license compatibility chart and there were rules (both written and passed down through oral tradition) about what is and is not compatible with the different GPL licenses.  A common case was a GPL project incorporating BSD licensed code which meant the entire collective work was GPL licensed _per FSF guidelines_.  This is the part that Fedora Legal wants to do away with.  Package maintainers do not need to perform this compatibility analysis. So yes, it could probably be worded better. The analysis maintainers are being asked to do today is not about interpreting licensing. They "merely" being asked to determine what source files are containing code that becomes part of the resulting binary RPM. This is more build system analysis than license analysis, and distinct from what Fedora would traditionally describe as "effective license analysis". Correct. > * Some package maintainers, when translating to SPDX, merely translate >   the existing License: line as best as they can, without looking at the >   actual sources or produced binaries. This I think is probably the main flaw in the process we asked our maintainers to follow. At a high level we portrayed the whole exercise as merely a terminology change, but it was not. Given the removal of the effective license analysis requirement, that was / is an over simplification. Strictly speaking I think the exercise ought to have been portrayed as more of a license (re-)audit. In the general case maintainers ought to be redoing the license audit part of the new package review process, for all existing packages, not blindly converting existing terminology. We did portray this as a re-audit and not simply a change in abbreviations.  I did many presentations on just that and we held numerous hack fests where we helped people analyze packages to determine the correct license expression in SPDX. There are definitely maintainers who thought it was just a change in abbreviations and I do not think there is an easy way to stop that.  But as we have been going through this process, the number of maintainers auditing packages has been high and we are seeing more licenses captured and added to SPDX that were not previously represented. What I would like to see in the future is a tool connected to Bodhi that can run for each build of a package and perform a license analysis, build the License tag string, then compare it to what is in the spec file.  If it's different then alert the package maintainer and say "Hey, I'm a script and I analyzed the licenses in this package and I *think* I found something different than what you put in the spec file License tag.  If I were you, I would check it out because one of us is probably wrong."  Maybe we'll have that at some point. > In the light of this, I would like to suggest updating the guidelines in > the following way: > >   The License: line should be based on the sources only.  Using a tool >   such as Fossology to discover relevant licenses and their SPDX tags is >   sufficient.  No analysis how licenses from package source code or the >   build environment propagate into binary RPMs should be performed. >   Individual SPDX identifiers that a tool has listed should be separated >   by AND.  Package maintainers are encouraged to re-run license analysis >   tooling on the source code as part of major package rebases, and >   update the License: tag accordingly. > > To me, that seems to be much more manageable. What I'm not a fan on with this approach is that it would cause us to include licenses that are clearly irrelevant for Fedora binary packages. If we consider the "license" tag to be something for end users to look at, I think this will be misleading. For example in one package I reviewed there is kernel code that is only built on Solaris which is under the CDDL. Including that in the Fedora binary RPM license feels totally wrong. In many packages using autotools there are snippets of m4 code that are under a variety of licenses, again not affecting the output. Those would "bloat" the license tag for little obvious gain. I do agree though that doing *perfect* build system analysis to figure out what source files become part of the binary RPMs is impractical for any non-trivial packages. My approach has been to scan the source for licenses, and then look at source files with any licenses I was surprised to see. Often it is possible to exclude these unexpected licenses, because they are obviously part of the build system, or are obviously for a differnt OS platform. I agree here.  To me, the source archive already includes its licensing information.  What Fedora does is build this source in a curated way for distribution, so the licenses that apply to our build do not necessarily align with other distributions.  This is the licensing information that I think is relevant for Fedora to understand and convey to users.  There will always be additional licenses in the source archives (given your examples above such as autotools or optional code that is not enabled at build time), but the source archives include all of that licensing information.  If they didn't, we would not be able to build anything from that source to include in Fedora. I would describe this as trying to meet the spirit of the having the RPM license reflect binary content, while acknowledging the reality that maintainers won't fully analyse the build system as it is too time consuming & impractical. I might suggest adding an extra sentance to make it more explicit that the binary RPM license is not a perfect representation of the binary content, as may sometimes include extra licenses from source files that were not relevant. This would reflect the somewhat pragmatic approach that I think maintainers already take in practice One thing I have learned through this whole SPDX project is that being a convergence of something technical and something not makes it very difficult to arrive at what we think is an acceptable completion.  I think what we have now in Fedora is pretty good compared to other distributions, but it can always improve.  We just keep making improvements and keep refining the process.  Shaving the yak, as it were. Thanks,  | The License: field is meant to provide a simple enumeration of the  | licenses found in the source code that are reflected in the binary  | package. In may also include additional licenses for files that are  | not part of the binary where it is impractical to filter them out  | during license review. No further analysis should be done regarding  | what the "effective" license is, such as analysis based on theories  | of GPL interpretation or license compatibility or suppositions that  | “top-level” license files somehow negate different licenses appearing  | on individual source files. With regards, Daniel -- |: https://berrange.com <https://berrange.com>      -o- https://www.flickr.com/photos/dberrange <https://www.flickr.com/photos/dberrange> :| |: https://libvirt.org <https://libvirt.org>         -o- https://fstop138.berrange.com <https://fstop138.berrange.com> :| |: https://entangle-photo.org <https://entangle-photo.org>    -o- https://www.instagram.com/dberrange <https://www.instagram.com/dberrange> :|

Regarding this, I am testing a new tool for license analysis.

I took a random package from an SPDX PR in my Inbox. https://src.fedoraproject.org/rpms/90-Second-Portraits/pull-request/1 Surprise, surprise, we have non free code, this is just amazing!

V Mon, Aug 21, 2023 at 01:04:29PM +0200, Florian Weimer napsal(a): > * Most package maintainers probably assume that License: tags on all > built RPMs (source RPMs and binary RPMs) should reflect binary package > contents, at least when all subpackages are considered in aggregate. > Often, Source RPMs contain the same License: line as binary RPMs. > That's a shortcomming of RPM. It reuses License tag of the main subpackage for source RPM.

> In the light of this, I would like to suggest updating the guidelines in > the following way: > > The License: line should be based on the sources only. Using a tool > such as Fossology to discover relevant licenses and their SPDX tags is > sufficient. No analysis how licenses from package source code or the > build environment propagate into binary RPMs should be performed. > Individual SPDX identifiers that a tool has listed should be separated > by AND. Package maintainers are encouraged to re-run license analysis > tooling on the source code as part of major package rebases, and > update the License: tag accordingly. > > To me, that seems to be much more manageable. > Yes, that's a very realistic approach of what we can expect from the packagers. I only worry whether the resulting License tag will be any helpful for our users. E.g. most of the subpackages of perl.spec are "GPL-1.0-or-later OR Artistic-1.0-Perl". With your approach their license tag would gain a ridiculous license identifiers that are not really contained.

V Sun, Aug 27, 2023 at 12:30:01PM -0400, Richard Fontana napsal(a): > On Tue, Aug 22, 2023 at 3:34 AM Petr Pisar <ppisar(a)redhat.com&gt; wrote: >> V Mon, Aug 21, 2023 at 01:04:29PM +0200, Florian Weimer napsal(a): >>> * Most package maintainers probably assume that License: tags on all >>> built RPMs (source RPMs and binary RPMs) should reflect binary package >>> contents, at least when all subpackages are considered in aggregate. >>> Often, Source RPMs contain the same License: line as binary RPMs. >>> >> That's a shortcomming of RPM. It reuses License tag of the main subpackage for >> source RPM. > Out of curiosity, is what subpackage is the "main" subpackage a well > defined concept, or is it just "the builit package that is described > first in the spec file" and beyond that a matter of convention? I > couldn't find the answer to this in a few minutes of naive searching. > I don't think the "main" title is an offical RPM term. Probably that's why you were unable to find it. It's used at few places in Fedora packaging guidelines <https://docs.fedoraproject.org/en-US/packaging-guidelines/>;. Otherwise, the concept is well defined. At least empirically. The "main" subpackage is a subpackage which is defined with Name spec tag. All subsequent subpackages can and are only defined with a %package macro. RPM requires the Name tag to exist and come before any %package macros. Hence, the main subpackage which shares a License value with a source package is usually and effectively the first subpackage. I write usually, because there can be spec files which do not produce a binary package for the first subpackage. Then the only package where the Name tag (and its License tag, if overriden in other subpackages) manifests is the source package. We use these spec files without main binary subpackge rarely in EPEL.

Nevertheless, in short, the main subpackage is the first package defined in a spec file. -- Petr _______________________________________________ legal mailing list -- legal(a)lists.fedoraproject.org To unsubscribe send an email to legal-leave(a)lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

Dne 28. 08. 23 v 17:26 Petr Pisar napsal(a): > V Sun, Aug 27, 2023 at 12:30:01PM -0400, Richard Fontana napsal(a): >> On Tue, Aug 22, 2023 at 3:34 AM Petr Pisar <ppisar(a)redhat.com&gt; wrote: >>> V Mon, Aug 21, 2023 at 01:04:29PM +0200, Florian Weimer napsal(a): >>>> * Most package maintainers probably assume that License: tags on all >>>> built RPMs (source RPMs and binary RPMs) should reflect binary package >>>> contents, at least when all subpackages are considered in aggregate. >>>> Often, Source RPMs contain the same License: line as binary RPMs. >>>> >>> That's a shortcomming of RPM. It reuses License tag of the main subpackage for >>> source RPM. >> Out of curiosity, is what subpackage is the "main" subpackage a well >> defined concept, or is it just "the builit package that is described >> first in the spec file" and beyond that a matter of convention? I >> couldn't find the answer to this in a few minutes of naive searching. >> > I don't think the "main" title is an offical RPM term. Probably that's why you > were unable to find it. It's used at few places in Fedora packaging guidelines > <https://docs.fedoraproject.org/en-US/packaging-guidelines/>;. > > Otherwise, the concept is well defined. At least empirically. > > The "main" subpackage is a subpackage which is defined with Name spec tag. All > subsequent subpackages can and are only defined with a %package macro. RPM > requires the Name tag to exist and come before any %package macros. Hence, > the main subpackage which shares a License value with a source package is > usually and effectively the first subpackage. > > I write usually, because there can be spec files which do not produce a binary > package for the first subpackage. Then the only package where the Name tag > (and its License tag, if overriden in other subpackages) manifests is the > source package. We use these spec files without main binary subpackge rarely > in EPEL. Isn't it the default case for python packages? IOW I don't think it is that rare (although I am not sure why you mention EPEL instead of Fedora).

On Mon, Aug 28, 2023 at 3:25 PM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote: > So yes, we rely on and adhere to the "License tag reflects binary > package contents" rule. So you are reasonably happy with the current rules as they affect the License: field for Rust crate packages? Or is there anything you would like to see changed?

I think Richard said that he would start a thread like this, but it hasn't happened, so I feel like should get this off my chest now.

<https://docs.fedoraproject.org/en-US/legal/license-field/#_no_effective_l... starts with this: | No “effective license” analysis | | The License: field is meant to provide a simple enumeration of the | licenses found in the source code that are reflected in the binary | package. No further analysis should be done regarding what the | "effective" license is, such as analysis based on theories of GPL | interpretation or license compatibility or suppositions that | “top-level” license files somehow negate different licenses appearing | on individual source files. This is contradictory. I think there are two aspects here: * Determine possible licenses that end up in the binary package. * Perform algebraic simplifications on the license list. Both analyses are forms of effective licensing analysis. Of course, you cannot derive an SPDX identifier without doing any analysis. However, I strongly believe that the first approach (determining the binary package license) is itself a form of effective licensing analysis, and similar reasons for package maintainers not doing this applies. The derived SPDX identifier will reflect both the package source code and what went into the build system.

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. * Most package maintainers probably assume that License: tags on all built RPMs (source RPMs and binary RPMs) should reflect binary package contents, at least when all subpackages are considered in aggregate. Often, Source RPMs contain the same License: line as binary RPMs.

In the light of this, I would like to suggest updating the guidelines in the following way: The License: line should be based on the sources only. Using a tool such as Fossology to discover relevant licenses and their SPDX tags is sufficient. No analysis how licenses from package source code or the build environment propagate into binary RPMs should be performed. Individual SPDX identifiers that a tool has listed should be separated by AND. Package maintainers are encouraged to re-run license analysis tooling on the source code as part of major package rebases, and update the License: tag accordingly.

On Mon, Aug 21, 2023 at 7:04 AM Florian Weimer <fweimer(a)redhat.com&gt; 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. > > * Most package maintainers probably assume that License: tags on all > built RPMs (source RPMs and binary RPMs) should reflect binary package > contents, at least when all subpackages are considered in aggregate. > Often, Source RPMs contain the same License: line as binary RPMs. This is the most important issue I was hoping to raise, if we mean the same thing.

When I look randomly at spec files of Fedora packages, I begin to suspect that most Fedora package maintainers must have always ignored this directive and have continued to ignore it after the rule was recast in the post-July-2022 docs. In *most* cases of packages other than possibly those coming from ecosystems or historical contexts featuring highly uncomplicated licensing structures, there will be some differences in the makeup of binary packages from a built source code licensing standpoint. I only rarely see attempts to reflect this via multiple License: fields. While in the scheme of things I only look at a small sample of Fedora packages I suspect they are representative. I can conclude one of two things: 1. The license of the binary rule is too hard for most Fedora package maintainers to comply with. 2. Fedora package maintainers are unaware of the rule and are substituting their own intuition, which I think must be something like "each RPM should have one License: field that reflects the makeup of all the binary RPMs without attempting to distinguish among them".

> 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. > > * Most package maintainers probably assume that License: tags on all > built RPMs (source RPMs and binary RPMs) should reflect binary package > contents, at least when all subpackages are considered in aggregate. > Often, Source RPMs contain the same License: line as binary RPMs. This is the most important issue I was hoping to raise, if we mean the same thing. We (Jilayne and I and others who worked on the new Fedora license-related docs) did not invent this concept. The old Fedora documentation had a "license of the binary" policy, I assume developed mainly by Tom Callaway, that I always thought was a great analytical or representational advance. Here's what the old Fedora docs said: The oldest archived version of http://fedoraproject.org/wiki/Packaging:LicensingGuidelines(dated from 2008) says "The License: field refers to the licenses of the contents of the *binary* rpm." The author was clearly at pains to make clear that it was not meant to encompass the entirety of the source code as packaged in source RPMs. At least since 2009, this was followed by: "If a source package generates multiple binary packages, the License: field may differ between them if necessary. This implies that a single spec may have multiple per-subpackage License: tags. Each of those License: tags must comply with all applicable guidelines."

I thought I understood what that meant and I thought I saw examples of that in operation. Recently, I've started to wonder whether I misunderstood that all along, though I don't see how. The text seems very clear to me.

When I look randomly at spec files of Fedora packages, I begin to suspect that most Fedora package maintainers must have always ignored this directive and have continued to ignore it after the rule was recast in the post-July-2022 docs. In *most* cases of packages other than possibly those coming from ecosystems or historical contexts featuring highly uncomplicated licensing structures, there will be some differences in the makeup of binary packages from a built source code licensing standpoint. I only rarely see attempts to reflect this via multiple License: fields. While in the scheme of things I only look at a small sample of Fedora packages I suspect they are representative.

I can conclude one of two things: 1. The license of the binary rule is too hard for most Fedora package maintainers to comply with.

2. Fedora package maintainers are unaware of the rule and are substituting their own intuition, which I think must be something like "each RPM should have one License: field that reflects the makeup of all the binary RPMs without attempting to distinguish among them".

BTW I don't think #1 is "The license of the binary rule is too hard for most Fedora package maintainers to comply with *without the application of effective licensing folkloric concepts". Because even when "effective licensing" was assumed by some Fedora package maintainers to be legitimate (even though it was never consistently endorsed in Fedora legal/packaging rules) it must be the case that most Fedora package maintainers were still ignoring the rule. This puzzles and disappoints me since, as I have said, the license of the binary concept was in my view a major advance in the way people were thinking about appropriate ways of representing licenses of packages.

If you look into SPDX, for example, SPDX doesn't even have (as far as I can tell) a sophisticated way of distinguishing between binary and source licensing. I believe this reflects the source code-centric and non-packaging-centric world view of many of the people who got involved with SPDX early on, but that may be unfair.

When we (a bunch of us inside Red Hat that is) started to think about revamping the rules on RPM license metadata, we thought about a number of options. One thing I should note is that my enthusiasm for a "license of the binary" rule was never really shared by anyone else I talked to at Red Hat

I'm deliberately ignoring most of the rest of your comments in this message because I think they raise some additional topics, because I want to make sure there is some focus on this one. What do we do about the "license of the binary" rule?

If it is really too hard to comply with, I think we can only conclude that it has to be replaced with some other approach. Since I'm not a Fedora package maintainer I do not have good intuition for what's too hard vs. what's merely annoying or cumbersome. I know why I find it challenging to figure out what source files map to a given binary RPM, but I don't really directly understand why this is hard for a Fedora package maintainer who is theoretically highly familiar with the code they are packaging and theoretically has some expertise in the language(s) and build tools at issue.

> I think we should definitely try to get a downstream view on this, if > there is one. I assume you primarily mean the view of engineers working on packaging for CentOS Stream/RHEL,

Anyway, the approach that has always been taken in responding to these requests for RPMs, at least those coming from RHEL specifically, has been to use the License: field contents (ignoring any varying information for subpackages). So basically there is one list item corresponding to each SRPM. This is justified partly by the quality we associate with the Fedora-based approach, i.e. we feel we can report the contents of the License: field in most cases rather than scan or otherwise review the package anew.

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.

On Sat, Oct 28, 2023 at 6:05 PM Richard Fontana <rfontana(a)redhat.com&gt; wrote: > > On Mon, Aug 21, 2023 at 7:04 AM Florian Weimer <fweimer(a)redhat.com&gt; 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. > > 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? This might have been the case a few years ago, but no longer. New packages often don't bother building documentation (be it with doxygen, sphinx, or rubygems), because the effort to make this work "properly" for the latest guidelines wrt/ bundling and license tags makes it very onerous. You will find many mentions of this, especially for sphinx, in recent Python package reviews, or on the mailing lists.

On Mon, Aug 21, 2023 at 7:04 AM Florian Weimer <fweimer(a)redhat.com&gt; 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.

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.

But I also am not sure if a Fedora package maintainer should realistically be expected to know that this situation occurs.

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.

On Mon, Oct 30, 2023 at 10:56 AM Daniel P. Berrangé <berrange(a)redhat.com&gt; wrote: > > 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. This is just not true, especially for Rust. We do our best to accurately reflect statically linked dependencies, and we have helper scripts / macros to determine *which* dependencies are actually linked into the final binaries, and which are only needed at build-time. And I also do similar things for the one Go package I maintain. Fabio _______________________________________________ legal mailing list -- legal(a)lists.fedoraproject.org To unsubscribe send an email to legal-leave(a)lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

On Mon, Aug 21, 2023 at 7:04 AM Florian Weimer <fweimer(a)redhat.com&gt; 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. 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. But I also am not sure if a Fedora package maintainer should realistically be expected to know that this situation occurs. 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. Richard _______________________________________________ legal mailing list -- legal(a)lists.fedoraproject.org To unsubscribe send an email to legal-leave(a)lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

The worst thing is that it appears to me, that often only we care about such subtleties.