Announcement

Collapse
No announcement yet.

Native Linux Kernel Module Is Out For Microsoft exFAT

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #61
    Originally posted by erendorn View Post
    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.

    Comment


    • #62
      Originally posted by RussDill View Post
      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

      Comment


      • #63
        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):

        Originally posted by chrisb View Post
        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
        Code:
        390         /*
        391          * We don't return -EPERM here. Yes, strange, but this is too
        392          * old behavior.
        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 EXPORT_SYMBOL_GPL(fat_setattr);
        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?

        Comment


        • #64
          Originally posted by birdie View Post
          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.

          Comment


          • #65
            Originally posted by mrugiero View Post
            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.

            Comment


            • #66
              Originally posted by birdie View Post
              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.

              Comment


              • #67
                Originally posted by birdie View Post
                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.

                Comment


                • #68
                  cjit

                  Originally posted by chithanh View Post
                  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?

                  Comment


                  • #69
                    Originally posted by mrugiero View Post
                    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.

                    Comment


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

                      Comment


                      • #71
                        Originally posted by birdie View Post
                        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.
                        Originally posted by RealNC View Post
                        I'm sure there's a law about interoperability which applies here and pretty much disarms patent claims.
                        You are both confusing patents and copyright. You can't work around patents with clean room design: Wikipedia

                        Originally posted by Wikipedia Clean Room Design
                        Clean room design is useful as a defense against copyright and trade secret infringement because it relies on independent invention. However, because independent invention is not a defense against patents, clean room designs typically cannot be used to circumvent patent restrictions.

                        Comment


                        • #72
                          A lot of countries in the world don't have software patents so I'm not mistaken. ;-)

                          Comment


                          • #73
                            Just ONE end-user lawsuit would sink exFAT just like GIF

                            Let's get real: no individual user is going to buy Windows because some patent says their camera's files are "illegal" to read from a Linux box. Hell, Mint goes so far as to say that only corporate or institutional users need to use the "no-codecs" versions in software patent countries. If the Sumsung module mixes GPL and MS code (copyrights), we still have the FUSE method.

                            I see ExFAT becoming another MP3 or H264-a standard institutional users must avoid, but nobody else. US-based distros will simply keep it in foreign repos only. There will always be countries that don't sign NAFTA-style trade deals to host such repos. Some don't even attempt to enter the WTO world.

                            This means that people will always be able to get either GPL or warez software to read the filesystem on their linux boxes. For individual users there is no deterrent, no reason to follow un unenforceable and unjust law. At worst, it would be like finding libdvdcss somewhere so you can use those old DVD's you bought before the MPAA boycott.

                            OK, so MS cannot enforce their ExFAT patent on end users, anymore than the RIAA can stop music sharing. What can they do about it? Years ago, the owners of the .gif image format sued websites for hosting images in that format without paying for a patent license. The resulting fear did not get them a wave of compliance. Instead, the .gif format sank as web hosts rejected it. MPEG-LA, fearing the same, as declined to sue individuals over H264 "piracy." Not only that, they now went so far as to grant license for non-monetized use to essentially all individual users and non-monetized websites.

                            If Microsoft sued even a single Linux user for reading files out of their own camera, milions of people would fear to ever buy another device using the ExFAT filesystem, and it would sink. Any individual fearing such lawsuits can buy cameras with cash so MS doesn't know who they are, and encrypt their filesystem so nobody can even tell what software they have installed. Might want to boycott Hotmail and 127.0.0.1 out microsoft.com and bing.com if this ever does get going, until ExFAT sinks. In short, the survivial on ExFAT is dependant on MS not suing individuals, probably on not suing corporate newsrooms either.

                            Lastly, remember this: a Linux box bought with cash and no ID/discount card on which Windows was never activated, or which was bought used and off the record,is undetectable to Microsoft if their websites are not used and they are firewalled out in /etc/hosts. They would not even know who to sue with the exception of maybe some famous corporate photographer who did not appear in a list of Windows buyers. That lawsuit would guarantee them maximum adverse press, making people afraid to buy not only ExFAT cameras, but maybe all computer equipment. PC sales are already plunging due to Windows 8, a lawsuit about someone's home computer could sink Microsoft outright!

                            Comment


                            • #74
                              I don't care what these entities do... but if it's available in the kernel I will build and use that module. Microsoft can go and ride the big baloney pony... they should have no right to patent things like that to hamper interoperability. It pisses me off because of all the good (open) filesystems we could have had for flash media (e.g. jffs2), we get that rubbish that has even worse fault tolerance than FAT32.

                              Right now I wipe devices that come with exFAT and "mkdosfs -F 32 -s 128" for a FAT32 filesystem with 64 kb clusters. Works fine, even for 1Tb external drives (Windows won't let you create a FAT32 filesystem larger than 32 Gb, but it supports them if created with third party utilities), but then you can't have files 4 Gb or larger and it wastes storage space when there's "cluster overhang" on small files. (but that's not such a big deal). I need to be able to take that to any Windows computer and any Linux computer so FAT32 it is for now.

                              I don't prefer that FUSE stuff, I would rather just "modprobe filename". exFAT is a simple enough filesystem.

                              Take ntfs.ko vs. NTFS 3G in userspace for a relevant example for me. Different situation of course, but I would much rather have a good, fast kernel driver with good read support that lets me mount even damaged filesystems than the newer userspace driver that supposedly is safe for write support. That's rather useless to me, because it disconnects on i/o errors (if it mounts in the first place). At least the old ntfs driver lets me mount it, and I can "cp -R" and let it just fail to copy files stored on bad blocks that can't be re-read, and continue copying on errors.

                              Comment

                              Working...
                              X