* Richard Fontana: >> 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." Very interesting. I was not aware of this advice. > 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. Yes, it's quite clear. > 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. Yeah, I knew it was possible to have per-subpackage License: tags, but I haven't seen much use of them. > 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. I don't see how this is practical to implement, particularly for projects which an assortment of licenses. Unbundling helps somewhat because if code comes from a system library, it seems that we still do not have to declare its license under the rules as written (except if it's a Rust package). > 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". The multiple License: field thing is probably not well-known. > 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. But the rules seem to exclude things that come from the buildroot instead of source package, so framing this as “license of the binary” is slightly misleading. It may not be what people want to know if they are looking for the “license of the binary”. > 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. SPDX seems to have evolved somewhat, and I found some talk of covering dynamic linking and self-configuring components: | Packages and Relationships | | While the single package concept of files worked well, the notion of | relationships was added beginning with SPDX 2.0. This allows SPDX | documents to address more complex use cases by being able to refer to | one another along with what the relationship is between them. | | As an example, consider a binary-only delivery or download as shown in | the following figure. | | In this particular example, the binary SPDX document has two | relationships: | | 1. That it was “generated from” these source files; and | 2. It dynamically links (say at runtime) with this particular library. | | This now gives a complete licensing picture as you know the licenses | of the sources used to build the application and then what it links | with at runtime as well. <https://spdx.dev/resources/use/#fws_64e844a377638> > 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 There might now be downstream requirements for something like this. Some people are trying to figure out. One the one hand, I'd be exciting about tooling support for this. (There is significant overlap with recording “this program has components that used include files from glibc-devel-2.36-9.fc37.x86_64 for compilation”.) But it's a lot of work to implement across many components before such information can be propagated automatically. But I don't know if that matches commercial needs, and to what these needs can be met with tooling alone and without per-source-file markup. It's also possible that people who are looking for “license of the binary” actually want information about potential run-time executions and what is constructed by very late binding. Personally, I'm also worried that the data may be used to minimize shipping source code, although I don't think it's technically suited to that. > 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? I think we should definitely try to get a downstream view on this, if there is one. > 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. Detailed knowledge of a package (not even its implementation language) or the changes that come in from upstream (which might invalidate previously license analysis) is not actually required. There's definitely a generic maintainer skillset that focus more on scale than deep knowledge of one upstream project. Things like knowing how to report things to upstreams in such a way that it's likely they they give you a workaround or a fix in the form of a patch. And even with deep technical knowledge, the license aspects are probably not on many people's radar. For many packages with uniform licensing or without subpackages, the licensing changes due to ongoing development is likely minimal. But otherwise, it's really not something that is on the radar. From time to time, the matter of dependency management (and minimizing unwanted dependencies) gets increased attention, but that is generally only a concern across packages, and as far as I understand it, we are ignoring the cross-package aspects of licensing. One possible outcome is that we need to produce per-file instead of per-binary-package licensing metadata, with reasonable efforts to reproduce over-reporting. That would extend the complications of the multi-binary-package scenario to many more source packages. Thanks, Florian _______________________________________________ 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
