On Fri, Aug 25, 2023 at 5:58 AM Florian Weimer <fweimer@xxxxxxxxxx> wrote: > > * Richard Fontana: > > 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. I assume you primarily mean the view of engineers working on packaging for CentOS Stream/RHEL, but the main downstream interest in package license metadata I am aware of doesn't relate directly to engineering. Red Hat periodically gets requests from some customers or partners for detailed lists of information about components, primarily licensing information. For reasons that go well beyond the need to respond to such requests, Red Hat Product Security has also invested in developing systems for producing SBOMs and this is now being used as a basis for responding to those kinds of requests. 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. Note that there are other important ways in which the license review and categorization work done by Fedora benefits Red Hat. Most notably, the data on allowed and not allowed licenses serves as Red Hat's own policy on what licenses are allowed and not allowed. The switch to SPDX identifiers has facilitated this because it enables a much more precise definition of allowed/not allowed than was possible under the Callaway system. But none of that is really directly dependent on any particular rule adopted for what license information gets reported in RPM license metadata. Richard _______________________________________________ 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
