Ja

Patente ersticken nicht die Kreativität, sondern die Innovation (was Sie sicher gemeint haben).

Wir argumentieren, dass der Patentschutz für die Förderung von Innovationen nicht so nützlich ist, wenn Innovation „sequenziell“ (so dass jede nachfolgende Erfindung im Wesentlichen auf ihren Vorgängern aufbaut) und „komplementär“ ist (so dass jeder potenzielle Innovator eine andere Forschungsrichtung einschlägt). wie in einer statischen Einstellung. Tatsächlich sind die Gesellschaft und sogar die Erfinder selbst ohne einen solchen Schutz möglicherweise besser dran. Darüber hinaus kann der voraussichtliche Gewinn eines Erfinders tatsächlich durch Wettbewerb und Nachahmung gesteigert werden.

http://onlinelibrary.wiley.com/doi/10.1111/j.1756-2171.2009.00081.x/full

Und das nicht nur in der Software.

Die jüngste Verbreitung von Rechten an geistigem Eigentum in der biomedizinischen Forschung deutet jedoch auf eine andere Tragödie hin, eine „Anticommons“, bei der Menschen knappe Ressourcen zu wenig nutzen, weil zu viele Eigentümer sich gegenseitig blockieren können. Die Privatisierung der biomedizinischen Forschung muss sorgfältiger eingesetzt werden, um sowohl die vorgelagerte Forschung als auch die nachgelagerte Produktentwicklung zu unterstützen. Andernfalls könnten mehr geistige Eigentumsrechte paradoxerweise zu weniger nützlichen Produkten zur Verbesserung der menschlichen Gesundheit führen.

http://www.sciencemag.org/content/280/5364/698.short

Und schließlich Bill Gates:

Wenn die Menschen verstanden hätten, wie Patente erteilt würden, als die meisten heutigen Ideen erfunden wurden, und Patente angemeldet hätten, stünde die Industrie heute in einem kompletten Stillstand. Die Lösung . . . ist Patentbörsen. . . und patentieren so viel wie wir können. . . . Ein zukünftiges Start-up ohne eigene Patente wird gezwungen sein, den Preis zu zahlen, den die Giganten auferlegen. Dieser Preis dürfte hoch sein: Etablierte Unternehmen haben ein Interesse daran, künftige Wettbewerber auszuschließen.

Fred Warshofsky, The Patent Wars 170-71 (NY: Wiley 1994).

Die akzeptierte Antwort ist gut. Das möchte ich hier an konkreten Beispielen aus dem Bereich der Datenkompression verdeutlichen.

LZW, die "GIF-Patente"

In den späten 1970er Jahren wurden von Lempel und Ziv zwei grundlegende Wörterbuchkomprimierungsalgorithmen veröffentlicht, die kurz als LZ77 und LZ78 bekannt sind. Viele moderne Datenkomprimierungsalgorithmen können als LZ77- oder LZ78-Familien bezeichnet werden, obwohl sie ausnahmslos erhebliche Verbesserungen gegenüber den Originalen enthalten, insbesondere bei der Verwendung eines Entropiecodierers.

Ein Algorithmus der LZ78-Familie, der in den 1980er Jahren sehr populär wurde, war LZW, benannt nach seinem Vorläuferalgorithmus und seinem Autor, daher Lempel-Ziv-Welch. LZW war eine sehr unkomplizierte Weiterentwicklung von LZ78, die es auf einen 8-Bit-Bytestrom und ein Wörterbuch mit 4096 Einträgen anwendete, das bequem in den typischen 64-KB-Adressraum der damaligen Zeit passte. Die meisten LZW-Implementierungen speichern die Wörterbuchcodes unter Verwendung einer variablen Bitbreite, die zunimmt, wenn sich das Wörterbuch füllt.

Die beiden bekanntesten Anwendungen von LZW sind das UNIX compress-Dienstprogramm und das GIF-Bildformat, das auch heute noch beliebt ist. Frühere Versionen des PKZIP-Dienstprogramms verwendeten es ebenfalls (intern als "Implosion" bekannt). Nach modernen Maßstäben ist es kein sehr guter Komprimierungsalgorithmus, hauptsächlich aufgrund seines kleinen Wörterbuchs und des Fehlens weiterer Entropiecodierung. Es wird jetzt angenommen, dass LZ78-basierte Algorithmen langsamer zu ihrer optimalen Komprimierungsrate konvergieren als entsprechende LZ77-Implementierungen.

Sowohl LZ78 als auch LZW sind im Prinzip recht einfach. Nichtsdestotrotz war LZW durch nicht weniger als drei US-Patente und entsprechende international angemeldete Patente geschützt. Zwei der US-Patente gingen an Unisys und das dritte an IBM.

Der LZW-Algorithmus wurde weit außerhalb des Patentökosystems veröffentlicht, was zu seiner anfänglichen Popularität führte. Softwareingenieure lesen normalerweise keine Patente und haben normalerweise Probleme, die Patentsprache ausreichend gut zu verstehen, um die Algorithmen, die sie beschreiben, genau auf einem praktischen Computer zu implementieren. Normalerweise ist es einfacher, eine wissenschaftliche Arbeit oder sogar ein Quellcode-Listing zu verstehen, und das waren damals die üblichen Mittel zur Verbreitung von Algorithmen. (Zum Teil sind sie es immer noch.)

In den 1990er Jahren bekundete Unisys seine Absicht, die von ihm gehaltenen LZW-Patente durchzusetzen. Dies hätte von den Implementierern des Algorithmus verlangt, Lizenzgebühren zu zahlen – selbst wenn sie das Patent nie gelesen oder auch nur davon gehört hätten, aber jetzt Millionen und Abermillionen von Kopien des LZW-Codes auf Computern auf der ganzen Welt hätten, für die sie jetzt verantwortlich seien.

Es wurde schnell klar, dass die Patente im Wesentlichen den Verschlüsselungsalgorithmus und nicht den Decodierer abdeckten, sodass Personen, die niemals Daten mit LZW komprimierten , sondern nur unkomprimierte vorhandene Daten, relativ sicher waren. Es wurde eine Problemumgehung entdeckt, durch die eine LZW-kompatible Datei erstellt werden konnte, ohne das Patent zu verletzen, aber dies erzeugte eine äquivalente Komprimierung zu einem einfachen RLE-Schema - es war daher nur nützlich, um (große, ineffiziente) GIFs zu erstellen, ohne das Patent zu verletzen.

Die Besorgnis über die Rechtmäßigkeit der Verwendung von LZW führte zu einer Suche nach patentfreien Alternativen und mehr oder weniger direkt zur Entwicklung des "Deflation"-Algorithmus, der eine einfache Kombination des LZ77-Wörterbuchkompressors ist (der Wörterbuchfenster bis zu 32KB) mit dem Huffmann-Entropiecodierer aus den 1950er Jahren.

PKZIP Version 2 ließ die LZW-Unterstützung zugunsten des messbar überlegenen Deflate fallen. Mehrere andere Komprimierungsprogramme, wie z. B. StuffIt auf dem Mac, folgten diesem Beispiel. Das GNU-Projekt wurde gzipals direkter Ersatz für UNIX compressund zlibals einfacher Weg zur Verwendung von Deflate in anderen Anwendungen und Formaten eingeführt.

Das PNG-Bildformat zielte dann darauf ab, GIF durch die doppelten Vorteile einer besseren Komprimierung (über zlib) und Unterstützung für mehr als 256 Farben zu ersetzen - obwohl es die Animationsunterstützung verlor, was sich als erhebliches Versehen herausstellte.

Praktisch die einzige Verwendung für das GIF-Format ist heute seine Animationsfunktion - und jetzt, da die LZW-Patente abgelaufen sind, hat seine Popularität wieder erheblich zugenommen. Es muss jedoch beachtet werden, dass die GIF-Animation nichts mit dem LZW-Algorithmus zu tun hat.

In diesem Fall war die patentfreie Alternative relativ einfach zu finden und erwies sich als objektiv überlegen, was eine Migration weg vom patentierten Algorithmus zu einer relativ einfachen Wahl machte. Nicht jeder Fall ist so zufällig.

Arithmetische Codierung

Der früheste Entropiecodierer, der sich als "optimal" erwiesen hat, war der Huffmann-Codierer von 1951, der selbst eine Verbesserung gegenüber dem sehr ähnlichen Shannon-Fano-Codierer darstellte. Es baut im Wesentlichen einen ausgeglichenen binären Baum des Symbolverzeichnisses auf und speichert ein Bit für jede Verzweigungsentscheidung auf dem Baum. Praktisches Rechnen steckte damals noch in den Kinderschuhen; Wenn jemals Patente für den ursprünglichen Huffmann-Algorithmus angemeldet wurden (was ich bezweifle), sind sie längst abgelaufen, sodass die Verwendung rechtssicher ist.

Es ist jedoch selten, dass die Äste eines Huffmann-Baums perfekt ausbalanciert sind; dies erfordert, dass die Symbolfrequenzen alle Zweierpotenzen sind. Im Allgemeinen ist es also möglich, eine weitere Komprimierung durch arithmetische Codierung zu erhalten, anstatt durch Bitgrenzen eingeschränkt zu werden. Im Wesentlichen wird eine Zahl mit beliebiger Genauigkeit konstruiert, in einem Zahlenraum, der immer wieder in beliebig schiefen Verhältnissen nach relativen Symbolhäufigkeiten unterteilt ist. Sehr häufigen Symbolen werden große Teile des Zahlenraums zugewiesen und können dadurch im Extremfall weniger als ein Bit pro Symbol verbrauchen. Dies ist der Huffmann-Codierung von Natur aus überlegen, die mindestens ein Bit pro Symbol verwenden muss.

Da die arithmetische Codierung jedoch in den 1970er Jahren entwickelt wurde, wurde sie über einen Zeitraum von etwa 15 Jahren mehrfach patentiert. Die meisten Patente decken Methoden zur effizienten Implementierung des Algorithmus für einen bestimmten Datentyp und auf einer bestimmten Klasse von Computerhardware ab, aber die meisten vernünftigen Optionen wurden tatsächlich patentiert (obwohl diese Patente, wie LZW, inzwischen abgelaufen sind). Es wurde allgemein angenommen, dass ein eng verwandter Algorithmus namens Bereichscodierung patentfrei sei, obwohl dies mathematisch der arithmetischen Codierung entspricht.

Die Patente zur arithmetischen Codierung hatten direkte, nachteilige Auswirkungen auf mindestens zwei Komprimierungsformate: bzip/bzip2und JPEG.

Das bzipKomprimierungsdienstprogramm war ein Versuch, das gzipKomprimierungsverhältnis von durch den Einsatz modernerer Techniken zu verbessern; insbesondere die Burrows-Wheeler-Transformation (BWT) und die arithmetische Codierung. Obwohl das Experiment erfolgreich war, erkannte der Autor, dass seine Software aufgrund der Patente nicht legal als Freie Software in den USA veröffentlicht werden konnte, also schrieb er bzip2mit der arithmetischen Codierung, die durch die Huffmann-Codierung ersetzt wurde. Dies war immer noch messbar besser als gzipund wurde daher bzip2für eine Weile in der Freie-Software-Community populär (bis noch fortschrittlichere Dienstprogramme verfügbar wurden). Die ursprüngliche bzipSoftware wurde nie allgemein veröffentlicht, aber ein reines Dekomprimierungsprogramm ist verfügbar, falls Dateien, die damit komprimiert wurden, ans Licht kommen.

Der JPEG-Standard von 1990 ist sehr weit verbreitet; praktisch jede Digitalkamera, jedes Bildbearbeitungsprogramm und jeder Webbrowser unterstützen es heute. Allerdings wird fast ausnahmslos die patentfreie Variante des Formats mit Huffmann-Codierung verwendet. Der Standard definiert auch eine Variante mit arithmetischer Codierung, die jedoch aufgrund der Patente selten verwendet und von den meisten Softwareprogrammen nicht einmal unterstützt wird. Einige der späteren Arithmetik-Codierungspatente sind tatsächlich speziell für JPEG-konforme Arithmetik-Codierer, was die Wahrscheinlichkeit stark erhöht, dass eine unabhängige Implementierung des JPEG-Standards versehentlich verletzen könnte.

Einige Archivkomprimierungsprogramme, einschließlich einiger Versionen von StuffIt, sind in der Lage, JPEG-Dateien zu erkennen und speziell zu behandeln, indem sie sie im Wesentlichen verlustfrei umkehrbar in die arithmetisch codierte Variante konvertieren. Dies spart normalerweise etwa 25 % Speicherplatz, viel besser als die Anwendung eines allgemeinen Komprimierungsalgorithmus auf die Originaldatei. Ohne die Patente zur arithmetischen Codierung, die die allgemeinere Verwendung der effizienteren Variante ersticken, wären JPEG-Dateien meist von vornherein so viel kleiner.

Nachdem die Patente zur arithmetischen Codierung größtenteils abgelaufen sind, beginnt die Verwendung dieser Entropiecodierungsmethode zuzunehmen. Mehrere neuere Videokomprimierungsstandards verlassen sich stark darauf; Insbesondere verwenden sowohl H.264 als auch H.265 einen arithmetischen Codierungsalgorithmus namens CABAC. H.264 unterstützt auch das weniger fortschrittliche CAVLC, das keine arithmetische Codierung verwendet, für das Baseline-Profil.

Dieser Fall veranschaulicht ein Beispiel, bei dem der patentierte Algorithmus den verfügbaren patentfreien Alternativen deutlich überlegen war, was über einen Zeitraum von mehreren Jahrzehnten zu einer beobachtbaren und überprüfbaren Abnahme der den Endbenutzern zur Verfügung stehenden Softwarefunktionen führte.