| 1. How is the Microsoft exFAT Intellectual Property (IP) protected? |
| exFAT IP is protected by multiple patents, owned by Microsoft, that are valid for the next several years. | |
| 2. How can an OEM use exFAT in Linux without paying any patent fees to Microsoft? |
| Microsoft is a member of the Open Innovation Network (OIN). This membership provides a defensive patent commitment to all OIN members. Thus, if an OEM is a member of OIN, then their use of exFAT does not require paying a patent fee to Microsoft. | |
| 3. Does OIN membership cover anything other than Linux (Kernel 5.7 or later) in terms of the exFAT patent? |
| No. OIN’s defensive patent commitment applies only to the Linux System as defined in the OIN license agreement. The use of exFAT under any other operating system or kernel is not covered by OIN’s defensive patent commitment. | |
| 4. Which exFAT implementation is free to use in Linux? |
| It is important to understand that exFAT can only be used as an implementation in Linux Kernel 5.7 and later. Other implementations of exFAT (e.g. an external exFAT driver, or retrofit of 5.7 kernel code to earlier versions of Linux Kernel) will require an agreement with Microsoft for exFAT IP, which is protected by patents. | |
| 5. Can exFAT be used for free under any version of Linux earlier than Kernel 5.7? |
| No. Microsoft only endorsed the use of the exFAT implementation code in the Linux Kernel beginning with Linux Kernel 5.7. exFAT royalties must still be paid for use in any earlier version of Linux. | |
| 6. What obligations are imposed on Open Invention Network (OIN) members? |
| Apart from a variety of other obligations, the OIN license agreement clause 1.2 requires that every OIN member and its affiliates “grant to each Licensee and its Subsidiaries that are Subsidiaries as of the Eligibility Date a royalty-free, worldwide, nonexclusive, non-transferable license under Your Patents for making, having made, using, importing, and Distributing any Linux System.” OIN membership provides defensive patent commitment on a quid pro quo basis – an OIN member must provide their patent portfolio for free to the entire open source community. Most OEMs will prefer to obtain a proper license for Microsoft exFAT technology from either Microsoft or an authorized Microsoft partner such as Paragon Software, rather than make their valuable IP patents available for free to the entire OIN community and potential competitors. | |
| 7. What is the fundamental difference between a GPL v2 license, which covers exFAT inclusion in a Linux Kernel, and its successor GPL v3 in regard to exFAT technology? |
| GPL v3 contains an explicit patent license, whereas GPL v2 does not. This is why the “patent-free” use of exFAT technology under the GPL v2 license is possible via the mutual defensive patent commitment of the Open Invention Network (OIN). This distinction clearly outlines Microsoft’s intention to limit the “patent-free” use of its exFAT technology only to OIN members and strictly under the GPL v2 license. | |
| 8. What are the implications of GPL v2 license for OEM manufacturers? |
| OEMs prefer to avoid using GPL software and components, which typically require modifications to make the final product optimized for stability, size, memory usage and performance. GPL requires any changes made to the original Linux code to be published (i.e. released to the open source community) in case of further distribution – this is always the case when OEM products are distributed with GPL software and components. Reasons OEMs avoid using GPL code: - Their competitors may directly benefit from their code changes and optimizations,which must be made public;
- Serving GPL/open source community requests is a legal process, which requires highly qualified (i.e. expensive) legal resources from the OEM.
| |
| 9. Is the open-source code committed into a Linux Kernel for implementing exFAT support developed or in any way endorsed or approved by Microsoft? |
| The code committed into a Linux Kernel was originally developed by enthusiasts of the open source community – it was not developed, tested, approved or endorsed by Microsoft, and is not in any other way related to Microsoft in terms of quality of the code. | |
| 10. Which implementations of exFAT are recommended by Microsoft? |
| Microsoft recommends industry leaders such as Paragon Software for OEMs that require an industrial-grade solution for exFAT implementation, backed by professional support and a warranty. Paragon Software is Microsoft’s preferred exFAT provider of stable, robust solutions for exFAT implementations for various operating systems and kernels such as Linux, based upon proprietary (non-GPL) Paragon code – and includes the Microsoft exFAT technology license required for OEM distribution. Paragon can also deliver custom builds of Linux with exFAT support implemented in the Linux Kernel, provided that such implementation is used in-house, i.e. without further distribution. | |
| 11. How complete are the exFAT specifications made public by Microsoft? |
| exFAT specs released by Microsoft, to help the open source community develop Kernel support for the exFAT file system, do not include specifications for Transactional exFAT (TexFAT). Thus, any exFAT implementation with Transactional exFAT support requires a proper license for Microsoft exFAT technology. | |
| 12. How can OEM manufacturers be assured that exFAT file system implementations will not cause Kernel panics, is free from data-loss bugs and memory leaks, and compatible with a variety of real-world file systems usage scenarios? |
| Kernel implementations of a file system driver is a highly sophisticated task. Any misbehavior of the code inside the kernel of an operating system leads to issues with general OS functionality. The cost of such a mistake with implementations is much higher than application level programming. A crash of an application does not lead to an entire system crash and further consequences. Auto-tests, load tests and regression testing for previously known issues are the best way to assure healthy and stable OS kernel code. The main problem here is that the scope of such tests are extremely large. Paragon’s test cycle includes hundreds of tests and scenarios to ensure that changes to code or to the OS itself will not lead to problems in real life. These tests took almost two decades to develop and are based on real-life scenarios from Paragon’s customers – many of the largest OEMs in the world. It’s not clear how the open-source community will compare to this level of quality assurance, but more important, how long it would take to get to a comparable level of bug coverage and reliability. Consider Mac OS, where kernel-level NTFS Write mode implementation has remained at “staging” status since October 24, 2003 (over 16 years). This example shows that even tech giants like Apple are not able to solve such complexities in a reasonable timeframe, even with the disclosure of source code to the open-source community. *Note: The FreeBSD offering of NTFS Write support in Mac OS only works for a small number of use cases – it’s blocked by Mac OS for generic write use since it requires a tremendous effort to ensure stability. | |
| 13. Will disclosure of the exFAT specification by Microsoft be of any help in developing stable exFAT support in a Linux Kernel? |
| The availability of a file system format is not a prerequisite for implementing a stable file system driver. The major problem is handling asynchronous, multi-stream read/write requests. There are no specifications available that describe how to do this properly in an abstract OS kernel like Linux. It is a matter of designing a robust kernel-level component architecture, which is very different from FUSE-level and application-level programming, and requires exhaustive and time consuming test coverage and experience in developing Kernel-level code to succeed. | |
| 14. Why is Microsoft not providing its own genuine implementation of exFAT support for a Linux Kernel? |
| We do not know the answer to this question. | |
| 15. What are some of the risks OEMs face when using open-source code for a Linux Kernel versus a proprietary solution from Paragon Software? |
- If an issue is found within the open-source code and no one is willing or able to fix or maintain it, then the code can be excluded from Linux. For example of this was the removal of EXOFS from Linux in version 5.1.
- If an issue is caused by the open-source code (e.g. fails completely, causes extensive memory or CPU usage with an OEM’s hardware configuration, performance degrades with a new Linux update, etc.), then the only resource for assistance is the open source community. OEMs should not expect any assistance from commercial exFAT providers since GPL v2 requires the source code to be published.
- OEMs can become a target for legal inquiries for GPL compliance concerning full disclosure of the source code related to the OEM’s product. The main problem with such demands for source code disclosure is determining to what extent an OEM is obligated to disclose the source code of its product – especially since OEM products typically use a mix of both proprietary and open source GPL code. An experienced (i.e. expensive) lawyer is required to address such GPL compliance inquiries properly and determine to what extent source code should be disclosed.
- Open-source code is not free of vulnerabilities that are easy to exploit for viruses and cyber attacks. Vulnerabilities of SMB protocol have already led to major virus attacks. Proprietary code, which is not available as source code, is safer and decreases the risk of an OEM’s product being susceptible to such vulnerability-based attacks.
| |
| 16. Paragon Software can license the exFAT driver either with or without a license for the Microsoft exFAT technology included. Is there a difference in those licensing terms? |
| There are minor differences in reporting the use of Microsoft exFAT technology, as well as specific payment terms. Details are available upon request for potential customers under NDA. | |
