Unfortunately, it turns out that even after removal of the firmware/ tree, a few nonfree files still remain in the Linux kernel sources. Debian provides a list: https://salsa.debian.org/kernel-team/linux/blob/master/debian/copyright (see "Files-Excluded:" there). Especially, the following files from that list look like they cannot even be redistributed: - arch/powerpc/{sysdev,platforms/8xx}/micropatch.c: Upstream says in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43db76f41824aea0a31f817e69ad304a95cf068a: "The binary code is public. The source is not available." This isn't a license, and it is not clear what "public" even means (presumably, that it was published?). In any case, the file is labelled as GPL-2 and the source code is not available, which implies that it cannot be redistributed at all. - drivers/media/usb/dvb-usb/af9005-script.h: The comment at top of the file says: "File automatically generated by createinit.py using data extracted from AF05BDA.sys (windows driver)". The file is labelled as GPL-2, which is doubtful. Even if it was correct, the missing source code means again that the file cannot be redistributed. - drivers/net/appletalk/cops_ffdrv.h, - drivers/net/appletalk/cops_ltdrv.h: "This material is licensed to you strictly for use in conjunction with the use of COPS LocalTalk adapters." which doesn't grant the right to redistribute. So, either "linux-firmware" should be added to LICENSE, which may cause problems for RelEng. Or, these files should be removed before installation (and the corresponding options in Kconfig disabled).
Adding releng for input if adding "linux-firmware" to sys-kernel/*-sources LICENSE would really cause some problems. @ Ulm: Did you already check https://packages.debian.org/sid/linux-source if Debian still ships these files or not?
This is only relevant for Releng for stages that build kernels, so for livecd-stage{1,2} and stage4 targets. We currently have in the releng repo the following config for licenses: $ cat releases/weekly/portage/isos/package.license/package.license # Allow linux-firmware and other required packages in @BINARY-REDISTRIBUTABLE # license group */* @BINARY-REDISTRIBUTABLE which is used by the following specs: $ grep -i portage releases/weekly/specs/amd64/installcd-stage* releases/weekly/specs/amd64/installcd-stage1.spec:portage_confdir: @REPO_DIR@/releases/weekly/portage/isos releases/weekly/specs/amd64/installcd-stage2-minimal.spec:portage_confdir: @REPO_DIR@/releases/weekly/portage/isos $ grep -i portage releases/weekly/specs/amd64/stage4-* releases/weekly/specs/amd64/stage4-minimal.spec:portage_confdir: @REPO_DIR@/releases/weekly/portage/isos releases/weekly/specs/amd64/stage4-nomultilib-minimal.spec:portage_confdir: @REPO_DIR@/releases/weekly/portage/isos So as long as the linux-firmware license is covered by the @BINARY-REDISTRIBUTABLE, we should be able to build the kernels.
(In reply to Thomas Deutschmann from comment #1) > @ Ulm: Did you already check https://packages.debian.org/sid/linux-source if > Debian still ships these files or not? I have checked, these files are _not_ present in the source tarball that is included in their linux-source-5.2_5.2.9-2_all.deb package (.tar.xz inside .tar.gz inside .deb ...). If we apply the same criteria that we apply for sys-kernel/linux-firmware, then the ebuild shouldn't install these files, or install them only with a USE flag (like "unknown-license" in linux-firmware). Not sure if it's worth the complexity, given that it's only a handful of files, and these drivers are for legacy hardware. (In reply to Jorge Manuel B. S. Vicetto from comment #2) > So as long as the linux-firmware license is covered by the > @BINARY-REDISTRIBUTABLE, we should be able to build the kernels. Unfortunately, it won't. These files are not distributable, so they aren't covered by @BINARY-REDISTRIBUTABLE.
Also, the files mentioned in comment #0 are already listed in https://wiki.debian.org/KernelFirmwareLicensing#Inventory which is for 2.6.32 (from 2009). I wonder if nobody has reported this to Linux upstream in all these years, or if upstream doesn't care.
ping
(In reply to Ulrich Müller from comment #5) > ping It's on my todo list
(In reply to Mike Pagano from comment #6) > (In reply to Ulrich Müller from comment #5) > > ping > > It's on my todo list Ulm, Is your expectation that I will go through every file to determine if something is non-free ?
(In reply to Mike Pagano from comment #7) > Is your expectation that I will go through every file to determine if > something is non-free ? No, but the list in comment #0 (as well as the Debian list of excluded files) is a guideline what files should be excluded from installation. IMHO, as a bare minimum the following two files should be excluded: - drivers/net/appletalk/cops_ffdrv.h - drivers/net/appletalk/cops_ltdrv.h For most of the rest, their status depends on the interpretation whether they qualify as source code. Upstream seems to think that it's fine to distribute them under the GPL, while Debian excludes them.
I'm going to ask the trustees to consider this request and if getting some legal help is warranted here. I know we have some funds currently. Otherwise, I don't feel qualified to make legal decisions as I am not a expert in this field.
(In reply to Mike Pagano from comment #9) > I'm going to ask the trustees to consider this request and if getting some > legal help is warranted here. I know we have some funds currently. > > Otherwise, I don't feel qualified to make legal decisions as I am not a > expert in this field. First, I am not opposed to seeking legal counsel for things, but it is not warranted in this case IMHO. The easy solution here is to accept what Debian has done and the research Ulm has completed adds additional merit to the Debian decision. These files do not look terribly important from a general/mainstream perspective either. I would advise a technical solution be implemented to remove the files or put them behind a USE flag with license acceptance (as Ulm suggested).
(In reply to Ulrich Müller from comment #0) > Unfortunately, it turns out that even after removal of the firmware/ tree, a > few nonfree files still remain in the Linux kernel sources. Debian provides > a list: > https://salsa.debian.org/kernel-team/linux/blob/master/debian/copyright (see > "Files-Excluded:" there). > > Especially, the following files from that list look like they cannot even be > redistributed: > > - arch/powerpc/{sysdev,platforms/8xx}/micropatch.c: > Upstream says in > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ > ?id=43db76f41824aea0a31f817e69ad304a95cf068a: "The binary code is public. > The source is not available." This isn't a license, and it is not clear what > "public" even means (presumably, that it was published?). In any case, the > file is labelled as GPL-2 and the source code is not available, which > implies that it cannot be redistributed at all. It looks like there was some very recent chatter (literally last week) on this file on the GNU Linux Libre ML: https://lists.nongnu.org/archive/html/gnu-linux-libre/2021-08/msg00011.html https://lists.nongnu.org/archive/html/gnu-linux-libre/2021-09/msg00000.html (In reply to Ulrich Müller from comment #4) > Also, the files mentioned in comment #0 are already listed in > https://wiki.debian.org/KernelFirmwareLicensing#Inventory which is for > 2.6.32 (from 2009). > > I wonder if nobody has reported this to Linux upstream in all these years, > or if upstream doesn't care. Based on the ML link above, perhaps this question should be raised with the Linux Libre folks? It sounds like the micropatch.c file is going to be addressed shortly, but they might be the better source to ask about the other files. As Alexandre Oliva is an upstream kernel maintainer, he probably has the ability to get any non-conforming files evicted from the mainline tree and over to linux-firmware.
(In reply to Mike Pagano from comment #9) > I'm going to ask the trustees to consider this request and if getting some > legal help is warranted here. I know we have some funds currently. > > Otherwise, I don't feel qualified to make legal decisions as I am not a > expert in this field. So I see three issues here. (1) Some files appear to have a non-free license and its unclear if we should distribute those files. I think we should not distribute those files (e.g. the appletalk driver.) (2) Some files are labeled GPL, but we are suspicious of the labels. I think we should distribute those files and investigate the labeling upstream; provided we can fulfill the license the code has (e.g. we must be able to follow the GPL.) (3) Some files are labeled GPL, but we cannot follow the GPL (e.g. because no source is available.) In practice on the face applying these 3 rules it means we cannot distribute any of the files in the list.
currently, deblob option is working but not enabled for gentoo-sources, only for rt-sources deblob is cleaning linux kernel non-free sources and making it not only non free but also GNU FSDG-compliance. There is already many discussions about kernel non-free sources I suggest the linux-libre mailing list as is the active list about libre-kernel http://www.fsfla.org/pipermail/linux-libre/ For example, this is the review on Linux kernel 5.14 http://www.fsfla.org/pipermail/linux-libre/2021-August/003439.html
Sorry I typo "and making it not only free but also GNU FSDG-compliant"
This bug isn't about deblob but about removal of a few non-distributable files. (In reply to Alice Ferrazzi from comment #13) > deblob is cleaning linux kernel non-free sources and making it not only non > free but also GNU FSDG-compliance. It also makes the kernel unusable for many users, because it removes (free!) code for firmware loading that is needed on many systems, e.g. for mitigation of Spectre/Meltdown CPU vulnerabilities.
(In reply to Ulrich Müller from comment #15) > This bug isn't about deblob but about removal of a few non-distributable > files. > > (In reply to Alice Ferrazzi from comment #13) > > deblob is cleaning linux kernel non-free sources and making it not only non > > free but also GNU FSDG-compliance. > > It also makes the kernel unusable for many users, because it removes (free!) > code for firmware loading that is needed on many systems, e.g. for > mitigation of Spectre/Meltdown CPU vulnerabilities. Yes, you are right. I was not advocating deblob as a solution of the problem, but as a reference tool for checking what non-free script there are on the kernel Yes, is also removing some loader that we don't want to remove. But I think as a reference tool and discussion point is still useful.
*** Bug 889036 has been marked as a duplicate of this bug. ***
Reassigning to licenses@ as discussed in today's trustees meeting: <@ulm> bug 693288 <@dilfridge> that feels a bit like an OPP <@ulm> this was filed by me, but I think it's not really actionable <@ulm> reassign to kernel, or to licenses? <@dilfridge> licenses <@ulm> basically it's an upstream issue and there's nothing we can do <@ulm> certainly we won't stop mirroring kernel sources <@ulm> any objections against reassigning to licenses@ <@soap> nope
