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
2/ side note: wondering if they require a CLA that allows re-licensing for any meaningful contributions, otherwise they can not do so (and wouldn't be allowed to ship the drivers pre-compiled themselves).
@kernellogger
That is unfortunate. Relevant license reference: https://www.gnu.org/licenses/gpl-faq.html#v2v3Compatibility
@tuxedocomputers
unfortunate, evil, stupid, … -- not sure how I'd classify this. A bit of everything maybe.
@kernellogger @tuxedocomputers important reply to mention on this thread:
Yeah, it's well known that Open Source has always works so well, because it allows authors to control their code.
Ohh, wait, no! It was the other way around: Open Source works so well because people do not have control and thus are able to bring it to levels that seemed unreachable earlier! 😬
@kernellogger @tuxedocomputers devils advocate: They know their code isn't good enough to be included in the kernel itself, so they want to rewrite before that happens. this license allows them to prevent from someone else putting the code in and then going "wow, this toxedo code sucks" and then tuxedo having to go "well yeah, it wasn't ready for kernel merging yet"
I'd consider that a lame excuse; just put a "we know the code does not meet the standards upstream expects and are working on a cleaner driver we plan to upstream" into the README while releasing it as GPLv2 – nearly everybody would understand and those who do not fall into the "you sometimes just have to ignore some people" category.
But then others could at least easily borrow parts of the code if they upstream improved or independently developed drivers.
@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?
And they tell the kernel they are GPLv2 by setting the module license to "GPL":
MODULE_LICENSE("GPL")
Rules are listed here: https://docs.kernel.org/process/license-rules.html#id1
@waldi rules say "GPL == GPLv2", which is not a case. Wondering if this is by accident or on purpose. Worth submitting as a bug IMHO.
3/ I got even stranger: it seems @tuxedocomputers provided the wrong license to MODULE_LICENSE()[1] macro either by accident or on purpose. 🧐
@waldi pointed that out earlier today elsewhere in this thread; PWM maintainer Uwe Kleine-König a little later submitted a bug report asking this to be fixed:
https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/merge_requests/21
[1] they proclaim it's GPL, which according to the #Linux #kernel's docs means "GPLv2" (either -only or -or-later), when in fact the code is GPLv3
@kernellogger A typical case of Hanlon's razor.
I would assume on purpose. You can't actually build drivers for much low level stuff anymore, without requiring GPL-only stuff in the kernel. NVIDIA was caught a lot of times trying to circumvent those GPL-only restrictions.
Dony by someone: https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/merge_requests/21
@waldi thx for pointing this out, added a toot about this in a more prominent place
@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.
@Conan_Kudo @thelinuxEXP @fabyk @tuxedocomputers
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…
This thread is the second time when I heard about @tuxedocomputers at all.
First was "we will make Linux powered SnapDragon laptop" news post.
Interesting ways to get popular for nearly unknown brand.
@hrw at least in Germany they hardly are unknown.
If you are in the market for laptops with pre-installed Linux here, you probably have heard of them.
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.
@thibaultmol @kernellogger @tuxedocomputers In the current climate of companies playing licensing games, I'm just not able to assume good faith
@kernellogger@fosstodon.org @tuxedocomputers@linuxrocks.online @waldi@chaos.social
Hmm, I was seriously thinking about buying my next laptop from them, after they finally started to offer AMD based models (but an ARM based one would be even more tempting!). The idea was to use the laptop with my favorite distro and ignore, what they ship it with.
But when I read this:
"makes it impossible for competitors and distros to ship them pre-compiled, as that license is incompatible"
Doesn't that imply that I can't (easily) use their own driver's on their own laptop, as soon as I use my freedom to choose another Linux distro but theirs?
THAT'S SO ABSURD!!
Well, it does not imply that in general, as using these drivers and redistributing them are different things; but yes, with a different licence other distros could make things more easy and reliable for the users.
If it implies that when it comes to "easily" depends on a lot of factors: what coud consider easy, which distro you use, and how well those drivers and/or @tuxedocomputers supports that distro, …
@mxk I tend to ignore hardware vendor provided images.
Distributions work on getting things done so I use what they provide and reinstall any computer I get (if it has to run Linux).
@kernellogger IANAL, but I don't think a CLA should make much of a difference for distributing binaries. It would allow them to avoid the problematic combination of GPL v3 + GPL v2-only, but instead they would have proprietary + GPL v2-only, which isn't any better. To me it looks more or less the same as the old problem of shipping pre-compiled proprietary graphics drivers from Nvidia or whatever.
@caoimhin yeah, you might be right, for distributing it might make no difference, unless they use a GPLv2 compatible license there, which they likely would not, as then the cat would be out of the bag.
4/ TWIMC and for the record:
Werner Sembach from @tuxedocomputers now merged Uwe's proposed changes that make the drivers provide the right license to the #Linux #kernel's MODULE_LICENSE()[1] macro. 👏
(side note: I wonder if the kernel will now taint itself as "proprietary" when loading these drivers)
CC: @waldi
yeah, I expect that, but you know how it is with things you haven't tried yourself: better be careful with your words.
But you are right. Edited the toot to better express what I meant.
5/ TWIMC and for the record:
Werner Sembach from @tuxedocomputers *reverted* Uwe's changes that made the drivers provide the right license to the #Linux #kernel's MODULE_LICENSE()[1] macro "until the legal stuff is sorted out":
Wondering why that happened – did they only notice now that the drivers do not compile any more because they use GPL-onlyed symbols, which are inaccessible for any non-GPLv2-compatible module?
CC: @waldi
6/ To follow up:
There are now patches under discussion to '"teach the module loader that these modules [from @tuxedocomputers ] are proprietary despite their declaration to be GPLv2 compatible "until the legal stuff is sorted out". "'
https://lore.kernel.org/all/20241114103133.547032-4-ukleinek@kernel.org/t/#u
CC: @waldi
@kernellogger @tuxedocomputers What a shit show.
I think this can only go two ways now:
The modules will be non-gpl restricted, either be setting the correct license or by force of the module loader, and they have to cope with that.
They quickly announce the re-licensing if the code that the company owns of those drivers and the commitment to get approval from the rest of the contributors within a few weeks.
@waldi @kernellogger I'm just coming from an internal meeting on that topic.
The whole story is pretty heated, which is both unfortunate and unnecessary. I mean, hey, we made a mistake in the past and now are confronted to get called liars. A bit unfair, eh?
However, we just decided to re-license TUXEDO drivers from GPLv3 to GPLv2. Checking code and asking contributors for agreement will take time, so please bear with us - and maybe let go on the heated discussions... ;-)
6/ To follow up once more:
@tuxedocomputers relicensed all full inhouse code in their driver package to GPLv2+ : https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/commit/dd34594ab880ed477bb75725176c3fb9352a07eb 👍
They are working on doing the same for the remaining drivers.
They also submitted a updated version of the patchset making the #Linux #Kernel's module loader treat some of the modules as proprietary; the list of modules handled that way is much shorter now:
https://lore.kernel.org/all/20241115130139.1244786-1-wse@tuxedocomputers.com/
CC: @waldi
@kernellogger @tuxedocomputers @waldi that's pretty cool actually
i guess they technically were right that the relicensing can't happen overnight, but they are pretty close
@pavel Blaming us to lie intentionally (!sic) in a commit message against better knowledge has nothing to do with sensitivity or deserved heat.
@waldi @kernellogger
@vinzv @pavel @kernellogger Could you please quote what you mean? I only see "lie" in regard to the MODULE_LICENSE settings. So the code was blamed, not a you.
@waldi @pavel @kernellogger "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."
" * Tuxedo distributes their kernel modules under GPLv3, but intentially lies in their MODULE_LICENSE() calls."
See https://lore.kernel.org/all/20241114103133.547032-6-ukleinek@kernel.org/
@pavel @waldi @kernellogger You have the timeline wrong:
First we made a mistake, years ago. This only came up by a merge and the discussion. We then realized that this merge would be illegal as it would not respect the rights of external contributors and would be against the licence chosen in the past. So we reverted that and made it clear that things need to be sorted out.
I don't see any lies in there. The whole story is transparent there.
@pavel @waldi @kernellogger And "pending legal review" is no shit (as you call it), it's the absolute bare minimum necessary and was done within working day!
Don't get me wrong, I understand your (the kernel devs) position and can live with harsh calls there. But calling us publicly liars is just plain simply wrong and nothing we will apologize for.
@pavel @waldi @kernellogger Okay, I tried to explain our point of view and made clear, we feel treated unfair by a) allegations made b) in public with the c) to be expected outcome. And I think that came through pretty clearly, while you still have a different opinion and haven't moved in that regard.
So, I don't see this discussion leading to anything and I'll give up on it, yet find it disappointing. If you still want to talk about it, I'm of course open to that.
Have a nice weekend!
7/ To follow up once more, likely for the last time:
Werner Sembach relicensed the last of the formally GPL3+ed #Linux #kernel drivers from @tuxedocomputers to #GPLv2 about an hour ago after all external contributors have agreed to that move. 👏
https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/commits/main
Cc: @waldi #LinuxKernel
@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.
@kernellogger I don't understand how can it prevent anyone from distributing modules. Sure, you can't mix their sources, but you can just distribute them as separate package.
separate package might not be enough if you distribute the pieces together; separately might be something different, but you might violate the GPLv3 then by linking the modules to code that is not GPLv3 compatible, not sure.
IOW: better ask lawyers, this is tricky.