| 1. Wie wird Microsofts geistiges Eigentum an exFAT geschützt? |
| exFAT wird durch zahlreiche von Microsoft gehaltene Patente geschützt, die noch einige Jahre Gültigkeit haben. | |
| 2. Wie kann ein Hersteller (OEM) exFAT in Linux einsetzen, ohne Lizenzgebühren an Microsoft abführen zu müssen? |
| Microsoft ist Mitglied im Open-Innovation-Netzwerk (OIN). Eine solche Mitgliedschaft beinhaltet eine defensive Patentverpflichtung gegenüber allen OIN-Mitgliedern. Ist also ein Hersteller ebenfalls OIN-Mitglied, dann werden für seine Nutzung von exFAT keine Patentgebühren an Microsoft fällig. | |
| 3. Deckt die OIN-Mitgliedschaft, was das exFAT-Patent angeht, mehr ab als Linux (ab Kernel 5.7)? |
| Nein. Das defensive Patent innerhalb von OIN gilt nur für das Linux-System, definiert in der OIN-Lizenzvereinbarung. Diese erstreckt sich nicht auf den Einsatz von exFAT unter einem anderen Betriebssystem oder Kernel. | |
| 4. Welche exFAT-Implementierung darf kostenlos in Linux verwendet werden? |
| Es ist wichtig zu wissen, dass exFAT ausschließlich in den Linux Kernel 5.7 und Folgeversionen implementiert werden darf. Andere Implementierungen von exFAT (etwa ein externer exFAT-Treiber oder ein Retrofit des 5.7-Kernelcodes auf eine ältere Linux-Kernelversion) bedürfen einer gesonderten Vereinbarung mit Microsoft, das die Rechte an exFAT hält. | |
| 5. Darf exFAT kostenlos in älteren Linux-Kernelversionen (vor 5.7) eingesetzt werden? |
| Nein, Microsoft gestattet nur die Implementierung des exFAT-Codes in den Linux Kernel ab Version 5.7. Patentgebühren werden fällig, sobald exFAT in einer älteren Linux-Version verwendet wird. | |
| 6. Welche Verpflichtungen haben Mitglieder des Open-Invention-Netzwerks (OIN)? |
| Neben vielen anderen Verpflichtungen fordert Paragraph 1.2 der OIN-Lizenzvereinbarung, dass jedes OIN-Mitglied und seine Mitarbeiter “ab dem Zeitpunkt der Teilnahmeberechtigung jedem Lizenznehmer und dessen Tochterunternehmen unter diesem Patent eine gebührenfreie, weltweit gültige, nicht-exklusive und nicht übertragbare Lizenz für die eigene Herstellung oder Herstellung im Auftrag, Nutzung, den Import und Vertrieb von Linux-Systemen gewährt.” Die OIN-Mitgliedschaft bedeutet eine defensive Patentverpflichtung quid pro quo – ein OIN-Mitglied muss sein Patent-Portfolio der gesamten Open-Source-Community zur Verfügung stellen. Bevor Hersteller (OEMs) ihre wertvollen Patente durch die gesamte OIN-Community und damit mögliche Konkurrenten nutzen lassen, ziehen es die meisten von ihnen vor, eine ordnungsgemäße Lizenz für Microsofts exFAT-Technologie zu beziehen, entweder direkt von Microsoft oder von einem authorisierten Microsoft-Partner wie Paragon Software. | |
| 7. Worin liegt hinsichtlich der exFAT-Technologie der grundlegende Unterschied zwischen einer GPL-v2-Lizenz, welche die Inklusion von exFAT in einen Linux-Kernel abdeckt, und ihrer Nachfolgerin GPL v3? |
| GPL v3 enthält eine ausdrückliche Patentlizenz, GPL v2 hingegen nicht. Das ermöglicht die “patentfreie” Nutzung der exFAT-Technologie unter der GPL-v2-Lizenz, getragen von der gegenseitigen defensiven Patentverpflichtung im Open-Invention-Netzwerk (OIN). Diese Unterscheidung zeigt ganz klar Microsofts Absicht, die “patentfreie” Nutzung seiner exFAT-Technologie auf die OIN-Mitglieder zu beschränken, und das ausschließlich im Rahmen der GPL-v2-Lizenz. | |
| 8. Welche Konsequenzen hat die GPL-v2-Lizenz für Hersteller (OEMs)? |
| Hersteller scheuen den Einsatz von GPL-Software und -Komponenten, die in der Regel modifiziert werden müssen, damit das Endprodukt hinsichtlich Stabilität, Größe, Speichernutzung und Performanz optimal funtioniert. Die GPL verlangt, dass jede Änderung im Linux-Code veröffentlicht (d.h. der Open-Source-Community zugänglich gemacht) wird, sobald das Produkt weitervertrieben wird – was natürlich immer der Fall ist, wenn Hersteller ihre Produkte auf den Markt bringen. GPL-Codes werden selten eingesetzt, weil Hersteller - verhindern wollen, dass ihre Mitbewerber direkt von ihren Code-Änderungen und -Optimierungen, die ja offengelegt werden müssen, profitieren.
- den juristische Prozess, den die Erfüllung der Verpflichtung gegenüber der GPL/Open-Source-Community ja auch bedeutet, vermeiden wollen, denn dieser ist zeitintensiv und mit hohen Kosten verbunden.
| |
| 9. Wurde der in den Linux-Kernel eingebundene Open-Source-Code, der exFAT-Unterstützung implementiert, von Microsoft entwickelt bzw. unterstützt oder genehmigt? |
| Der in den Linux-Kernel eingebundene Code wurde urprünglich von Technologie-Fans in der Open-Source-Community entwickelt. Microsoft hat den Code weder entwickelt noch getestet, genehmigt oder unterstützt, und auch hinsichtlich seiner Qualität hat er keinerlei Verbindung zu Microsoft. | |
| 10. Welche exFAT-Implementierungen werden von Microsoft empfohlen? |
| Herstellern, die eine für die Industrie geeignete exFAT-Implementierung inkl. professionellem Support und Garantie brauchen, empfiehlt Microsoft Branchenführer wie Paragon Software. Paragon Software ist Microsofts bevorzugter Anbieter für stabile, zuverlässige Lösungen bezüglich exFAT-Implementierungen in unterschiedliche Betriebssysteme und Kernel wie Linux, die auf einem proprietäten (also nicht GPL-konformen) Paragon-Code basieren – Lösungen, welche die für den OEM-Vertrieb unbedingt benötigte exFAT-Lizenz von Microsoft gleich mitbringen. | |
| 11. In welchem Umfang veröffentlicht Microsoft die exFAT-Spezifikationen? |
| Die von Microsoft veröffentlichten exFAT-Spezifikationen, die der Open-Source-Community dabei helfen sollen, Kernel-Kompatibilität mit dem exFAT-Dateisystem zu entwickeln, enthalten keine Spezifikationen für Transactional exFAT (TexFAT). Daher benötigen alle exFAT-Implementierungen mit Unterstützung für Transactional exFAT ordnungsgemäße Lizenzen für Microsofts exFAT-Technologie. | |
| 12. Wie können Hersteller (OEMs) sicher sein, dass die exFAT-Dateisystemimplementierung keine Kernel panics verursacht, frei ist von Programmfehlern und Speicherlecks, die zu Datenverlust führen, und dabei kompatibel mit verschiedensten realen Dateisystem-Anwendungsszenarien? |
| Die Implementierung eines Dateisystemtreibers in einen Kernel ist eine anspruchsvolle und komplexe Aufgabe. Jedes Fehlverhalten des Codes innerhalb des Kernels eines Betriebssystems führt zu Problemen in der Gesamtfunktionalität des Betriebssystems. Die Folgen eines Implementierungsfehlers sind schwerwiegender als bei bei der Programmierung einer Anwendung: Der Absturz einer Anwendung bedeutet nicht das Gleiche wie ein Absturz des gesamten Systems mit all seinen Folgen. Auto-Tests, Auslastungs- und Regressionstests (auf zuvor aufgetretene Probleme) sind ein sicherer Weg zu einem gesunden und stabilen Kernel-Code im Betriebssystem. Die Herausforderung liegt im enormen Umfang dieser Prüfungsverfahren. Testzyklen bei Paragon Software umfassen Hunderte von Tests und Szenarien, um sicherzustellen, dass Änderungen im Code oder im Betriebssystem nicht zu Problemen in der Praxis führen. Paragons Testreihen haben sich über zwei Jahrzehnte hinweg entwickelt und basieren auf Szenarien aus der Praxis von Kunden, zu denen einige zu den weltweit führenden Herstellern zählen. Unklar ist, wie die Open-Source-Community ein vergleichbar hohes Niveau an Qualitätssicherung sicherstellen will, oder, was noch wichtiger ist, wie lang es dauern würde, ein vergleichbares Niveau an Fehlerbereinigungen und Zuverlässigkeit zu erreichen. Bei Mac OS zum Beispiel befindet sich die Implementierung eines NTFS-Schreibmodus auf Kernel-Ebene seit dem 24. Oktober 2003 (seit über 16 Jahren) im “Staging”-Status. Allein diese Beispiel zeigt, dass selbst Tech-Giganten wie Apple solche komplexen Probleme nicht innerhalb eines sinnvollen Zeitrahmens bewältigen können, selbst bei Offenlegung des Quellcodes für die Open-Source-Community. *Anmerkung: Was FreeBSD an NTFS-Schreibzugriff unter Mac OS anbietet, funktioniert nur in wenigen Fällen – Mac OS blockiert diese Funktion eines generischen Schreibzugriffs, weil sie nur unter großen Mühen stabil läuft. | |
| 13. Wird die Offenlegung der exFAT-Spezifikationen von Microsoft von Nutzen sein, um eine stabile exFAT-Unterstützung im Linux-Kernel zu entwickeln? |
| Voraussetzung für die Implementierung eines stabilen Dateisystemtreibers ist nicht etwa die Verfügbarkeit des Dateisystemformats. Die Herausforderung liegt in der Handhabung asynchroner Lese/Schreibanfragen in mehreren Streams. Bisher gibt es keine Spezifikationen, die beschreiben, wie das in einem abstrakten Betriebssystem-Kernel wie Linux richtig gemacht werden soll. Es geht also um die Entwicklung einer zuverlässigen Komponentenarchitektur auf Kernelebene; dieser Prozess unterscheidet sich stark vom Programmieren auf FUSE- oder Anwendungsebene und erfordert sehr gründliche und zeitaufwändige Testungen sowie Erfahrung in der Entwicklung von Codes auf Kernelebene. | |
| 14. Warum liefert Microsoft keine eigene, genuine Implementierung einer exFAT-Unterstützung für Linux-Kernel? |
| Die Antwort auf diese Frage kennen wir nicht. | |
| 15. Welche Risiken gehen Erstausrüster ein, wenn sie den quelloffenen Code für den Linux-Kernel anstelle der proprietären Lösung von Paragon Software verwenden? |
- Tritt im Open-Source-Code ein Problem auf und es findet sich niemand, der dieses beheben bzw. warten will oder kann, kann es passieren, dass der Code aus Linux wieder ausgeschlossen wird. Ein Beispiel dafür ist die Entfernung von EXOFS aus der Linux-Version 5.1.
- Verursacht der Open-Source-Code ein Problem (etwa einen Totalabsturz, beträchtlichen Speicherverbrauch oder enorme CPU-Last innerhalb der Hersteller-Hardware-Konfiguration, Leistungsverlust nach einem Linux-Upgrade usw.), dann kann der Hersteller einzig die Open-Source-Community um Unterstützung bitten. Kommerzielle exFAT-Anbieter scheiden hier aus, weil sie gemäß der GPL v2 ihre Quellcodes offen legen müssten.
- Hersteller könnten Zielscheibe für Forderungen zur Erfüllung von GPL-Richtlinien werden, was die Offenlegung des Quellcodes im Endprodukt bedeutet. Hier wird es schwierig, zu entscheiden, wie weit diese Offenlegung gehen muss, denn typischerweise befindet sich im Endprodukt eine Mischung aus prorietären und quelloffenen, der GPL unterliegenden Codes. Hier bedarf es eines erfahrenen (d.h. teuren) Anwalts, der Anfragen zur Erfüllung der GPL richtig einordnen und festlegen kann, bis zu welchem Grad ein Quellcode offengelegt werden sollte.
- Auch Open-Source-Codes haben ihre Schwachstellen, die leicht von Viren und Cyber-Angriffen ausgenutzt werden. So haben Schwachstellen im SMB-Protokoll schon zu massiven Virenangriffen geführt. Proprietäre, d.h. nicht quelloffene Codes sind sicherer und mindern das Risiko einer solchen Anfälligkeit für Virenangriffe im Produkt.
| |
| 16. Die Paragon-Software-Lizenz für den exFAT-Treiber gibt es mit und ohne Lizenz für Microsofts exFAT-Technologie. Worin besteht der Unterschied bei den Lizenzbedingungen? |
| Es gibt kleinere Unterschiede in der Berichterstellung über die Nutzung von Microsofts exFAT-Technologie sowie spezifische Zahlungskonditionen. Genaueres erfahren Sie auf Anfrage und nach Unterzeichnung einer Verschwiegenheitserklärung. | |
