HashiCorp übernimmt die Business Source License

 (hashicorp.com)
1 Punkte von GN⁺ 2023-08-11 | 1 Kommentare | Auf WhatsApp teilen
  • HashiCorp stellt die Quellcode-Lizenz künftiger Produkt-Releases von MPL 2.0 auf Business Source License v1.1 um und will damit weiterhin in Community und Produkte investieren
  • Das bisherige Open-Source-Modell habe zwar ein großes Ökosystem geschaffen, zugleich habe aber das Problem zugenommen, dass einige Anbieter Community-Arbeit kommerziell nutzen, ohne nennenswert selbst beizutragen
  • BSL 1.1 ist eine Source-available-Lizenz, die Kopieren, Ändern, Weiterverbreiten, nichtkommerzielle Nutzung und kommerzielle Nutzung unter Bedingungen erlaubt; APIs, SDKs und die meisten Bibliotheken bleiben unter MPL 2.0
  • Endnutzer, Partner sowie Kunden von Enterprise- und Cloud-Managed-Produkten können ihre bisherige Nutzung größtenteils fortsetzen, ausgenommen ist jedoch das Anbieten von Produkten, die mit HashiCorp konkurrieren
  • Für Anbieter, die auf HashiCorp-Community-Produkten konkurrierende Services anbieten, wird es künftig schwieriger, neue Releases, Bugfixes und Sicherheits-Patches zu übernehmen

Umfang der Lizenzänderung

  • Die Quellcode-Lizenz aller künftigen HashiCorp-Produkt-Releases wird von Mozilla Public License v2.0 (MPL 2.0) auf Business Source License (BSL oder BUSL) v1.1 umgestellt
  • HashiCorp-APIs, SDKs und fast alle weiteren Bibliotheken bleiben unter MPL 2.0
  • Produktquellcode und Updates werden weiterhin in den GitHub-Repositories und Distributionskanälen von HashiCorp veröffentlicht
  • HashiCorp will den Quellcode weiterhin breit zugänglich machen und kostenlose Nutzung ermöglichen, dabei aber die Auswirkungen auf Community, Partner und Kunden minimieren

Open-Source-Modell und Kommerzialisierungsdruck

  • HashiCorp nannte bei der Gründung drei Gründe dafür, die Produkte als Open Source zu veröffentlichen
    • Praktiker sollten den Quellcode frei herunterladen und prüfen sowie Probleme selbst beheben können
    • Rund um die Produkte sollte ein Ökosystem und eine Community entstehen, um breite Integrationen zu ermöglichen
    • Transparenz ist für Nutzer wichtig
  • Über mehr als zehn Jahre wurden neue Produkte und Funktionen unter einer freien Open-Source-Lizenz bereitgestellt; daraus entstand eine große Community aus Nutzern, Beitragenden, Partnern und Kunden
  • Jedes Jahr investiert das Unternehmen zig Millionen Dollar in Forschung und Entwicklung für Open-Source-Produkte; möglich wird dieses Modell durch kommerzielle Kunden, die mit HashiCorp bei mission-kritischer Infrastruktur zusammenarbeiten
  • Das Unternehmen arbeitete eng mit Cloud-Anbietern zusammen, um Integrationen für gemeinsame Nutzer und Kunden bereitzustellen, und kooperierte zudem mit Hunderten Technologiepartnern

Anwendung von BSL 1.1

  • BSL 1.1 ist eine Source-available-Lizenz, die Kopieren, Ändern, Weiterverbreiten, nichtkommerzielle Nutzung und kommerzielle Nutzung unter bestimmten Bedingungen erlaubt
  • In den letzten Jahren haben auch Couchbase, Cockroach Labs, Sentry und MariaDB einen ähnlichen Weg eingeschlagen; MariaDB entwickelte diese Lizenz im Jahr 2013
  • Auch Confluent, MongoDB, Elastic und Redis Labs werden als Beispiele für alternative Lizenzen mit Beschränkungen der kommerziellen Nutzung genannt
  • HashiCorps Einsatz der BSL enthält zusätzliche Nutzungserlaubnisse, die eine breite, permissive Nutzung des Quellcodes ermöglichen sollen
  • Bei der Ausarbeitung der Lizenz holte das Unternehmen Beratung von OSS-Lizenzexperten und Branchenvertretern ein, um sie an gängige Branchenpraktiken anzupassen

Auswirkungen auf Nutzer, Partner und Kunden

  • Endnutzer können den Code weiterhin für alle nichtkommerziellen und kommerziellen Zwecke kopieren, ändern und weiterverbreiten, solange sie kein Produkt anbieten, das mit HashiCorp konkurriert
  • Partner können weiterhin Integrationen für gemeinsame Kunden entwickeln
  • Mit Cloud-Service-Providern will HashiCorp weiterhin eng zusammenarbeiten, um eine tiefe Unterstützung der jeweiligen Technologien aufrechtzuerhalten
  • Für Kunden von Enterprise- und Cloud-Managed-HashiCorp-Produkten ändert sich nichts
  • Anbieter, die auf Basis der Community-Produkte Services anbieten, die mit HashiCorp konkurrieren, können künftige Releases, Bugfixes und Sicherheits-Patches nicht mehr in HashiCorp-Produkte integrieren

Weitere Hinweise

  • HashiCorp erklärt, dass sich an den Zusagen gegenüber Community, Partnern und Kunden nichts geändert habe
  • Für weitere Fragen gibt es häufig gestellte Fragen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-08-11
Meinungen auf Hacker News

  • Die einzige Schlussfolgerung daraus ist, dass HashiCorp kein Open-Source-Unternehmen mehr ist.
    Dass es „Anbieter gibt, die das reine OSS-Modell und Community-Arbeit für kommerzielle Ziele nutzen, ohne substanzielle Beiträge zurückzugeben“, entspricht zu 100 % dem Geist von Open Source.
    Wenn das ein Problem ist, sollte man eine Open-Source-Lizenz wie die AGPL wählen, die Entwickler dazu zwingt, ihren Code offenzulegen.
    Das ist lediglich ein Weg, mit dem HashiCorp frühere Open-Source-Projekte allein kommerzialisieren will. An sich ist das in Ordnung, aber dann sollte man einfach Closed Source machen und dazu stehen, statt beides haben zu wollen.

    • Ich bin Gründer/CEO von Pulumi.
      Der Blogbeitrag ist nicht ehrlich. Wir haben mehrfach versucht, Upstream-Fixes zu Terraform-Providern beizutragen, aber HashiCorp hat sie nie akzeptiert, sodass wir einen Fork pflegen mussten.
      HashiCorp hat seine OSS-DNA schon vor langer Zeit verloren, und dieser Schritt ist der letzte Nagel im Sarg.
      Zum Glück hat HashiCorp im Lauf der Zeit die Verantwortung für die meisten Terraform-Provider an Partner abgegeben; ich hoffe daher, dass das Provider-Ökosystem weiter lebendig und offen bleiben kann.
      Ich glaube zutiefst an Open Source. Mein letztes Projekt bei Microsoft war ebenfalls, .NET Open Source und plattformübergreifend zu machen; unser CTO war an der Entstehung von TypeScript beteiligt, und Pulumi ist ebenfalls ein Apache-Open-Source-Projekt. HashiCorp scheint das nicht mehr zu sein.
    • Ideale sind großartig, bis Menschen ihren Lebensunterhalt verdienen müssen. Deshalb braucht es Umsatz.
      Im Großen und Ganzen haben sich die Zeiten geändert, und meiner Ansicht nach sollte Source-Veröffentlichung keine Frage von „Wenn nicht alles kostenlos ist, ist es nicht echt“ sein, sondern eine gegenseitig vorteilhafte Beziehung zwischen denen, die etwas bauen, und denen, die es nutzen.
      Nutzer sollten das, was läuft, anhand des Quellcodes verstehen und erweitern können, und Projektmanager, Maintainer und Eigentümer sollten in der Lage sein, diese Arbeit fortzuführen.
      Das ist kein Gleichgewichtspunkt, den man erreichen muss, sondern ein Gleichgewicht, das unter Spannung gehalten werden muss.
    • Praktisch gesehen ist BSL besser als vollständig Closed Source, und wenn Übergangszeitraum und Lizenz vernünftig sind, würde ich eher ein BSL-Produkt nutzen als ein zu 100 % geschlossenes Produkt.
    • Nach Erfahrungen bei mehreren früheren Arbeitgebern scheinen Softwareunternehmen etwa 1,5 Jahre nach dem Börsengang merklich bergab zu gehen.
      Ich habe in Wikipedia nachgesehen: HashiCorp soll die IPO-Bedingungen am 29. November 2021 festgelegt haben.
      Diese Hypothese wirkt für mich immer plausibler. Anekdotische Gegenbeispiele oder bestätigende Beispiele sind willkommen.
    • Das Gegenteil von Open Source ist nicht Closed Source, sondern eine restriktive Lizenz.
      Nur weil etwas nicht Open Source ist, heißt das nicht, dass man den Quellcode nicht sehen dürfen sollte, und auch nicht, dass alle Eigenschaften einer OSI-zugelassenen Lizenz entfernt werden müssten.
      Natürlich wäre es besser gewesen, wenn es freie Software wäre, aber das ist gleichbedeutend mit der Aussage, dass es besser wäre, wenn alle Software freie Software wäre.
      Das Problem entsteht, wenn man eine Lizenz, die keine OSI-Zulassung erhalten kann, als Open Source ausgibt. HashiCorp behauptet weiterhin nicht, es sei Open Source, sondern nennt es jetzt „source-available“.

  • Ziemlich enttäuschend. Persönlich habe ich außer Vault nicht viel genutzt; Terraform habe ich ausprobiert, aber weder gern verwendet noch etwas darauf aufgebaut. Das hier ist jedoch das genaue Gegenteil dessen, was ich an HashiCorp-Produkten am meisten geschätzt habe.
    Ich habe sogar zu Zertifikatsmanagement beigetragen, einem der Teile von Vault, die ich am häufigsten nutze. Jetzt muss ich neu überlegen, ob ich Kunden diesen Service künftig noch empfehlen kann und ob ich erneut beitragen werde.
    In einer Zeit, in der VC-Geld austrocknet, fühlt es sich so an, als werde die schlimmste Zukunft von Lizenzen sichtbar, die nicht zur GPL-Familie gehören.
    Das ist bedauerlich für Menschen, die OSS und seinen Betrieb bewusst gelernt haben, mit dem Traum, dieses Wissen eines Tages zu nutzen, um einen Service aufzubauen, ihr eigener Chef zu werden und weiterhin an das OSS zurückzugeben, das sie bis hierher gebracht hat.

    • Ich habe auch deine anderen Kommentare zu diesem Thema gelesen, und es tut mir leid, dass du so etwas erleben musst.
      Ich habe viel Erfahrung damit, Enterprise Vault für das Management von Applikations-Secrets in der gesamten Unternehmensinfrastruktur zu implementieren und zu betreiben.
      In den Jahren, in denen wir Vault eingeführt und Verträge verhandelt haben, habe ich erlebt, wie Sales Engineers unzutreffende oder irreführende Aussagen darüber machten, welche Funktionen für unsere Use Cases „notwendig“ seien, und langfristige Feature-Versprechen gaben, die sie nicht einhalten konnten.
      Sie empfahlen auch Integrationswege, bei denen eine Migration weg von Vault praktisch unmöglich oder riskant sein konnte, und entzogen uns immer wieder Funktionen, von denen wir dachten, sie würden für immer kostenlos bleiben. Okta/MFA-Login war das größte Beispiel; ernsthafte Compliance ist ohne das schwer zu bestehen, und HashiCorp scheint erkannt zu haben, dass Teams, die stark von Vault abhängen, letztlich dafür zahlen müssen.
      Insgesamt wirkte es stark nach Vendor Lock-in, und jedes Jahr zahlten wir mehr für dieselben oder weniger Funktionen. Auch die Preispolitik, die nicht einmal die Engineers erklären konnten, änderte sich weiterhin willkürlich.
      Vault selbst halte ich für hervorragende Software, aber weil ich das Vertrauen in HashiCorp verloren habe, würde ich persönlich bei wichtigen Dingen wohl nicht darauf setzen.
    • Dem Beitrag zufolge „können Endnutzer den Code weiterhin für nichtkommerzielle und kommerzielle Zwecke kopieren, ändern und weiterverbreiten, außer wenn sie ein Konkurrenzprodukt zu HashiCorp anbieten“.
      Wörtlich genommen hat sich nichts geändert; das ist nicht enttäuschend, sondern eine kluge Entscheidung. HashiCorp schützt sich damit vor Cloud-Anbietern, die den Goodwill der Open-Source-Community wiederholt missbraucht haben.
    • Der große Unterschied ist, wo das Copyright am Code liegt.
      OSS-Projekten, die von Beitragenden eine Übertragung des Copyrights verlangen, sollte man nicht vertrauen, und sie sollten von Anfang an keine Beiträge aus gutem Willen annehmen.
      Andernfalls kann etwas heute Apache 2.0 sein und morgen ohne Zustimmung irgendeiner anderen Person kommerziell umgestellt werden, weil der Maintainer 100 % des Codes besitzt.
      Bei OSS-Projekten, hinter denen ein kommerzieller Akteur steht, ist es normalerweise selten, dass externe Beitragende einen relevanten Umfang an Beiträgen leisten. Trotzdem ist das ein wichtiges Detail, über das man bei OSS nachdenken sollte.

  • Wenn man sagt, „das kommerzielle Open-Source-Modell muss sich weiterentwickeln, damit das Ökosystem weiterhin offene und frei nutzbare Software bereitstellen kann“, und dabei Nicht-Open-Source-Lizenzen wie BUSL implizit als Teil der Weiterentwicklung des Open-Source-Modells darstellt, ist das eine erhebliche Verwirrung oder eine bewusste Irreführung.
    Hat jemals jemand von relevanter Größe HashiCorp-Produkte genutzt, um tatsächlich mit HashiCorp zu konkurrieren?

    • Ich habe nicht geprüft, welche Lizenz dabei relevant ist, aber Pulumi nutzt Terraform-Provider in großem Umfang[1]. Und Pulumi kann man eindeutig als Wettbewerber von HashiCorp betrachten.
      [1]: https://www.pulumi.com/docs/concepts/vs/terraform/#:~:text=U...
      Pulumi kann jeden Terraform Provider so konvertieren, dass er in Pulumi nutzbar ist, sodass sich die gesamte vom Terraform-Providers-Ökosystem unterstützte Infrastruktur mit Pulumi-Programmen verwalten lässt.
    • Nur weil es bisher noch niemand versucht hat, heißt das nicht, dass es künftig nicht passieren wird.
      Unternehmen ergreifen solche Maßnahmen, weil Firmen wie Amazon freie und Open-Source-Lizenzen nutzen, um selbst gehostete Versionen von Open-Source-Projekten aufzubauen.
    • Wenn man mit ctrl+f nach „open source“ sucht, sieht man, ab wo sie aufhören, diese Formulierung zu verwenden.
      HashiCorp beschreibt diese Änderung nicht als Erhalt von „Open Source“, sondern als Erhalt offener und frei nutzbarer Produkte.
      Ich halte sie für ehrlicher als andere, weil sie trotz Lizenzwechsel nicht behaupten, Open Source zu bleiben. Sie wissen offensichtlich, welchen Gegenwind sie bekämen, wenn sie es so nennen würden.
    • Das Produkt, das mir sofort einfällt, ist Pulumi. Auf der Service-Seite gibt es auch Dinge wie env0 und SpaceLift.
    • Fly.io war eine Zeit lang auf Nomad aufgebaut. In der neuen Lizenzwelt wäre das nicht mehr erlaubt.

  • Interessant, dass @mitchellh sich nicht an der Diskussion beteiligt. Früher hat er auf HN direkt kommuniziert, und auf diese Entscheidung dürfte er wohl den letztlichen Einfluss gehabt haben.
    Insgesamt sieht das nach einem Zug von Verlierern aus. Man muss sich nur ansehen, was mit Elasticsearch passiert ist. Für mich und die meisten Leute existiert ES nicht mehr. Wir sind gerne zu OpenSearch gewechselt und schauen dem armen kimchi nicht hinterher. Durch das eigene Handeln ist Elasticsearch irrelevant geworden.
    Wird dieser Schritt von HashiCorp ähnliche Bemühungen auslösen, die letzte Open-Source-lizenzierte Version von Terraform und anderen Tools zu forken? Wenn die Macher kleinlich und unsicher werden und sich feindselig gegenüber der Open-Source-Community verhalten, die mitgeholfen hat, es aufzubauen, welche andere Wahl bleibt dann?
    Ich bin extrem enttäuscht von der Führung von HashiCorp. MitchellH und Armon Dadgar hätten die Community besser behandeln müssen.
    2016 hatte ich ein Vorstellungsgespräch bei HashiCorp und habe am Ende abgelehnt; zeitweise habe ich diese Entscheidung etwas bereut. Jetzt, da ihr wahres Gesicht sichtbar ist, bin ich sicher, dass es die richtige Wahl war.
    Es gibt doch diesen Spruch über Vertrauen: Vertrauen braucht Jahre, um aufgebaut zu werden, Sekunden, um zerstört zu werden, und eine Ewigkeit, um wiederhergestellt zu werden.
    Es überrascht mich, dass Menschen, die ich für klug hielt, so töricht sein können.

    • Mitchell ist schon seit ziemlich langer Zeit nicht mehr in der Führung von HashiCorp, und er hat das mehrfach gesagt.
      Es ist nicht nötig, jemanden zu beleidigen, der sehr viel geleistet hat.
    • Ist mitchellh nicht aus seiner Führungsrolle zurückgetreten? Ich verstehe nicht, warum man davon ausgeht, dass er bei dieser Entscheidung „letztlichen Einfluss“ hatte.
    • Das wirkt ziemlich aggressiv. Es ist ein Unternehmen und muss Geld verdienen.
      Ihre Software war Open Source, und die guten Dinge werden geforkt werden, also gibt es keinen Grund, HashiCorp zu hassen.
      Dem Satz „Vertrauen braucht Jahre, um aufgebaut zu werden, Sekunden, um zerstört zu werden, und eine Ewigkeit, um wiederhergestellt zu werden“ stimme ich ebenfalls nicht zu. Das ist zu aggressiv.
      HashiCorp hat großartige Dinge gebaut und versucht, ein Geschäft auf Open-Source-Basis zu betreiben. Sie haben keinen Vertrag gebrochen und nichts Unmoralisches getan; das ist ihre Entscheidung.
    • Zahlt tatsächlich jemand Geld für Terraform? Abgesehen vom gehosteten „workspace“-Produkt sind doch alle Provider kostenlos verfügbar, oder?

  • Das wirkt wie das unvermeidliche Ende, dem jedes Open-Source-Unternehmen nach dem Ende des kostenlosen Geldes entgegensieht. Was stört, ist, dass die Formulierung ziemlich vage ist.
    HashiCorp definiert Konkurrenzprodukte als „Produkte oder Services, die Nutzern oder Kunden außerhalb der Organisation bereitgestellt werden und sich in ihrer Funktionalität wesentlich mit kommerziellen Produkten oder Services von HashiCorp überschneiden“.
    Angenommen, es gibt keinen Service zur Kostenschätzung, man baut etwas, und es wird bekannt: https://github.com/infracost/infracost
    Was passiert, wenn Terraform Cloud zwei Jahre später nachzieht? Muss man dann sein Geschäft aufgeben?

    • Der Apache/MIT-Weg scheint „gut“ funktioniert zu haben, um Sammlungen von Bibliotheken zu pflegen.
      Bei größeren geschäftskritischen Produkten wie Datenbanken sieht man jedoch viel merkwürdigere Verrenkungen, etwa indem Self-Hosting erschwert oder wesentliche Funktionen eingeschränkt werden.
      Das ist besser als Closed Source, aber nicht ideal. Ich denke schon seit einiger Zeit, dass Lizenzen wahrscheinlich ein pragmatischer Ausweg sein können, aber sie müssen allgemein verstanden, fair und klar sein.
      Die Formulierung „Produkte oder Services, die Nutzern oder Kunden außerhalb der Organisation bereitgestellt werden und sich in ihrer Funktionalität wesentlich überschneiden“ tut weh. Dem Wortlaut nach ist sie (1) unklar und (2) die Macht über diese Unklarheit liegt beim Unternehmen, was den Weg für selektive Durchsetzung öffnet.
      In einer Situation, in der man ein juristisches Dokument unterschreibt, ist „Keine Sorge, wir werden niemandem nachgehen“ nicht überzeugend. Wenn ein Vertrag Rechte anhäuft, die derzeit harmlos wirken oder erst in Zukunft ausgeübt werden können, ist das für mich ein großes Warnsignal.
      Mich würde interessieren, wie andere diese Lizenz selbst einschätzen.
    • Der einzige Weg, ein Unternehmen an Bait and Switch zu hindern, scheint eine Änderung der Unternehmenssatzung zu sein: https://opencoreventures.com/blog/2022-10-preventing-the-bai...
      „Terraform Cloud zieht zwei Jahre später nach“ ist ein wirklich guter Punkt. Der Umfang eines Unternehmens verändert sich.

  • Laut https://www.couchbase.com/blog/couchbase-adopts-bsl-license/ hat die BSL normalerweise ein Änderungsdatum nach 1 bis 4 Jahren; dann wechselt die BSL-Lizenz zu einer Open-Source-Change License wie GPL, AGPL, Apache usw.
    Die wichtigste Frage ist also, was die Change License ist und wie lange es dauert.
    Wenn es nach einem Jahr zu MPL 2.0 geht, ist das in Ordnung. Wenn es aber deutlich länger und restriktiver ist, ist das ein kompletter Kurswechsel, und die Open-Source-Version wäre so weit von der aktuellen Version entfernt, dass sie praktisch unbrauchbar wird.
    Update: Es ist MPL 2.0 nach 4 Jahren.
    https://www.hashicorp.com/license-faq#What's-the-difference-...
    Wenn Sicherheit im Spiel ist, sind 4 Jahre im Grunde nur noch „von historischem Interesse“.

  • Ich weiß nicht, wie es bei anderen Unternehmen ist, aber ich frage mich bei Software solcher Firmen immer, wo sie heute stünden, wenn sie von Anfang an unter einer unfreien Lizenz gestanden hätte.
    Das ist nicht nur feindlich gegenüber großen Unternehmen, die den Code „stehlen“ und als Service betreiben wollen, sondern auch gegenüber Endnutzern sowie kleinen Einzelpersonen und Firmen.
    Wenn du HashiCorp-Software erfolgreich betreibst und nutzt und dann als Wettbewerber eingestuft wirst, kann HashiCorp entscheiden, dich auszuschließen.

    • Was wäre, wenn die Abhängigkeiten dieselbe Haltung einnähmen?
      Zum Beispiel https://github.com/hashicorp/vault/blob/main/go.mod#L25
    • Genau. Open Source wurde als Marketing genutzt.
      Wenn sie von Anfang an mit BSL gestartet wären, wäre es vermutlich nicht so breit adaptiert worden.
    • Soweit ich die BSL verstehe, ändert sich für mich kaum etwas; nur meine Vorstellung davon, was der „echte Open-Source-Geist“ ist.

  • HashiCorps CLA-Seite von vor zwei Monaten: https://web.archive.org/web/20230610041432/https://www.hashi...
    Dort hieß es, man verlange von externen Beitragenden die Unterzeichnung eines Contributor License Agreement (CLA), „damit HashiCorp ein nachhaltiges Geschäft aufbauen kann und die Projekte zugleich unter freien und Open-Source-Lizenzen wie MPL2 bleiben“.
    Außerdem stand dort: „HashiCorp verpflichtet sich, für nichtkommerzielle Software echte Free- und Open-Source-Software-Lizenzen (FOSS) zu verwenden. Das CLA ermöglicht es HashiCorp, Produkte sicher zu kommerzialisieren, während Nutzer alle Rechte behalten, die Standard-FOSS-Lizenzen gewähren, etwa das Recht zur Nutzung in eigenen Projekten oder Unternehmen, zur erneuten Veröffentlichung geänderter Quellen und zu vollständigen Forks.“
    Enttäuschend ist, dass die nicht-juristischen Formulierungen auf der Seite wiederholt nahelegten, die Unterzeichnung des CLA helfe dabei, HashiCorp-Projekte Open Source zu halten, während der tatsächliche Vertragstext keine solche Garantie enthielt.

    • Dort steht: „Das CLA ändert nicht die Bedingungen von Standard-Open-Source-Lizenzen wie MPL2 oder MIT. Man kann die Projekte weiterhin in eigenen Projekten oder im eigenen Unternehmen verwenden und geänderte Quellen erneut veröffentlichen. Maßgeblich ist die jeweilige Lizenz des Projekts, zu dem beigetragen wird.“
      Jemand sollte das anfechten, wenn sich die Prämisse des CLA ändert, also wenn Beiträge unter eine Nicht-FOSS-Lizenz relicenziert werden.
      Die meisten CLAs sind sehr nüchtern, aber HashiCorp hat in sein CLA mehrere Erklärungen aufgenommen, was ihnen Probleme bereiten könnte.
    • Man sollte kein CLA unterschreiben.
      Der einzige Grund, so etwas zu verlangen, ist Relicensing, und wenn etwas bereits FOSS ist, ist der einzige Grund für ein Relicensing der Weg hin zu proprietärer Software.
      Linux verlangt für Beiträge kein CLA. Nur diese Clowns, die Open Source nachahmen, verlangen so etwas.

  • Unser OSS-Unternehmen steht unter Apache 2.0 und ist um Nomad als Kern herum aufgebaut.
    Wir haben darum herum einige Services gebaut, um Gameserver-Orchestrierung anzubieten; das könnte von HashiCorp als „Angebot eines Konkurrenzprodukts“ missverstanden werden.
    Da die Lizenz absichtlich unklar ist, werden wir unsere Nomad-Version auf der letzten MPL-Version einfrieren.
    Wir verwenden auch CockroachDB, das ebenfalls BSL ist, aber wir bieten keinerlei Produkt an, das damit konkurriert.
    Es ist gut möglich, dass wir Ratsuchenden weiterhin HashiCorp-Produkte wie Nomad, Consul, Terraform und Packer empfehlen, aber diese Änderung klingt enttäuschend.
    Für Interessierte pflegen wir eine einfache SBOM: https://github.com/rivet-gg/rivet/blob/main/docs/infrastruct...

    • Bitte melde dich: schmichael at hashicorp
      Ich bin Engineering Lead für Nomad. Die Lizenz liegt außerhalb meiner Kontrolle, aber es gibt viele Nutzer, die verunsichert sind, ob sie irgendwann als Konkurrenz interpretiert werden könnten.
      Ich kann nichts versprechen, aber ich werde alles versuchen, um dir die Sicherheit zu geben, dass Nomad weiterhin das passende Tool für deine Arbeit ist.
    • Ich würde so schnell wie möglich aussteigen. Wenn sie so etwas mit ihren ältesten und beliebtesten Tools machen können, ist es nicht abwegig anzunehmen, dass sie bald die Lizenzen für den gesamten Code ändern werden.
    • Ich sehe das genauso. Aber das wird nicht lange halten. Was macht ihr, wenn ein Security Bug auftaucht?

  • Ich persönlich sehe darin kein Problem. Wenn das Endziel darin besteht, eine SaaS-Plattform zu werden, würde ich mir wünschen, dass mehr Open-Source-Projekte von Anfang an mit der Business Source License starten.
    Ich habe immer wieder gesehen, wie große Unternehmen den Open-Source-Gedanken für ihren eigenen finanziellen Vorteil missbrauchen, nichts zurückgeben und sich böswillig verhalten.

    • Den Open-Source-Gedanken missbrauchen? Wenn man keine Konkurrenten wollte, hätte man die Lizenz lesen und verstehen müssen; man hätte Open Source nicht einfach als Marketing-Buzzword verwenden dürfen.
    • Für viele bedeutet der Open-Source-Gedanke, dass die Nutzung auf jede Weise erlaubt ist, ob kommerziell oder nicht.
      Etwas zu verwenden, das öffentlich zugänglich und verfügbar gemacht wurde, sehe ich nicht als böswillig an, und ich gebe auch gern Dinge kostenlos weiter.
      Wenn nicht, ist es nicht Open Source. Natürlich muss nicht jede Software Open Source sein, das ist also auch in Ordnung.
      Den Open-Source-Gedanken missbraucht eher die Seite, die willkürliche Regeln für die Nutzung aufstellt.
    • Es wurde gesagt: „Ich wünschte, mehr Open-Source-Projekte würden mit der Business Source License starten“, aber per Definition wären es dann keine Open-Source-Projekte.
      Trotzdem ist es besser, das von Anfang an klarzustellen.