Fedora licence compliance check

Project Discussion
,
1

Hi all,

I was recommended to raise this topic here - hope that works.

We (Lenovo) do open source compliance review for every Fedora workstation edition image we preload. Generally the image is pretty good - but there are always a small number of packages (4 to 10) that have failed to make their license available in the default image under /usr/share/licenses.

Usually it’s because the license is in one of the sub-packages that is not included in the default image (e.g librdmacm is in the image, but the license for that project is in the rdma-core package, which is not included).

I raise bugs for these and they mostly get fixed (big thanks to the package maintainers who do this). There are a few long time offenders too.

To make sure we’re covered, we manually add the few ‘missing’ licences in /opt/lenovo as part of the ‘documentation’ - it keeps our lawyer happy, and the world keeps on turning.

The list of packages has been generally reducing from when we started this exercise, but unfortunately each release there are some new packages to add to the list. Fedora 43 was particular bad with 6 new instances (three of them already fixed and a couple more being actively worked on).

Would it be possible to have a mechanism for each major release to make sure that the licensing is complete and correct? Some way of checking that the license for every package is actually included/referenced in the filesystem?

I’m not sure how this would be done. The review is a manual process and a little bit tedious - we use fossology for doing license identification which helps, but it’s far from perfect and it can’t identify gaps - that has to be done manually…line-by-line.

I’m very happy to help and contribute in any ways possible - this would definitely make my life easier and as an incentive it would improve the schedule for getting Fedora preload out the door on our platforms :slight_smile:

In case it’s useful, the list of packages I’m currently tracking are below along with BZ# (note - list reduced from actual F43 release, because some have been fixed already).

  • sqlite-libs (2418961)
  • numactl (2362726)
  • librdmacrm (2418959)
  • numad (2418962)
  • brasero (2295831)
  • shim (2315751)
  • initscripts-service (2418955 - fix built but not rolled out yet)

Let me know if any questions.

Thanks

Mark

8 Likes
3

Thanks for the list.

We need to figure out how to address this systematically so we are doing things sufficiently well and consistently for all the composed outputs and catching these problems before release of the composites. Composed/composite here meaning created from a subset collection of the binary packages (usually as part of coordinated release activities).

But first lets talk about what is sufficient versus what is ideal.
My current understanding is that it is sufficient to have 1 copy of each relevant license in a composed image. I’m not sure its understood to be required that each subpackage carry with it its own copy of the license files. In the case of librdmacrm to continue your example, my understanding is it would be sufficient to ensure that the text of the GPL-2.0-only, BSD-2-Clause and BSD-3-Clause licenses are in the composed image…assuming the rpm metadata is correct. My understanding is somewhat informed by the debian approach of using /usr/share/common-licenses/ for the canonical location for license files with I believe links into package specific directory structure as needed as a way to dedupe hundreds of the same file.

But with that said here are a couple off the top of my head straw proposals for everyone to discuss:
Straw proposal 1:
There is a need to add some automated blocker tests for this to ensure that at least one copy of the license as listed in the spec for binary packages making up a composed fedora output are included in any composed image (editions,spins,flatpaks etc…). Even better if we found a way to share this logic with downstream remixes that are composing from the Fedora collection as well so they can help catch problems as part of their release process.

Straw proposal 2:
Create license specific packages that include the license text and all subpackages depend on the packages explicitly for each relevant license. This ensures license files are installed into composites as per normal package installation mechanisms. Naively I would hope this sort of dep could be added via some rpm macro automation at rpm binary build time by mapping the license metadata to deps for the vast majority of packages.

These 2 straw proposals won’t address the line by line auditing, but that’s probably something that can be added as automation against rawhide dist-git and making sure spec file metadata matches the spdx file level hints to ensure the metadata matches the codebases making up the rpm sources.

4

Thanks Jef,

I think from our perspective (at least based on the discussions with the lawyer I do the review with) we need a way to be able to say ‘the licence for this package is here‘. It’s fine for it to be in a common-licences folder - but should probably be symlinked at that point so it’s obvious.

We do rely on that a fair bit when a license is part of the same package family. E.g. there is the abrt package which has the license, and then 13 abrt-xxx sub packages that I just say “see abrt” in my review.
The lawyer doesn’t love it…but he’s let me get away with it thus far (I hope it’s accurate…I think it is). If there was the ability to specifically call out that a sub package uses “this license” that would be really nice and I think would make checking compliance easier/safer. You just confirm that every package has a license file and have the location in the file system where it is stored?

5

The current licensing guidelines (which were, presumably, signed off by RH’s legal team) specifically says that subpackages don’t have to carry the license files if they depend on a package that contains them:

“If a subpackage is dependent (either implicitly or explicitly) upon a base package (where a base package is defined as a resulting binary package from the same source RPM which contains the appropriate license texts as %license), it is not necessary for that subpackage to also include those license texts as %license.”

Of course, the converse is that if a subpackage does not depend on a base package with the license files, it must contain the license files itself.

Just to flag it up, @mattdm opened a Quality team ticket for this and I’ve looped in dcantrell as it seems like rpminspect would be the logical place to do this. We’re following up there.

1 Like
6

Coincidentally, we discussed this topic in the Fedora Packaging Committee meeting today. @salimma is going to explore the common-licenses concept and see if we can amend things for that model for Fedora. It doesn’t help for some of these that don’t use verbatim/template licenses, but updating our policy to make things just a tiny bit easier would be nice indeed.

(Honestly, this would be nice to also crib some REUSE stuff so things like KDE are easier to ship!)

1 Like
7

Yeah, I’ll draft a Change Proposal for this next week so FESCo can discuss the scope of what licenses we can pre-ship. I envision this to work like Debian where you can just point to one of the pre-shipped files and omit shipping the text yourself; a full implementation would also include updating our linting tools to accept missing license files if all the licenses described in the spec file are known to be shipped.

8

I did license compliance in a past life and this is not sufficient as I understand things.
If it is possible to install an RPM but not have the license then you are in trouble.

See this that explains why from Adam.

9

hmm.
Maybe you should define what you mean by “possible to install” because as of right now I don’t think what you just said and what Adam said is congruent if you take into account all possible ways to install subpackages, including ways that break dependancy resolution.

10

If you can install a set of RPMs and not have the %licenese installed then you are breaking license terms typically.

What gets installed is a usually a subset of the compose and therefore a package that breaks the rules that Adam outlines allows for a Fedora package to be installed with missing license files.

12

The policy rules in place don’t cover all possible ways to install. They cover expected ways to install using the packaging dependency mechanisms. I want to be clear about the language here… “possible” versus “expected” because I think this conversation we are having right now is more about confusion over the precision of language and not about intent.

It is my current understanding that it is sufficient to rely on the packaging dependencies and address expected installation workflows that depend on package dependencies to be resolved. The existing policy Adam refers to is inline with my current understanding. My current understanding is also that it is sufficient to only need one copy of a license file installed, and that its reasonable to use the packaging dependency system to achieve that sufficient condition.

13

Yeah, and this is part of the exploration. :slight_smile:

It might be we need a notice file similar to debian/copyright (which we could generate from information in the License tag maybe?) so that the references are there.

14

So long as the deps mean that there is always a license installed when any allowed subset of a SRPM’s RPM packages are installed I think we are good.

What the OP is reporting is that there are packages that break this expectation. An allowed subset of an SRPM’s RPMs do not install a license.

So long as the deps mean that there is always a license file installed there is no reason to think about “possible” and “expected”.

15

Yes. there is a reported problem that needs to be addressed. And existing policy if followed would address it. What I’m hoping is that we can figure out a way to make it easier to test for these situations and there is maybe possible future out there where our hardware partners are collectively helping by contributing/maintaining automation tests upstream that serves their own interests.

We can’t take away their need to do audit checks downstream, because they have to cover their own liability as distributors, that’s never going to change. But hopefully there are some automation and policy improvements lurking here so we can test/catch situations earlier in the release process, that directly impact our hardware parterners. So our collective best effort results in less work overall. It does pain me that a hardware partner is doing a bit of a downstream hacky fix for things that appear to be existing project policy violations.

17

any non-Fedora Materials included as part of the install image must reside entirely within a single folder under /opt (e.g. /opt/VENDORNAME). Please note that this exception only applies to content and documentation, not code, fonts or firmware;

So, they can put the missing licenses in /opt/lenovo without needing special permission.

In general, the rule here is “when in doubt, ask the Council”.

2 Likes
18

Filed an rpminspect issue.