Not really. The FSF has a neat and simple guide that covers which licenses are compatible with which. It's only when you go and do stupid stuff like the CDDL, and realize later that your lawyers were idiots, that you're in a pickle. But if you stick to the defaults (BSD 2C, [L]GPL 2/3, MPL, Apache, etc) you know exactly what you have and exactly what you can combine it with.
@@andersjjensen except you cannot combine gpl 2 with gpl 3 and there's no way to know that unless you do research about these licenses and what rights they grant
I will comment once, to be a ridiculous grammar pedant - "purposely, allegedly" in that context the comma is meant to divide the statements into "They did this purposely" and "allegedly to 'keep control the upstream pacing'", not connect them into "allegedly-purposely".
What do you mean? They ship it with a fully compatible Linux at no extra cost (or cost is already included and removing it doesn't lower the cost, depending on how cynical you are about it). Which is magnitudes easier than getting a random store bought laptop and hoping that every subsystem will actually work.
This was definitely a case of them just making a really dumb mistake, but them reverting the commit that fixed the problem definitely wasn't a good look. I doubt that a company who distributes computers that have Linux would want to have any problems with upstream. I think the response from upstream is totally reasonable, but for the sake of the customer's involved, I hope this is resolved.
The reason they reverted it, was because that made the code unusable. They would have had to significantly rewrite the driver for that to work. Relicensing was the only viable option, they should have just done that way sooner.
@@autarchprinceps Clearly it wasn't too hard to relicense all of the code because they did it pretty quickly after they were forced to. They should have done that instead of reverting the commit.
@@alex84632 The reverted commit set the kernel macro calls to GPL v3. The license change would still have to undone all changes in that commit. It would otherwise have been both technically broken and legally wrong in the other way around. I don't disagree otherwise, but my point was, the first thing any developer finding a completely broken main branch after a merge would do, is revert the merge, and reevaluate from there. That's why it was a comment on the above thread. The merge of the macro changes was not "the commit that fixed everything" that was reverted for malicious reasons. It broke the functionality and failed to adress the license change that we all agree was the way forward. Reverting it may have triggered the legal based anger of the kernel team, but it was just as pointless as making the repo incompatible to the kernel in the beginning. They would still only have shipped it once they get it working again, so the GPLv3 code would still have been redistributed illegaly together with the GPLv2 kernel in the same way until they got to the same conclusion as they did in reality, that finally changing the license was the best way forward. The only alternative would have been a major rewrite of each driver's code while not adressing the many other reasons the license conflict was a stupid thing to maintain.
WELLL... even if Linus wanted to re-license to GPLv3, he has to get everyone to sign off on the re-licensing, or replace any contributions that say no. For all practical purposes Linus can't even if he wanted to.
Sometimes I wish that Linus had required contributors to sign over copyrights, then I remember that once Linus retires, corporations are going to fight over control and we don't want any company to fully control the kernel.
Some projects have conditions to contribute, that you adhere to if you want to contribute upstream (otherwise, you have to fork). Some conditions are much mone onerous (not in the £€¢¥$ sense) than others. Often, one of those conditions is granting the upstream owner/foundation/BDFL the right to re-license the code... Please also notice that this does not violate neither le letter, nor the spirit of the GPL(v2). You are free to get the code, to modify it, and to redistribute it. What such clauses are limiting, is your right to cuntribute upstream, not your right to fork and create your own upstream... I am nnot well versed about the linux kernel specifically, but give that it was not GPLv2 originally, and the change was done latter, maybe a clause like that is lurking there somewhere. IANAL, I am an electronics engineer, that started using FreeBSD in '95 and Linus in '96 for his thesis, and used Linux in a telco environment where compliance is key. And hang around with A LOT of lawyers, so, there is that...
@@nobodyimportant7804 Absolutely no F/LOSS project should require contributors to sign over copyrights, or even permit re-licensing under a different license. Doing so allows them to change the terms to whatever they want, even if it's not in the spirit of what you wanted to license it as. To a lesser degree, this is why Linus made the right choice by making it GPLv2, rather then GPLv2+. There was no predicting the changes for GPLv3, nor can we predict what will happen with subsequent "versions."
As someone daily driving a Tuxedo, I can totally get behind this being 100% non-malicious. They seem to take a "move fast and break things" approach to everything, and it *usually* works out 😅
How is taking 4 years to upstream a trivial driver (modules have a lower bar for acceptance) 'moving fast'? Using GPL2 for code going into the kernel is the default. Someone had to positively make a decision to do this weird thing. They had to have a reason. The only explanation is they wanted their in-house distro to be easier to run than alternatives on their hardware and made a concerted effort to make it so with licensing shenanigans, which belies their claim to being 'blissfully unaware'.
14:58 Come on, that's like the first thing you learn as a kernel dev. MODULE_LICENSE is the one thing you cannot leave out from a kernel module. MODULE_AUTHOR and MODULE_DESCRIPTION are not required.
...until you never create a module? (my guess, not a linux dev) Which can be 100% a case with a hired dev. Creating new kernel module is not something you do daily, after all
yeah I know this is hyperbole but it's not like every kernel dev goes through some shared curriculum it seems like an easy thing that would be caught in a PR, since the kernel maintainers would have that knowledge and it's a trivial issue to fix
CS students really need to have at least one lecture where the professor stands up and screams at the top of their lungs "SOFTWARE LICENSING IS IMPORTANT AND YOU NEED TO UNDERSTAND WHAT YOU'RE DOING. IT DOESN'T MATTER IF YOU'RE NOT A LAWYER BECAUSE IF YOU SCREW UP YOU WILL NEED ONE"
In my BS degree there was a course about IP, copyright and software licensing. In my MS degree we had advanced version of it. It’s not like CS/SE students can’t learn this in uni, most just forget it immediately after finals because “this is bs I’m CS student not law student. Why it’s in the curriculum” attitude
@@volom8289 this is also a fault in teaching and it wouldn't even take a lot of work on the side of the lecturer to do this you can do it in the first half an our of the first lecturer (best with examples), you just need to explicitly say how it relates to them
TUXEDO is a relatively small company, relying on passionate developers. (I applied there, so I know roughly how it looks there, they have a really cozy kitchen with lots of Tux merch and even hold public events in their HQ). They most likely don't have any lawyers for stuff, that isn't a pressing issue. (I haven't seen such a department in their HQ at least, doesn't mean they can't be contracted externally). You can expect, that management decided, that modules should be GPLv3 in line with the GNU FOSS philosophy and company image, and didn't know it's incompatible with GPLv2 in the kernel. Also the developer really didn't know, there's any incompatibility between the licenses, as the identifiers were called only "GPL" and not "GPL v2", which already makes it indistinguishable from GPLv1. (And to be fair it's more important, that the kernel is GPLv2 ONLY, as it would have been compatible with GPLv3 otherwise.) All in all, it's just "legal incompetence" from a relatively small company with good intentions. You really need to think of TUXEDO as a "indie dev" with great upwards momentum and less of an established player. (That's also why no CLA was in place, which even caused this delay) Either way, everything's resolved now, so we can all sleep well.
The way the community attacks them just show how toxic the linux community is. Lots of socially incompetent keyboard warriors with a genious complex, always pretending everything is obvious with the benefit of hindsight. Most of them contributing nothing.
I'd recommend you to try some of the free (as in freedom) GPLv2-compatible entertainment options endorsed by the GNU Foundation (or as I've recently taken to calling them, GNU+Hookers).
If you do an seL4-type microkernel written in RUST or ZIG (with as little "unsafe" keyworded code as possible), with a BSD/MIT/Apache license, that can use Linux loadable modules as drivers and has a unix BSD/MIT/Apache userland, count me in.
I kinda feel bad for Werner. Yes, they dug themselves into this hole, but I also see all of this as a series of human errors. Licensing the code under GPLv3+ should have never happened but afterwards, if you don't fully understand the legal consequences, it's easy to loose sight of this problem. Even after getting informed about this problem, as seen in this story, it can go under the radar again, if you don't understand these consequences. Should he have known about this stuff in the first place? Yes, especially as an author of kernel modules. But now he learned it the hard way. As long as Tuxedo doesn't do this mistake again, I think we can count this outcome as a win
...Not that he had anything to do with this story, it's just that I wouldn't know about Tuxedo computers if not from him and I think I am not alone here. I think Nick got the Tuxedo brand a lot of visibility.
I think using the word incompetence is probably a bit harsh, seems more like a case of a small company that doesn't have a lawyer on staff and not having the skills in house to deal with the issue or to make them aware of the severity of the issue
@@azmah1999 It's a different skill set, I've never meet a Lawyer that can write kernel drivers, nor have I even meet a lawyer who could design a water treatment plant. just because you don't have training or experience in a field doesn't make you an incompetent person. And you can't expect small companies to have a lawyer on staff, it may have been a case of it taking them several years to find a suitable lawyer who is familiar with software licencing that they could even hire to help them, remember they are a German company not a USA company, so they are not in a region where people sue you just because a napkin fell on the floor.
@@daveamies5031I think this may be an interpretation difference on your part. If I'm a dev, I'm hopefully very competent in certain languages, less competent in certain others and probably incompetent in the rest. I may also be a competent woodworker as I do that as a hobby, but a completely incompetent mechanic. Tuxedo made mistakes because of incompetence (in legal issues). However, they aren't incompetent in general.
I highly doubt Tuxedo wants to piss off the upstream of the OS they built their entire business off of lol. This has to be just being painfully unaware.
Honestly, there should probably be some kind of FOSS license consultant lawyer firm. I have raised issues of open source license noncompliance at one of my jobs, and let me tell you, it was NOT taken into consideration at all.
What people don't realize in regard to the different GPL versions is that the general assumption of "higher is better" doesn't always work. Another example was GNOME, which I left after they degraded it terribly in the switch from 2 to 3. The code I write is either GPLv2+ (because I don't think anything I write in my code is patentable, which is the only advantage of GPLv3), MIT (because it's simple but not too simple), or the no-problem-bugger-off license (which is simply four short sentences "Sure. No problem. Don't worry, be happy. Now bugger off!") for the code I really don't feel like maintaining but which still could be useful for others. OR it is whatever the package owners of what I'm contributing to chose (eg. openssl is Apache 2.0, opendkim/opendmarc are licensed like sendmail which is a bit weird, but ok, and there are others as well).
I personally like MPL the best. It's able to be used in anything as long as you mention you are using it and only requires you to redistribute if you are adding anything directly to it. That way you aren't blocking it from being used alongside any other code, you get credit, and you prevent the embrace, extend, extinguish risks that permissive licenses have like that prevent software like BSD from benefitting from common development from Apple or Game Consoles.
i personally like the AGPLv3+, and more extreme variations like requiring the entire stack to open source(similar to SSPL but without money exemptions so it remains FOSS)
What FSF license REQUIRES redistribution? I can fork any type of GPL license code and make any changes for my own use and no one can force me to make those changes public until I distribute it. And then, I don't have to make the changes available to just anyone, just those that I distributed to. Of course, they can make it public if they wish. That is the way it should be.
@@nobodyimportant7804 They're not fulling spelling out what they mean. "Redistribute" means "redistribute the changed source code under MPL" What they mean is, unlike the GPL, which requires you to license your entire project(including all of YOUR work) under the GPL if you're including a GPL component, the MPL lets you keep your portions of the whole project under any license you want. If you distribute the resulting project, the only time you are required to redistribute source code under the MPL is if you make direct changes to the MPL code. Those changes specifically need to be redistributed, also under the MPL. The rest of the project does not.
MPL mentioned let's gooo And I think the most important thing about it is that it takes effect on a file basis Which means if someone else uses your project, only the copied files are under that license, the rest could perfectly be another one Unlike the LGPL that I believe is meant to be used with shared libraries And since the part of your project is meant to be "replaceable", that has some problems when you want to have something compiled all together but also under a different license
Imho it's obvious it was incompetence. And tuxedo-drivers ain't even mandatory for many of their models, they are pre installed only because some of their more niche laptops have components without upstream support, and anyone who asks "booo why no upstream?!" just shows that they are clueless. Most of the time you are free to not install tuxedo-drivers in their nicher laptops too, result being missing hardware functionality such as fan control, keyboard backlights, etc. Good that this situation resulted in a resolution. And by the way, even if tuxedo did everything "perfectly" and tried to upstream everything day 1, the dkms situation isn't leaving any time soon. New laptops are released constantly, if they had to wait for a kernel merge and a new kernel release with said new drivers they would not sell anything. Especially taking into consideration that up until 2022 they weren't offering their own distro. What do you think is worse, a FOSS dkms or a new laptop that literally lacks working advertised hardware niceties, or said hardware niceties only work on bleeding edge distros? Be realistic.
thank you for being like the only person who understands this! if the new laptops are to be supported immediately when they come out, upstreaming the changes to kernel is just too slow. there are also some more niche things like having to come to terms with the kernel devs about how to structure certain apis if some functionality does not yet exist (see kernel mailing list about how to handle keyboards with backlights that allow every single led to be controlled, which the kernel devs wanted to have one sysfs path for every single led - which is slow and clunky which would make animations basically impossible)
Then they better not pretend that they support Linux then. If I can only use the manufacturers custom distro for basic hardware support (fan control is not a nicety) then it supports one Linux-based OS from a small vendor.
@@LordVarkson Tuxedo drivers are packaged by them for virtually 99% of distros, Debian, Fedora and Arch based, and packaged by the community by niche distros like Void Linux. So no, no one forces you to use their custom OS. Anything that is supported upstream will work anyways, it's the unsupported stuff that they ship tuxedo-drivers for, that's a service they offer to you, they make stuff work before upstream. If you don't want any of that, and want all your drivers to be upstream, then just don't buy, do market research yourself, it's simple. But personally I am glad to know that I can buy a laptop and be certain that battery charging limits, keyboard backlight, fingerprints, etc, are working/not working out of the box. Eventually they should be upstreaming everything, which is why I am glad this was resolved. But the dkms is unavoidable if you want to be a legit business. Like, can you imagine for a bit? If they waited out a year for stuff to get merged & released before they started shipping laptops, people would complain about outdated hardware. Not only that, but you also have to amount for the people running LTS distros that will be spamming their support team(reminder it's a 50-people company). On the other hand, if they ship their own DKMS, people complain about upstream, can't win apparently.
@@CristalianaIvor Yes most people aren't devs and it shows. They also can't see this from a business perspective, they are basically asking for tuxedo to be a reseller, buy standard laptops from others, wait for upstream, and then sell them year later to make sure people running LTS on their laptops will work out of the box. People would then complain about outdated hardware. Unless they genuinely believe shipping a laptop that works only with bleeding edge distros is acceptable given tuxedo's target audience and goal. People are always so quick to judge, but I am glad I am seeing this, because it has me thinking if I too suffer from such shortsightedness on other topics.
not really, in linux there are three types of drivers. Drivers compiled directly in the kernel (those are GPLv2), Loadable modules that are GPLv2, those are presented an interface that almost never changes, and is the full interface for a driver to the kernel. Loadable modules that are binary blobs, or non-gpl (like nVIDIA's propiertary drivers), those are presented with a reduced intewrface to the kernel (and the interface changes quite often). Search for Linux Kernel Condom Defense, and go down that rabbit hole
It's a little more complicated than that. Linus took the "derived works" statement in the vanilla GPLv2 the wrong way and asked the FSF for a version that allows for linking to GPLv2 code.... then later introduced "strict GPLv2 compliant linking" because he realized he messed up. This is why some parts of the kernel allows proprietary modules to link to them, but others do not. And Nvidia carefully avoids the parts that would get them booted.
@@X11R11 The license itself has no concept of a "GPL symbol", all kernel code is under the GPL. The GPL symbol mechanism is basically a gentleman's agreement.
Never attribute to malice what can more than adequately be explained by incompetence. First I thought this was a case of upstream control in the sense of 'keep features exclusive to tuxedoOS or make them hard to access for offbrand distros'. The more context I hace seen this shifted more and more to 'The got told 4 years ago, forgot, and now the wrong person happened to notice, someone who did not grasp all the consequences made a decision, realised there was a problem, reverted without communication and this mess happened.
the crazy part is GPLv3 only exists because of some obscure Tivo hardware that briefly existed 20 years ago. One company broke the open source world xD
@@lorenzo42p oh perhaps, but it's such a technicality. it was not worth splintering the kernel like this over some edge cases nobody knows/cares about anyway.
@@ovrskr the only thing I can think, maybe linus didn't want to scare away companies from using the kernel. more use at the cost of a bit of freedom. I don't agree with that myself.
@@lorenzo42p the hypocrisy is the GNU foundation does the same (LGPL is designed to allow GNU software to run on freedom-less platforms, and they happily ship binaries for Windows etc)
This almost certainly resulted from incompetence and internal miscommunication or unawareness at Tuxedo Computers. To the question of what we run, recently I have made TuxedoOS my secondary OS of choice and I recommend it to most newcomers. Secondary since my main desktop and laptop run Garuda Linux, an Arch derivative which works surprisingly well for me. But I maintain more TuxedoOS systems than Arch (based) systems at the moment. Interesting licensing mishap, but while serious it does not affect the technical merits of the distro. So unless this repeats multiple times, like Manjaro's various mistakes, no reason to distro-hop over this.
License and legal stuff is really a deep knowledge, I really admire people who can understand all this. Just curious, I have zero to none knowledge about all this and I want my project to be safe, can I just use BSD or MIT license?
You could, but I'd personally recommend something like Apache or MPL. Look around you and see what your programming language's libraries or programs generally use, and stick with that.
I might be straight up missing something with this right now cus software licensing makes my brain hurt, but why was the response from the kernel developers so harsh right on the offset while tuxedo was trying to at least somewhat fix it? They acknowledged they made a mistake, I don't see why they had to go right for the cut-throat option of bricking every tuxedo laptop in a customers hands opposed to just... giving them a few days to at least try to fix it and moving on from that?
Because certain kernel functions cannot be used with non compatible modules *this was mainly against nvidia originally iirc) but because GPLv3 isn't compatible with GPLv2 GPLv3 modules like Tuxedo cannot use these functions either.
They where using code they had no right to access for FOUR YEARS, and they reverted the change that fixed their licensing without checking why that change broke something. That is a severe legal issue.
> the cut-throat option of bricking every tuxedo laptop in a customers hands I actually am not 100% sure if that is what happened here. module_license_offenders only marks the kernel itself as tainted when these modules are loaded, but I don't think that this prevents already compiled modules from using the "GPLonlyed" symbols. But I am not 100% sure. Also, even if that commit did actually stop the Tuxedo dkms modules from loading - it still wouldn't brick user devices. Firstly, because it would only affect users after updating their kernels to a version that includes those checks (and most people don't compile the kernel from source and don't run the mainline version). And secondly, because AFAIK those drivers are only needed for "optional" features like keyboard backlighting and stuff like that. The "core functionality" of those laptops shouldn't require any custom drivers. > why was the response from the kernel developers so harsh right on the offset IANAL, but I think that it's because this was a legal issue. Basically, when somebody breaks your license, you can't be lenient (even if they didn't break it by accident), otherwise you are risking getting into legal trouble yourself (or getting someone else into legal trouble).
Also sometimes courts will interpret non-enforcement of a license condition as permission to violate it. From the perspective of the Linux kernel they need to enforce their licensing all the time, even when no malaice was involved, lest they leave the door open for bad actors to abuse the percived lack of enforcement.
Thing is I do like Tuxedo OS and is a viable flavor as its kubuntu KDE Neon without snaps, I have been desperate to find a good KDE distro based on ubuntu to fill the gap Kubuntu left behind.
I think this is a common "problem". Lot of TH-cam can tell how how just a small fraction of their watcher are actually subscribed. It's also the reason why every TH-camr tells you to subscribe.
Not necessarily. If you see a lot of viewers that aren't subbed then it likely means the video is being pushed to new or even occasional viewers that aren't subbed.
Could someone help me understand the issue here. Didn't they already say that all code they upstreamed was automatically relicenced to GPLv2? Is the issue that the out-of-tree modules were GPLv3 and could not be redistributed along with the kernel by Tuxedo computers?
With the exception of a tiny bit of code none of it had yet been upstreamed so it was all still GPLv3, the issue is this GPLv3 code was being distributed with Tuxedo OS and possibly in other forms and was accessing GPLv2 symbols in the kernel which it's very much not allowed to do.
Are they keyboard lights and a few other FN-key shortcuts gonna suddenly break on my Clevo laptop any time soon? As a user do I need to/can do anything about this situation?
I understand this "keep control of upstream pacing". Yeah, who would do that? Well, maybe Manjaro, known for taking unfinished drivers and modules from Asahi and sending them to upstream?
I have a Tuxedo. Pretty happy with it. It took 2 months to get delivered because I pre-ordered a new model and the date kept slipping but after that it's been pretty good. For distributing their drivers they have a tool that you can just use. I think the only thing the license incompatibility causes is that the drivers can't be upstreamed into the kernel, but they are still usable anyway. Also their pre-installs, even of other distros, use a tuxedo patched kernel.
6:03 - No, he doesn't consider it positive. He looks at it as something that can have valid reasons and be necessary evil and also as something tangential to actual code, that's from his answer on Deb Conf.
They may be licensed in such a way that they require a GPL v2 compatible license. For example by being licensed under GPL v2 Only. GPL v3 is not GPL v2 compatible. So GPL v3 code cannot be distributed together with GPL v2 Only code.
They can still call the functions, they just can't be distributed with each other. The intent is to prevent proprietary software from infecting the rest of the project. And they may have been a little strict with what the GPL v2 rejects
Question, what if a hacker develops a hack for kernel anti cheat and sell it off to make some money, does it mean that he won't be able to do that if he used a linux distro that has gpl 2 license?
The license doesn't stop you from making money off of it, but you do have to follow the terms of the license which means making the source code available, distributable, etc. Read the license carefully and pay a lawyer to check if you can.
I think it was something between the two. Meaning it started as incompetence and later on even though was noticed, since they got away with it, they thought it should be fine. On the other hand though, I am neither fan of the linux kernel devs approach. They should have said , eg. you have 3 weeks to fix it. Tuxedo as clients and they do have a good presence for the Linux world. Breaking the systems of their clients hit also hard on the linux credibility. None of those would actually care about the overall story, and at the end the lack of timeline is a problem.
I have an even more principled issue with the approach the kernel took here. Basically they are banning certain module names in the kernel as a way to enforce copyright law. As far as I'm concerned that is a clear violation of the spirit of the GPL, making it a really ironic approach. If they go down that route they should also start banning processes based on names of known illegal programs for example. I think they really don't want to go down the route of a enforce legal thing through technical measures. Either way, I'm working on a few GPLv3 licensed kernel modules right now, they are called amdgpu, usb_storage and snd. Please add those names to the in kernel list as well.
There is a crossover where incompetence is indistinguishable from malice. That point was the reversion of the patch. There is no non-malicious to do that without then publically notifiying the contributor. If they didn't have authority to merge it then it should have waited for a lawyer sign off, there is no way to have done that without someone misrepresenting the truth at some point. Either it was merged without authority or someone with authority quietly reverted it hoping to not be noticed.
It's frustrating how much time gets wasted on this. No surprise that hardware manufacturers don’t bother shipping Linux drivers themselves, leaving us to rely on volunteer Linux developers to provide drivers. The strict licensing around source code often feels unnecessarily restrictive. Even when companies like Tuxedo write open-source drivers for Linux, getting them upstream is a challenging and messy process.
It's really simple: It's GPLv2. If you are not prepared to do that, get lost. When you work with Microsoft you have two options: Follow their rules (that seem arbitrary and paranoid by comparison) and you can get your driver distributed through Windows Update or kindly fck off. A lot of small vendors chose the latter... which leads to googling PCI-IDs to find a forum post that will inform you which make and model you're working with so you can download the driver off the manufacturers website (if they still have it up... or they refer you to the OEM which only bothered to have a driver for the previous version of Windows).
Knowing which license to use is easy. Don't be dense. The kernel being GPLv2 only is extremely widely known and easy to find out. I guarantee that part of the submittal process for code requires the submitter to specifically acknowledge that the kernel requires GPL2 code. They do not leave this to chance. The **actual** issues that have to do with licenses, is companies either not wanting to release their code GPL2, or not being legally able to (if they use other proprietary code, for example).
What about just doing the right thing since the beginning? If they licensed the damn drivers as GPLv2 since the beginning none of this shit would have happened.
I'm just an average user and I don't get this licensing or drivers stuff. On Manjaro all I needed was to install tuxedo-drivers from repo (also available on AUR) but all worked without them as well, so I'm not really sure what they do. On another partition I do have Tuxedo OS, just to have some reference, but I rarely use it. I don't like LTS systems and Arch based systems are the only ones suiting me. However, Tuxedo laptops are not 100% Linux compatible. In fact, my old Alienware was more Linux compatible then Tuxedo laptop, that suffers from various incompatibility issues, like lack of suspend capability (need a patch in kernel to work, which only Tuxedo OS has), FN keys don't work (this is however individual issue, since all other laptops in that like have no such problem), there are some bizarre gesture issues with pad, some external hardware incompatibilities (which on the same system didn't happen on another laptop) and so on.
I have a Tuxedo computer that's 4 years old. I wanted to use Linux for development and Windows for gaming, but the keyboard stopped working after a year, I sent it to get fixed, then the keyboard broke again after a few weeks (I think the internals get too hot and mess something up in the keyboard), now it's a gaming machine with Windows only. I do not recommend it.
"they did this purposely *COMMA* allegedly to 'keep control of the upstream pacing' *dash* and want to re-license the code while upstreaming". A bit awkward and unusual however perfectly legible if you pay attention to the comma there. Sure, the _" allegedly to 'keep control of the upstream pacing' "_ would have been better in parenthesis but this is a valid way to structure it with the comma and the dash.
From my experience in a similar area, I think it's not exactly incompetence but selective blindness and impatience by the talented of what they don't understand. I used to work in a university, as a subject academic, and also as the sort of nerd who works out the rules and regulations. It's an acquired taste, and I could well understand my colleagues who weren't the least bit interested; but some would refuse to admit that this sort of stuff was anything to do with them at all. I'd say "I know what you want, and it's good, but the way you're doing it won't work in the system, and it's affecting your students. Let me design some regulations for you that will do what you want, and the computer won't barf over." "No, I did it this way in my last university and I'm not going to change for some bureaucrat." Well, you can kind of see that, but you need some kind of system: in the FOSS world, legal technicalities are what keeps it FOSS, so you have to respect them, even if they bore the hind leg off a donkey. I never had the nuclear option, but sometimes I'd have used it if I had.
I'm watching this from a very non-bricked Tuxedo Mini which I got about 1.5 years ago. I do love the machine! Only problem I had was that the wi-fi was not working with Debian out-of-the-box, but since it's basically a desktop machine it did not bother me as it will be just connected to my optical modem (60cm away) using Eth anyway. Originally it came with an USB stick (a nice, sturdy one) to auto-install their distro -- perhaps the wi-fi problem would have been resolved by using that. However I had not even realized that and just used the stick to install Debian :-D
I think, whether something was a failed attempt at being sneaky or an honest mistake, being openly apologetic is actually rather irrelevant. How a problem is handled is often more important and telling about a person or company than the nature of the problem itself. I'm not a big fan of 'Sorry, I didn't know.' That's something a high schooler would say to their teacher and expect to be forgiven as always. I do believe that when it comes to running a business, ignorance is a form of incompetence. It was your job to know ... or to consult someone who does. A lawyer in this case. However... reacting harshly to the point where it interferes with someone's attempts to correct their mistakes is unproductive. This isn't a billion-$ corp trying to screw us over. Let's just wait and see how this plays out; now need for pitchforks just yet.
I mean people here are arguing that they're violating "people's right to upstream their code" which is crazy to me, if i go to the effort of sitting down, cranking out a driver and crafting it into existance i don't expect you to swoop in behind me and publish it to the kernel without my knowledge or permission, i didn't even know this was a thing, opens up a whole new game for the those people desperate for Kernel commits to get into the habit of doing i guess, it's better than README nonsense i suppose lol It's with stuff like this that the whole concept of FOSS becomes repulsive to me, digital communism that ironically mostly benefits big corporations and completely wrecks small developers actually doing the work, it's wild
I'm going to say neither are the word that applies. It's not malice, nor merely incompetence. It's negligence. If you're going to be dealing with anything that has any legal ramifications, you had better know the situation you're working with or proactively work with someone who does. That's not even a should, that's mandatory. Because I guarantee if you fuck up, no one who has to deal with it is going to have any sympathy that you couldn't be bothered to handle it when you should have. More so when you had every opportunity to consider that maybe you should at least double check.
i feel like there's way more to explain to a noob like me. I get thing, told I'm free to use it by the people who made it... the end? Also, as far as functionality, is there anything that gives a fuck about the GPL version? or is that effectively just meta data? Maybe I missed some stuff being such a noob.
I actually have a Tuxedo. It has great specs even at almost 3 years old, works well with many distros (I'd recommend skipping Tuxeodo OS though), and been pretty durable. I might get another one.
No wonder dkms updates everytimes theres an update for me lol (tuxedo customer). Its not that bad updating, but would be great if it was just part of the kernel. It sucks because the control center software is honestly great and easy to use for power and fan control for those who don't want to write custom scripts and all that for detailed control.
I wouldn't call it incompetance either. Seems like a honest mistake when starting out a company, which was then forgotten about because "it works". Please don't be harsh towards them. They candidly accepted the mistake, and are working on it. You can cite very few examples of good citizenship like this. Otherwise, if the backlash is too harsh, people will just make all drivers proprietary. Please, let's give them a change, and see how they fix it.
Actually, we have banned Australia years ago! xD On a serious note, we've had some weird cases with lost parcels, hence we suggest to use a parcel forwarder if ordering from us. I remember that it took like three months and two attempts until a small LCD cable we shipped to a customer eventually arrived - just one of many examples why Australia cannot be currently chosen as a delivery address.
Just another reason to buy System76 hardware. At least I've never heard of them violating the GPL. I just don't think that Jeremy would allow it and it seems like Richell is a good dude.
@@KartonRealista2 I don't see anything wrong with the sentence, but Brodie misinterpreted it, so I "fixed" it to eliminate the possibility for the misinterpretation he made.
I met Tuxedo Computers at some cons, probably the marketing guys and I have to admit, everytime I wanted to dig deeper into their hardware stuff and ask serious questions, they kinda dodged on upstream kernel as I was considering that stuff as hardware to run gentoo linux on...
It may depend on the specific con. Especially for Linux-oriented fairs like the FrOSCon, we usually have some of our developers with us so we can tackle these deeper questions. Our team has grown in the past few years noticeably and we hope that this will continue to shine through upcoming cons.
IMO If your main sales pitch is that you are selling computers compatible with Linux, its extremely misleading if you are using drivers to achieve this that do not conform to the Linux licensing model. I'd expect any company making a big deal about selling Linux compatible computers would be mainlining any drivers needed.
isn't this what android and google do, except they're worse? or is it fine when they do it because it's userspace vs here where it's kernel space? seems like an internal conflict that we shouldn't be having when there are much bigger issues
I still don't understand the pacing thing. If your code isn't ready, it doesn't go upstream. Hell, wasn't there pretty heated arguments between Linus and Kent for the exact opposite situation where Kent was trying to push code to production after a freeze? No one is going to mind if you wait until the next release window.
If you were a company, you wouldnt want having a competitor just after you launched your flagship laptop. Because if your drivers are in the upstream, any compatible hardware could use your drivers for free. Whats the incentive to buy them from Tuxedo then ? Drivers for your old models wouldnt be a problem after you sold all of them.
@@gokhanersumer2273but wasn't the driver source all available under GPL V3? So a competitor could still take it and use it the same way Tuxedo was using it?
Well, I have never deleoped a kernel module, but if I came across a macro like MODULE_LICENSE("GPL") in a GPLv2 codebase that cares about the distinction between GPLv2, GPLv2+ and GPLv3, I would assume "GPL" to be a catch-all, meaning "any GPL version". Using "GPL" to implicitly mean "GPLv2" as a distinction to "GPLv3" is frankly bad form and smells like historical baggage. Now, yes, they absolutely should have talked to their lawyer and read the documentation more carefully, but this is an incredibly easy mistake to make. And going "don't you dare suggest our documentation is bad" when the other person already acknowledged the documentation was there and they were just not aware of it, is simply hostile and counter-productive. This right there is why I have always refrained from getting involved in the kernel, being roasted for any mistake even after admitting it and working to fix it is something I thought we all left behind us on the elementary school playground...
I was thinking the same thing. I cannot believe "GPL" is a valid parameter there, it's just common sense to force GPLv2 or GPLv3 (or, as someone mentioned elsewhere, what about GPLv1?)
@@kusucks991 Pretty much nobody uses GPLv1, so it's entirely irrelevant. Anyone wanting to submit code to the fucking kernel can reasonably be expected to be vaguely familiar with the GPL and the kernel license.
It's most likely named that for legacy reasons, and can't easily be changed without permanent depreciation and never being removed. Remember GPL 2 predates all the other versions you can pick there, and the other option at the start was probably "proprietary" or non GPL licences
In this case, "purposely, allegedly" is actually valid English, if a little awkward. To rephrase it, it can mean "they did this on purpose, with the alleged reason being ..." or perhaps "allegedly, they did this on purpose" meaning someone is making the allegation that they are doing it on purpose.
"They did it on purpose, allegedly to ..." - makes sense. They did it deliberately, and the purpose they stated was "...", but we do not quite believe it. You might acquaint yourself with the concept of "," (comma).
I honestly don't think they were ever going to change the licensing. So having their hand forced like this was the only way it was ever going to happen.
This sucks so much, because they're the only ones currently offering Linux-compatible laptops with a combination of AMD CPU and Nvidia GPU. All the alternatives I know of, including System76, only offer the trash-tier Intel 13th and 14th gen CPUs (no, I'm not trying to crap all over companies like System76, because it's not their fault their providers have exclusivity deals with Intel). Back to looking for a Windows laptop to fight with, I guess.
I think purposely, allegedly does make sense. The reason i think this is because its meant to be read somewhat like this; they did x action on purpose with the alleged reason of z. In fact the alleged reason proves they did do it on purpose, but if you have doubt on the reason given then you could still say "they allegedly did this becauss ' yada yada yada'" You see the difference? Its not it being on purpose thats alleged but the reason given.
This looks to have been a deliberate attempt to make their in-house distribution the easiest thing to run on their hardware, since dkms is not always smooth and easy to use on common distros (at least it wasn't the last time I worked with them). There is just no other simple, reasonable explanation for these license shenanigans. It *could* have been RMS-style fundamentalism (his partisans aren't thrilled Linux is GPL2), and that would even have been probable given they're Germans, but they would've proudly declared that as the reason if it were true, and they didn't. Another option would be that they somehow think they'd be violating NDAs by releasing the source, but then it wouldn't have been open sourced under GPL3. Nothing else makes sense. It's especially weird since people fall over backwards to upstream as soon as they can to reduce maintenance burden, the code is relatively small/trivial (and the standard for driver modules is more lax) so shouldn't have been much of a problem to get into acceptable shape. So if a company does a weird thing that makes no engineering or practical sense *except* it magically means their stuff can't be shipped easily with other distros.. you have to assume malfeasance of some description. The fact it is mixed with ignorance isn't exculpative. Every kernel programmer who writes drivers is aware of the license issues and specifically the GPL2 requirement for full kernel API access. If they are not, they are not kernel driver programmers and need to RTFM (at a minimum) before being allowed to submit patches. If not more, since their one attempt to upstream a relatively trivial driver went badly (this is unusual).
Tuxedo does not make the hardware that they run the software on. I have had a computer similar to one of the models that they sold. Tuxedo made the drivers detect a BIOS variable that they would set on their BIOS, and locked these drivers from working on hardware where it should. (I set this BIOS variable on my system, and the drivers worked without issue) This sort of behavior is precisely anti the spirit of the GPL. In my talks to Tuxedo, they were friendly but ultimately very unhelpful. In the end their position appears to be that they rely on the Open Source community for their entire OS, but are unwilling to let their drivers be used by the Open Source community unless they bought the hardware from Tuxedo. Seeing their position on working with the open source community (which they depend on for the rest of Tuxedo OS which they did not write) I decided that my next computer will be an ASUS. Build quality is much, much better, and ASUS actually has people who work on Linux drivers specifically that get into the Kernel.
Yes, you can say "purposely, allegedly". In two ways this makes sense. Either the purpose is alleged, or, as the comma here indicates, the reason WHY they did it is alleged .i.e. there mightve definitely been purpose behind it, but the reason why is not proven. Now i dont know what is in fact true here, but the sentence absolutely makes sense.
License stuff is hard
That's basically the TLDR of the video
When is it not.
"Licenses are hard. They're harder when you're stupid." -John Wayne, probably.
Not really. The FSF has a neat and simple guide that covers which licenses are compatible with which. It's only when you go and do stupid stuff like the CDDL, and realize later that your lawyers were idiots, that you're in a pickle. But if you stick to the defaults (BSD 2C, [L]GPL 2/3, MPL, Apache, etc) you know exactly what you have and exactly what you can combine it with.
@@andersjjensen except you cannot combine gpl 2 with gpl 3 and there's no way to know that unless you do research about these licenses and what rights they grant
I will comment once, to be a ridiculous grammar pedant - "purposely, allegedly" in that context the comma is meant to divide the statements into "They did this purposely" and "allegedly to 'keep control the upstream pacing'", not connect them into "allegedly-purposely".
as another grammar pedant, I agree
I am a non native speaker. What does allegedly mean in that context?
@@rimenahi That the person quoting them does not believe the reason that they gave.
@@rimenahi "This has been said but it hasn't been proved in court".
@@rimenahi It means I heard it's true but I I'm not sure/can't prove it.
There's a high probability that a manager thought they could just keep punting on this until they'd got all the code merged.
i had no idea you watched linux content
@CosmicDriftR only been using a Linux desktop for 30 years. Of course I watch Brodie
Likely.
@@djsmeguk, with that amount of time using linux, yoy don't need to watch linux videos. You migjt as well be making videos as well. 😏
Basically sums it up
>make laptops meant to be used with Linux
>Make it more difficult to use with linux than a normal store bought laptop.
Nice.
How long until they close shop?
GPLv3 is way better than GPLv2 anyway. Tivoization = bad
What do you mean? They ship it with a fully compatible Linux at no extra cost (or cost is already included and removing it doesn't lower the cost, depending on how cynical you are about it). Which is magnitudes easier than getting a random store bought laptop and hoping that every subsystem will actually work.
@@qwesx A lot of normal store bought laptops work with any distro, not just a specific one
@@LautaroQ2812 They are a 20 year old company, I think they are going to be fine. Still wouldn't buy a laptop from them.
This was definitely a case of them just making a really dumb mistake, but them reverting the commit that fixed the problem definitely wasn't a good look. I doubt that a company who distributes computers that have Linux would want to have any problems with upstream. I think the response from upstream is totally reasonable, but for the sake of the customer's involved, I hope this is resolved.
The mistake was trying to get some of it merged into the kernel.
The reason they reverted it, was because that made the code unusable. They would have had to significantly rewrite the driver for that to work. Relicensing was the only viable option, they should have just done that way sooner.
@@autarchprinceps Clearly it wasn't too hard to relicense all of the code because they did it pretty quickly after they were forced to. They should have done that instead of reverting the commit.
@@alex84632 The reverted commit set the kernel macro calls to GPL v3. The license change would still have to undone all changes in that commit. It would otherwise have been both technically broken and legally wrong in the other way around. I don't disagree otherwise, but my point was, the first thing any developer finding a completely broken main branch after a merge would do, is revert the merge, and reevaluate from there. That's why it was a comment on the above thread. The merge of the macro changes was not "the commit that fixed everything" that was reverted for malicious reasons. It broke the functionality and failed to adress the license change that we all agree was the way forward. Reverting it may have triggered the legal based anger of the kernel team, but it was just as pointless as making the repo incompatible to the kernel in the beginning. They would still only have shipped it once they get it working again, so the GPLv3 code would still have been redistributed illegaly together with the GPLv2 kernel in the same way until they got to the same conclusion as they did in reality, that finally changing the license was the best way forward. The only alternative would have been a major rewrite of each driver's code while not adressing the many other reasons the license conflict was a stupid thing to maintain.
WELLL... even if Linus wanted to re-license to GPLv3, he has to get everyone to sign off on the re-licensing, or replace any contributions that say no. For all practical purposes Linus can't even if he wanted to.
Sometimes I wish that Linus had required contributors to sign over copyrights, then I remember that once Linus retires, corporations are going to fight over control and we don't want any company to fully control the kernel.
Some projects have conditions to contribute, that you adhere to if you want to contribute upstream (otherwise, you have to fork). Some conditions are much mone onerous (not in the £€¢¥$ sense) than others. Often, one of those conditions is granting the upstream owner/foundation/BDFL the right to re-license the code...
Please also notice that this does not violate neither le letter, nor the spirit of the GPL(v2). You are free to get the code, to modify it, and to redistribute it. What such clauses are limiting, is your right to cuntribute upstream, not your right to fork and create your own upstream...
I am nnot well versed about the linux kernel specifically, but give that it was not GPLv2 originally, and the change was done latter, maybe a clause like that is lurking there somewhere.
IANAL, I am an electronics engineer, that started using FreeBSD in '95 and Linus in '96 for his thesis, and used Linux in a telco environment where compliance is key. And hang around with A LOT of lawyers, so, there is that...
When the issue first came up the kernel was considerably smaller, it would have been hard but now it's effectively impossible
@@nobodyimportant7804 Absolutely no F/LOSS project should require contributors to sign over copyrights, or even permit re-licensing under a different license. Doing so allows them to change the terms to whatever they want, even if it's not in the spirit of what you wanted to license it as.
To a lesser degree, this is why Linus made the right choice by making it GPLv2, rather then GPLv2+. There was no predicting the changes for GPLv3, nor can we predict what will happen with subsequent "versions."
@@BrodieRobertson Honestly, even in 2007 I'm not sure it would have been possible.
As someone daily driving a Tuxedo, I can totally get behind this being 100% non-malicious. They seem to take a "move fast and break things" approach to everything, and it *usually* works out 😅
Yeah. And then failed miserably in this case
Germans do random esoteric shit in IT
@@MrVecheater They do random esoteric shit in everything. Germans are special creatures.
@@plebisMaximus true, but we have a higher entropy for IT decisions
How is taking 4 years to upstream a trivial driver (modules have a lower bar for acceptance) 'moving fast'? Using GPL2 for code going into the kernel is the default. Someone had to positively make a decision to do this weird thing. They had to have a reason. The only explanation is they wanted their in-house distro to be easier to run than alternatives on their hardware and made a concerted effort to make it so with licensing shenanigans, which belies their claim to being 'blissfully unaware'.
14:58 Come on, that's like the first thing you learn as a kernel dev. MODULE_LICENSE is the one thing you cannot leave out from a kernel module. MODULE_AUTHOR and MODULE_DESCRIPTION are not required.
...until you never create a module? (my guess, not a linux dev) Which can be 100% a case with a hired dev. Creating new kernel module is not something you do daily, after all
yeah I know this is hyperbole but it's not like every kernel dev goes through some shared curriculum
it seems like an easy thing that would be caught in a PR, since the kernel maintainers would have that knowledge and it's a trivial issue to fix
@@KryptLynxthen you should learn how to do it
@@kreuner11 Naaah, I preemptively banned from contributing to linux kernel by virtue of being Russian.
@@KryptLynx I'm not talking about you I'm talking about the person you're defending for not know how to
CS students really need to have at least one lecture where the professor stands up and screams at the top of their lungs "SOFTWARE LICENSING IS IMPORTANT AND YOU NEED TO UNDERSTAND WHAT YOU'RE DOING. IT DOESN'T MATTER IF YOU'RE NOT A LAWYER BECAUSE IF YOU SCREW UP YOU WILL NEED ONE"
In my BS degree there was a course about IP, copyright and software licensing. In my MS degree we had advanced version of it. It’s not like CS/SE students can’t learn this in uni, most just forget it immediately after finals because “this is bs I’m CS student not law student. Why it’s in the curriculum” attitude
@@volom8289 "In my BS degree..." Why'd you get a bullshit degree? 🙃
@@volom8289 this is also a fault in teaching
and it wouldn't even take a lot of work on the side of the lecturer to do this
you can do it in the first half an our of the first lecturer (best with examples), you just need to explicitly say how it relates to them
considering it's a global issue, I don't think even the legal experts know all the nuances lol
TUXEDO is a relatively small company, relying on passionate developers.
(I applied there, so I know roughly how it looks there, they have a really cozy kitchen with lots of Tux merch and even hold public events in their HQ).
They most likely don't have any lawyers for stuff, that isn't a pressing issue.
(I haven't seen such a department in their HQ at least, doesn't mean they can't be contracted externally).
You can expect, that management decided, that modules should be GPLv3 in line with the GNU FOSS philosophy and company image,
and didn't know it's incompatible with GPLv2 in the kernel. Also the developer really didn't know, there's any incompatibility between the licenses, as the identifiers were called only "GPL" and not "GPL v2",
which already makes it indistinguishable from GPLv1.
(And to be fair it's more important, that the kernel is GPLv2 ONLY, as it would have been compatible with GPLv3 otherwise.)
All in all, it's just "legal incompetence" from a relatively small company with good intentions.
You really need to think of TUXEDO as a "indie dev" with great upwards momentum and less of an established player.
(That's also why no CLA was in place, which even caused this delay)
Either way, everything's resolved now, so we can all sleep well.
Yeah, that seems to be the case. I have a Tuxedo laptop and I'm running Fedora KDE 41 on it, which works flawlessly with all of the Tuxedo software.
The way the community attacks them just show how toxic the linux community is. Lots of socially incompetent keyboard warriors with a genious complex, always pretending everything is obvious with the benefit of hindsight. Most of them contributing nothing.
ok then, I'll go build my own kernel with blackjack and hookers
Ah forget the blackjack and the hookers, ah forget the whole thing
Where do I sign up 😎
I'd recommend you to try some of the free (as in freedom) GPLv2-compatible entertainment options endorsed by the GNU Foundation (or as I've recently taken to calling them, GNU+Hookers).
with blacklists and hooks
If you do an seL4-type microkernel written in RUST or ZIG (with as little "unsafe" keyworded code as possible), with a BSD/MIT/Apache license, that can use Linux loadable modules as drivers and has a unix BSD/MIT/Apache userland, count me in.
I kinda feel bad for Werner. Yes, they dug themselves into this hole, but I also see all of this as a series of human errors. Licensing the code under GPLv3+ should have never happened but afterwards, if you don't fully understand the legal consequences, it's easy to loose sight of this problem. Even after getting informed about this problem, as seen in this story, it can go under the radar again, if you don't understand these consequences. Should he have known about this stuff in the first place? Yes, especially as an author of kernel modules. But now he learned it the hard way. As long as Tuxedo doesn't do this mistake again, I think we can count this outcome as a win
........... What?
I feel the same.
@@totoshampoinask chatgpt to summarize
@@totoshampoin What what?
measure twice cut once mentality needs to be implemented more frequently...
I admire the fact that you managed to make this entire video without mentioning Nick from The Linux Experiment
...Not that he had anything to do with this story, it's just that I wouldn't know about Tuxedo computers if not from him and I think I am not alone here. I think Nick got the Tuxedo brand a lot of visibility.
hahha I was thinking exactly the same. Wasn't going to mention it till you brought it up in the comments.
If I had a penny for each time an open source related project had problems with licenses, I'd be richer than Elon.
And then get treated like they're the devil.
I think using the word incompetence is probably a bit harsh, seems more like a case of a small company that doesn't have a lawyer on staff and not having the skills in house to deal with the issue or to make them aware of the severity of the issue
So in a way, you could say they lacked the competence to see where they fucked up?
@@azmah1999 It's a different skill set, I've never meet a Lawyer that can write kernel drivers, nor have I even meet a lawyer who could design a water treatment plant. just because you don't have training or experience in a field doesn't make you an incompetent person. And you can't expect small companies to have a lawyer on staff, it may have been a case of it taking them several years to find a suitable lawyer who is familiar with software licencing that they could even hire to help them, remember they are a German company not a USA company, so they are not in a region where people sue you just because a napkin fell on the floor.
@@daveamies5031I think this may be an interpretation difference on your part. If I'm a dev, I'm hopefully very competent in certain languages, less competent in certain others and probably incompetent in the rest. I may also be a competent woodworker as I do that as a hobby, but a completely incompetent mechanic.
Tuxedo made mistakes because of incompetence (in legal issues). However, they aren't incompetent in general.
not many people are competent in international software licensing law, aren't there whole countries where the license remains virtually untested?
I highly doubt Tuxedo wants to piss off the upstream of the OS they built their entire business off of lol. This has to be just being painfully unaware.
Honestly, there should probably be some kind of FOSS license consultant lawyer firm. I have raised issues of open source license noncompliance at one of my jobs, and let me tell you, it was NOT taken into consideration at all.
What people don't realize in regard to the different GPL versions is that the general assumption of "higher is better" doesn't always work. Another example was GNOME, which I left after they degraded it terribly in the switch from 2 to 3.
The code I write is either GPLv2+ (because I don't think anything I write in my code is patentable, which is the only advantage of GPLv3), MIT (because it's simple but not too simple), or the no-problem-bugger-off license (which is simply four short sentences "Sure. No problem. Don't worry, be happy. Now bugger off!") for the code I really don't feel like maintaining but which still could be useful for others. OR it is whatever the package owners of what I'm contributing to chose (eg. openssl is Apache 2.0, opendkim/opendmarc are licensed like sendmail which is a bit weird, but ok, and there are others as well).
I personally like MPL the best. It's able to be used in anything as long as you mention you are using it and only requires you to redistribute if you are adding anything directly to it.
That way you aren't blocking it from being used alongside any other code, you get credit, and you prevent the embrace, extend, extinguish risks that permissive licenses have like that prevent software like BSD from benefitting from common development from Apple or Game Consoles.
Personally, I'm a fan of the WTFPL.
i personally like the AGPLv3+, and more extreme variations like requiring the entire stack to open source(similar to SSPL but without money exemptions so it remains FOSS)
What FSF license REQUIRES redistribution?
I can fork any type of GPL license code and make any changes for my own use and no one can force me to make those changes public until I distribute it. And then, I don't have to make the changes available to just anyone, just those that I distributed to. Of course, they can make it public if they wish.
That is the way it should be.
@@nobodyimportant7804 They're not fulling spelling out what they mean. "Redistribute" means "redistribute the changed source code under MPL"
What they mean is, unlike the GPL, which requires you to license your entire project(including all of YOUR work) under the GPL if you're including a GPL component, the MPL lets you keep your portions of the whole project under any license you want. If you distribute the resulting project, the only time you are required to redistribute source code under the MPL is if you make direct changes to the MPL code. Those changes specifically need to be redistributed, also under the MPL. The rest of the project does not.
MPL mentioned let's gooo
And I think the most important thing about it is that it takes effect on a file basis
Which means if someone else uses your project, only the copied files are under that license, the rest could perfectly be another one
Unlike the LGPL that I believe is meant to be used with shared libraries
And since the part of your project is meant to be "replaceable", that has some problems when you want to have something compiled all together but also under a different license
Sometimes, the best thing someone can say is, "Have your lawyer contact our lawyer and let them straighten this mess out. Here is the contact info."
Imho it's obvious it was incompetence.
And tuxedo-drivers ain't even mandatory for many of their models, they are pre installed only because some of their more niche laptops have components without upstream support, and anyone who asks "booo why no upstream?!" just shows that they are clueless.
Most of the time you are free to not install tuxedo-drivers in their nicher laptops too, result being missing hardware functionality such as fan control, keyboard backlights, etc.
Good that this situation resulted in a resolution.
And by the way, even if tuxedo did everything "perfectly" and tried to upstream everything day 1, the dkms situation isn't leaving any time soon.
New laptops are released constantly, if they had to wait for a kernel merge and a new kernel release with said new drivers they would not sell anything. Especially taking into consideration that up until 2022 they weren't offering their own distro.
What do you think is worse, a FOSS dkms or a new laptop that literally lacks working advertised hardware niceties, or said hardware niceties only work on bleeding edge distros?
Be realistic.
thank you for being like the only person who understands this!
if the new laptops are to be supported immediately when they come out, upstreaming the changes to kernel is just too slow.
there are also some more niche things like having to come to terms with the kernel devs about how to structure certain apis if some functionality does not yet exist (see kernel mailing list about how to handle keyboards with backlights that allow every single led to be controlled, which the kernel devs wanted to have one sysfs path for every single led - which is slow and clunky which would make animations basically impossible)
Then they better not pretend that they support Linux then. If I can only use the manufacturers custom distro for basic hardware support (fan control is not a nicety) then it supports one Linux-based OS from a small vendor.
@@LordVarkson
Tuxedo drivers are packaged by them for virtually 99% of distros, Debian, Fedora and Arch based, and packaged by the community by niche distros like Void Linux. So no, no one forces you to use their custom OS.
Anything that is supported upstream will work anyways, it's the unsupported stuff that they ship tuxedo-drivers for, that's a service they offer to you, they make stuff work before upstream.
If you don't want any of that, and want all your drivers to be upstream, then just don't buy, do market research yourself, it's simple.
But personally I am glad to know that I can buy a laptop and be certain that battery charging limits, keyboard backlight, fingerprints, etc, are working/not working out of the box.
Eventually they should be upstreaming everything, which is why I am glad this was resolved. But the dkms is unavoidable if you want to be a legit business.
Like, can you imagine for a bit? If they waited out a year for stuff to get merged & released before they started shipping laptops, people would complain about outdated hardware. Not only that, but you also have to amount for the people running LTS distros that will be spamming their support team(reminder it's a 50-people company).
On the other hand, if they ship their own DKMS, people complain about upstream, can't win apparently.
@@CristalianaIvor Yes most people aren't devs and it shows.
They also can't see this from a business perspective, they are basically asking for tuxedo to be a reseller, buy standard laptops from others, wait for upstream, and then sell them year later to make sure people running LTS on their laptops will work out of the box. People would then complain about outdated hardware.
Unless they genuinely believe shipping a laptop that works only with bleeding edge distros is acceptable given tuxedo's target audience and goal.
People are always so quick to judge, but I am glad I am seeing this, because it has me thinking if I too suffer from such shortsightedness on other topics.
License it GPLv2 compatible in the first place, then.
The Nvidia binary driver is almost certainly a GPLv2 violation as is this. It's just that the Linux kernel devs choose not to enforce it in court.
not really, in linux there are three types of drivers. Drivers compiled directly in the kernel (those are GPLv2), Loadable modules that are GPLv2, those are presented an interface that almost never changes, and is the full interface for a driver to the kernel. Loadable modules that are binary blobs, or non-gpl (like nVIDIA's propiertary drivers), those are presented with a reduced intewrface to the kernel (and the interface changes quite often).
Search for Linux Kernel Condom Defense, and go down that rabbit hole
It's a little more complicated than that. Linus took the "derived works" statement in the vanilla GPLv2 the wrong way and asked the FSF for a version that allows for linking to GPLv2 code.... then later introduced "strict GPLv2 compliant linking" because he realized he messed up. This is why some parts of the kernel allows proprietary modules to link to them, but others do not. And Nvidia carefully avoids the parts that would get them booted.
When you are rich/powerful enough, you are de facto above the law until someone more powerful comes after you.
NVIDIA driver doesn't use GPL symbols in the kernel afaik
@@X11R11 The license itself has no concept of a "GPL symbol", all kernel code is under the GPL. The GPL symbol mechanism is basically a gentleman's agreement.
Tell me you're German without telling me you're German
Tuxedo: *overcomplicates git commits*
Basicly, my experience with many German companies...
Whenever the LKML gets brought up, I know to start popping the popcorn.
Never attribute to malice what can more than adequately be explained by incompetence. First I thought this was a case of upstream control in the sense of 'keep features exclusive to tuxedoOS or make them hard to access for offbrand distros'. The more context I hace seen this shifted more and more to 'The got told 4 years ago, forgot, and now the wrong person happened to notice, someone who did not grasp all the consequences made a decision, realised there was a problem, reverted without communication and this mess happened.
the crazy part is GPLv3 only exists because of some obscure Tivo hardware that briefly existed 20 years ago. One company broke the open source world xD
tivo kicked off the license but they're not the only company to do such things.
@@lorenzo42p oh perhaps, but it's such a technicality. it was not worth splintering the kernel like this over some edge cases nobody knows/cares about anyway.
@@ovrskr the only thing I can think, maybe linus didn't want to scare away companies from using the kernel. more use at the cost of a bit of freedom. I don't agree with that myself.
@@lorenzo42p the hypocrisy is the GNU foundation does the same (LGPL is designed to allow GNU software to run on freedom-less platforms, and they happily ship binaries for Windows etc)
This almost certainly resulted from incompetence and internal miscommunication or unawareness at Tuxedo Computers.
To the question of what we run, recently I have made TuxedoOS my secondary OS of choice and I recommend it to most newcomers.
Secondary since my main desktop and laptop run Garuda Linux, an Arch derivative which works surprisingly well for me.
But I maintain more TuxedoOS systems than Arch (based) systems at the moment.
Interesting licensing mishap, but while serious it does not affect the technical merits of the distro.
So unless this repeats multiple times, like Manjaro's various mistakes, no reason to distro-hop over this.
The comma separates clauses, the allegedly is nothing to do with the purposely.
License and legal stuff is really a deep knowledge, I really admire people who can understand all this. Just curious, I have zero to none knowledge about all this and I want my project to be safe, can I just use BSD or MIT license?
You could, but I'd personally recommend something like Apache or MPL. Look around you and see what your programming language's libraries or programs generally use, and stick with that.
What does "safe" mean? Who are you trying to protect your code from?
I might be straight up missing something with this right now cus software licensing makes my brain hurt, but why was the response from the kernel developers so harsh right on the offset while tuxedo was trying to at least somewhat fix it? They acknowledged they made a mistake, I don't see why they had to go right for the cut-throat option of bricking every tuxedo laptop in a customers hands opposed to just... giving them a few days to at least try to fix it and moving on from that?
Because certain kernel functions cannot be used with non compatible modules *this was mainly against nvidia originally iirc) but because GPLv3 isn't compatible with GPLv2 GPLv3 modules like Tuxedo cannot use these functions either.
They where using code they had no right to access for FOUR YEARS, and they reverted the change that fixed their licensing without checking why that change broke something. That is a severe legal issue.
> the cut-throat option of bricking every tuxedo laptop in a customers hands
I actually am not 100% sure if that is what happened here. module_license_offenders only marks the kernel itself as tainted when these modules are loaded, but I don't think that this prevents already compiled modules from using the "GPLonlyed" symbols. But I am not 100% sure.
Also, even if that commit did actually stop the Tuxedo dkms modules from loading - it still wouldn't brick user devices. Firstly, because it would only affect users after updating their kernels to a version that includes those checks (and most people don't compile the kernel from source and don't run the mainline version). And secondly, because AFAIK those drivers are only needed for "optional" features like keyboard backlighting and stuff like that. The "core functionality" of those laptops shouldn't require any custom drivers.
> why was the response from the kernel developers so harsh right on the offset
IANAL, but I think that it's because this was a legal issue. Basically, when somebody breaks your license, you can't be lenient (even if they didn't break it by accident), otherwise you are risking getting into legal trouble yourself (or getting someone else into legal trouble).
Because they had 4 years to fix it
Also sometimes courts will interpret non-enforcement of a license condition as permission to violate it. From the perspective of the Linux kernel they need to enforce their licensing all the time, even when no malaice was involved, lest they leave the door open for bad actors to abuse the percived lack of enforcement.
Thing is I do like Tuxedo OS and is a viable flavor as its kubuntu KDE Neon without snaps, I have been desperate to find a good KDE distro based on ubuntu to fill the gap Kubuntu left behind.
abandon ubuntu accept fedora pill
i've been watching your videos for so long now, how did i just notice that i wasnt subscribed 😭
I think this is a common "problem". Lot of TH-cam can tell how how just a small fraction of their watcher are actually subscribed. It's also the reason why every TH-camr tells you to subscribe.
Not necessarily.
If you see a lot of viewers that aren't subbed then it likely means the video is being pushed to new or even occasional viewers that aren't subbed.
Maybe you were subbed at one point but got automatically unsubbed for one reason or another
Could someone help me understand the issue here. Didn't they already say that all code they upstreamed was automatically relicenced to GPLv2? Is the issue that the out-of-tree modules were GPLv3 and could not be redistributed along with the kernel by Tuxedo computers?
Yeah I got lost on that part as well.
With the exception of a tiny bit of code none of it had yet been upstreamed so it was all still GPLv3, the issue is this GPLv3 code was being distributed with Tuxedo OS and possibly in other forms and was accessing GPLv2 symbols in the kernel which it's very much not allowed to do.
Are they keyboard lights and a few other FN-key shortcuts gonna suddenly break on my Clevo laptop any time soon? As a user do I need to/can do anything about this situation?
I understand this "keep control of upstream pacing". Yeah, who would do that? Well, maybe Manjaro, known for taking unfinished drivers and modules from Asahi and sending them to upstream?
at that point, it's on upstream to ban contributors who send them patches that are neither ready, nor even from their own projects.
I have a Tuxedo. Pretty happy with it. It took 2 months to get delivered because I pre-ordered a new model and the date kept slipping but after that it's been pretty good.
For distributing their drivers they have a tool that you can just use. I think the only thing the license incompatibility causes is that the drivers can't be upstreamed into the kernel, but they are still usable anyway. Also their pre-installs, even of other distros, use a tuxedo patched kernel.
6:03 - No, he doesn't consider it positive. He looks at it as something that can have valid reasons and be necessary evil and also as something tangential to actual code, that's from his answer on Deb Conf.
I'm a bit lost at the point why certain modules need a specific licence to access certain kernel functions? Can someone elaborate what this means?
They may be licensed in such a way that they require a GPL v2 compatible license. For example by being licensed under GPL v2 Only. GPL v3 is not GPL v2 compatible. So GPL v3 code cannot be distributed together with GPL v2 Only code.
It's designed to piss off nvidia by locking them out of systems that foss developers have access to
They can still call the functions, they just can't be distributed with each other. The intent is to prevent proprietary software from infecting the rest of the project. And they may have been a little strict with what the GPL v2 rejects
As a Tuxedo owner on a rolling release..........uhhh.......I think I might hold off updating for a bit.😮💨
They've done the relicence now so you should be fine
Question, what if a hacker develops a hack for kernel anti cheat and sell it off to make some money, does it mean that he won't be able to do that if he used a linux distro that has gpl 2 license?
The license doesn't stop you from making money off of it, but you do have to follow the terms of the license which means making the source code available, distributable, etc. Read the license carefully and pay a lawyer to check if you can.
@josep43767 , that's basically the problem. Making the source code available and distributable defeats the purpose of making money by selling it.
Never attribute to malice, what can be explained by incompetence. So definitely incompetence to me
I think it was something between the two. Meaning it started as incompetence and later on even though was noticed, since they got away with it, they thought it should be fine.
On the other hand though, I am neither fan of the linux kernel devs approach. They should have said , eg. you have 3 weeks to fix it. Tuxedo as clients and they do have a good presence for the Linux world. Breaking the systems of their clients hit also hard on the linux credibility. None of those would actually care about the overall story, and at the end the lack of timeline is a problem.
I have an even more principled issue with the approach the kernel took here. Basically they are banning certain module names in the kernel as a way to enforce copyright law. As far as I'm concerned that is a clear violation of the spirit of the GPL, making it a really ironic approach. If they go down that route they should also start banning processes based on names of known illegal programs for example. I think they really don't want to go down the route of a enforce legal thing through technical measures.
Either way, I'm working on a few GPLv3 licensed kernel modules right now, they are called amdgpu, usb_storage and snd. Please add those names to the in kernel list as well.
There is a crossover where incompetence is indistinguishable from malice. That point was the reversion of the patch. There is no non-malicious to do that without then publically notifiying the contributor. If they didn't have authority to merge it then it should have waited for a lawyer sign off, there is no way to have done that without someone misrepresenting the truth at some point. Either it was merged without authority or someone with authority quietly reverted it hoping to not be noticed.
It's frustrating how much time gets wasted on this. No surprise that hardware manufacturers don’t bother shipping Linux drivers themselves, leaving us to rely on volunteer Linux developers to provide drivers. The strict licensing around source code often feels unnecessarily restrictive. Even when companies like Tuxedo write open-source drivers for Linux, getting them upstream is a challenging and messy process.
It's really simple: It's GPLv2. If you are not prepared to do that, get lost. When you work with Microsoft you have two options: Follow their rules (that seem arbitrary and paranoid by comparison) and you can get your driver distributed through Windows Update or kindly fck off. A lot of small vendors chose the latter... which leads to googling PCI-IDs to find a forum post that will inform you which make and model you're working with so you can download the driver off the manufacturers website (if they still have it up... or they refer you to the OEM which only bothered to have a driver for the previous version of Windows).
Knowing which license to use is easy. Don't be dense. The kernel being GPLv2 only is extremely widely known and easy to find out. I guarantee that part of the submittal process for code requires the submitter to specifically acknowledge that the kernel requires GPL2 code. They do not leave this to chance.
The **actual** issues that have to do with licenses, is companies either not wanting to release their code GPL2, or not being legally able to (if they use other proprietary code, for example).
What about just doing the right thing since the beginning? If they licensed the damn drivers as GPLv2 since the beginning none of this shit would have happened.
I'm just an average user and I don't get this licensing or drivers stuff. On Manjaro all I needed was to install tuxedo-drivers from repo (also available on AUR) but all worked without them as well, so I'm not really sure what they do. On another partition I do have Tuxedo OS, just to have some reference, but I rarely use it. I don't like LTS systems and Arch based systems are the only ones suiting me.
However, Tuxedo laptops are not 100% Linux compatible. In fact, my old Alienware was more Linux compatible then Tuxedo laptop, that suffers from various incompatibility issues, like lack of suspend capability (need a patch in kernel to work, which only Tuxedo OS has), FN keys don't work (this is however individual issue, since all other laptops in that like have no such problem), there are some bizarre gesture issues with pad, some external hardware incompatibilities (which on the same system didn't happen on another laptop) and so on.
I have a Tuxedo computer that's 4 years old. I wanted to use Linux for development and Windows for gaming, but the keyboard stopped working after a year, I sent it to get fixed, then the keyboard broke again after a few weeks (I think the internals get too hot and mess something up in the keyboard), now it's a gaming machine with Windows only. I do not recommend it.
I had a Tuxedo system, but it was honestly not a great experience. Build quality was bad and I had a lot of problems with the audio hardware in it.
1:03 - no, "allegedly" pertains to the intent that is alleged by this company, because stated intent may not match the real intent.
"they did this purposely *COMMA* allegedly to 'keep control of the upstream pacing' *dash* and want to re-license the code while upstreaming".
A bit awkward and unusual however perfectly legible if you pay attention to the comma there. Sure, the _" allegedly to 'keep control of the upstream pacing' "_ would have been better in parenthesis but this is a valid way to structure it with the comma and the dash.
From my experience in a similar area, I think it's not exactly incompetence but selective blindness and impatience by the talented of what they don't understand. I used to work in a university, as a subject academic, and also as the sort of nerd who works out the rules and regulations. It's an acquired taste, and I could well understand my colleagues who weren't the least bit interested; but some would refuse to admit that this sort of stuff was anything to do with them at all. I'd say "I know what you want, and it's good, but the way you're doing it won't work in the system, and it's affecting your students. Let me design some regulations for you that will do what you want, and the computer won't barf over." "No, I did it this way in my last university and I'm not going to change for some bureaucrat." Well, you can kind of see that, but you need some kind of system: in the FOSS world, legal technicalities are what keeps it FOSS, so you have to respect them, even if they bore the hind leg off a donkey. I never had the nuclear option, but sometimes I'd have used it if I had.
GPLv3 is compatible with GPLv2 or later, by the wording "or later".
That’s what I’d assume, but I’m not a lawyer
But Linux is GPLv2, not GPLv2 or later.
yeah the linux kernel is gplv2 ONLY not "or later"
Destroy modernity and return to the farms. Life is simpler than the over-complication we seem to be experts at doing.
I'm watching this from a very non-bricked Tuxedo Mini which I got about 1.5 years ago. I do love the machine! Only problem I had was that the wi-fi was not working with Debian out-of-the-box, but since it's basically a desktop machine it did not bother me as it will be just connected to my optical modem (60cm away) using Eth anyway.
Originally it came with an USB stick (a nice, sturdy one) to auto-install their distro -- perhaps the wi-fi problem would have been resolved by using that. However I had not even realized that and just used the stick to install Debian :-D
Brodie, I know this is a bit of a random question, but what laptop do you daily drive with Linux?
I don't daily drive a laptop but I do have some chromebooks I need to mess around with
I think, whether something was a failed attempt at being sneaky or an honest mistake, being openly apologetic is actually rather irrelevant.
How a problem is handled is often more important and telling about a person or company than the nature of the problem itself.
I'm not a big fan of 'Sorry, I didn't know.' That's something a high schooler would say to their teacher and expect to be forgiven as always.
I do believe that when it comes to running a business, ignorance is a form of incompetence. It was your job to know ... or to consult someone who does. A lawyer in this case.
However... reacting harshly to the point where it interferes with someone's attempts to correct their mistakes is unproductive.
This isn't a billion-$ corp trying to screw us over. Let's just wait and see how this plays out; now need for pitchforks just yet.
Corporate does corporate things. A true classic 😂
I mean people here are arguing that they're violating "people's right to upstream their code" which is crazy to me, if i go to the effort of sitting down, cranking out a driver and crafting it into existance i don't expect you to swoop in behind me and publish it to the kernel without my knowledge or permission, i didn't even know this was a thing, opens up a whole new game for the those people desperate for Kernel commits to get into the habit of doing i guess, it's better than README nonsense i suppose lol
It's with stuff like this that the whole concept of FOSS becomes repulsive to me, digital communism that ironically mostly benefits big corporations and completely wrecks small developers actually doing the work, it's wild
@@SXZ-dev none of what you said is how any of the concepts in this story work
I have a clevo laptop but rely on drivers from tuxedo to control the keyboard and fans.
I use Tuxedo OS, but with my own hardware, so i don't really have much of an opinion other than that I'm happy its all sorted for them
I'm going to say neither are the word that applies. It's not malice, nor merely incompetence. It's negligence. If you're going to be dealing with anything that has any legal ramifications, you had better know the situation you're working with or proactively work with someone who does. That's not even a should, that's mandatory. Because I guarantee if you fuck up, no one who has to deal with it is going to have any sympathy that you couldn't be bothered to handle it when you should have. More so when you had every opportunity to consider that maybe you should at least double check.
i feel like there's way more to explain to a noob like me. I get thing, told I'm free to use it by the people who made it... the end?
Also, as far as functionality, is there anything that gives a fuck about the GPL version? or is that effectively just meta data? Maybe I missed some stuff being such a noob.
Meanwhile big corporations just laugh as they steal all the free code from open-source regardless, licenses be damned... :/
I actually have a Tuxedo. It has great specs even at almost 3 years old, works well with many distros (I'd recommend skipping Tuxeodo OS though), and been pretty durable. I might get another one.
No wonder dkms updates everytimes theres an update for me lol (tuxedo customer). Its not that bad updating, but would be great if it was just part of the kernel.
It sucks because the control center software is honestly great and easy to use for power and fan control for those who don't want to write custom scripts and all that for detailed control.
I wouldn't call it incompetance either. Seems like a honest mistake when starting out a company, which was then forgotten about because "it works". Please don't be harsh towards them.
They candidly accepted the mistake, and are working on it. You can cite very few examples of good citizenship like this.
Otherwise, if the backlash is too harsh, people will just make all drivers proprietary. Please, let's give them a change, and see how they fix it.
I have a clevo laptop and have used their software in the past. Those clevo modules as well as uniwill are developed by tuxedo.
Next time on Tuxedo Computers: "The entire country of Australia is BANNED!!! (because it does not exist)" xD
Actually, we have banned Australia years ago! xD
On a serious note, we've had some weird cases with lost parcels, hence we suggest to use a parcel forwarder if ordering from us. I remember that it took like three months and two attempts until a small LCD cable we shipped to a customer eventually arrived - just one of many examples why Australia cannot be currently chosen as a delivery address.
I don't understand what they thought they were going to do with controlling the pacing of upstreaming.
Just another reason to buy System76 hardware. At least I've never heard of them violating the GPL. I just don't think that Jeremy would allow it and it seems like Richell is a good dude.
"They did this purposely, *with the alleged motivation* to..."
FTFY
What's ftfy
@@gekkkoincroe It stands for "fixed that for you". Although in my opinion there was nothing wrong with this sentence and the "fix" is unwieldy.
@@KartonRealista2 I don't see anything wrong with the sentence, but Brodie misinterpreted it, so I "fixed" it to eliminate the possibility for the misinterpretation he made.
I met Tuxedo Computers at some cons, probably the marketing guys and I have to admit, everytime I wanted to dig deeper into their hardware stuff and ask serious questions, they kinda dodged on upstream kernel as I was considering that stuff as hardware to run gentoo linux on...
They don‘t make the hardware. The marketing guys don‘t know much about it.
It may depend on the specific con. Especially for Linux-oriented fairs like the FrOSCon, we usually have some of our developers with us so we can tackle these deeper questions. Our team has grown in the past few years noticeably and we hope that this will continue to shine through upcoming cons.
IMO If your main sales pitch is that you are selling computers compatible with Linux, its extremely misleading if you are using drivers to achieve this that do not conform to the Linux licensing model.
I'd expect any company making a big deal about selling Linux compatible computers would be mainlining any drivers needed.
i haven't been online for like 2 months and my man Brodie already became a chonky boyyy
isn't this what android and google do, except they're worse? or is it fine when they do it because it's userspace vs here where it's kernel space? seems like an internal conflict that we shouldn't be having when there are much bigger issues
Covering OS scandals is my favorite part of your channel
Open source means do it yourself if you don't like how they did it
linux kernel developers trying not to break userspace (challenge impossible)
I just got a new computer from Tuxedo shipped yesterday. Haven't had time to start it up yet.
21:08 certainly not a lawyer but definitely a great detective
luckily i didn't buy a tuxedo product and decided to go with a T460 Thinkpad.
they had some ads in tech magazines over here.
I still don't understand the pacing thing. If your code isn't ready, it doesn't go upstream. Hell, wasn't there pretty heated arguments between Linus and Kent for the exact opposite situation where Kent was trying to push code to production after a freeze? No one is going to mind if you wait until the next release window.
The kernel would much rather something be basically broken for years but functional, than code being pushed before it's ready
If you were a company, you wouldnt want having a competitor just after you launched your flagship laptop. Because if your drivers are in the upstream, any compatible hardware could use your drivers for free. Whats the incentive to buy them from Tuxedo then ? Drivers for your old models wouldnt be a problem after you sold all of them.
@@BrodieRobertson Exactly
@@gokhanersumer2273but wasn't the driver source all available under GPL V3? So a competitor could still take it and use it the same way Tuxedo was using it?
@@gokhanersumer2273 the drivers are already open source, they can already use them they're just not upstreamed
Well, I have never deleoped a kernel module, but if I came across a macro like MODULE_LICENSE("GPL") in a GPLv2 codebase that cares about the distinction between GPLv2, GPLv2+ and GPLv3, I would assume "GPL" to be a catch-all, meaning "any GPL version". Using "GPL" to implicitly mean "GPLv2" as a distinction to "GPLv3" is frankly bad form and smells like historical baggage.
Now, yes, they absolutely should have talked to their lawyer and read the documentation more carefully, but this is an incredibly easy mistake to make.
And going "don't you dare suggest our documentation is bad" when the other person already acknowledged the documentation was there and they were just not aware of it, is simply hostile and counter-productive.
This right there is why I have always refrained from getting involved in the kernel, being roasted for any mistake even after admitting it and working to fix it is something I thought we all left behind us on the elementary school playground...
I was thinking the same thing. I cannot believe "GPL" is a valid parameter there, it's just common sense to force GPLv2 or GPLv3 (or, as someone mentioned elsewhere, what about GPLv1?)
@@kusucks991 Pretty much nobody uses GPLv1, so it's entirely irrelevant. Anyone wanting to submit code to the fucking kernel can reasonably be expected to be vaguely familiar with the GPL and the kernel license.
It's most likely named that for legacy reasons, and can't easily be changed without permanent depreciation and never being removed. Remember GPL 2 predates all the other versions you can pick there, and the other option at the start was probably "proprietary" or non GPL licences
I'm starting to think Ngompa is the main character of this timeline, and we are all just extras.
That dude is everywhere!
In this case, "purposely, allegedly" is actually valid English, if a little awkward. To rephrase it, it can mean "they did this on purpose, with the alleged reason being ..." or perhaps "allegedly, they did this on purpose" meaning someone is making the allegation that they are doing it on purpose.
I have a tuxedo and am using their OS. Wanted to go NIxOs, but now I’m concerned this may be much harder….
with Tuxedo moving from GPLv3 to GPLv2+, the issue is already resolved. I would not expect any kernel version to release with their modules blocked.
I get Manjaro vibes here.
Eh not entirely.
I was thinking of manjaro when Brodie was saying "but who would ship unreleased drivers without talking to the developers?"
No. It was just mistake. They will correct it.
"They did it on purpose, allegedly to ..." - makes sense. They did it deliberately, and the purpose they stated was "...", but we do not quite believe it.
You might acquaint yourself with the concept of "," (comma).
I honestly don't think they were ever going to change the licensing. So having their hand forced like this was the only way it was ever going to happen.
Using the latest version of a license does not seem to give the same vibe as using the latest version of a software.
Thanks so much Bordie, you video explained the thing and the license. Hope we all happy now, including Tuxedo :D
Yay another episode of the adventures of neal gompa
I run… Adidas?
FreeBSD in the past couple of weeks, actually. Time to broaden my knowledge…
This sucks so much, because they're the only ones currently offering Linux-compatible laptops with a combination of AMD CPU and Nvidia GPU. All the alternatives I know of, including System76, only offer the trash-tier Intel 13th and 14th gen CPUs (no, I'm not trying to crap all over companies like System76, because it's not their fault their providers have exclusivity deals with Intel). Back to looking for a Windows laptop to fight with, I guess.
I remember seeing StarLabs having AMD CPUs, but it was a long time ago.
Last I heard the Lenovo Thinkpads (non-E at least) are fully compatible except the fingerprint sensor sometimes.
Is this not actually the case?
Framework supposedly has pretty good linux support, although they only do AMD + AMD for now (or Intel + Intel, but cmon).
Hmm, my Asus laptop with AMD CPU and NVidia RTX 2070 work just fine with Ubuntu.
@@LazarNaskov Yeah, Framework is top-tier, but I sadly do need CUDA for work.
I use Tuxedo. Should I never update?
Bro, when universe would reach heat death, linux nerds would still be arguing which open-source licence should some code have to be working.
Yeah that was a poor decision by them.
I think purposely, allegedly does make sense. The reason i think this is because its meant to be read somewhat like this; they did x action on purpose with the alleged reason of z. In fact the alleged reason proves they did do it on purpose, but if you have doubt on the reason given then you could still say "they allegedly did this becauss ' yada yada yada'"
You see the difference? Its not it being on purpose thats alleged but the reason given.
What proportion of kernel devs are paid?
This looks to have been a deliberate attempt to make their in-house distribution the easiest thing to run on their hardware, since dkms is not always smooth and easy to use on common distros (at least it wasn't the last time I worked with them). There is just no other simple, reasonable explanation for these license shenanigans. It *could* have been RMS-style fundamentalism (his partisans aren't thrilled Linux is GPL2), and that would even have been probable given they're Germans, but they would've proudly declared that as the reason if it were true, and they didn't. Another option would be that they somehow think they'd be violating NDAs by releasing the source, but then it wouldn't have been open sourced under GPL3. Nothing else makes sense.
It's especially weird since people fall over backwards to upstream as soon as they can to reduce maintenance burden, the code is relatively small/trivial (and the standard for driver modules is more lax) so shouldn't have been much of a problem to get into acceptable shape. So if a company does a weird thing that makes no engineering or practical sense *except* it magically means their stuff can't be shipped easily with other distros.. you have to assume malfeasance of some description. The fact it is mixed with ignorance isn't exculpative.
Every kernel programmer who writes drivers is aware of the license issues and specifically the GPL2 requirement for full kernel API access. If they are not, they are not kernel driver programmers and need to RTFM (at a minimum) before being allowed to submit patches. If not more, since their one attempt to upstream a relatively trivial driver went badly (this is unusual).
Tuxedo does not make the hardware that they run the software on. I have had a computer similar to one of the models that they sold.
Tuxedo made the drivers detect a BIOS variable that they would set on their BIOS, and locked these drivers from working on hardware where it should. (I set this BIOS variable on my system, and the drivers worked without issue) This sort of behavior is precisely anti the spirit of the GPL. In my talks to Tuxedo, they were friendly but ultimately very unhelpful. In the end their position appears to be that they rely on the Open Source community for their entire OS, but are unwilling to let their drivers be used by the Open Source community unless they bought the hardware from Tuxedo.
Seeing their position on working with the open source community (which they depend on for the rest of Tuxedo OS which they did not write) I decided that my next computer will be an ASUS. Build quality is much, much better, and ASUS actually has people who work on Linux drivers specifically that get into the Kernel.
Yes, you can say "purposely, allegedly". In two ways this makes sense. Either the purpose is alleged, or, as the comma here indicates, the reason WHY they did it is alleged .i.e. there mightve definitely been purpose behind it, but the reason why is not proven. Now i dont know what is in fact true here, but the sentence absolutely makes sense.