Bear wechselt jetzt zu einer Source-Available-Lizenz
(herman.bearblog.dev)- Das Bear-Projekt ist von der MIT-Lizenz zur Elastic License gewechselt
- Die bisherige MIT-Lizenz erlaubte die freie Nutzung des Codes und Forks, die neue Lizenz beschränkt dies jedoch bei der Bereitstellung als Hosting-Service
- Auch mehrere Open-Source-Projekte führen zunehmend ähnliche Lizenzänderungen ein, um unentgeltliche Konkurrenz zu verhindern
- Im Zeitalter der künstlichen Intelligenz ist es sehr einfach geworden, Code zu kopieren und als Service anzubieten
- Die Offenheit des Codes ist wichtig, aber entscheidend für Bear sind die Nutzer-Community und der Wille zum langfristigen Betrieb
Hintergrund des Wechsels zur Source-Available-Lizenz bei Bear
- Das Bear-Projekt veröffentlichte seinen Quellcode anfangs unter der MIT-Lizenz mit dem Ziel, Lernen und Prüfbarkeit zu ermöglichen und den Nutzern Vertrauen in Privatsphäre und Sicherheit zu geben
- Mit der Zeit gab es jedoch Fälle, in denen konkurrierende Dienste auf Basis des Bear-Projektcodes entstanden
- Obwohl die Software mit viel Herzblut entwickelt wurde, führte das Gefühl, dass der Quellcode leicht kopiert und dann zur Konkurrenz wird, zu Frustration und wirtschaftlichen Sorgen
- Man glaubte an die Werte von Open Source, befand sich in der Praxis jedoch in einer schwierigen Lage
Entscheidung zur Lizenzänderung
- Ausgelöst durch jüngste Ereignisse fiel die Entscheidung, die Lizenz von der MIT-Lizenz zur Elastic License zu ändern, einer von Elastic Search eingeführten Copyleft-ähnlichen Lizenzform
- Die Elastic License ähnelt der MIT-Lizenz, untersagt jedoch, die Software als gehosteten oder gemanagten Service bereitzustellen
- Die genauen Lizenzbedingungen finden sich im GitHub-Link
Entwicklungen im Open-Source-Ökosystem
- Recherchen zeigen, dass zahlreiche Open-Source-Projekte in den letzten Jahren ihre Lizenzen eingeschränkt haben, um „Trittbrettfahrer-Konkurrenz“ zu verhindern
- Beispiele: Plausible, Fathom, Grafana, Snowplow, ScyllaDB, Sentry und weitere Projekte haben ähnliche Entscheidungen getroffen
Das KI-Zeitalter und verschärfter Wettbewerb
- Durch das Aufkommen von AI-Coding-Tools sind schnelle Replikation und Service-Angebote möglich geworden, etwa mit Anweisungen wie: „Forke dieses Repository, ändere den Namen und deploye es auf EC2“
- Diese veränderten Rahmenbedingungen bedeuten für die ursprünglichen Autoren eine deutlich größere Belastung und mehr Risiko
Der besondere Wert von Bear
- Der eigentliche Wert der Bear-Plattform liegt nicht nur im Quellcode selbst, sondern in der Community, die sie nutzt, und in der langfristigen Verantwortung des Betreibers
- Auch wenn es künftig einige Einschränkungen auf Code-Ebene geben wird, wurde der Wille bekräftigt, die Plattform selbst weiterhin gewissenhaft zu pflegen und zu betreiben
3 Kommentare
GLPv3 und AGPL scheinen nicht so verwendet zu werden, wie es von den Urhebern dieser Lizenzen beabsichtigt war.
Dadurch, dass in den meisten Fällen Dual Licensing erlaubt wird, habe ich viel zu oft gesehen, dass sie am Ende als Mittel eingesetzt werden, um kommerzielle Nutzung zu erzwingen.
In diesem Sinne sind Apache oder MIT meiner Meinung nach einige der wenigen Open-Source-Lizenzen, die noch so funktionieren, wie ursprünglich beabsichtigt.
(Allerdings glaube ich nicht, dass es eine vollkommen perfekte Open-Source-Lizenz gibt.)
Hacker-News-Kommentare
So wie ich das verstehe, vertritt das „Open-Source“-Lager die Position, dass etwas kein echter Open Source ist, wenn Amazon es nicht als AWS-Service anbieten kann, und reagiert ziemlich verärgert, wenn jemand etwas anderes behauptet.
Ich wünschte, mehr Leute würden das vom Autor angesprochene Phänomen des „Trittbrettfahrer-Wettbewerbs“ anerkennen. Was Herman macht, kommt allen zugute, deshalb wäre ein neuer Begriff schön, der wärmer klingt als „source-available“ und Community-Projekte besser erfasst.
Ich ergänze noch, weil ein Kommentar unten meine Sicht gut zusammenfasst:
Die natürliche Tendenz des Marktes zu Monopolen hilft der Mission freier Open-Source-Software (FOSS) nicht. Wenn man große Unternehmen nicht daran hindert, auf diese Weise Gewinne abzuschöpfen, untergräbt das im Gegenteil die Mission von Open Source massiv. Und dabei geraten Nutzer in eine Falle, die proprietäre Software von Großkonzernen mit FOSS kombiniert
Die ursprüngliche Haltung des Open-Source-Lagers zeigte sich in Lizenzen wie GPL → GPLv3 → AGPL; man unterstützte also Ansätze, die dieses Problem klar verhindern
Dass all die sehr freizügigen Lizenzen wie MIT/BSD/Apache so weit verbreitet wurden, wirkt wie eine gezielte Entwicklung im Interesse von Unternehmen, um die Ideale freier Software zu verwässern
Die meisten Menschen haben auch mit nicht-offener Software kein großes Problem
Das Problem ist, dass Projekte wie Terraform beliebt wurden und gewachsen sind, weil sie Open Source waren, und dann in eine Situation gerieten, in der der Maintainer auf eine geschlossene Lizenz umstellt und damit die Grundlage des ursprünglichen Erfolgs verschwindet
Wenn dazu noch Mitwirkende eine CLA (Contributor License Agreement) unterschrieben haben und ihr Code dann ebenfalls nach Belieben unter eine geschlossene Lizenz gestellt werden kann, ist das doppelt enttäuschend
Wenn einem Open Source egal ist, muss man es ja nicht nutzen; bisher hatte Open Source eine klare und konsistente Bedeutung
Jeder kann Software frei entwickeln, und man kann je nach den eigenen Werten auswählen, was man nutzt; daran ist nicht zwingend etwas problematisch
Jeder kann jede gewünschte Lizenz verwenden, aber man sollte darüber nachdenken, warum die meisten Open-Source-Entwickler freizügige Lizenzen wie MIT wählen
In der Praxis gibt es viel gute Open-Source-Software, also eine breite Auswahl; wenn man Einschränkungen in die Lizenz aufnimmt, wählen die Leute einfach Alternativen
Deshalb haben es Projekte mit GPL-artigen Lizenzen schwerer, breite Nutzung zu erreichen. Natürlich gibt es Ausnahmen wie Linux oder WordPress, die sehr erfolgreich wurden, aber das ist nicht gerade der Normalfall
Selbst mit freizügigen Lizenzen wie MIT ist Monetarisierung schwierig, aber wenn einem schon die Nutzer fehlen, ist es noch schwerer
Ob das gut oder schlecht ist, darüber kann man streiten, aber tatsächlich handeln alle offenbar rational. Im Kern ist Software eben nicht so knapp
Wurde die AGPL nicht genau für solche Fälle geschaffen?
Die AGPL ist eine von der OSI anerkannte Open-Source-Lizenz, die Beschränkungen vorsieht, wenn Software als Netzwerkdienst angeboten wird
Ich frage mich, ob sich der Maintainer Fair Source angesehen hat: fair.io
Ich halte Fair Source für besser als „source-available“, auch weil es unter DOSP (opensource.org/dosp) einen Weg zu vollständigem Open Source bietet und damit sowohl kostenlosen als auch zahlenden Nutzern nützt; gerade für eine Blog-Plattform wie Bear ist das ein ideales Modell
Die FCL (fcl.dev) Fair Source License entspricht auch in ihrer Grundhaltung der Bear Blog License und passt gut zum Bear-Manifesto (herman.bearblog.dev/manifesto/)
Selbst wenn Bear PTY LTD verschwinden sollte, könnte Bear selbst in dieser Struktur weiterbestehen (das lässt sich über DOSP definieren)
Ich war selbst an der Ausarbeitung von Fair Source beteiligt
Trotzdem klingt der Begriff „fair source“ ziemlich gut
Kann man Software, die wie bei Apache oder MIT nach einiger Zeit Open Source wird, einfach als fair source einordnen, oder sind die Kriterien komplizierter?
Manche waren wohl etwas naiv. Wenn man die MIT-Lizenz wählt, darf jeder den eigenen Code frei verwenden, wie er möchte. Und wenn man später Geld verdienen will, wechselt man zur Lösung auf eine sonderbare Lizenz
Am Ende sind die Optionen MIT/BSD, GPL, LGPL, AGPL, und alle anderen Lizenzen schaffen nur unnötige Kompatibilitätsprobleme
Dem stimme ich zu. Wenn man wirklich eine Veröffentlichung des Quellcodes „ohne Bedingungen“ will, nimmt man MIT
In diesem Fall wirkt es eher so, als wäre das nicht wirklich die klare Überzeugung gewesen, sondern ein etwas vager Versuch, zugleich „der Gute“ und „der Geschäftsmann“ sein zu wollen
Ich halte auch die MPL (Mozilla Public License) für eine ziemlich nützliche und unterschätzte Lizenz
Sie ist deutlich weniger ansteckend als die GPL-Familie und zugleich restriktiver als MIT/BSD (Änderungen müssen bei der Verbreitung als Quellcode offengelegt werden)
MIT und BSD enthalten keine Patentzusage, was ein gutes Argument für die Apache License ist
Guy (der Ersteller) wollte wohl einfach sein Projekt bauen und fand es wichtig, den Quellcode zu veröffentlichen
Ich glaube nicht, dass dahinter ein besonderer strategischer Zweck stand
Nutzer, die glauben, ein Open-Source-Projekt werde für immer Open Source bleiben, sind ebenfalls naiv
Autoren haben das Recht, die Lizenz zu ändern, und sowohl darüber überrascht zu sein als auch zu glauben, Open Source lasse sich leicht kommerzialisieren, ist letztlich naiv
Wenn man konkurrierende Nutzung grundsätzlich verhindern will, macht man es normalerweise genau so. Und es ist auch richtig, den Begriff Open Source dann nicht mehr zu verwenden
Ich denke aber, dass in den meisten Fällen die AGPL die bessere Alternative ist. Mit AGPL können große Unternehmen den Code wegen interner Richtlinien nicht verwenden, was einen gewissen Schutz vor großen Anbietern bietet
Das verrät den eigentlichen Sinn von Open Source
„Ich habe unter MIT veröffentlicht, und jetzt verdient jemand Geld damit, meinen Code geschäftlich zu nutzen. Erstaunlich, dass ich dieses Ergebnis nicht vorhergesehen habe.“
Warum passiert das immer wieder? Ich frage mich, warum so viele Entwickler diese naheliegende Folge nicht sehen
MIT war lange die niedrigschwellige Standardwahl auf GitHub: neues Projekt anlegen, Dropdown auswählen, fertig
Wenn ein Projekt neu ist und man nicht weiß, wie es sich entwickelt, ist es schwer, sich vorzustellen, dass es einmal so groß wird, dass man sich später um die Lizenz Sorgen machen muss
Die MIT-Lizenz erlaubt von Anfang an, ein Projekt später neu zu lizenzieren
Der Bear-Maintainer hat zunächst eine freizügige Lizenz gewählt und dann, als sich die Lage änderte, zu einer strengeren gewechselt
Für mich ist das eine völlig vernünftige Entscheidung
Ich denke, das liegt daran, dass das BSD-Lager den kulturellen Krieg um Open Source vor 15–20 Jahren gewonnen hat
Ich frage mich, wie anders das Ökosystem heute aussähe, wenn stattdessen das GNU-Lizenzlager gewonnen hätte
Ich habe Bear unterstützt, weil es Open Source war; wenn das nicht mehr so ist, habe ich keinen Grund mehr, es weiter zu unterstützen, und habe mein Abo gekündigt
Ich würde es sehr begrüßen, wenn es zur AGPL zurückkehren würde
Bear hat die Freiheit, die gewünschte Lizenz zu wählen, und ich kann entscheiden, ob ich es nutze oder nicht
Der Zweck einer Open-Source-Lizenz ist grundsätzlich eher das Teilen als finanzieller Gewinn
Dass man nur Open-Source-Projekte unterstützen möchte, ist völlig nachvollziehbar
Wenn der Zeitpunkt kommt, an dem Einnahmen erzielt werden müssen, ist eine Open-Source-Lizenz möglicherweise nicht mehr passend
Manche Entwickler irren sich, wenn sie glauben, Open Source werde ihr Einkommen schützen, und manche Nutzer glauben fälschlich, ein Projekt werde für immer Open Source bleiben
Modelle wie source-available oder shipped-with-source sind ebenfalls eine Form proprietärer Lizenzierung; sie müssen nicht zwingend Open Source sein
„Nutzer dürfen die primären Funktionen der Software nicht als gehosteten oder Managed Service anbieten“
Ich bin kein Anwalt, aber ich frage mich, ob diese Einschränkung auch verbietet, Bear selbst zu installieren und intern im Unternehmen oder privat zu betreiben
Wenn das tatsächlich nicht erlaubt wäre, verstehe ich ehrlich gesagt nicht, warum man überhaupt die MIT-Lizenz gewählt hatte
Originaltext der Bear Blog License
Sie dürfen es aber nicht als Dienst für andere Personen oder Unternehmen anbieten
Siehe dazu: Elastic License FAQ
Ich kann die Enttäuschung nachvollziehen, aber die neue Lizenz ist etwas vage
Wenn dort steht „keine Bereitstellung der Funktionen über Hosting-/Managed Services“, sind dann auch gewöhnliche VPS-Anbieter betroffen, bei denen man es per Paketmanager installiert?
Was ist mit Setup-Skripten für 1-Click-Installationen, ist das in Ordnung, solange man im Serviceprozess nicht ausdrücklich darauf hinweist? Das wirkt auf mich wie ein „Theater“, bei dem es reicht, wenn ein Dritter das Installationsskript bereitstellt und man es im eigentlichen Service nur nicht erwähnt
Das heißt: Man darf die Software nicht anderen als Dienst (kostenlos oder bezahlt) zur Verfügung stellen; nur für sich selbst ist es in Ordnung
Im Kern muss man das so verstehen, dass die Vergabe von Konten selbst untersagt ist
Turnkey-Hosting ist zwar ebenfalls ausgeschlossen, aber problematisch ist dabei nicht der Hoster selbst, sondern derjenige, der auf dieser Hosting-Instanz Nutzerkonten erstellt und verkauft
Diese Formulierung soll große Unternehmen wie Amazon daran hindern, Datenbankinstanzen extern anzubieten und dort einfach nur Konten auszugeben
Dagegen ist es in Ordnung, es auf einer VM einfach per Paketmanager zu installieren
Trotzdem sind Lizenzen dieser Art sehr verwirrend und unklar
Wenn man es ohnehin Open Source belassen will und viele Leute es nutzen sollen, aber gleichzeitig nicht möchte, dass andere es hosten, muss man den Code gar nicht erst teilen; man könnte es einfach bei „All rights reserved“ belassen
Ich verstehe die Motivation und die Absicht, den Quellcode zugänglich zu machen, aber wenn die Sorge Konkurrenz war, hätte man statt MIT wohl AGPL in Betracht ziehen können
Kann die AGPL nicht trotzdem dazu führen, dass andere den Code unverändert kommerziell weiterverkaufen?
Die AGPL erzwingt doch nur die Offenlegung des Quellcodes von Änderungen
Hier scheint eher das Problem zu sein, dass jemand Bearblog fast unverändert oder nur leicht umbenannt kommerziell anbietet
Vermutlich hielt man Konkurrenz anfangs nicht für ein Problem, und erst mit der Zeit wurde es eines, woraufhin die Lizenz geändert wurde
Ich persönlich halte dieses Modell (Quellcode offen + Hosting-Einschränkung usw.) für das beste Lizenzmodell
Ich kann den Code nach meinem Geschmack prüfen und anpassen, während Projekt und Maintainer ihre Basis schützen können, ohne übermäßigen Konkurrenzdruck
Wenn man von Anfang an so startet, verhindert man auch, dass es später plötzlich einen Wechsel gibt, der Streit auslöst, oder dass ein Fork das Original überholt
Ich glaube zwar nicht, dass Bear ein Projekt mit so großer Strahlkraft war
Aber ich nutze mataroa.blog auch gelegentlich gern, und ich hoffe, dass der Bear-Maintainer in seinem Projekt Erfüllung findet
Tatsächlich sind das Interesse und die Beiträge der Nutzer bei Open-Source-Projekten fast die einzigen Ressourcen.
Wenn ein Projekt sich nicht vollständig etabliert hat und irgendjemand, insbesondere ein Großunternehmen, es forkt und die gesamte Aufmerksamkeit auf sich zieht, hat man am Ende nur Arbeit für andere geleistet.
Diese Lizenzen waren von Anfang an ohnehin für die Freiheit der Nutzer gedacht, nicht für die Entwickler.
Wussten Sie, dass auch
winget, der CLI-Paketmanager von Windows, dadurch entstanden ist, dass Microsoft das Projekt eines anderen praktisch unverändert geforkt und nur unter einem anderen Namen veröffentlicht hat?Es gibt auch einen Beitrag des Autors des ursprünglichen Projekts
appget.The Day AppGet Died.
Wenn Sie nicht nur Arbeit für andere leisten wollen (insbesondere zugunsten von Großunternehmen oder Menschen, die sehr gut in viralem Marketing sind) und Ihrer eigenen Zeit einen Wert beimessen, sollten Sie die Wahl einer Open-Source-Lizenz noch einmal überdenken.
Selbst wenn beides ehrenamtlich ist, besteht ein großer Unterschied zwischen Respekt für den eigenen Beitrag und völliger Missachtung.
Schauen Sie sich Alternativen wie die in den Hacker-News-Kommentaren genannten an.