Kommerzialisierung von Verbesserungen der freien Software unter Copyleft-Lizenzen

Ich wollte diesen Artikel mit Informationen beginnen, dass es immer erhebliche Schwierigkeiten gibt, die Verbesserungen freier Software zu kommerzialisieren, und die Situation mit dem Redis-Projekt als anschauliches Beispiel anführen.

Aber dann wurde mir klar, dass die Situation mit Redis ( Redis ändert seine Lizenz wieder ) als Beispiel nicht sehr geeignet ist. Und das nicht nur wegen der höllischen Mischung verschiedener im Projekt verwendeter Lizenzen, sondern auch wegen zusätzlicher Verwirrung, die sich aus der Interpretation der Begriffe Open Source und Freie Software ergibt.

Gemessen an den Ergebnissen der Arbeit von Cloud-Anbietern für das letzte Quartal 2019 und schließlich basiert dieses Geschäft hauptsächlich auf freier Software, schließt dies die Frage nach mindestens einer wirklich funktionierenden Art der Kommerzialisierung freier Software.

Immerhin sprechen die Zahlen für sich. Der Gesamtumsatz der Cloud-Anbieter belief sich im letzten Quartal 2019 auf über 30 Milliarden US-Dollar. Der Marktführer ist Amazon (32,4% des Marktes), Microsoft Azure fast die Hälfte (17,6%), gefolgt von Google Cloud (6%) und Alibaba Cloud (5,4%).

Für kleinere Unternehmen ist ein solches Geschäft jedoch im Allgemeinen nicht erreichbar. Daher kann für sie das Problem der Kommerzialisierung von Verbesserungen der freien Software unter Copyleft-Lizenzen (wie der GPL) durchaus relevant sein.
Ich mache Sie auf einen praktischen Weg aufmerksam, um Änderungen an freier Software unter Copyleft-Lizenzen zu kommerzialisieren, auch im Hinblick auf die Gesetzgebung der Russischen Föderation.

Über welche Lizenzen sprechen wir?


In diesem Artikel geht es um freie Software in dem Sinne, wie es die Free Software Foundation (FSF) vorsieht.

Seine Prinzipien werden durch 4 Freiheiten formuliert:

  • Freiheit 0: Führen Sie das Programm für einen beliebigen Zweck aus.
  • Freiheit 1: Das Programm studieren und seine Arbeit an Ihre Bedürfnisse anpassen. *
  • Freiheit 2: Verteilen Sie Kopien des Programms. **
  • Freiheit 3: Verbessern Sie das Programm und veröffentlichen Sie diese Änderungen oder den gesamten Programmcode als Ganzes. *

*) Die Freiheiten 1 und 3 erfordern die Verfügbarkeit des Quellcodes des Programms, der zum Studieren und Ändern verfügbar sein muss. Es ist gerade wegen dieser , dass Verwirrung oft entsteht, da Open Source bedeutet genau Open - Source - Code, während das Konzept der Free Software bezieht sich auf Software - Rechte , und für die die Anwesenheit des Quellcodes eines Programms ist obligatorisch, aber nicht die einzige Voraussetzung.

**) Freedom 2 erlaubt die kostenlose Verbreitung des Programms und aus diesem Grund gibt es auch Verwechslungen mit dem Begriff Freeware , was nur ein kostenloses Programm bedeutet, sich aber auf jedes Programm beziehen kann, nicht unbedingt auf ein kostenloses.

Die Idee der Freien Software ist es daher, dem Benutzer angemessene Informationen zur Verfügung zu stellenRechte an der Software, die der Inhaber des Urheberrechts jedem Benutzer garantiert.

Ein ähnliches Prinzip heißt Copyleft , das die Wahrung der Freiheiten in abgeleiteten Werken erfordert und deren Einschränkung im Vergleich zum ursprünglichen Softwareprodukt verbietet.

In der Rechtssprache ist dies in der GPL (GNU General Public License) formuliert, nach der der Autor eines abgeleiteten Werks die Freiheiten im Vergleich zum ursprünglichen Programm bewahren (nicht einschränken) muss.

Aufgrund der Wahrung der ursprünglichen Freiheiten werden solche Lizenzen als "klebrig" oder "viral" bezeichnet.

Was ist das Problem bei der Kommerzialisierung der GPL?


Problem 1


Das Hauptproblem bei der Kommerzialisierung von Software unter der GPL besteht darin, dass der allererste Kunde, der das Programm oder seine Quellen erhält, das Recht hat, der Distributor dieses Programms selbst zu werden, und der Entwickler es in keiner Weise stoppen kann: www.gnu.org/licenses/gpl-faq. ru.html # DoesTheGPLAllowNDA , www.gnu.org/licenses/gpl-faq.ru.html#DoesTheGPLAllowModNDA

Und da jeder offizielle Benutzer die Quelle erhalten kann, kann jeder Benutzer die empfangene Software oder deren Quelle kostenlos und kostenlos veröffentlichen Dies wird sicherlich zu Problemen bei der Rückzahlung der in die Entwicklung eines solchen Softwareprodukts investierten Finanzen führen.

Für Genehmigungen gibt es kein solches ProblemLizenzen wie BSD, MIT oder Apache. Sie ermöglichen die Einschränkung der Freiheiten bei Derivaten. Daher reicht es aus, die ursprüngliche kostenlose Lizenz in proprietär (proprietär) zu ändern und den Quellcode der Software nicht für den Benutzer (Kunden) zu öffnen.

Problem 2


Die zweite Schwierigkeit beim Aufbau eines Geschäfts mit Open Source-Software mit viralen Lizenzen besteht darin, dass die vollständige Freiheit bei der Verwaltung der Rechte an einem Softwareprodukt nur ihrem Eigentümer gehört, was völlig logisch ist.

Und nur der Inhaber exklusiver Rechte an dem Programm kann das Doppellizenzmodell verwenden, das eine „nicht kostenlose“ kommerzielle Lizenz für Software für Geschäftskunden und eine GPL-kompatible Lizenz für Vertreter der Community impliziert.

Ein solches Schema eignet sich jedoch nicht für sekundäre Projekte (sogenannte „Forks“) oder Projekte, bei denen zusätzliche Module erstellt werden sollen, die mit dem GPL-Code zusammenarbeiten sollen, und muss daher auch über eine GPL-kompatible Lizenz verfügen.
Mit der unten vorgeschlagenen Methode zur Kommerzialisierung von Verbesserungen der freien Software können Sie die oben beschriebenen Probleme umgehen. Es ist geeignet für:

  • Virale Lizenzen wie die GPL.
  • Vermarktung von Software - Verbesserungen , wenn der Entwickler nicht eigene exklusive Rechte an der Software - Produkt.

Wann erscheint der kommerzielle Wert?


Nach den Erläuterungen der Free Software Foundation (FSF) erlaubt die GPL die kostenpflichtige Verteilung der Programme www.gnu.org/philosophy/selling.html , www.gnu.org/licenses/gpl-faq.ru.html#DoesTheGPLAllowMoney .

Gleichzeitig verpflichtet die GPL den Entwickler nicht, seine Verbesserungen der Öffentlichkeit zugänglich zu machen: www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic

Dies macht es theoretisch möglich, das Geschäftsmodell der Kapitalrendite in Open-Source-Software aufgrund ihrer kostenpflichtigen Verteilung zu nutzen, wenn der kommerzielle Wert durch das ausschließliche Eigentum an dem Softwareprodukt geschaffen wird, genauer gesagt, indem die Verfügbarkeit der aktuellen Version für eine breite Palette von Benutzern eingeschränkt wird. Tatsächlich ist dies eine Wiederholung des Geschäftsmodells proprietärer Software, das auf dem ausschließlichen Eigentum an der Ressource basiert.

Mit anderen Worten, Sie müssen vorübergehend die zweite Verzögerung zwischen dem Recht des Kunden auf weitere Verteilung der Softwareübertragung an den Kunden und dem Aufkommen der gekauften Software unter der GPL-Lizenz festlegen.

In der Tat ist es BP ,Variable Einschränkung der Vertriebsfreiheit, as Andernfalls wird einfach „die Wirtschaft nicht funktionieren“, da die Bedingung für das Vorhandensein einer Nachfrage nach dem Produkt die mangelnde Verfügbarkeit billigerer (oder kostenloser) Analoga auf dem Markt sein wird.

Erstellen einer temporären für die zweite Verzögerung auf der Grundlage der Lizenzbedingungen


Die erste Option ist die Schaffung einer vorübergehenden etwa zweiten Verzögerung zwischen der Übertragung der Software an den Kunden und dem Auftreten seines Rechts auf eine weitere Verbreitung gekaufter Verbesserungen, basierend auf der Schaffung der erforderlichen Bedingungen gemäß der Auslegung der Klausel der GPL seitens der Free Software Foundation.

Dies wird ermöglicht, indem der Käufer des Softwareprodukts in einen (Mit-) Entwickler verwandelt wird : www.gnu.org/licenses/gpl-faq.html#DevelopChangesUnderNDA

Dazu reicht es aus, eine Vereinbarung mit dem Käufer (Kunden) über seine Arbeit zu unterzeichnen, beispielsweise als Tester für die Produktivität Daten, die eine Vereinbarung über die Nichtverteilung von Kopien des Softwareprodukts für die Dauer dieses Vertrags enthalten sollten.

Das Schema der Interaktion des Entwicklers mit dem Benutzer:

  1. «» .
  2. (-) , , .
  3. FSF . www.gnu.org/licenses/gpl-faq.html#DevelopChangesUnderNDA
  4. .

GPL


Der zweite Weg, um eine Zeit für die zweite Verzögerung zwischen der Übermittlung des Kunden und dem Erscheinen der Software in seinem legitimen Recht auf ihre weitere Verbreitung zu schaffen, ist aufgrund der Tatsache möglich, dass die Rechte an dem Programm, die durch die Bestellung des Computers erstellt wurden, und dementsprechend die Möglichkeit einer weiteren Verbreitung dort beim Kunden erst nach Abschluss Erfüllung ihrer Verpflichtungen durch die Vertragsparteien zur Überarbeitung der Software.

Das Schema der Interaktion mit der Benutzerfirma:

  1. Der Entwickler schließt mit der Anwenderfirma eine Vereinbarung über die Fertigstellung des Originalprodukts für freie Software mit einer Virenlizenz.
  2. , ( 712. ; 1296. , ).
  3. () - . , .. .
  4. , .

?


Diese Arbeitspläne wurden der Community bereits 2014 auf mehreren Konferenzen vorgeschlagen. Zuvor haben sich die Autoren jedoch an Richard Stallman gewandt, um seine Meinung zu diesen Methoden zur Kommerzialisierung der GPL zu erfahren.

Natürlich war er nicht begeistert, denn in diesem Schema gibt es eine vorübergehende, aber immer noch Verletzung der ursprünglichen Freiheiten: Freiheit 2: Verteilen Sie Kopien des Programms und Freiheit 3: Verbessern Sie das Programm und veröffentlichen Sie diese Änderungen oder den gesamten Programmcode.

Er musste jedoch zustimmen, dass die erste Methode mit einem (Mit-) Entwickler nicht gegen die GPL verstoßen würde, es sei denn, die Arbeit des Benutzers war fiktiv. Mit anderen Worten, der Benutzer muss wirklich in Übereinstimmung mit den vertraglichen Verpflichtungen arbeiten und diese Arbeit muss wirklich bezahlt werden.

Bei der zweiten Methode ist Richard Stallman der Ansicht, dass das System gegen GPLv3 verstößt, in dem ausdrücklich festgelegt ist, dass die Lizenz Vorrang vor vertraglichen Verpflichtungen hat. Die Anwälte stimmen dem jedoch nicht zu, da die Lizenz erst nach der Übertragung der Rechte an dem Ergebnis der Arbeit „zu arbeiten beginnt“. Wer sich als Ergebnis von Rechten herausstellt, kann daher nur echte Rechtspraxis nachweisen.

Abschließend


Die Schaffung von Beschränkungen für den Vertrieb von Freier Software wird von der Community immer als „feindlich“ empfunden, auch wenn diese Beschränkungen den Lizenzbestimmungen vollständig entsprechen, nicht dem Gesetz widersprechen und zur Entwicklung freier Projekte selbst beitragen.

Andererseits schränkt das Fehlen einer normalen Methode zur Kommerzialisierung von Code unter der GPL die Attraktivität von Investitionen und deren Entwicklung erheblich ein, weil Normale Kommerzialisierungsmethoden stehen nur Eigentümern mit exklusiven Rechten am Quellcode zur Verfügung.

Infolgedessen sind Entwickler gezwungen, entweder nicht zum Kerngeschäft gehörende Geschäfte zu tätigen oder die GPL-Lizenzumgehungstechniken zu verwenden, um mit einem proprietären Geschäftsmodell für Software zu arbeiten, das auf dem ausschließlichen Eigentum an dem Urheberrechtsobjekt basiert.

Ich hoffe, dass dieses Material jemandem hilft, mit freier Software ein Geschäft aufzubauen.

Autoren: Alexander Ryabikov, Sergey Sereda, Ph.D.

Basierend auf Konferenzmaterialien:
Open Source Summit
LVEE 2014
Ich würde mich sehr über Ihre Erfahrungen bei der Kommerzialisierung freier Software mit Copyleft-Lizenzen freuen.

All Articles