Native Linux Kernel Module Is Out For Microsoft exFAT

[RussDill]

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.

Are you kidding? I examined exfat_super.c and compared it to fs/fat/misc.c, fs/fat/dir.c, fs/fat/namei_vfat.c, and fs/fat/file.c. I will avoid sharing my conclusions here, but any one else is free to look.

Course, that could have all been inserted by rxrz, or have some common BSD ancestor, but it seems doubtful to me.

[chrisb]

Are you kidding? I examined exfat_super.c and compared it to fs/fat/misc.c, fs/fat/dir.c, fs/fat/namei_vfat.c, and fs/fat/file.c. I will avoid sharing my conclusions here, but any one else is free to look.

Course, that could have all been inserted by rxrz, or have some common BSD ancestor, but it seems doubtful to me.

It is especially doubtful because the Samsung code contains Linux specific comments copied directly from the kernel source!

• "timestamp is already written, so mark_inode_dirty() is unneeded."
• "This protects against truncating a file bigger than it was then"
• "GFP_KERNEL is ok here, because while we do hold the"
• etc

[timofonic]

I'll copy this from the news about the discovery of being a leak, I hope chrisb will not get upset because of it (anyway, he did post it there):

Ok I took a quick 10 second look: https://github.com/rxrz/exfat-nofuse.../exfat_super.c contains string "timestamp is already written, so mark_inode_dirty() is unneeded." searching on this string shows that it was added to the kernel in 2005 in this commit: http://linux.derkeiler.com/Mailing-L...5-03/1976.html

Other comments are the same e.g. exfat_setattr() "We don't return -EPERM here. Yes, strange, but this is too * old behavior.": http://www.cs.fsu.edu/~baker/devices.../fs/fat/file.c

390         /*
391          * [B]We don't return -EPERM here. Yes, strange, but this is too[/B]
392          * [B]old behavior.[/B]
393          */
394         if (attr->ia_valid & ATTR_MODE) {
395                 if (fat_sanitize_mode(sbi, inode, &attr->ia_mode) < 0)
396                         attr->ia_valid &= ~ATTR_MODE;
397         }
398 
399         if (attr->ia_valid)
400                 error = inode_setattr(inode, attr);
401 out:
402         return error;
403 }
404 [B]EXPORT_SYMBOL_GPL(fat_setattr);[/B]

So it appears the "Samsung Proprietary code" contains GPLv2 copied straight from Linux kernel.

What about making more research about this? Are there a lawyer reading this?

[mrugiero]

There's no way this code can be incorporated - it's Microsoft's IP. Only clean room reverse engineering can land in mainline.

The patents, yes, but isn't the code Samsung's? If the code isn't MS IP, the only problem would be for distributing binaries, i.e., it will not be included by default on distros but might appear as a module on restricted repos (install on you own responsibility and such, and stored in servers where such patents aren't valid).
Kernel.org doesn't distribute binaries.

[birdie]

The patents, yes, but isn't the code Samsung's? If the code isn't MS IP, the only problem would be for distributing binaries, i.e., it will not be included by default on distros but might appear as a module on restricted repos (install on you own responsibility and such, and stored in servers where such patents aren't valid).
Kernel.org doesn't distribute binaries.

That's a very murky area - distros can probably include the source code for this driver (the 1st amendment actually allows that), but still it cannot be merged in mainline - Linus will not agree on that.

But even if distros include the source code, users automatically become legally responsible for using this driver - i.e. Microsoft have all the rights to sue you for "make modules" - that is NOT funny.

[mrugiero]

That's a very murky area - distros can probably include the source code for this driver (the 1st amendment actually allows that), but still it cannot be merged in mainline - Linus will not agree on that.

But even if distros include the source code, users automatically become legally responsible for using this driver - i.e. Microsoft have all the rights to sue you for "make modules" - that is NOT funny.

Linus allowing it or not isn't really something I can say anything about. What about vfat, or the (mostly useless) ntfs kernel driver? Those are on the kernel, and both have some MS patents. Also, the whole point of "use under your own responsibility" is to let you know in some countries you could be sued. In my country, there are no software patents, for example.

[chrisb]

That's a very murky area - distros can probably include the source code for this driver (the 1st amendment actually allows that), but still it cannot be merged in mainline - Linus will not agree on that.

Well, neither Linus or any other kernel developer removed vfat long file names even though it was covered by a patent, instead they added a patch to disable it at compile time. But the source code is still there in mainline.

But even if distros include the source code, users automatically become legally responsible for using this driver - i.e. Microsoft have all the rights to sue you for "make modules" - that is NOT funny.

Actually Red Hat users should be covered by their patent indemnification. But yeah, users are responsible - patents suck like that.

[toyotabedzrock]

cjit

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 iseu either unaware of, or not bothered enough by his code being public on github.

A crazy idea what if someone made a jit like compiler for c. Maybe the compiler could just record the steps it took for a normal compile as a way to do it quicker upon boot?

[birdie]

Linus allowing it or not isn't really something I can say anything about. What about vfat, or the (mostly useless) ntfs kernel driver? Those are on the kernel, and both have some MS patents. Also, the whole point of "use under your own responsibility" is to let you know in some countries you could be sued. In my country, there are no software patents, for example.

For interoperability you are allowed to write code (from scratch, without using original specs) to operate with closed technologies/standards - there's a provision for that in the US law - that's exactly how in-kernel vfat/ntfs modules were created in the first place - it doesn't matter if they infringe or not on MS patents - they are made using clean room reverse engineering.

exfat on the other hand was written after MS IP - thus this whole driver is MS's IP.

Only clean room reverse engineered exfat can be legally merged upstream.

End of story, end of thread.

[RealNC]

I'm sure there's a law about interoperability which applies here and pretty much disarms patent claims.