A new patch series posted today to the Linux kernel mailing list would block kernel modules/drivers from TUXEDO Computers from accessing GPL-only symbols in the kernel.
TUXEDO Computers maintains a set of kernel drivers currently out-of-tree for their various laptops for additional functionality around power profiles, keyboard backlight controls, WMI, sensor monitoring, the embedded controller, and other functionality. They have said they want to eventually mainline these drivers but in the name of allowing for rapid hardware support they maintain them out-of-tree and ship them with their Ubuntu-based TUXEDO OS and also have the driver sources available via GitLab.
The issue at hand though is that these kernel drivers marked as GPLv3+ and that conflicts with the upstream Linux kernel code licensed as GPLv2. There was a commit to change the driver license from GPLv3 to GPL(v2) but was reverted by TUXEDO Computers on the basis of “until the legal stuff is sorted out.”
Thus Linux developer Uwe Kleine-König took to drafting this set of patches to prevent these TUXEDO GPLv3 drivers from accessing the GPL (v2) only kernel symbols:
“Tuxedo licenses the modules used on their hardware under GPLv3+, to “keep control of the upstream pacing” – and want to re-license the code while upstreaming.
They were asked to then at least not use MODULE_LICENSE(“GPL”) which declares compatibility to the kernel’s GPLv2. They accepted the pull request and shortly after reverted the change and so continue to lie about the license.
So teach the module loader that these modules are proprietary despite their declaration to be GPLv2 compatible “until the legal stuff is sorted out”.”
The patches check for the gxtp7380, ite_8291, ite_8291_lb, ite_8297, ite_829x, stk8321, tuxedo_compatibility_check, tuxedo_io, tuxedo_nb02_nvidia_power_ctrl, tuxedo_nb04_keyboard, tuxedo_nb04_wmi_ab, tuxedo_nb04_wmi_bs, tuxedo_nb04_sensors, tuxedo_nb04_power_profiles, tuxedo_nb04_kbd_backlight, tuxedo_nb05_keyboard, tuxedo_nb05_kbd_backlight, tuxedo_nb05_power_profiles, tuxedo_nb05_ec, tuxedo_nb05_sensors, tuxedo_nb05_fan_control, tuxi_acpi, tuxedo_tuxi_fan_control, clevo_wmi, tuxedo_keyboard, clevo_acpi, and uniwill_wmi kernel modules and will taint if they are present.
In response to these patches, Werner Sembach of TUXEDO Computers commented on the LKML thread:
As already being implied by that commit message, this is sadly not an issue that can be sorted out over night.
We ended up in this situation as MODULE_LICENSE(“GPL”) on its own does not hint at GPL v2, if one is not aware of the license definition table in the documentation.
It was and is never our intention to violate neither GPL v2 nor GPL v3 and we are working on it.
…
I can not tell anything else than I wrote above so I probably can’t gain your trust that it was an honest mistake.Thing is we are working on rewriting the driver bit by bit directly for upstream under GPL v2, e.g.
https://lore.kernel.org/all/[email protected]/And we don’t stop anyone else from doing so and actively involve ourself in the process, giving advice where we can from our experience with the devices, e.g. https://github.com/Wer-Wolf/uniwill-laptop/issues/1
And tuxedo-drivers got code in the past from external contributors under GPL v3 that also weren’t aware of the correct definition of MODULE_LICENSE(“GPL”) which needs to be sorted out.
And no tuxedo-drivers module would get accepted upstream as is at the moment, because the focus of the driver package is mainly to get support for new devices out as quickly as possible, while upstream rightfully has way stricter guidelines on code quality (not implying that tuxedo-drivers has bad code quality, it’s a spectrum after all).
What I want to say: If the end goal is upstream support for our devices nothing is speed up by the relicensing, arguably it’s slowed down because someone now has to sort out legal stuff. If you want to take on the actual coding work yourself, please do so, I will give you advice as I did with Armins uniwill laptop driver and several times on the mailing list.
We’ll see if/when these patches for taining on the TUXEDO drivers get picked up for the mainline kernel and how long until the TUXEDO drivers end up being cleaned up or rewritten for mainline inclusion.
