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
2/ side note: wondering if they require a CLA that allows re-licensing for any meaningful contributions, otherwise they can not upstream contributed code (and wouldn't be allowed to ship the drivers pre-compiled themselves).
3/ It got even stranger: it seems @tuxedocomputers provided the wrong license to the #LinuxKernel's 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
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 suspect the kernel will now taint itself as "proprietary" when loading these drivers, but haven't tried)
CC: @waldi
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 upstream to '"teach the [#Linux #Kernel's] 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 #LinuxKernel
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
7/ To follow up once more, likely for the last time:
Werner Sembach relicensed the last of the formerly 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
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.
@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).
@hrw @kernellogger @tuxedocomputers can't agree on the point of TuxedoComputers being utterly unknown. They were doing a decent amount of rounds on the internet. I would speculate that they may be a bit less known in the US, due to being a German brand, but nothing less.
@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, …
@kernellogger @herr_irrtum @waldi @tuxedocomputers also, having out-of-tree modules and in time, upstreaming them while making out-of-tree copy absolete is considered a normal practice, isn't it?
Having in mind that Tuxedo do seem to contribute to the kernel and various drivers, so I'm not sure if there are some alarm bells in order.
Examples of upstreaming, bugfixing, etc:
https://lore.kernel.org/linux-leds/ZSk16iTBmZ2fLHZ0@duo.ucw.cz/T/#md6f8e97f53bd385fffd0f7134bb6ae770e1811c2
https://lore.kernel.org/all/20241029151653.80726-1-wse@tuxedocomputers.com/
https://lore.kernel.org/all/41c1c88a-b2c9-4c05-863a-467785027f49@tuxedocomputers.com/
etc
@kernellogger @herr_irrtum @waldi @tuxedocomputers also, from the last year:
> "The first time I submit a whole module, so please let me know if it made any
mistakes e.g. I'm unsure if I need add myself explicitly as a maintainer, if
MODULE_AUTHOR has to be a human, or if i have to split this up into smaller junks.
...
...
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
...
"
Yet, again, I would not expect any foul play Just learning. And new contributors is happiness, right? :}}}
@KasTasMykolas@river.group.lt @kernellogger@fosstodon.org @waldi@chaos.social
Thanks Kas Tas for these insights. I should have considered my tone a bit – it's not given, and Kernellogger himself did mention it... it's not given that there is an "evil" plan behind all this.
I hope @tuxedocomputers@linuxrocks.online receive those concerns and find a wise way to deal with this.
I didn't want to start a witch hunt (and surely Thorsten even less so, just raising awareness) but yes, I wasn't amused when writing my first comment, and I'm still not happy about this situation.
@herr_irrtum @tuxedocomputers @waldi @kernellogger well, I believe that none of us is happy about this... situation :) will see how this unroll in the nearest future. Because raised issues and discussion requires some action.
And thanks for pitching in to put some pressure and raising awareness! ^_^
@kernellogger The one thing is a clearly communicated decision, disregarding if you like it or not.
The other thing looks just like a small mistake. No big deal to fix that.
And nothing "strange" from my POV.
@kernellogger @tuxedocomputers Of course it will taint itself.
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.
@kernellogger
What a shit show!
Get this sorted out! It only hurts your reputation!
@musicmatze Whoa... harsh words for a thing that's obviously work in progress. I mean, sure, the whole story is a bit unfortunate. But wouldn't it be fair to give at least a few days time, especially looking at the commit message?
@vinzv where's the problem with working in a proper, sane way in the first place?
@musicmatze Well... the "problem" is that it's human beings working over here as well.
@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... ;-)
@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.
Who are you, what is your relationship in Tuxedo (are you speaking for them?) and do you believe you know about copyright law?
@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!
@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
@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.
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 I'm confused what they really 'gain' from doing this (using GPLv3) , it's weird yeah
1. Release poor quality code.
2. Restrict community rights of improving it and bringing upstream.
That's a big no-go, big NAK for Tuxedo. Interesting twist, how one can release something open-source but not in open-source spirit.
@thibaultmol @kernellogger @tuxedocomputers In the current climate of companies playing licensing games, I'm just not able to assume good faith
Let's recap what Tuxedo said:
> We do not plan to relicense the tuxedo-drivers project directly as we want to keep control of the upstream pacing,
This is absolutely terrible move, restricting community and customers from working upstream. Kind of what proprietary company would like to do... Bleh, just choose other laptops.
@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.
@thelinuxEXP @fabyk @kernellogger Why DKMS? Source code is on github. Distros can just compile for their version of kernel without DKMS hackery.