They produced the driver under license, somehow someone got a hold of the code and "guerilla relicensed" it, which they did not have authority to do, and uploaded the result to Github.
Sometime later when this repository was noticed on Github, someone noticed the source was a derivation of one of the existing Linux FAT filesystem drivers. In other words, under the terms of the GPL it is derived code. The fact it was only previously distributed in binary form does not excuse this: Samsung were distributing GPL derived code in violation of the license.
So this clears things up a little bit. What I don't understand now is the usefulness of this code. For example, could it potentially be merged upstream? If not, then why not? If it can be distributed under the GPL independently, I don't understand why it couldn't get shipped with Linux.
The fact this driver exists "legitimately open source" now, yet is still covered by patents, confuses me a bit.
It's probably in the same situation as ffmpeg, x264, lame, (previously) gif encoders etc are or were.
If it is true that non-US countries do not acknowledge the related patents, it would be a very interesting situation if anyone were to make it integrated in a git fork of the mainline kernel. Could we end up having a richer git branch/repo hosted on "kernel.eu"? Would others do pull requests on top of this, thus meaning further kernel patches (related or not so related) get interwoven? Would a "us compatible" mainline linux stagnate while an off-limits-for-americans "eurolinux" flourish? Probably not for just a fringe fs driver that can stay separate. But what about possibly-US-patent-covered patches to the core, if they provide enough benefits?
> Would a "us compatible" mainline linux stagnate while an off-limits-for-americans "eurolinux" flourish?
That sounds like a silly way to go about things. A much simpler solution, if this really was a problem: a kernel compile-time config option to disable (and disable the selectability of) patent-encumbered kernel modules. "Check this to compile a kernel for use in the US", etc. There'd only be one codebase; the only active maintenance would be in making sure that if a new patent-encumbered module were added, that an entry for it also got added to the configure switch.
Source code can't infringe US patents because source code isn't a machine or a process or a composition of matter.
A machine running a Linux kernel can be plausibly accused of infringing thousands of active US patents even without FAT support. There is no version of Linux that does or could ever pass a patent clearance review in the USA.
The distinguishing character of the VFAT patents is that Microsoft threatens to sue people over them. I don't know of any cases they've won so far and no patent is actually infringed until a jury says so.
I think the key part of that paragraph is in the last sentence:
"... in order to serve the goal of providing and supporting only free and open source software that is not restricted by software patents by default. "
So, not a legal reason, but a philosophical reason.
(They make package maintainers excise MP3 code from upstream tarballs and repackage those, not just patch it out of the compiled code - it's a massive pain).
Sometime later when this repository was noticed on Github, someone noticed the source was a derivation of one of the existing Linux FAT filesystem drivers. In other words, under the terms of the GPL it is derived code. The fact it was only previously distributed in binary form does not excuse this: Samsung were distributing GPL derived code in violation of the license.
So this clears things up a little bit. What I don't understand now is the usefulness of this code. For example, could it potentially be merged upstream? If not, then why not? If it can be distributed under the GPL independently, I don't understand why it couldn't get shipped with Linux.
The fact this driver exists "legitimately open source" now, yet is still covered by patents, confuses me a bit.