Talk:Linux kernel/Archive 7

Archive 1

←

Archive 5

Archive 6

Archive 7

Archive 8

RfC on the Linux kernel licensing rules

Does the official Linux kernel code that is maintained and released by Mr. Linus Torvalds infringe the GPLv2 (and derived licenses or dual licensing with MIT)?

From the COPYING file that is located at the root of the Linux tree source code:

"The Linux Kernel is provided under:

SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note

Being under the terms of the GNU General Public License version 2 only, according with:

LICENSES/preferred/GPL-2.0

With an explicit syscall exception, as stated at:

LICENSES/exceptions/Linux-syscall-note

In addition, other licenses may also apply. Please see:

Documentation/process/license-rules.rst

for more details.

All contributions to the Linux Kernel are subject to this COPYING file."

This morning I had to revert the umpteenth edit of the nth "contributor" that stated that the Linux licensing rules allow developers of proprietary modules to upload binary code (i.e., compiled executable objects) into the official kernel tree. Furthermore, the above mentioned editors write that Mr. Torvalds regularly distributes such executables hidden in his own git branch. This implies that Linus voluntarily breaks the GPLv2, thus making himself the leader of a gang of outlaws

Contributors should read the entire Linux kernel article, and act with coherence with it. In more than one section of this article is clearly stated that Linux has not "binary blobs", although it is capable to locate and load them from user space. There are authoritative citations supporting it.

Please read https://www.kernel.org/doc/html/latest/process/license-rules.html

From now on, such disruptive edits will be immediately reverted and editors will be reported for vandalism. Fabio Maria De Francesco (talk) 13:13, 31 July 2020 (UTC)

@Fabio Maria De Francesco: That's inaccurate. The Linux kernel is full of blobs, as an IP pointed out on your talk page. Also, don't threaten to report people for vandalism when they're engaged in a good-faith content dispute with you - it's BITEy. Jackmcbarn (talk) 21:47, 31 July 2020 (UTC)

@Jackmcbarn: I really can't believe to hear that from you or everyone else. GPL violators can be sued before courts. It is a serious thing and you may read a WP article about how seriously the courts treat it at GNU_General_Public_License#Legal_status. There you find notable real cases of GPL infringements, for which people have been sued and lost. If Mr. Torvalds et al. are violating GPL rules, nobody has yet proved it. In a word, this is "defamation". If the FSF thinks that Mr. Torvalds and al. are infringing GPLv2, they have the means to sue them.

Furthermore, I've read the scripts that Linux-libre use to remove the parameters (or "magic numbers", in computer science jargon) that driver/firmware developers must pass to the hardware at runtime. Whenever they remove them the hardware cease to work. As a long time kernel hacker and device/firmware developer I assure you that using magic numbers is a necessary means to make the hardware work. For example, how do you think an open source driver could order a hard disk to locate heads/cylinders/tracks or to start and stop spinning? Kind regards, Fabio Maria De Francesco (talk) 18:49, 1 August 2020 (UTC)

@185.89.35.4:

@Jackmcbarn:

Please let me add something more about magic numbers vs. binary blobs. In February of 2007, I wrote an article for the issue number 165 of an Italian monthly magazine called Computer Programming, published by the Gruppo Editoriale Infomedia S.r.l. It was about a special kind of "binary blob", more precisely a "shellcode", put within the source code of a C program. Its purpose was to open a shell (a command prompt, in Windows). I just put that binary blob in a char array like this:

char shellcode[] = "\xeb\x18\x5e\x31\xc0\x88\x46\x07\..."

The array has 47 executable opcodes disguised as the content of an array of characters (I've copied here just the first 8 opcodes, for to not incur in copyright violations and other obvious issues. The intent of the the code is to replace the current program with a shell, whenever users input some specific sequence of input.

The point is that executables hidden within C source code are easily recognizable to a trained eye. And it's easily provable before the courts. The deblog script of Linux-libre doesn't tell the difference between a "shellcode" and innocuous magic numbers like these: #define NOP 0x90, #define BSIZE 512, #define OFFSET 0, and so on. Fabio Maria De Francesco (talk) 19:53, 1 August 2020 (UTC)

@Jackmcbarn:

@Fabio Maria De Francesco:

Richard Stallman, as stated in the article, believes the Linux kernel has been violating the GPL for a long time. It's not defamation to say this, because the blobs detected by the Linux-libre deblob scripts are evidence.

Evidence for what? Well, the blobs are probably all completely undocumented. The ones I pointed out are completely undocumented huge arrays of bytes. What do they mean? How can I modify them? This obviously violates the GPL for not being the "preferred form of a work for modifying them."

However, you mentioned that some of them may be magic numbers. These are very easy to detect, as tools such as file and binwalk will automatically pick them out for you. Magic numbers are usually only a few bytes long at most, and usually determine what type of file proceeds in the data.

I think you are conflating magic numbers and initialisation code. How can a magic number take up hundreds of lines of bytes? I think they are more likely to be blobs.

I do want to be proven wrong though. There are tons of devices that would start working again if Linux-libre was unnecessary. However, its mere existence is a big red flag.

Could you prove any one of the blobs detected by Linux-libre's deblob scripts is not a blob? You said that executables would be easy to spot.

Once again, I thank you for all your work improving the article.

Thank you. :)

185.89.35.4 (talk) 21:16, 1 August 2020 (UTC)

@Jackmcbarn:

@185.89.35.4:

You provided three files. I've had just few minutes to review one of them. I must admit that wanxlfw.inc_shipped contains a huge array that contains binary opcodes (exactly like the example of the shellcode[] array that I wrote). But there is a fundamental difference: wanxlfw instructions are meant for execution by the controller of the related device, whilst my code is meant to be executed by the computer CPU (in fact those 47 opcodes are written using the x86 ISA). The GPL complaint wan driver simply send the content of the above-mentioned array to the I/O controller ports. That means that that code is not meant to be in execution within the kernel address space and it is not executable by any CPU. I don't see x86 or amd64 code in it (ok, I have little knowledge of other architectures).

Most devices have their own software embedded in ROM and EPROM, software that the controller needs to make the device work. For example, my Samsung 850 EVO has it in its own read only memory. The device driver of the kernel doesn't need to load it every time the computer starts. However some devices need runtime injection of firmware for maximum efficiency and compatibility with the kernel. This is the case, in my opinion.

If you have time for one more notable example, please keep reading... Intel provide free documentation of their ISA, but people forget that that instruction set is interpreted by means of a special kind of firmware known as "microcode". Microcode resides in read only memory within the CPU. Even a simple "mov ebx, eax" (i.e., the copy of the content of one register to another) is an implementation mystery. However, the Linux-libre de-blob script removed an Intel file that was there to upgrade that firmware (for security and efficiency). Ok, if you choose to throw away your older i5 and replace it with a new one. That firmware upgrade wouldn't be necessary anymore (at least, until someone spots a bug in the newer CPU).

I think that forwarding firmware to hardware controllers, and even to CPUs, doesn't break the GPLv2. The prove is that the FSF would've already sued Mr. Torvalds, the community of Linux hackers, the hardware manufacturers, and so on if they could win before the courts. Thanks, Fabio Maria De Francesco (talk) 22:45, 1 August 2020 (UTC)

I don't have the background to comment on the legal issues, but I see several technical problems in this discussion.

1. Programming in machine language is error prone; unless there isn't even an assembler for the device, best practice is to use an assembler or other compiler. I am suspicious of any claim that firmware provided in binary was originally written in binary. Technically, it is easy to provide source code for firmware and also encapsulate the object code in C or some other language, satisfying the spirit of the GPL.
2. If you have to write restricted code in support of proprietary interfaces, I know of no technical obstacle to putting it in an LKM rather than the kernel.
3. Some devices have restricted interfaces; not all do. In particular, I've written code for disk drives without requiring any proprietary information.
4. Unless you need to update the microcode, it's irrelevant how a particular Intel processor implements the ISA.
5. Linus has no responsibility for what Linux-libre breaks; that's an issue for the FSF. Shmuel (Seymour J.) Metz Username:Chatul (talk) 03:40, 2 August 2020 (UTC)

@185.89.35.4:

@Jackmcbarn:

The firmware in the file https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/gt215.fuc3.h?h=v5.8-rc7

is from the Nouveau project and it is released under the MIT free license which is compatible with the kernel licensing rules. Nouveau are working hard since years on free code to replace Nvidia proprietary drivers for video cards. Fabio Maria De Francesco (talk) 11:44, 2 August 2020 (UTC)

@185.89.35.4:

@Jackmcbarn:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wan/wanxlfw.inc_shipped?h=v5.8-rc7

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/aic7xxx/aic79xx_seq.h_shipped?h=v5.8-rc7

The two files above are neither .c or .h files. Their type is .inc_shipped. That suffixes make me think that, being neither Assembly or C file types, they were just put there for documentation purposes. However I'm going to talk about them with the drivers maintainers as soon as possible. Fabio Maria De Francesco (talk) 11:59, 2 August 2020 (UTC)

@Fabio Maria De Francesco:

@Jackmcbarn:

@Chatul:

This whole situation really unsettles me and something doesn't add up here. Why does Linux-libre exist if the blobs are actually free software? If they aren't blobs, why do people keep changing the page to say there are blobs? If they aren't blobs, why aren't they in, "the preferred form of a work for modifying them" ie. source code, instead of suspicious, long sequences of bytes with a a nonstandard ".inc_shipped" file extension? Why are they not written in assembly at least? Why are they undocumented? (By the way, the Linux-libre deblob scripts are not perfect and will sometimes remove false positives.) My gut feeling is that we are all correct in some small way, in that we are all clinging onto some kind of kernel of truth, if you'll pardon the pun. I think what may be going on here is that free software licensed binary blobs are technically compatible with the GPL, on the sketchy basis that these binaries don't actually have source code, because they were written in hex. I've only ever seen someone program in hex like this once before, and it was just a trivial experiment, let alone hundreds of lines of firmware. Again, this whole situation unsettles me.

Unsigned comment by 185.89.35.4 14:14

Please sign your posts.

Linux-libre exists because of the ideology of RMS and the FSF, which Linus does not share. I regard GPL 3 as an abomination, and will never use it for anything that I write.

I share your unhappiness at binary data embedded in actual source code, although I have no problem with embedded binary data that are generated from publicly available source code. Whether the first is a license violation is above my pay grade.

I've written hex (and octal and decimal) code; it's not something that I would do when there is a reasonable alternative. Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:55, 2 August 2020 (UTC)

@Jackmcbarn:

@Chatul:

@185.89.35.4:

I want to stress what Chatul wrote above: "Linux-libre exists because of the ideology of RMS and the FSF", and Linux-libre is a Linux distribution, not a fork of Linux kernel. It dates back to when Linux distros (Linux OS) dropped the GNU before Linux, as in GNU/Linux. I've read the code of the de-blobber script, that is written in plain Bash script language. It also removes every occurrence of functions in kernel code that load firmware from filesystems (in userspace). Loading firmware from userspace and linking it to the kernel address space is a Linux feature and it is a lawful (GPL) acceptable and necessary practice. However, whenever using that for loading proprietary firmware the kernel is marked as "tainted" until next reboot, and nobody in the Linux community would fix bugs in a "tainted" kernel. Please read the relevant section about "tainted" kernels and the authoritative citation that I provided.

Finally, I also want to stress again that GPL violations have serious legal consequences. Whoever thinks that Mr. Torvalds is violating that license should sue him in court. The FSF has the means to sue him but they know they cannot win. Can they? Fabio Maria De Francesco (talk) 17:13, 2 August 2020 (UTC)

@Fabio Maria De Francesco:

@Jackmcbarn:

@Chatul:

I don't see how the differing ideology of RMS and the FSF, and Torvalds has anything to do with this, let alone the GNU GPLv3. Linux-libre is GNU GPLv2-covered, just as the mainline Linux kernel is. Only the copyright holders of the Linux kernel have the legal right to change its license. Everybody, please read the following thread on the Linux-libre kernel mailing list archives: http://www.fsfla.org/pipermail/linux-libre/2020-August/003400.html (I apologise; I forgot to sign my post last time.) 185.89.35.4 (talk) 15:09, 2 August 2020 (UTC)

It has to do with the fact that Linux-libre is not Linus's dog, and if it bite's someone that's an issue for FSF, not for Linux. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:19, 2 August 2020 (UTC)

@Fabio Maria De Francesco:

@Jackmcbarn:

@Chatul:

Again, please read the link I posted. It provides evidence the Linux kernel source tree contains blobs, and also explains how only copyright holders can sue for copyright infringement.

The last two messages are off-topic. Ideologies are irrelevant. Whether the kernel marks itself as tainted is irrelevant. Whether proprietary software is necessary (it's not, I haven't used proprietary software for months) is irrelevant.

The point is that we have evidence which proves there are proprietary binary blobs in the kernel now which supersedes any previous evidence or statements in COPYING files because they can bypass the GNU GPLv2 via sketchy loopholes such as claiming to be a library, or aggregation.

Again please read the thread I linked.

185.89.35.4 (talk) 17:28, 2 August 2020 (UTC)

@Jackmcbarn:

@Chatul:

You don't have any proof. One of the link you provided in my talk page points to the well known free and open source nouveau drivers, that want to replace proprietary Nvidia ones. The other two link point to files that cannot be compiled and linked within the kernel and they, with a high degree of probability, are provided merely as document files. As I already wrote, as soon as possible I'm going to talk to the maintainers and ask them to explain. Everybody will be notified here, but it may take a while. Fabio Maria De Francesco (talk) 17:56, 2 August 2020 (UTC)

No, what is off topic is the reference to Linux-libre. It has nothing to do with whether there is a GPL violation. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:29, 2 August 2020 (UTC)

@Fabio Maria De Francesco: @Jackmcbarn: @Chatul:

Let's all take a step back here and summarise the arguments on each side:

Linux does not contain blobs:

• Linux is licensed under the GNU GPLv2, which requires source code.
  • This is affirmed by the COPYING file.
• If Linux does contain blobs, Torvalds et al can be sued for copyright infringement.
• Linux contains magic numbers, not blobs.
• The long sequences of uncommented bytes are merely documentation and are not compiled or linked into a kernel build.
• The Linux kernel only loads proprietary code at runtime and marks itself as tainted; there are no blobs in the tree.
• Contributors keep erroneously stating that the Linux kernel contains blobs, and these these falsehoods keep getting removed.
• The long sequences of bytes were written as bytes.

Linux contains blobs:

• Linux-libre exists; this proves there are many people ready and willing to remove blobs. There would be no point in tons of effort being put in to remove free code.
  • The project claims to remove blobs from Linux.
  • Many GNU+Linux distributions which are composed of entirely libre software use it.
  • The deblob scripts point to specific examples of binary-only blobs.
• Torvalds et al cannot be sued for copyright infringement from a party whose works are not being infringed upon.
• Magic numbers are only a few bytes long, not hundreds of lines long.
• The long sequences of bytes are uncommented dumps of firmware, or other kinds of proprietary, binary-only firmware, and are not documentation.
• The Linux kernel has blobs in its tree which are compiled and linked into the kernel.
• Contributors keep trying to correct Wikipedia by stating that the Linux kernel contains blobs, but this fact keeps getting erroneously removed.
• The long sequences of bytes were not written as bytes, there were written in assembly or some other higher-level programming language such as C, and were then compiled into bytes.
  • This violates the GNU GPLv2, as long sequences of bytes are not proper source code, and are not, "in the preferred form of a work for modifying it."
  • These long sequences of bytes cannot be effectively understood by any programmers, let alone modified, as no source code is given. This inhibits Freedom 1, and makes Freedom 3 impossible due to the lack of Freedom 1, hence making them proprietary, binary blobs.

Please feel free to update the arguments by copy/pasting this post. 185.89.35.4 (talk) 19:10, 2 August 2020 (UTC)

Does the official Linux kernel code that is maintained and released by Mr. Linus Torvalds infringe the GPLv2 (and derived licenses or dual licensing with MIT)? RFCs are about determining article content (or structure, or policy, etc), not for settling legal questions. I haven't looked into this and I don't think I'm really going to beyond this comment, but I just wanted to point out that people here seem to be quibbling over text in licenses and performing their own analyses of the language in them. This isn't appropriate. We merely need to pass on what reliable, secondary sources say about the matter. If they disagree, then we can point out that opinions differ. If they are silent, then so should we be. –Deacon Vorbis (carbon • videos) 21:09, 2 August 2020 (UTC)

I absolutely agree with you: "[We] merely need to pass on what reliable, secondary sources say about the matter.". I must admit that I'm strongly biased towards the good faith of the community of Linux kernel hackers, in particular Mr. Torvalds and Mr. Kroah-Hartman. Furthermore I rely heavily on primary sources and on my own experience with this subject. Therefore, it's time to look for reliable secondary sources. That's exactly what I'm going to do. Thanks a lot, Fabio Maria De Francesco (talk) 23:07, 2 August 2020 (UTC)

The first internet search result on "linux contains blobs" pulls this (a reliable source of journalism on the issue). It would make sense in staying neutral in point of view so that all views are represented. Altanner1991 (talk) 04:11, 3 August 2020 (UTC)

Often when there is a dispute, a key question is "What do you mean by foo?" It often turns out that the parties to the dispute mean different things by "foo". In this case, it is not clear whether the article is claiming that the Linux kernel contains blobs, or only that loadable kernel modules contain blobs. Shmuel (Seymour J.) Metz Username:Chatul (talk) 04:32, 3 August 2020 (UTC)

@Jackmcbarn: @Chatul: @Altanner1991: @Deacon Vorbis: I've just added a reliable, secondary sources to the article. Interestingly it is in a book written by professor Andrew S. Tanenbaum (people familiar with Linux development history know why it is). In the summary at https://en.wikipedia.org/w/index.php?title=Linux_kernel&diff=prev&oldid=971374176&diffmode=source I've left a little excerpt for the convenience of the people who might encounter difficulties in finding the book. I invite everyone to read at least that summary. Fabio Maria De Francesco (talk) 19:42, 5 August 2020 (UTC)

@Jackmcbarn:

@Chatul:

@Altanner1991:

@Deacon Vorbis:

@Fabio Maria De Francesco:

That book is referring to the GNU GPLv2 licensing conditions. The ironic fact that some parts of the Linux kernel "source code" are actually long sequences of undocumented, binary-only bytes just proves how the Linux kernel is violating the GPL, or perhaps slyly including proprietary code through aggregation.

Here are two articles which report on the recent release of Linux-libre 5.8, and the amount of deblobbing required:

• https://www.phoronix.com/scan.php?page=news_item&px=GNU-Linux-Libre-5.8-Released
• https://9to5linux.com/gnu-linux-libre-5-8-kernel-arrives-for-those-seeking-100-freedom-for-their-pcs

Also, in a number of his talks, Richard Stallman mentions the fact that the Linux kernel contains blobs.

It is also worth nothing that numerous other projects which call themselves "free" and/or "open-source" are not actually entirely so, and include blobs. Examples of such projects include FreeBSD, Haiku, and Android. See the following link for more information on this: https://www.gnu.org/distros/common-distros.html.

Yea I'm with 185.89.35.4 on this one. The Free Software Foundation's articles should be taken as reliable sources because of their stature and importance in the world today, which is unfathomed given the prominence of "free as in free" software in every major area of computing except desktop computers which is dominated by Windows and to a much lesser extent macOS. These industries create the richest people in the world, so their word is as good as gold. Altanner1991 (talk) 20:14, 5 August 2020 (UTC)

FSF is a party to a dispute; taking their word for it would violate WP:NPOV. What would be appropriate would be to document the dispute and cite statements by both sides. Also, if you're going to talk about stature and importance, then Linus arguably has more than the FSF. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:11, 5 August 2020 (UTC)

Does "Linux" include loadable kernel modules? Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:11, 5 August 2020 (UTC)

Yes, it does. However they are regulated by the licensing rules and can also be entirely disabled when configuring Linux for compilation from source code to an executable kernel (called vmlinux). Fabio Maria De Francesco (talk) 22:31, 5 August 2020 (UTC)

@Jackmcbarn: :@Chatul: :@Altanner1991: :@Deacon Vorbis:

Linux-libre is a distribution (operating system + user applications). Android is an operating system, isn't it? Furthermore, the link provided above (https://www.gnu.org/distros/common-distros.html) is about distributions, not about the kernel. Why do people compare apples and oranges? Do they know what exactly is the topic we are discussing here?

Distributions can have proprietary modules and the kernel can load them. There is an apposite feature in the kernel to give system administrators the power to load proprietary modules at runtime into the kernel address space. What 100% distributions want is disabling this feature. Linux-libre has this goal, among other questionable ones. Fabio Maria De Francesco (talk) 22:24, 5 August 2020 (UTC)

I'm sorry, but the URL above made me automatically think that the page regarded only distributions, instead they make a clear distinction between distros and the Linux kernel. Fabio Maria De Francesco (talk) 23:06, 5 August 2020 (UTC)

@Jackmcbarn:

@Chatul:

@Altanner1991:

@Deacon Vorbis:

@Fabio Maria De Francesco:

Fabio, you are the one who is mistaken here. Linux-libre is not a distribution; it contains neither an operating system, nor user applications. GNU is the OS, Linux-libre is the kernel, hence Parabola GNU/Linux-libre, which is an example of a GNU+Linux-libre-based OS, and also is the distro which I run.

Linux-libre is a parallel effort fork of Linux (remember, Linux is not an operating system, it is just a kernel), which is essentially Linux, minus the proprietary blobs.

To reiterate, Linux-libre is virtually identical to Linux, except for the fact that it has no blobs.

I think this is really an open-and-shut case. I have shown that Linux-libre has been removing blobs in Linux for over a decade. I have linked to the script which removes blobs. I have linked to specific examples of blobs. I have shown distributions which use Linux-libre. I have demonstrated that the GNU project, Stallman, and the FSF have encouraged the deblobbing of Linux. I have shown that binary-only blobs, in this case, long sequences of bytes stored in arrays in C source files, disguised as source code, almost certainly breaks the GNU GPLv2.

What astounds me is that you have seen the blobs for yourself, yet you claim they are not blobs!

I challenge you: pick any file the latest version of the Linux-libre deblob script removes as a blob, and tell me exactly how the blob works. After all, I have stated that binary/hex is not real source code, it is uncommented and undocumented, and no programmer can effectively understand it. So, if you can, please prove me wrong, and walk me through what one of these blobs is doing, because in your opinion, it must be proper source code.

Fabio there is enough dispute on this issue to warrant a mention in the article. We have a reliable source from techrepublic.com and I suggest you allow it to be incorporated. Altanner1991 (talk) 01:29, 6 August 2020 (UTC)

@Jackmcbarn:

@Chatul:

@Altanner1991:

@Deacon Vorbis:

Ok, it's time to come back to the real thing. This RfC asks "Does the official Linux kernel code that is maintained and released by Mr. Linus Torvalds infringe the GPLv2 (and derived licenses or dual licensing with MIT)?"

1) Copyright violations have serious legal consequences.

2) As far as I know, no courts has ever condemned Linux community members of GPL license violations simply because Mr. Greg Kroah-Hartman, who is in charge of maintaining the driver subsystem, reject every attempt by people who want to upload non compliant code to the official Linux kernel repository.

3) Somebody thinks that Mr. Torvalds at a certain point of his life went mad. Although he wanted his creature to be free and open source by releasing it with the GPLv2 license, he changed his idea and now he sponsors proprietary code within Linux (his Linux, since he is the copyright holder of the "Linux" name). He put his honorable career at stake, maybe he sold his soul to big tech for money. Who knows?

4) If anybody here thinks that one or more entities are violating the Linux license rules, they should report those infringements according to the following guidelines: https://sfconservancy.org/copyleft-compliance/ https://sfconservancy.org/blog/2012/feb/01/gpl-enforcement/

5) I have exhausted the time budget that I reserved to this discussion. Fabio Maria De Francesco (talk) 23:32, 6 August 2020 (UTC)

@Jackmcbarn:

@Chatul:

@Altanner1991:

@Deacon Vorbis:

6) I was about to forget this sixth point... please have a look at the documents in the following list and don't forget that, for being Linux "released under GPLv2 as a whole", it is sufficient that even a single developer who wrote just a few lines of core kernel code that is used by GPL violators can sue them according to the FSF (fourth link of the list). For example, this is what Harold Welte, among others, did.

https://gpl-violations.org/about/

https://gpl-violations.org/news/

http://laforge.gnumonks.org/about/

https://www.gnu.org/licenses/gpl-violation.html

Fabio Maria De Francesco (talk) 00:15, 7 August 2020 (UTC)

Please stop pinging me here. This is like the 4th or 5th time now, all after I said I didn't intend to comment further. I'm especially not going to try to slog through this morass of broken indentation, unsigned comments, malformatted pings, and so on. –Deacon Vorbis (carbon • videos) 00:26, 7 August 2020 (UTC)

In any discussion of what the V2 FPL allows, it's important to distinguish among

• The person who contributes the code
• Linus
• The person who compiles a distribution
• The person who uses a distribution
• The person who includes code into his own product.

It doesn't violate the GPL to contribute code containing a blob. However, if your only right to the blob is the license for a product containing it and that product contains the source code, then you are required to make the source code available. Is here anything in either the core kernel or the loadable kernel modules that violates that? Shmuel (Seymour J.) Metz Username:Chatul (talk) 01:41, 7 August 2020 (UTC)

I think you gave a lucid contribution, again. I imagine that your last question was rhetorical. However, the reply is: no, there's nothing that violates that. Fabio Maria De Francesco (talk) 02:59, 7 August 2020 (UTC)

I'm sorry, I didn't notice that Deacon wrote he didn't intend to comment further. Please excuse me. Fabio Maria De Francesco (talk) 02:59, 7 August 2020 (UTC)

• User:Fabio Maria De Francesco Please keep in mind that Requests for Comment should be brief and neutral. The last part of this Request for Comment is not neutral. < Atom (Anomalies) 04:31, 7 August 2020 (UTC)