The Latin American Free Software Foundation has published a fully free version of the Linux kernel 6.12 \u2014 Linux-libre 6.12-gnu, cleaned of firmware and driver elements containing non-free components or code sections restricted by the manufacturer. Additionally, Linux-libre disables kernel features for loading external non-free components not included with the kernel and removes references to the use of non-free components from the documentation. <\/p>\n
To clean the kernel of non-free parts, the Linux-libre project has created a universal shell script that contains thousands of templates to identify the presence of binary inserts and exclude false positives. Ready-to-download patches created based on the use of the aforementioned script are also available. The Linux-libre kernel is recommended for use in distributions that meet the Free Software Foundation's criteria for building fully free GNU\/Linux distributions. For example, Linux-libre is used in such distributions as Dragora Linux, Trisquel, Dyne:Bolic, gNewSense, Parabola, Musix, and Kongoni. <\/p>\n
The Linux-libre 6.12-gnu release adds code for cleaning blobs in drivers for the SoC CPM\/QE QMC, wireless chips Realtek 8852BE-VT, bluetooth adapters Amlogic, network adapters amcc qt2025, sensors aw96103\/aw96105, and TI TLV320AIC31XX codecs. Additional blob cleaning has been performed in drivers for Renesas and Intel ISH (Integrated Sensor Hub) HID xHCI controllers. The code for removing blobs in drivers and MHI PCI host subsystems, Adreno 620\/621, r8169, Qualcomm q6v5 remoteproc, rtw8852c, rtw8922a, as well as in dts files for ARM54 chips TI PRU and Qualcomm, has been updated. Cleaning of drivers for wireless cards ks7010 and the Intel SkyLake audio subsystem has been discontinued, as these drivers have been removed from the kernel. <\/p>\n
It is noteworthy that one of the drivers was found in the source texts containing executable object code generated from unpublished source texts and embedded as a sequence of hexadecimal numbers. The problematic driver is not explicitly named, but based on the changes, it refers to the presence of shader microcode in the file gfx_v9_4_3_cleaner_shader.h included in the AMDGPU driver. The first such insertion was identified in kernel 6.11 and subsequently proposed for removal by one of the developers, as the source texts were not provided (resulting in a situation where a program licensed under GPL was only available in binary form). However, in kernel 6.12, the specified binary code was retained, and another similar insertion was added to the same driver. <\/p>\n
Additionally, the announcement of Linux-libre 6.12 mentions two more events: <\/p>\n
It is noted that Tuxedo has long offered to change the license for its drivers, but continued to provide code under GPLv3 while indicating in the driver code the macro \u2018MODULE_LICENSE(\u2018GPL\u2019)\u2019 instead of \u2018MODULE_LICENSE(\u2018GPL v3\u2019)\u2019 to gain access to all kernel subsystems. Tuxedo has acknowledged the criticism and changed the license for part of its drivers to GPLv2+. This change applies to the drivers gxtp7380, ite_8291, ite_8291_lb, ite_8297, ite_8297, stk8321, tuxedo_compatibility_check, tuxedo_nb02_nvidia_power_ctrl, and tuxedo_tuxi. More than a dozen drivers have not yet been relicensed as changing the license for them requires the consent of third-party developers. <\/p>\n
The representative of Tuxedo explained that using 'MODULE_LICENSE(\"GPL\")' instead of 'MODULE_LICENSE(\"GPL v3\")' is due to the lack of clear explanations in the kernel documentation, stating that the marker 'GPL' cannot be used for the GPLv3 license. He also mentioned that the company intends to submit its drivers to the mainline of the Linux kernel and is working on completely rewriting them under the GPLv2 license, taking into account the requirements for kernel components. <\/p>\n
According to the maintainer of Linux-libre, the kernel should not infringe on users' rights to refuse unverified proprietary firmware and microcode on their own devices. Discussions about vulnerabilities should be tied to specific fixes in particular versions of firmware, rather than labeling any systems without the latest microcode as vulnerable, regardless of whether vulnerabilities manifest in that system and whether the updated firmware includes vulnerability fixes. <\/ul>\n