Conversation

Thorsten Leemhuis (acct. 1/4)

TIL: @tuxedocomputers released drivers for their machines under the , which makes it impossible for competitors and distros to ship them pre-compiled, as that license is incompatible with the 's 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#regarding-upstreaming-of-tuxedo-drivers

https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers#regarding-upstreaming-of-tuxedo-drivers

9
4
2

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).

2
1
1

@nicorikken @tuxedocomputers

unfortunate, evil, stupid, … -- not sure how I'd classify this. A bit of everything maybe.

0
0
0

@kernellogger @tuxedocomputers important reply to mention on this thread:

2
0
0

@thibaultmol @tuxedocomputers

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! 😬

1
0
0
@kernellogger @tuxedocomputers I wonder what is actually worse for customers: crappy driver release from vendors just for open-source compliance or this pseudo-open-source-move from Tuxedo which effectively blocks any community from upstreaming this code.

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.
0
1
11

@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"

3
0
0

@thibaultmol @tuxedocomputers

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.

0
0
1
@thibaultmol @kernellogger @tuxedocomputers " this license allows them to prevent from someone else" - this is exactly something they should not do. We all know open-source compliance releases have poor quality and we do not have problems with that. That's life. But what they did is:
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.
0
2
8

@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?

2
0
0

@kernellogger

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

1
0
1

@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.

1
0
0
@kernellogger @tuxedocomputers Wow, that's a new one. Is that even legal? Thumbs down for Tuxedo.
0
0
1

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 's docs means "GPLv2" (either -only or -or-later), when in fact the code is GPLv3

3
5
1
@thibaultmol @kernellogger @tuxedocomputers Unless they wrote code for something else and ported, their code is derived from GPLv2 work, and Tuxedo can't choose the licensing. What they are doing is likely not legal.
0
0
4

@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

1
0
0

@waldi thx for pointing this out, added a toot about this in a more prominent place

0
0
0

@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.

1
0
0

@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…

1
0
1

@kernellogger

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.

1
0
0

@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.

1
0
0

@thelinuxEXP

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.

CC: @fabyk @tuxedocomputers

0
0
0

@thibaultmol @kernellogger @tuxedocomputers In the current climate of companies playing licensing games, I'm just not able to assume good faith

0
0
0

@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!!

1
0
0

@herr_irrtum @waldi

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, …

0
0
0

@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).

0
0
0

@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.

1
0
0

@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.

0
0
0

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 's MODULE_LICENSE()[1] macro. 👏

https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/merge_requests/21#note_0294911d6ab1408f96fa73e062851920e16b4460

(side note: I wonder if the kernel will now taint itself as "proprietary" when loading these drivers)

CC: @waldi

2
1
0

@waldi @tuxedocomputers

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.

0
0
0

5/ TWIMC and for the record:

Werner Sembach from @tuxedocomputers *reverted* Uwe's changes that made the drivers provide the right license to the 's MODULE_LICENSE()[1] macro "until the legal stuff is sorted out":

https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/commit/a8c09b6c2ce6393fe39d8652d133af9f06cfb427

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

1
2
0

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

2
0
1

@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.

1
0
0

@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... ;-)

1
1
1

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 '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

2
1
1

@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

0
0
1
@vinzv @waldi @kernellogger For the record, that was not single mistake. Yes, FOSS community is pretty sensitive about the licensing, but you did deserve the heat.
1
0
0

@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

2
0
0

@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.

1
0
0

@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/

0
0
0
@vinzv @waldi @kernellogger Your GPLv3 modules are GPL violation, plain and simple. Module loader would catch that, but you lied in MODULE_LICENSE(). Them people pointed out your lies, so you fixed MODLUE_LICENSE() not to lie... and then tried to reintroduce the lie, with another lie about "pending legal review" or some such ****. Public apology would be good. Complaining about the heat is not.
2
0
0

@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.

1
0
0

@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.

1
0
0
@vinzv @waldi @kernellogger Actually, I did not call it ****, I called it ****. And it is pretty clear to me Tuxedo knowingly lied, trying to circumvent MODULE_LICENSE() check, when they already knew licensing was not compatible. And in process, they violated rights of existing kernel contributors.

Who are you, what is your relationship in Tuxedo (are you speaking for them?) and do you believe you know about copyright law?
1
0
0
@vinzv @waldi @kernellogger I may have the timeline wrong. But I'm pretty sure you made _two_ mistakes years ago: first, you tried to mess with kernel development process by choosing incompatible license. Second, you did it in a way that is actually illegal. :-(
0
0
0

@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!

0
0
1

7/ To follow up once more, likely for the last time:

Werner Sembach relicensed the last of the formally GPL3+ed drivers from @tuxedocomputers to 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

0
2
0

@thelinuxEXP @fabyk @kernellogger Why DKMS? Source code is on github. Distros can just compile for their version of kernel without DKMS hackery.

1
0
0

@uis @thelinuxEXP @fabyk

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.

0
0
0

@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.

1
0
0

@uis

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.

0
0
0