Native Linux Kernel Module Is Out For Microsoft exFAT

[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.

[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.

[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.

[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.

[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

[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.

[chithanh]

Can we be a bit more civil in here? I think we all agree on the following:

1. The source code does not contain any Microsoft IP (or if it does, their copyright headers were stripped from the code)
2. The exFAT technology is patent encumbered in countries where software patents exist. Even in those countries, this is a problem only when you distribute binaries, not source code.
3. The code has no license attached to it. Use and redistribution is only permitted with a license so you have to obtain one separately before you can do that.
4. github responds to DMCA takedown notices, which indicates that the copyright holder is either unaware of, or not bothered enough by his code being public on github.

[rzrx]

Deepest respect to you pal, thanks a lot for this!

You're welcome, Brother.
I appreciate you being open-minded and not following the victim philosophy.

I still don't understand why people here assume that any code which has been published on the Internet becomes public domain, it does not.

It does now.

My bad, the uploader clearly isn't the copyright holder, so yeah, code not redistributable.

Seems pretty redistributable to me.
By now is has been forked 10+ times, starred 30+ times and the news were published all over the oss websites in less than a day.
It won't get lost, and that's exactly what my intention was: to do a good thing for the community and the OS, to fix what was unfairly wrong.
I'm not saying I wrote the driver, but you definitely got the full source to figure out the specs for all fat* filesystems.
I also could've released a fully obfuscated driver or even binary builds, and would've never had any questions about the license.
I never did because I respect the good and hard work accomplished by the authors of the code.

The leak wasn't mine, I found it by pure luck. You can find the original repository of 3.0 droid kernel on github from at least 2 repos, updated 2-3 months ago.
There lies the original driver, as a part of the GNU/Linux kernel with tons of other proprietary patches/drivers for that platform. It can now be included with all custom firmwares for Android devices.
It has been there for months and months, nobody has put it offline, nobody got sued, hunted down or hanged.

All I did was updating the code to work with the recent kernels and promoting the leak.
People with emotional insecurities are trying to make up something depressing and horrible, point a finger and make lots of noise.
For me it was just sad to see people complaining more often than being grateful or happy about something.
I hope they will patent and release a license on negative thinking.

P.S.
This is not only an exFat driver, it's a fat12/16/32/64 driver. I can not state it works well for other filesystems besides the latter one, but it certainly was intended to. It has lots of code to support those versions of FAT. It could be turned into a fat.ko driver and it also could replace the slow vfat driver found in the current kernel trees. People really should stop being depressing, quit all the gossip and put their testosterone in the way of creating something for the computers.
I wish you to learn to see the bright sides and ignore parasites such as m$ in the future.

I honestly hope this driver module will make your data management easier and faster.
Thank you for the attention and being a part of the real IT of today.

?Never let your sense of morals prevent you from doing what is right.?
― Isaac Asimov

?Quite an experience to live in fear, isn't it??
― Roy Batty

[Ibidem]

Well, if MS tries to sue, one could argue that
1.(a) exFAT was mandated by a standard with the consent of Microsoft and
(b) Microsoft has argued that SEPs should not be grounds for suing, and is thereby estopped.
2. It is essential for interoperability.

Of course, I'm not interested in using exFAT in any way.

[Raven3x7]

Well, if this code was distributed as part of that 3.0 kernel it actually has to be GPL.