Eine weitere Softwarelizenz buhlt um die Aufmerksamkeit von SaaS-Unternehmen, die sich dem Open-Source-Bereich anschließen möchten, ohne ihre kommerziellen Bemühungen zu gefährden.
Postenein Unternehmen für App Performance Monitoring (APM), das Unternehmen wie Disney, Microsoft und Cisco dabei hilft, verzögerte oder fehlerhafte Anwendungen zu verfolgen und zu beheben, hat hat sein Kernprodukt umgestellt zu einer neuen, von ihm entwickelten Lizenz namens Functional Source License (FSL). Der Open-Source-Chef des Unternehmens Chad Whitacre sagt, dass die Lizenz für jedes SaaS-Unternehmen gilt, das „Freiheit ohne schädliches Trittbrettfahren gewähren möchte“.
„Es gibt eine lange Geschichte von Unternehmen mit größeren finanziellen Mitteln und mehr Ressourcen, die von traditionellen Open-Source-Unternehmen profitieren“, sagte Whitacre per E-Mail gegenüber TechCrunch. „Open-Source-Unternehmen sind unabhängig von ihrer Lizenz oder der pedantischen Definition zunehmend darauf angewiesen, durch Risikokapital finanziert zu werden, gewinnorientiert zu sein oder, was noch wichtiger ist, von den Unternehmen unterstützt zu werden, die auf ihren Code angewiesen sind.“
Schalten
Die jüngste Geschichte ist übersät mit Beispielen von Unternehmen, die aus Open-Source-Projekten entstanden sind, diese Wurzeln aber später aufgegeben haben, um ihre kommerziellen Interessen zu schützen. Im Jahr 2021 Elastisch geschaltet Elasticsearch wurde von einer Apache 2.0-Lizenz auf ein Duo von quellverfügbaren Lizenzen umgestellt. Dieser Schritt soll verhindern, dass Dritte wie AWS im Wesentlichen ihre eigene Version von Elasticsearch „as-a-Service“ verkaufen, ohne viel zum ursprünglichen Projekt beizutragen. In jüngerer Zeit hat HashiCorp etwas Ähnliches mit Terraform gemacht, während Unternehmen wie Element (mit Matrix) und Grafana etwas Ähnliches gemacht haben übergegangen Von freizügigen Open-Source-Lizenzen bis hin zu sogenannten „Copyleft“-Lizenzen, die Benutzer im Wesentlichen dazu zwingen, abgeleitete Projekte als Open Source zu belassen oder für eine Lizenz zur Nutzung des Produkts zu zahlen.
Was Sentry betrifft, so begann das in San Francisco ansässige Unternehmen vor mehr als einem Jahrzehnt unter einer Freizügigkeit BSD-3-Klausel-Lizenz, eines, das mit wenigen Einschränkungen verbunden ist. Ähnlich wie die anderen oben genannten Unternehmen hat Sentry sein Kernprodukt neu lizenziert zurück im Jahr 2019 um dem entgegenzuwirken, was Mitbegründer und CTO David Cramer als „finanzierte Unternehmen, die unsere Arbeit plagiieren oder kopieren, um direkt mit Sentry zu konkurrieren“ bezeichnete.
„Dazu gehörte, Marketinginhalte von unserer Website zu übernehmen, unsere Dokumentation zu plagiieren und als eigene zu gestalten oder unsere Produktvisualisierungen direkt zu kopieren/einzufügen“, schrieb Cramer damals. „Ihre Verteidigung? „Nun, es ist kostenloses Open-Source, und das können wir tun.“ Diese Unternehmen nutzen Sentry nicht, um ihre Softwareentwicklung zu verbessern; Sie erweitern ihren Code und ihre Ressourcen, um ihre Closed-Source-Produkte zu entwickeln und direkt mit uns zu konkurrieren.“
Daher ist Sentry auf die Business Source License (BSL) umgestiegen, eine quellenverfügbare Lizenz, die eine unbegrenzte Nutzung in den meisten nichtkommerziellen Szenarien ermöglicht. Insbesondere sind BSL-lizenzierte Produkte zeitlich begrenzt und werden nach vier Jahren automatisch auf eine Open-Source-Apache-Lizenz zurückgesetzt – dies soll kommerzielle Konkurrenten davon abhalten, kurzfristig von einem Projekt zu profitieren. Allerdings argumentiert Whitacre, dass vier Jahre einfach zu lang seien und nicht mit dem Geist von Open Source vereinbar seien.
„Das standardmäßige Wettbewerbsverbot beträgt vier Jahre, was in der Softwarewelt eine wirklich lange Zeit ist“, schrieb Whitacre in einem Blogbeitrag am Freitag. „Das kann den Eindruck erwecken, dass der eventuelle Wechsel zu Open Source nur eine symbolische Anstrengung ist. Es könnten fast genauso gut 100 Jahre sein.“
Während Sentry seine BSL-Lizenz tatsächlich auf drei Jahre verkürzt hatte, sagte Whitacre, dass sie immer noch zu lang sei. Darüber hinaus weist die BSL-Lizenz weitere Mängel auf, wie zum Beispiel „Zusatznutzungszuschuss”-Mechanismus, der es Projektbesitzern ermöglicht, bestimmte Umstände zu definieren, unter denen ihr Code kommerziell genutzt werden kann.
„Der zusätzliche Nutzungszuschuss ist das größte Problem“, schreibt Whitacre. „Es ist ein riesiger Lückentext, der im Grunde bedeutet, dass jede BSL eine andere Lizenz ist.“
Aufgrund dieser Variabilität ist es oft schwierig, Produkte mit einer BSL-Lizenz von den Compliance-Abteilungen der Unternehmen zu genehmigen, da diese jede Lizenz einzeln prüfen müssen.
„Außerdem wird es für Unternehmen schwierig, BSL für ihre eigenen Produkte einzuführen, da sie Entscheidungen treffen und eine benutzerdefinierte Sprache dafür schreiben müssen“, fuhr Whitacre fort. „Wir wollen die Werte, die uns zu BSL geführt haben, weithin bekannt machen und zu diesem Zweck wollen wir mit FSL die Spannungen beseitigen.“
Sentry nennt FSL eine „Weiterentwicklung von BSL“, die Benutzerfreiheit und Entwicklernachhaltigkeit in Einklang bringt. Es gibt keine zusätzliche Nutzungsgenehmigung und die Frist wurde auf zwei Jahre verkürzt. Danach werden zugehörige Produkte automatisch auf eine Apache 2.0- oder MIT-Lizenz umgestellt.
„Für Unternehmen, die FSL nutzen, bieten zwei Jahre Schutz vor Konkurrenz, dienen aber auch als Anreiz für weitere Innovationen“, schrieb Whitacre. „Für die Nutzergemeinschaft bieten zwei Jahre einen sinnvollen Schutz für den Fall, dass das Fahrunternehmen den Ball fallen lässt.“
Jedoch, Thierry CarrezGeschäftsführer der Open Infrastructure Foundation und stellvertretender Vorsitzender der Open Source Initiative (OSI), die das verwaltet Definition von Open-Source-Software, sagte, dass Sentry nur das jüngste in einer Reihe von Unternehmen sei, die ihren Ruf auf der Grundlage von Open-Source aufgebaut hätten und dann „das Modell aufgegeben hätten, das sie überhaupt erst erfolgreich gemacht habe“.
„Die Veröffentlichung einer weiteren Lizenzvariante, die den Entwicklern die Selbsthoheit bei ihren technischen Entscheidungen entzieht, ist nichts Neues – es geht immer noch darum, wesentliche Freiheiten aus dem gesamten Software-Ökosystem zu entfernen, um das Eigentum an ihrer proprietären Software und der Nutzung, die sie dürfen, klar durchzusetzen.“ es“, sagte Carrez. „Das ist kein Open Source: Es handelt sich um proprietäres Gatekeeping, verpackt in offen gewaschener Kleidung.“