Seit wir mit dem Release 2.1 der Structr-Plattform(https://structr.org/download) ein Lizenzschlüssel-System eingeführt haben, bekommen wir viele Fragen wie „Structr ist Open Source, aber benötigt Lizenzschlüssel. Ist das nicht ein Widerspruch?“
Das ist nicht der Fall, aber anscheinend gibt es immer noch viel Verwirrung über das Konzept von Open Source/Freier Software und kommerzieller Nutzung.
Offene Quelle
Open-Source-Software (in ihrer weitesten Definition) ist Software, die der Öffentlichkeit in Form von Quellcode zur Verfügung gestellt wird, der zu einem ausführbaren Programm kompiliert werden kann, das mit oder ohne eine kompilierte, lauffähige Version verbreitet wird.
In der Regel wird ein Open-Source-Softwarepaket (OSS) unter einer Open-Source-Lizenz vertrieben. Das bedeutet nicht notwendigerweise, dass die Software frei ist (von Kosten, oft verwendet in dem Ausdruck „frei wie Bier“, im Gegensatz zu „frei wie Sprache“), obwohl immer noch viele Leute zu denken scheinen, dass genau das immer der Fall ist. Um genau zu wissen, was mit dem Quellcode eines bestimmten OSS-Programms oder -Pakets erlaubt ist, muss man sich die Lizenz ansehen, mit der es geliefert wird.
Da dieser Blog-Beitrag nicht darauf abzielt, die Besonderheiten von Open-Source-Lizenzen zu erörtern, verweisen wir auf https://opensource.org/licenses, um einen guten Überblick über die gängigsten OSS-Lizenzen zu erhalten. Zusammenfassend kann man sagen, dass es grundsätzlich zwei Arten von OSS-Lizenzen gibt: Permissive (im Stil von BSD oder MIT) und nicht-permissive (z. B. GPL/AGPL, auch Copyleft genannt).
Beide garantieren im Grunde, dass ihre Nutzer die Freiheit haben, den Code zu verwenden, zu verändern und weiterzugeben, aber nur permissive Lizenzen erlauben proprietäre abgeleitete Werke. Ein abgeleitetes Werk ist eine neue, eigenständige Schöpfung (hier: eine Software), die wesentliche Elemente eines ursprünglichen Werks (des zugrundeliegenden Werks) verwendet, so dass Copyleft-Lizenzen sicherstellen, dass jedes abgeleitete Werk frei verfügbar bleibt.
Monetarisierung von Open-Source-Software
Unabhängig davon, ob sie von einer großen Gemeinschaft oder einem Unternehmen unterstützt werden: Die meisten Open-Source-Projekte bieten ihren Nutzern einen großen Nutzen und sind von guter Qualität. Außerdem sind sie meist gut dokumentiert, sicher und einfach zu verwenden und in eigene Projekte zu integrieren. Viele Menschen sind der Meinung, dass Open-Source-Projekte oder -Produkte insgesamt besser sind als ihre proprietären Gegenstücke.
Dennoch denken viele Menschen, dass Open-Source-Software kostenlos sein muss (wie Bier) und wundern sich darüber, dass Menschen oder Unternehmen für das Recht, ihre Software zu nutzen, einen Preis verlangen. Ein Grund dafür könnte der Trend sein, dass große Unternehmen wie Google oder Facebook zu einer Menge freier Software beitragen oder diese sogar erstellen, die unter freizügigen Lizenzen wie Apache, MIT oder BSD veröffentlicht wird. Das ist keine Überraschung, denn sie verdienen ihr Geld mit Werbung oder bezahlten Diensten, so dass die Softwareentwicklung an sich gar nicht darauf abzielt, Gewinne zu erwirtschaften, sondern vielmehr geschlossene Ökosysteme zu schaffen, um Entwickler anzuziehen und zu binden.
Doppellizenzierung
Viele OSS-Projekte von großem Wert werden unter der GPLv3 und/oder AGPLv3 veröffentlicht. Die GPL (und ihre Variante AGPL für gehostete Software oder Dienste) sind beides Copyleft-Lizenzen, die keine Rechte verletzen dürfen. Das bedeutet, dass jeder einen beliebigen Teil des OSS-Projekts nehmen und zur Erstellung eigener, neuer Software oder Dienste verwenden und sogar kommerziell nutzen kann. Das Einzige, was die GPL/AGPL-Lizenzen sicherstellen, ist, dass das abgeleitete Werk (die neue Software oder Dienstleistung) unter derselben Lizenz (GPL oder AGPL) veröffentlicht werden muss.
Wenn eine Person oder ein Unternehmen keine eigene Software oder Dienstleistung veröffentlichen möchte, die auf Copyleft-lizenzierten Komponenten basiert oder diese verwendet, kann sie/es eine kommerzielle Lizenz von den Betreuern oder Vertreibern des OSS-Pakets erwerben, das sie/es in ihre/seine eigene Lösung integrieren möchte. Wir bei Structr bieten eine kommerzielle Lizenz an, die jeden zahlenden Kunden von den Einschränkungen der GPL/AGPL befreit.
Kurz gesagt: Bei der Doppellizenzierung haben die Menschen die Wahl, entweder in Form ihres Codes zum Projekt beizutragen oder eine Lizenz zu erwerben. Auf beide Arten helfen sie, ein Projekt zu unterstützen, egal ob es von einer Gemeinschaft von Freiwilligen oder einem Unternehmen getragen wird.
Structr’s Lizenzmodell
Wie Sie vielleicht wissen, wird das Structr-Projekt nicht von einer großen Firma oder VC-Investoren finanziert. Alles, was wir in den letzten Jahren aufgebaut haben, war nur möglich, weil die kleine Firma hinter dem Structr-Projekt, die Structr GmbH, in der Lage war, durch kundenspezifische Entwicklung und Projektarbeit etwas Geld zu verdienen.
Seit der Version 1.0 im Jahr 2015 verlangen wir von kommerziellen Kunden eine Lizenzgebühr, weil wir es für fair halten, etwas für eine Software zurückzubekommen, in die wir viele Tausend Stunden ernsthafter Arbeit investiert haben. Aber um ehrlich zu sein – in den ersten zwei Jahren hat es nicht sehr gut funktioniert.
Ein typisches Muster in den Jahren 2015 und 2016 war, dass Unternehmen und noch mehr Einzelpersonen sehr an unserer Software interessiert waren und häufig um Unterstützung baten (um fair zu sein: Die Dokumentation und die Benutzerfreundlichkeit waren nicht so gut wie heute). Da Structr ein Open-Source-Projekt ist, konnten die Leute die Software herunterladen und kompilieren, und die meisten von ihnen erwarteten, Support, Fehlerbehebungen usw. kostenlos zu erhalten, weil sie das offenbar von Open Source erwarteten.
Die Unterstützung von Leuten, die eine Software bewerten, braucht Zeit, besonders wenn die Software jung ist und sich schnell entwickelt. Und es kann frustrierend sein zu sehen, dass Leute nicht bereit sind, auch nur den kleinsten Geldbetrag im Austausch für viele Stunden des Schreibens von E-Mails, Support-Tickets oder sogar Telefongesprächen mit individueller Hilfe auszugeben, selbst wenn es um völlig unverwandte Themen wie JavaScript-Codierung oder Hilfe bei der richtigen Konfiguration ihres Betriebssystems geht. An dieser Stelle sei angemerkt, dass nicht jeder so gehandelt hat, daher geht ein großes Dankeschön an die kleine, aber sehr hilfsbereite Gruppe von Menschen und Firmen, die uns mit Geld unterstützt und sogar einige Lizenzgebühren bezahlt haben. Ohne Sie wäre das Structr-Projekt nicht möglich, und noch viel mehr würde es keinen Sinn machen.
Lizenzschlüssel als Erfolgsgeheimnis
Im Jahr 2017 wuchs unsere Frustration über die unzähligen Stunden, die wir mit der Unterstützung von Leuten verbrachten, die überhaupt nichts zum Projekt beitrugen. Dann trafen wir eine wichtige Entscheidung und führten Lizenzschlüssel ein, was uns dazu zwang, die Funktionalität in freie (wie in Bier) vs. kostenpflichtige Editionen/Module zu gruppieren. Um es klar zu sagen: Alles im Structr-Projekt ist immer noch Open Source und Freie Software (wie in Sprache), und alles wird auf GitHub veröffentlicht. Aber obwohl es Open Source ist, haben wir in Structr Sicherheitsmechanismen auf zwei verschiedenen Ebenen eingebaut:
Eingeschränkte Kompilierung
Das Kompilieren des veröffentlichten Quellcodes in ein lauffähiges Programm kann nur von uns durchgeführt werden, da die Software mit einem Zertifikat ausgeliefert wird, dessen privater Schlüssel ausschließlich uns gehört. Damit wollen wir sicherstellen, dass unsere Kunden nur offizielle Kopien ausführen, da wir nur für offizielle Versionen unseres Produkts garantieren können (im Sinne der Haftung).
Sie werden sich vielleicht fragen: „Aber es ist Open Source und das Zertifikat auch – wir könnten unser eigenes Zertifikat/unseren eigenen privaten Schlüssel erstellen und es kompilieren“. Ja, das ist Absicht, und deshalb darf sich unsere Software immer noch Open Source und Freie Software nennen, denn Sie können den Quellcode ändern und Ihre eigene Version erstellen und verwenden. Wenn Sie jedoch das Zertifikat ändern, erstellen Sie ein abgeleitetes Werk, das unter derselben Lizenz (in diesem Fall GPL) veröffentlicht werden muss.
Eingeschränkte Laufzeit
Der zweite Baustein unserer Lizenzierungspolitik ist, dass Sie eine Structr-Instanz ohne Lizenzschlüssel auf der Funktionsstufe der Community Edition betreiben können. Um weitergehende Funktionen zu ermöglichen, müssen unsere Anwender einen Lizenzschlüssel für die benötigten Zusatzmodule erwerben.
Der Grund dafür ist, dass wir unseren Support- und Entwicklungsaufwand für die komplexeren Funktionen decken müssen, die einen höheren Wert liefern, ein gewisses Maß an Erklärung erfordern und teurer in der Wartung sind.
Wir denken, dass die Paketoptionen mit einer kostenlosen Community-Version und kostenpflichtigen Zusatzmodulen einen guten Kompromiss darstellen und die Fairness widerspiegeln, die wir von unseren Nutzern erwarten.
Resümee
Seit der Einführung des neuen Lizenzierungssystems haben wir ein starkes Wachstum der Lizenzeinnahmen und der Kundenzahl erlebt. Wir glauben, dass dies auf zwei Effekte zurückzuführen ist:
In erster Linie könnten wir mehr Zeit darauf verwenden, die Software und ihre Dokumentation zu verbessern, damit sich mehr Menschen und Unternehmen für die neueren Versionen interessieren.
Zweitens denken wir, dass die Zielgruppe insofern etwas gefiltert ist, als wir einen höheren Prozentsatz an Anfragen von Personen oder Unternehmen erhalten, die ernsthaft interessiert sind, den Wert unserer Software erkennen und sogar darüber nachdenken können, eine Lizenzgebühr im Austausch für eine gute Software und großartige Dienstleistungen ihrer Schöpfer zu zahlen.
