Talk:Linux kernel/Archive 9

Archive 5

←

Archive 7

Archive 8

Archive 9

Linux is partly proprietary

Linux has been deblobbed by the Linux-libre project for over a decade now, which regularly removes all the in-tree blobs. By not mentioning this in the article, it is lying by omission, asserting either that Linux has no in-tree blobs, which is obviously false, or that the Linux-libre project is lying, which is also obviously false.

Past attempts to rectify this mistake were stopped and removed from the Talk page, so the article still contains falsehoods to this day.

See also: https://www.fsfla.org/pipermail/linux-libre/2020-August/003400.html

185.217.158.63 (talk) 00:40, 7 February 2022 (UTC)

To correct myself: past attempts were moved to archive 7 of the talk page.

185.217.158.63 (talk) 11:20, 7 February 2022 (UTC)

Hi 185.217.158.63,

Thank You for Your recent set of contributions!

I'm not knowledgeable enough to tell if You are right about Linux being partially proprietary, but considering that You have not yet cited any (reliable) sources, I am going to tag it as disputed for now and link to this discussion. – K4rolB (talk) 18:42, 11 February 2022 (UTC)

I'm a Linux kernel developer with about one hundred contributions (patches) in the Linux kernel (please read the public official Torvalds' repository or simply run "git log --author="Fabio M. De Francesco").

I can assure everyone that maintainers reject code that doesn't comply with the GPL-v2.

Again, unless 185.217.158.63 proves that Linus Torvalds distributes the official Linux kernel by infringing his own choice of GPL, I'm going to remove every attempt to discredit the largest and one of the most important Community of developers.

As K4rolB stated "you have not yet cited any (reliable) sources". FSF is not reliable, is biased, and it is the only source you keep on citing.

Furthermore, you are contradicting everything it is said in the article about the license. So why not change all the rest of it, every statement about the free and open source nature of Linux, in accordance to your beliefs? Please be consistent. Fabio Maria De Francesco (talk) 01:39, 11 March 2022 (UTC)

Everyone here knows that Linux development is done by submitting patches to the LKML and that developers use Git. Each patch has its own unique "Commit number" (i.e., a "hash" that unequivocally identifies each work). Thus, is anybody here able to provide at least a commit hash for one of those "proprietary binary blobs"? I'll wait a couple of days and, if nobody will be able to prove that there is at least a patch with proprietary code (identifiable by a its commit hash), I'll revert everything that states that Linux is not free and open source software. Fabio Maria De Francesco (talk) 03:33, 11 March 2022 (UTC)

Before 4.14 proprietary binary blobs were just hosted in root/firmware in the kernel source tree, now they're hosted in a separate tree, but references to (and inclusions of) those blobs are still in the kernel. --Betseg (talk) 13:31, 11 March 2022 (UTC)

You are right. That code is firmware hosted within the official Linux kernel tree.

What some people is not able to understand is that the firmware is not part of the kernel executable (vmlinux). Firmware is executed by device's controllers.

For instance, if computers have HDD, SSD, Wi-Fi adapters, and so on, they have device's controllers that execute proprietary firmware that have nothing in common with what kernels do. Even Linux-libre can't stop firmware to be run by those devices.

Linux just hosts some firmware that must be sent to devices at boot-time. Nobody can say that the kernel is not free and open-source just because it _hosts_ proprietary firmware for mere technical reasons. The kernel object that results from compilation is only made of free and open source executable code.

People who don't understand this subject should avoid to vandalize this article.

Please read the following thread at kernelnewbies.org and follow the links that are in the messages: Fabio Maria De Francesco (talk) 17:21, 11 March 2022 (UTC)

Sorry, my phone sent the message while I was still searching the link in the kernelnewbies mailing list. Unfortunately it is not yet available because the discussion is too recent. I'll provide the link as soon as possible.

In the meantime, please read the following:

https://www.kernel.org/faq.html#i-heard-that-linux-ships-with-non-free-blobs

This link has been provided by someone of the Linux Foundation who participated in the above-mentioned thread at the kernelnewbies ml. Thanks, Fabio Maria De Francesco (talk) 17:27, 11 March 2022 (UTC)

Please see <https://www.fsfla.org/pipermail/linux-libre/2020-August/003400.html> once again.

Please also see <https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/appletalk/cops_ffdrv.h?h=v5.16.14> and <https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/appletalk/cops_ltdrv.h?h=v5.16.14> for evidence of blobs included in Linux. This is mainline, in-tree, proprietary code which is part of the kernel and loaded into devices at runtime. A large array of bytes is not source code, therefore it is proprietary software. In order for the kernel to be 100% libre software, there must be no blobs included in the kernel, no matter whether they are executed on the CPU or some other device. Whilst *most* blobs have been moved to the separate linux-firmware repo, blobs still remain embedded in Linux, which makes it partially proprietary. Moreover, Linux-libre removes references to blobs and the blob loading machinery, both of which would be technically libre, but useless in the free world since their only purpose is to load proprietary software.

Are you implying that the FSF and Linux-libre project are lying? In that case you'd need to provide evidence.

185.217.158.63 (talk) 19:04, 11 March 2022 (UTC)

<https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/net/appletalk/cops_ffdrv.h?h=v5.16.14&id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2> and <https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/net/appletalk/cops_ltdrv.h?h=v5.16.14&id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2> both show commit hash `1da177e4c3f41524e886b7f1b8a0c1fc7321cac2` on 2005-04-16, and these files were probably present in Linux earlier because the commit in question appears to be a very early initial import into a git project, whilst git was very young.

185.217.158.63 (talk) 01:13, 12 March 2022 (UTC)

OK, let's summarize what you said:

(1) I imply that the FSF and Linux-libre (that is backed by the same FSF) are lying and you are right (I imply exactly that!). Aside from those entities, there are no authoritative sources that affirm that "Linux is mostly free and open source".

(2) Your own words ("In order for the kernel to be 100% libre software, there must be no blobs included in the kernel, no matter whether they are executed on the CPU or some other device") make me think that you understand that those binary objects are not part of the kernel but they are necessary firmware. Still you keep on melting the two logical entities without regard for your own words.

(3) Did you read the link that I provided? Whilst I for sure imply that the FSF is lying, you instead imply that the Linux Foundation is lying. Who should we trust?

The problem here is that a very large part of what is inside any Linux distributions has nothing to do with the GNU project anymore (systemd, llvm, xorg, Wayland, RPM and APT package managers, and much more), but those people still want that the Linux OS should be referred to as GNU/Linux. Please notice that the Wikipedia's article about the OS is simply called "Linux" (be consistent!).

Here we have two links of the thread on the kernelnewbies mailing list thread that I was talking about:

https://lore.kernel.org/kernelnewbies/20220311141435.geqwbrtzshlhmxe6@meerkat.local/

https://lore.kernel.org/kernelnewbies/DAA1998F-0037-42CD-B20F-7E83D3DC2381@redrectangle.org/

In this thread, Konstantin Ryabitsev (of linuxfoundation.org) wrote "I doubt anyone really cares about the purity of Wikipedia articles here.". "anyone" == "kernel developers", if someone don't get it.

Paul McKenney, one of the most important kernel developer and one of the most knowledgeable person that I know in the field of concurrency and parallelism has give up since long time with writing Wikipedia's articles (please see read-copy-update). It looks like Wikipedia has a strong bias against computer scientists and software engineers. We'd better leave these subjects to better equipped people.

I have made the idea that my spare time is not worth these kind of discussions. So, if people here is happy with saying in the article that the Linux kernel is not free and open source just because it hosts some lines of proprietary firmware without which you have a pretty useless system, that Linux infringes the GPLv2 license, and other similar things, I'll give up with working on this article after about 250 edits and instead focus on volunteering on Linux development.

I mean: no more reverts of false/disputed information and no more work to improve and update this article. I'll leave the burden of this work to better suited people. Thanks, Fabio Maria De Francesco (talk) 06:03, 12 March 2022 (UTC)

1. You have still provided zero evidence that the FSF, FSFLA, or Linux-libre project is lying. In fact, you yourself have provided evidence via a link to the Kernel Newbies mailing list archive from Robert Joslyn that the Linux kernel is in fact blobbed as I have described.

2. Yes, blobs are part of the kernel no matter whether they are executed on the CPU or loaded at runtime into some other device. They are in-tree code.

3. I never implied the Linux Foundation is lying and what you describe is a false dichotomy.

Yes, the OS is GNU and Linux is just a kernel. I am shocked that you refer to Linux as a so-called "Linux OS" when you obviously know from contributing to it that Linux is just a partly proprietary kernel. Those other Wikipedia pages should be edited, but one thing at a time.

There is insufficient evidence for your claim that Wikipedia "has a strong bias against computer scientists and software engineers", and you're only saying this as a last resort because you know you're wrong about Linux not having blobs. Also, you're implying that other people editing this article or replying to this discussion are not computer scientists or software engineers, which you have zero evidence for.

"without [blobs] you have a pretty useless system" -- I use Linux-libre and it works fine aside from the non-critical components which need blobs.

I remember when I started the previous discussion about Linux being blobbed, first you denied it, then you said there are blobs but they've been moved to the linux-firmware repo, then you said the blobs I linked to were just "shellcode", and now I've met your challenge of linking to in-tree, mainline blobs and providing a specific commit hash, you threaten to stop editing! When are you going to realize that you are wrong?

Threatening to stop editing when you've been proven wrong about something is more childish than the time you started a discussion on the talk page because you were no longer the single largest contributor to this article!

185.217.158.63 (talk) 15:54, 12 March 2022 (UTC)

Your ridiculous claim on the email you linked that "fake information, mainly sponsored and backed by the FSF and by the Linux libre project (or something like that)" also has zero evidence to back it up. I am in no way affiliated with the FSF or the Linux-libre project, I just want to correct this article so that it stops stating false information, namely that Linux is "free" when it contains proprietary, binary blobs. Why are you resorting to ridiculous attempts to discredit me instead of admitting that you are wrong?

185.217.158.63 (talk) 16:05, 12 March 2022 (UTC)

I've added three citations to the article.

185.217.158.63 (talk) 16:55, 12 March 2022 (UTC)

Again, Mr. 185.217.158.63 cannot understand the logical difference between kernels and firmware (I invite her/him to attend at least an undergraduate OS course). The kernel is 100% free and open source code, while some firmware hosted in Torvalds' tree is not.

Thus a better approach would be writing something like "while the Linux kernel (core + drivers + development tools - e.g., tracers and tests) is made of 100% free and open-source code, the official Torvalds' tree hosts also some files with proprietary firmware that are needed to initialize closed-source hardware at boot time and without which that same hardware cannot be made operational". I would also add the link that the Linux Foundation sent to me for explaining why those binaries are there (https://www.kernel.org/faq.html#i-heard-that-linux-ships-with-non-free-blobs). Why the Linux Foundation should not be considered an authoritative source compared to the FSF? Fabio Maria De Francesco (talk) 12:30, 17 March 2022 (UTC)

"The kernel is 100% free [(libre)] and open source code, while some firmware hosted in Torvalds' tree is not." -- do you not see the logical contradiction here? Firmware *is* code.

185.217.158.63 (talk) 13:39, 17 March 2022 (UTC)

That's a red herring, because "Torvald's tree" is not "The kernel". The code for the kernal is part of the code tree, but not all of it. Isn't it time for WP:DR? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:10, 17 March 2022 (UTC)

Firmware _is_ code. Indeed! But unfortunately you cannot understand that firmware _is_not_ part of any OS kernels. They don't share the same address space. Kernel are executed by the system CPU cores, firmware is executed by device controller. There is no overlap. The kernel, via device drivers, talks to the devices firmware by using I/O interfaces. Firmware cannot use in-kernel APIs. Again, if you cannot understand this subjects please take a course in Computer Architecture and another in Operating Systems. Fabio Maria De Francesco (talk) 06:54, 18 March 2022 (UTC)

I don't appreciate the insults, especially after I've explained numerous times that, to be a blob, it doesn't matter whether the code is executed on the CPU or loaded at runtime into another device. You are correct, firmware loaded into other devices at runtime cannot use in-kernel APIs, but you are incorrect about there being overlap; proprietary firmware blobs are embedded in in-kernel, mainline code files, and as such *are* part of the kernel. When compiled, these blobs become part of the kernel binary itself.

I have a suggestion: since we both no longer want this to be true, why don't you look at the deblob log from Linux-libre and start working on moving in-tree blobs to the Linux-firmware repository and write code for them to be requested from the filesystem at runtime? I presume you're capable of doing such a thing.

185.217.158.63 (talk) 22:59, 18 March 2022 (UTC)

When compiled, these blobs become part of the kernel binary itself. no? That's factually incorrect. They are distributed alongside the kernel but they aren't in the kernel. The blobs that are distributed alongside the kernel are located in /lib/firmware and the kernel loads them dynamically, not statically. Betseg (talk) 18:58, 19 March 2022 (UTC)

Some proprietary firmware binary blobs are loaded from /lib/firmware as you describe and are located in the linux-firmware repository, however, there still exist many proprietary firmware binary blobs embedded within code files as long sequences of hex arrays. I already linked to a couple earlier in this thread.

185.217.158.63 (talk) 05:16, 20 March 2022 (UTC)

For example, the following blob: <https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/appletalk/cops_ffdrv.h?h=v5.16.14> has a proprietary license which states: "This material is licensed to you strictly for use in conjunction with the use of COPS LocalTalk adapters."

185.217.158.63 (talk) 05:20, 20 March 2022 (UTC)

Yeah, no, this is stupid. These "proprietary blobs" you're referring to are indeed in binary form, but they're still distributed under the same license as the kernel. The actual proprietary blobs are distributed in a separate tree, linux-firmware.

Just stating that "hurr durr the kernel has blobs in binary form therefore proprietary >:((" isn't enough to mark the kernel as "partly proprietary" as, again, these binary blobs are licensed under the GPL, just not the source code to the blobs. However, the blobs are free to be reverse-engineered by whoever whenever, since they're distributed under the GPL ;)

There is an argument to be made that parts of the kernel tree isn't distributed in source code form, but saying that parts of the tree isn't licensed under the GPL (or any compatible license) is flat-out false, so I'm taking the liberty to revert this change

Bonan vesperon. 81.234.98.122 (talk) 18:57, 1 August 2022 (UTC)

This is simply not true. In this conversation has been linked the cops_ffdrv.h file which is bundled in kernel tarball releases directly from the developers, along with other binary firmware (i.e. it is not all relegated to linuxfirmware). You're right that not all firmware distributed as binary with the kernel tarball is proprietary (this one includes ASM source code here), but you're wrong that all firmware is distributed as GPLv2(+) or compatible. cops_ffdrv.h specifically says in its header that it is not part of the Linux kernel, it is a separate program - however it is bundled with Linux and it is not under a GPL license. This is why I made the small change to note that while not all Linux firmware within the main tarballs is proprietary, at least one of them is. I also made the change to specify that the software is not technically part of the Linux kernel itself, so I changed it to say "included with" rather than "in Linux." Xerxespersrex (talk) 13:21, 2 August 2022 (UTC)

sigh you don't seem to understand. The binary blob you're referring to in cops_ffdrv.h is distributed under a GPL-compatible license, just not the source code for it. If you're under the impression that distribution terms for that blob violates the GPLv2, please do shoot a mail to the LKML where you remove it and such, and detail the legal arguments as to why it should be removed, not the philosophical/political arguments.

Again, there's an argument to be made that Linux doesn't ship with GPL'ed/GPL-compatible source code for stuff like the firmware blobs, but stating that the kernel is "partly proprietary" because of that is false since the blobs themselves are redistributable under the GPLv2.

Licensing is pretty fucky and hard to understand, but I hoped I explained it well enough for you to understand where I'm coming from.

Bonan vesperon. 81.234.98.122 (talk) 17:50, 2 August 2022 (UTC)

I did not claim that the firmware makes Linux partly proprietary, I was just responding to your post as I assumed you were the one to revert a change I recently made (the name of this section of the talk page is incidental). My personal opinion about free software is not the topic of discussion. I also did not claim that having this firmware in the kernel violates the GPLv2. If it did, then no Linux distro could distribute any software that was not under a GPLv2-only license with their installation media, assuming that firmware can be considered a separate program from the kernel legally like general other pieces of software can (I am not a lawyer). I'm simply interested in the fact that we have a section detailing the license of the kernel, and short of external projects there isn't a way to get the kernel directly in a tarball without also downloading non-GPLv2 firmware. So, it seems fair to mention that in the section of the infobox detailing the license of the software.

I don't really know what you're trying to say by saying that the license of this particular firmware that says in its comment that it is not GPLv2 is GPLv2. It has restrictions on its use, and any restrictions on its use other than those in the GPLv2 violates the GPLv2 (again, for this particular piece of software, not for the entire kernel). It may be redistributable with software that is GPLv2 in this particular circumstance (like how bash, GPLv3+, can be distributed with the Linux kernel on a LiveISO), but do you have an external source to back up this claim that it is, in fact, under a GPLv2 license? Xerxespersrex (talk) 12:38, 3 August 2022 (UTC)