Recent searches
Search options
TIL: @tuxedocomputers released #Linux #kernel drivers for their machines under the #GPLv3, which makes it impossible for competitors and distros to ship them pre-compiled, as that license is incompatible with the #LinuxKernel's #GPLv2 only license.
They did this purposely, allegedly to "keep control of the upstream pacing" – and want to re-license the code while upstreaming.
https://github.com/tuxedocomputers/tuxedo-keyboard/issues/61
https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/issues/137
https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/issues/138
@kernellogger @tuxedocomputers @thelinuxEXP something for your vlog?
@fabyk @kernellogger @tuxedocomputers Maybe, I’ll admit this doesn’t seem like an issue: they relicense everything when upstreaming, so there’s no incompatibility, anyone can still grab the code and build the DKMS drivers package to add it to another distro (done in a COPR repo for Fedora, IIRC), and all the code of these drivers is open source.
Standard practice for stuff they wouldn’t be accepted as-is in the kernel?
@thelinuxEXP @fabyk @kernellogger @tuxedocomputers It is incompatible even for regular redistribution by everyone. And nobody can help them upstream the drivers because the code is effectively radioactive.
It's absolutely a terrible move and it should be fixed.
it's just a detail, but imagine how different the Linux world would look like if you for each machine where you install Arch/Debian/Fedora/… on would first have to hunt down a proper driver package from official or unofficial sources while praying on each kernel update that things do not fail because some API considered kernel-intenal changed and broke compilation with DKMS…
BTW, to get an impression how to hard this stuff is with DKMS and how it easily it can fail for users, just look here: https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/issues/209
That's another reason why I would avoid using words like "Standard practice", as it gives the wrong impression to people that are not aware of these things. Not to mention that this license trick is hardly standard, as @Conan_Kudo already pointed out.
They don't care about proprietary modules that don't respect the users freedom and don't enforce their license against those, but when it comes to free software modules, that are under a free software license that does a better job defending the users freedom, suddenly they're ready to enforce their license?
No matter what some documentation says, MODULE_LICENSE("GPL") can only legally mean any version of the GNU General Public License, as per the GPLv2;
Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.
Too bad not actually reading the GPLv2 seems very common.
For GPLv2-only, you *must* write; MODULE_LICENSE("GPLv2-only").
For GPLv2-or-later, you *must* write; MODULE_LICENSE("GPLv2-or-later").
Of course the licensing macro won't accept either?
@thelinuxEXP @fabyk @kernellogger Why DKMS? Source code is on github. Distros can just compile for their version of kernel without DKMS hackery.
this is irrelevant by now, as the code was GPLv2ed, but FWIW:
some distros do not want to go there, as quite a few people (e.g. some users and developers) believe it violates the GPLv2 and thus to not want to go there.