Ist es Ihnen wichtig, dass eine Software "verfügbare Quelle", aber nicht "Open Source" ist?

Sie kennen wahrscheinlich die Liste der vom OSI offiziell genehmigten Open Source-Lizenzen. Am bemerkenswertesten wäre wohl die GPL MIT [geben Sie hier Ihre Lieblingslizenz ein].

Ich bin kürzlich auf ein Projekt gestoßen, das zwar Open Source war (der Ersteller hat den gesamten Quellcode verfügbar gemacht), aber unter einer dieser offiziellen Lizenzen nicht offiziell Open Source war.

• Es gab die Quelle frei, machte aber kein Versprechen, die Quelle in Zukunft freizugeben.

• Es erlaubte Änderungsvorschläge, machte jedoch keine Zusagen, Patches zu akzeptieren, und verbot die externe Verteilung von extern gepatchten Versionen.

• Es erlaubte die Verwendung der Software in kommerziellen oder bezahlten Projekten, verbot jedoch den Verkauf der Software selbst.

Ich nehme an, es könnte als "verfügbare Quelle" bezeichnet werden, nicht als Open Source, wie wir es gerne sehen.

Ich kann sehen, warum das Managementteam eines Unternehmens mit dieser Software keine Geschäfte machen möchte. Sie können es nicht teilen, sie können es nicht verkaufen, sie können keine eigene Version der Software erstellen und sie vertreiben oder verkaufen.

Aber wäre es für Sie als Teil eines Software-Engineering-Teams wichtig, das nur diese Software verwendet? Ich kann meine Arbeit immer noch damit erledigen, ich kann sie in einem Projekt verwenden, für das ich bezahlt werde (aber ich kann die Software selbst nicht verkaufen, was ich sowieso nicht tun kann), und ich kann Nehmen Sie Änderungen am Code vor, damit er sich für meine Anforderungen anders verhält (aber ich kann diese Änderungen nicht veröffentlichen). Wenn ich möchte, dass diese Änderungen offiziell anderen zur Verfügung gestellt werden, liegt die Genehmigung beim Projekt selbst und sie entscheiden, ob um sie in eine offizielle Veröffentlichung aufzunehmen oder nicht.

Wir wissen also, dass ein Unternehmen, das sein Geschäft auf dieser "verfügbaren Quell" -Software aufbauen möchte, dies nicht kann. Aber als jemand aus dem Software-Engineering-Team wären diese Unterschiede für Sie von Bedeutung oder scheinen sie weniger relevant zu sein?

Neugierig, was andere darüber denken.

Für Projekte, bei denen die von dieser Software bereitgestellten Funktionen von Grund auf neu entwickelt werden müssten, ist es auf jeden Fall praktisch, dies nicht zu tun.

Ob ein vergleichbares Open Source-Paket besser wäre, hängt jedoch von anderen Faktoren ab:

• Wird es verwendet, um einen Service bereitzustellen oder als Teil eines anderen Produkts zu bündeln?
• Haben sie die Ressourcen, um das Produkt unabhängig zu verbessern und zu warten?
• Gibt es einen Wettbewerbsvorteil bei der Verwendung dieser Software gegenüber der Open Source-Version (entweder im Code oder im Projektmanagement)?

Wenn Sie auf einen dieser Faktoren mit Nein antworten , ist das OSS die bessere Wahl.

Meistens ist der Code selbst nicht der bestimmende Faktor. Man muss das Gesamtbild untersuchen.

SIDEBAR OSS-Projekte können rechtlich nicht versprechen, dass sie zukünftige Versionen offen halten oder dass es zukünftige Versionen geben wird. Das ist ein Grund, warum eine offene Lizenz so vorteilhaft ist. Außerdem müssen OSS-Projekte keine Patches von Mitwirkenden akzeptieren (insbesondere ohne Übertragung von Eigentum oder Rechten).

Die Frage für diese und jede andere externe Bibliothek ist die Wartung .

Was ist die Lebensdauer Ihrer Anwendung und wie ist die scheinbare Lebensdauer dieser Bibliothek? Ihre sollte hoffentlich die kürzeste sein.

Wer wird Fehlerbehebungen für diese Bibliothek durchführen? Wie es von hier aus aussieht, sollte Ihr Unternehmen in Zukunft explizit Ressourcen für die Wartung dieser Software zuweisen, da Sie sich nicht auf andere Fehlerbehebungen für Sie verlassen können. Sie können die Wartungslast nicht mit anderen teilen, da Sie die Quelle nicht teilen können. Möchten Sie einen schwer fassbaren Fehler in Bezug auf die Rennbedingungen in Code finden, den Sie nicht kennen?

Dieser Gedanke allein könnte die Nutzung der Bibliothek zu teuer machen.

Dies mag irrelevant sein, wenn die Bibliothek sehr solide und robust ist und auf Quellenebene leicht zu bearbeiten ist. Ich habe jedoch die Erfahrung gemacht, dass der Gruppenzwang von echten Open Source-Projekten den Code einfach verbessert, weil Sie dann dazu neigen, Ihr Bestes zu geben.

Persönlich würde ich sehr vorsichtig darüber nachdenken, ob ich diesen oder einen anderen externen Code übernehmen würde, da der ganze Grund für die Verwendung des Codes anderer Leute darin besteht, dass Sie sich nicht selbst damit befassen müssen . Denken Sie auch an zukünftige Betreuer - Sie sollten Feuerwehrübungen durchführen, um den Code in der Bibliothek zu ändern, um zu sehen, ob dies überhaupt möglich ist. Hier könnte es einige SEHR böse Überraschungen geben.

Ist es Ihnen freigestellt, die betreffende Bibliothek zu besprechen?

Um ehrlich zu sein, verstehe ich nicht, warum das Managementteam eines Unternehmens Probleme mit der Verwendung einer solchen "verfügbaren Quell" -Bibliothek haben würde. Was die Integration in das eigene Produkt betrifft, können sie es lediglich als Closed-Source-Bibliothek betrachten.

Für mich als Programmierer spielt es keine Rolle, ob eine Bibliothek "Open Source" oder "verfügbare Quelle" ist. Ich ziehe es vor, keine lokalen Änderungen an einer externen Bibliothek vorzunehmen, da dies einen zusätzlichen Wartungsaufwand bedeutet. Nicht nur, wenn Fehler in meinen lokalen Änderungen gefunden werden, sondern auch, wenn die Änderungen immer wieder integriert werden, wenn eine neue Version der Bibliothek herauskommt.

Die einzige Situation, in der "Open Source" meiner Meinung nach die in der Frage beschriebene "verfügbare Quelle" -Lizenz übertrifft, ist wann

• Die Lizenz für unser Produkt erfordert auch die Offenlegung der Quellen der enthaltenen Bibliotheken
• Wir sind im Geschäft, eine erweiterte Version der Bibliothek zu erstellen

Aus diesem Grund verwendet die Free Software Foundation die Begriffe "frei" oder "nicht frei" , um Software zu beschreiben. Sie beziehen sich nicht auf den Preis, sondern auf Einschränkungen, die der Verwendung oder dem Vertrieb der Software unterliegen.

Es sieht so aus, als hätten Sie einen der seltenen Eckfälle getroffen, in denen Sie vollen Zugriff auf den Quellcode von etwas haben, aber die Software ist nach der OSI-Definition nicht "Open Source" .

Jeder Begriff kann zu einer Fehlbezeichnung werden. Ich habe 50 US-Dollar für meine erste Kopie von Emacs (auf QIC-Band) bezahlt, aber Emacs ist freie Software . Ich habe den Quellcode für einige proprietäre Anwendungen, die mein Unternehmen intern verwendet, aber sie sind keine Open Source-Anwendungen.

Das, was (zumindest für mich) die größte rote Fahne auslöst, ist keine Garantie für den Zugriff auf den Quellcode zukünftiger Versionen. Wenn Sie stark davon abhängen, dieses Tool ändern zu können, wäre ich vorsichtig. Selbst wenn Sie mit dem Anbieter mündlich vereinbart haben, dass Sie immer Code haben, es sei denn, dieser liegt in Vertragsform vor. Diese Vereinbarung ist nie zustande gekommen.

Als CTO versuche ich mein Bestes, um sicherzustellen, dass wir nicht auf unfreie Software angewiesen sind. Ich war in der Vergangenheit mehrmals am schlechten Ende der Anbietersperre, ein Fehler, den ich gerne vermeiden möchte. Während wir einige proprietäre Dinge verwenden, würde unser Geschäft keine übermäßige Härte erleiden, wenn wir sie plötzlich nicht mehr verwenden könnten.

Es hört sich für mich so an, als würden Sie sich mit dieser Software und dem Zugriff auf den Code beschäftigen. Ich würde daher empfehlen, schriftlich etwas zu erhalten, das besagt, dass Sie immer Zugriff haben. Was passiert, wenn der Anbieter gekauft wird?

Das ist ziemlich wichtig. Hauptprobleme mit dem von Ihnen beschriebenen Ansatz "Verfügbare Quelle":

• Sie haben keine Kontrolle über Ihr technologisches Schicksal, wenn Sie nicht die Freiheit haben, die Quelle zu ändern. Oft ist das direkte Hacken der Quelle einer chaotischen Problemumgehung vorzuziehen.
• Sie haben keine Garantie dafür, dass die Software weiterhin gewartet wird, und Sie haben nicht die Möglichkeit, dies selbst zu tun, was Sie mit echtem Open Source erhalten.
• Da es sich wie eine benutzerdefinierte Lizenz anhört, besteht wahrscheinlich ein höheres rechtliches Risiko als bei der Verwendung von bekannten und bewährten Lizenzen wie der GPL oder der BSD.
• Wenn es sich nicht um echtes Open Source handelt, erhalten Sie nicht die gleiche hilfreiche Community, was für viele Open Source-Projekte von großem Vorteil ist

Mein Vorschlag: Versuchen Sie, den Ersteller davon zu überzeugen, die Software unter einer Open Source-Lizenz freizugeben. Das sollte für alle ein Gewinn sein - Sie, weil Sie die gewünschte Software unter Open Source-Lizenz erhalten, der Ersteller, weil das Open Source-Projekt die Software auf lange Sicht wahrscheinlich viel erfolgreicher macht.