Conversation

Notices

1. Embed this notice
   Thorsten Leemhuis (acct. 1/4) (kernellogger@fosstodon.org)'s status on Monday, 04-Nov-2024 17:00:43 JST Thorsten Leemhuis (acct. 1/4)

   • TUXEDO Computers

   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#regarding-upstreaming-of-tuxedo-drivers

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

   • Krzysztof Kozlowski likes this.
   • Embed this notice
     Krzysztof Kozlowski (krzk@social.kernel.org)'s status on Monday, 04-Nov-2024 17:04:16 JST Krzysztof Kozlowski

     in reply to

     • TUXEDO Computers
     @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.
   • Embed this notice
     Krzysztof Kozlowski (krzk@social.kernel.org)'s status on Monday, 04-Nov-2024 17:41:22 JST Krzysztof Kozlowski

     in reply to

     • TUXEDO Computers
     • Thibaultmol 🌈
     @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 by 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.
   • Embed this notice
     Thibaultmol 🌈 (thibaultmol@en.osm.town)'s status on Monday, 04-Nov-2024 17:41:23 JST Thibaultmol 🌈

     in reply to

     • TUXEDO Computers

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

   • Embed this notice
     Thorsten Leemhuis (acct. 1/4) (kernellogger@fosstodon.org)'s status on Monday, 04-Nov-2024 17:41:24 JST Thorsten Leemhuis (acct. 1/4)

     in reply to

     • TUXEDO Computers
     • Thibaultmol 🌈

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

   • Embed this notice
     Thibaultmol 🌈 (thibaultmol@en.osm.town)'s status on Monday, 04-Nov-2024 17:41:25 JST Thibaultmol 🌈

     in reply to

     • TUXEDO Computers

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

   • Embed this notice
     Thorsten Leemhuis (acct. 1/4) (kernellogger@fosstodon.org)'s status on Wednesday, 06-Nov-2024 23:38:24 JST Thorsten Leemhuis (acct. 1/4)

     in reply to

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

   • Embed this notice
     Thorsten Leemhuis (acct. 1/4) (kernellogger@fosstodon.org)'s status on Wednesday, 06-Nov-2024 23:38:24 JST Thorsten Leemhuis (acct. 1/4)

     in reply to

     • TUXEDO Computers
     • waldi

     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

     Haelwenn /элвэн/ :triskell: and Krzysztof Kozlowski like this.
   • Embed this notice
     Pavel Machek (pavel@social.kernel.org)'s status on Wednesday, 06-Nov-2024 23:38:30 JST Pavel Machek

     in reply to

     • TUXEDO Computers
     • Thibaultmol 🌈
     @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.
     Krzysztof Kozlowski likes this.
   • Embed this notice
     Thorsten Leemhuis (acct. 1/4) (kernellogger@fosstodon.org)'s status on Friday, 15-Nov-2024 18:00:51 JST Thorsten Leemhuis (acct. 1/4)

     in reply to

     • TUXEDO Computers
     • 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

     Krzysztof Kozlowski likes this.
   • Embed this notice
     Thorsten Leemhuis (acct. 1/4) (kernellogger@fosstodon.org)'s status on Friday, 15-Nov-2024 18:00:52 JST Thorsten Leemhuis (acct. 1/4)

     in reply to

     • TUXEDO Computers
     • waldi

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

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

     (side note: I suspect the kernel will now taint itself as "proprietary" when loading these drivers, but haven't tried)

     CC: @waldi

   • Embed this notice
     Thorsten Leemhuis (acct. 1/4) (kernellogger@fosstodon.org)'s status on Friday, 15-Nov-2024 18:00:52 JST Thorsten Leemhuis (acct. 1/4)

     in reply to

     • TUXEDO Computers
     • 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":

     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

   • Embed this notice
     Nick @ The Linux Experiment (thelinuxexp@mastodon.social)'s status on Friday, 22-Nov-2024 14:25:50 JST Nick @ The Linux Experiment

     in reply to

     • TUXEDO Computers
     • fabyk

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

   • Embed this notice
     Neal Gompa (ニール・ゴンパ) :fedora: (conan_kudo@fosstodon.org)'s status on Friday, 22-Nov-2024 14:25:50 JST Neal Gompa (ニール・ゴンパ) :fedora:

     in reply to

     • Nick @ The Linux Experiment
     • TUXEDO Computers
     • fabyk

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

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     fabyk (fabyk@social.tchncs.de)'s status on Friday, 22-Nov-2024 14:25:51 JST fabyk

     in reply to

     • Nick @ The Linux Experiment
     • TUXEDO Computers

     @kernellogger @tuxedocomputers @thelinuxEXP something for your vlog?

   • Embed this notice
     Thorsten Leemhuis (acct. 1/4) (kernellogger@fosstodon.org)'s status on Friday, 22-Nov-2024 14:26:00 JST Thorsten Leemhuis (acct. 1/4)

     in reply to

     • Nick @ The Linux Experiment
     • TUXEDO Computers
     • Neal Gompa (ニール・ゴンパ) :fedora:
     • fabyk

     @thelinuxEXP

     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…

     CC: @Conan_Kudo @fabyk @tuxedocomputers

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Thorsten Leemhuis (acct. 1/4) (kernellogger@fosstodon.org)'s status on Friday, 22-Nov-2024 15:11:29 JST Thorsten Leemhuis (acct. 1/4)

     in reply to

     • Nick @ The Linux Experiment
     • TUXEDO Computers
     • Neal Gompa (ニール・ゴンパ) :fedora:
     • fabyk

     @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

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Friday, 22-Nov-2024 15:11:29 JST 翠星石

     in reply to

     • Nick @ The Linux Experiment
     • TUXEDO Computers
     • Neal Gompa (ニール・ゴンパ) :fedora:
     • fabyk
     @kernellogger @thelinuxEXP @Conan_Kudo @fabyk @tuxedocomputers The hypocrisy was really incredible.
     
     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?