Native Linux Kernel Module Is Out For Microsoft exFAT

[curaga]

Someone said it was a fork of the kernel's vfat driver. Which is under the GPLv2 license.

Now, putting it publicly on github qualifies as distribution, and therefore this code is also under the GPLv2 license implicitly. The act has already been done, and even if it does contain copyrighted bits by MS, the released version is now forever GPL.

[brosis]

@brosis
patent licenses are per device. You don't get a license to use FAT everywhere as soon as you buy a camera. The device using this code is the (PC + OS), and it doesn't matter if a licensed camera wrote the pictures, you need a license to read them legally if you live in a country where exFAT patents are valid.

Of course you don't, thats the thing I am talking about. You don't get a license to use exFAT everywhere, BUT you get license to use exFAT on your camera!

Since you purchased the right to use exFat for the camera, stick or any other device you may have purchased, its the device is performing read and write operations! You only mount the filesystem in your Linux machine, you don't create or operate any exFat filesystem outside, it stays within device.

You can compare this to TV connected to PayTV receiver. You Linux box is the TV, it just receives and sends bits over the cable. Its not possessing exFAT, its only connected to it - and this driver just sends commands to the device.
In this scope, the driver is perfectly patent clear! And its exactly the scope the creator of the driver wanted to use it - to be able to connect and operate his devices, that came with exFAT from the factory, use it and are certified to be operating it.

And as I mentioned, it will be illegal to use this driver outside of your bought exFAT-native devices!

That's a load of BS. You have zero understanding of you're talking about.
Your assumptions are plain ridiculous - like "any code hosted on GitHub must be GPLv2" - that's just insane. There are many closed projects on GitHub. There are many projects which have licenses which are incompatible with GPLv2.
I'm not gonna refute the rest of your message 'cause it's just beyond asinine. I guess you are a 14 yo Open Source fanatic who believes Open Source is be all and end all.
Good bye. You're on my black list from now on. You clearly lack reasoning and knowledge to discuss such matters.

You failed to argument, you fail to provide the license to back up your argument on license being non-free, you even fail to understand why would a company host a PPA that has publicly accessible source code, IF it considers the code to be proprietary. Now I understand where does your anti-linux argument list comes from

You can't ignore the truth, you can try, but it will bust in your face sooner or later! But before it happens, you will live in your own cage - isolation that you put around yourself artificially. Ciao babe girlie!

Were do you assume "this source code is not under GPLv2"? Source of this please? This implementation (code) was on github, that says something to you?

Your assumptions are plain ridiculous - like "any code hosted on GitHub must be GPLv2" - that's just insane.

Ahaha, indeed your logic is INSANE, you get an F, sit down

[erendorn]

Since you purchased the right to use exFat for the camera, stick or any other device you may have purchased, its the device is performing read and write operations! You only mount the filesystem in your Linux machine, you don't create or operate any exFat filesystem outside, it stays within device.

No. The device is performing read and write operations at block level, it is completely agnostic to the filesystem, and both a sd card and a sd card reader are sold without patent license for any filesystem (do you really think all sd cards are sold with a license for each and every file system in existence?). If your camera can read and write exFAT, it needs a license. If your OS can read or write exFAT, it needs a license.

1. The source code does not contain any Microsoft IP (or if it does, their copyright headers were stripped from the code)

The source code most likely contains Samsung IP, see below.

Someone said it was a fork of the kernel's vfat driver. Which is under the GPLv2 license.

Now, putting it publicly on github qualifies as distribution, and therefore this code is also under the GPLv2 license implicitly. The act has already been done, and even if it does contain copyrighted bits by MS, the released version is now forever GPL.

No, that person said it was a fork of the Samsung exFat module, which, after a quick look on google, seems fully proprietary. I.e, not implicitly GPLv2.
I looked at the vFat code, and it's not the same, so not likely a fork of it.
The code mentions joosun hahn, who seems to work for Samsung.

So all in all, nope, not forever GPL, and most likely illegally distributed.

[RealNC]

FUSE is the way to go for this file system. If something can't be included in mainline, there's no point in having a kernel module. NTFS-3G works very well for a lot of people and it's not tied to a specific kernel version. There's no reason exFAT can't do the same.

I suspect though that the whole point of this project is about the author simply having fun in implementing it in the kernel. And that's a perfectly valid reason to do this.

[chithanh]

A disadvantage of FUSE is that it results in a high CPU load. This is less of a problem for fast desktop systems, but annoying on smaller embedded CPUs. It was said in this thread that the exFAT kernel driver originally comes from Samsung tablet kernels.

[peppercats]

That's funny - people want to destroy me because I see real Linux problems.

Is this page supposed to be a joke?
One point even complains that there's adobe flash video tearing... so? Adobe dropped support for Linux, what the hell do you want Linux developers to do to fix that?
Also,

No high level, stable, sane (truly forward and backward compatible) and standardized API for developing GUI applications (like core Win32 API - most Windows 95 applications still run fine in Windows 8 - that's 18 years of binary compatibility). Both GTK and Qt (incompatible GTK versions 1, 2, 3 and incompatible Qt versions 2, 3, 4, 5 just for the last decade) don't strive to be backwards compatible.

yes, more GUIs should strive to be like Win32, known to be really easy to work with due to its awesome backwards compatibility /sarcasm
The backwards compatibility is why Win32 is garbage and they had to make winforms for .NET.

I can point to almost anything related to software development and its flaws will almost be entirely with backwards compatibility, you'd think an area that just started existing in the past half-century would be fine with fast progress.

[brosis]

No. The device is performing read and write operations at block level, it is completely agnostic to the filesystem, and both a sd card and a sd card reader are sold without patent license for any filesystem (do you really think all sd cards are sold with a license for each and every file system in existence?). If your camera can read and write exFAT, it needs a license. If your OS can read or write exFAT, it needs a license.

No. If my OS reads and writes to existing exFAT device, it does not need a license.
If I need an OS to be able to create and modify exFAT on media of my need, then I need ms license.
Who is gonna need this FS outside of his camera/usb stick? No one.

Yes, SD cards ARE sold with license in filesystem they are formatted from factory.

[brosis]

FUSE is the way to go for this file system. If something can't be included in mainline, there's no point in having a kernel module. NTFS-3G works very well for a lot of people and it's not tied to a specific kernel version. There's no reason exFAT can't do the same.

I suspect though that the whole point of this project is about the author simply having fun in implementing it in the kernel. And that's a perfectly valid reason to do this.

A disadvantage of FUSE is that it results in a high CPU load. This is less of a problem for fast desktop systems, but annoying on smaller embedded CPUs. It was said in this thread that the exFAT kernel driver originally comes from Samsung tablet kernels.

FUSE change absolutely nothing. FUSE is userspace filesystem, this way the FS loads in userspace, not in kernel. From kernel developer point of view, they don't have to support it as module; from maintainer point of view, they don't have to port it to newer kernel versions. Convenience at exchange of speed.. doesn't change anything else.

Ofc its much better to have module kernel version. And ofc the thin line HOW you use the FS - on certified device, which is legal; or on any device, which is not legal, does not affect kernel anymore if its FUSEd, but then no difference anyway. In my humble opinion, no one is going to use this FS outside of its own device, so I don't see the legal problem here.

[erendorn]

No. If my OS reads and writes to existing exFAT device, it does not need a license.
If I need an OS to be able to create and modify exFAT on media of my need, then I need ms license.
Who is gonna need this FS outside of his camera/usb stick? No one.

Yes, SD cards ARE sold with license in filesystem they are formatted from factory.

The sd card license does not give you licenses for other devices.
That's why your camera has a separate license.
That's why your PC needs a separate license (if it can use exFAT).
That's why Samsung paid a license to add exFAT capability to their tablet (using the very module from which comes the code leaked here).
That's why android manufacturers push for no sd card and MTP (usb raw access= FAT filesystem on the phone, patent fee. usb MTP access= any filesystem on the phone, no patent fee).

I'll rewrite it once again for you, it's very simple:
you distribute an exFAT module to or from a country where the related patents are enforceable => you need a license.

[Luke]

Microsoft can stuff their patents

This driver is Microsoft's intellectual property, it will be taken offline and you will receive a C&D letter from Microsoft. Good work.

Legally no one can even use it unless you pay ExFAT tax (which is $2 per device if I'm not mistaken).

Shame.

Therefore, this module needs to become available through Pirate Bay as a torrent, and/or mirrored in countries hostile to the US and to software patents. As anyone who ever watched a pirated movie knows, there are workarounds against the legal system. There is even an onion-routed bittorrent network that works like Tor does but is designed for filesharing growing as we speak. I haven't used it mostly because I ignore Hollywood's content almost completely.

As a person with no assets vulnerable to any lawsuit, I would have exactly NO hesistation about using "illegal" software to extract data from a device enslaved to Microsoft. As a political enemy of Microsoft, I would see that as extra satisfaction. I keep things like libdvdcss on all my systems, whether or not they have optical drives. Since I also keep all my systems encrypted, not even a raid could prove their presence by a court-usable standard anyway. No way in hell I would pay a dime to Microsoft, any more than I would ever pay a Getty extortion note. All they'd ever get from me is a nasty fight, over patents my whole political movement advocates abolition of, not only for software but also for seeds and living things.