Gründe, keinen Open Source-Code für gemeinnützige Zwecke zu verwenden? [geschlossen]

Ich bin ein großer Fan von Open Source Code. Ich denke, ich verstehe die meisten Vorteile von Open Source. Ich bin ein wissenschaftlicher Forscher und muss mit einer erstaunlichen Menge an Software und Code arbeiten, die nicht Open Source sind (entweder proprietär oder nicht öffentlich). Ich kann keinen guten Grund dafür erkennen, und ich kann sehen, dass der Code und die Leute, die ihn verwenden, definitiv davon profitieren würden, öffentlich zu sein. und das ist viel schwieriger, wenn andere keinen Zugriff auf Ihren Code haben).

Bevor ich Missionierung gehen und beginnen, möchte ich wissen: Gibt es gute Argumente für nicht not-for-Profit - Code öffentlich freigeben und mit einer OSI-konformen Lizenz?

(Ich weiß , es gibt ein paar ähnlichen Fragen auf um, aber die meisten konzentrieren sich auf Situationen , in denen der Code in erster Linie für die Herstellung von Geld verwendet wird, und ich konnte nicht viel relevant in den Antworten.)

Klarstellung: Mit "nicht gewinnorientiert" beziehe ich nachgelagerte Gewinnmotive wie die Markenbekanntheit der Muttergesellschaft und die Gewinnerwartungen der Anleger ein. Mit anderen Worten, die Frage bezieht sich nur auf Software, für die KEIN Gewinnmotiv an die Software gebunden ist.

Sie müssen berücksichtigen, dass Open Sourcing Ihres Codes möglicherweise zusätzlichen Aufwand erfordert.

In diesem Blogeintrag beschreibt Sun / Oracle Engineer beispielsweise die Anstrengungen, die sie beim Open-Sourcing ihres Codes unternehmen mussten: Open Source oder Dirty Laundry?

Während wir uns darauf vorbereiten, in die Open-Source-Welt einzutauchen, besteht eine der vielen Aktivitäten darin, den Code für Open-Sourcing vorzubereiten. Es gibt einige offensichtliche Dinge, die getan werden müssen. Zum Beispiel enthält unser Quellcode eine Mischung aus Code, den wir geschrieben haben, und Code, den wir von anderen lizenziert haben. Wir müssen letztere trennen und nur die entsprechenden Codeteile als Open Source-Dateien bereitstellen.

Eine andere Vorbereitungsaktivität ist das "Scrubben" des Codes für proprietäre Informationen, Erwähnungen bestimmter Kunden, Entwickler, Technologien usw. Dies ist etwas weniger offensichtlich, aber betrachten Sie das folgende Beispiel:

/\*
 \* HACK - insert a time delay here because the stupid Intertrode
 \* Technologies framebuffer driver will hang the system if we
 \* don't. Those guys over there must really be idiots.
 \*/

Obwohl all das oben Genannte zutrifft, haben wir wahrscheinlich eine Art Beziehung zu Intertrode Tech, und Kommentare wie diese im Code könnten unser Geschäft irgendwie schädigen und sollten daher entfernt werden. Vielleicht hätte es gar nicht dort sein sollen, aber jetzt ist es an der Zeit, es rauszunehmen.

Ein weiterer Teil der "Schrubb" -Aktivität besteht darin, Schimpfwörter und andere "unerwünschte" Wörter zu entfernen ...

Beachten Sie alle oben genannten Änderungen am Code vorgenommen werden mussten , die als Closed - Source vollkommen in Ordnung angesehen wurde - , dass es rein macht zusätzliche Anstrengungen so zu sprechen.

Sicherheit.

Angenommen, Sie erstellen ein Webframework und verwenden es selbst.

Als gemeinnütziges Projekt hatten Sie nicht die Zeit, jeden Code auf Anfälligkeit für den einen oder anderen Angriff zu untersuchen:

• CSRF
• XSS
• SQL-Injektion
• Sitzungsfixierung
• Verwendung fehlerhafter Bibliotheken von Drittanbietern oder sogar von Sprachen

Nachdem Sie das Projekt mit Open-Source-Funktionen erstellt haben, gestatten Sie freundlichen Augen, einen Beitrag zu leisten, aber auch böswilligen Augen, einen vollständigen Einblick in Ihre Arbeit zu erhalten. Wenn sie einen Server finden, auf dem Ihr Code ausgeführt wird, haben Sie die Möglichkeit, Ihren Code zu verbergen, aufgehoben Unvollkommenheiten im Dunkeln.

Dies gilt natürlich möglicherweise nicht für die Art von Software, an der Sie arbeiten. und wie immer Unklarheit ist keine Entschuldigung für Faulheit in Sicherheit.

Genauso wie ich in den Levels, die ich im Stripe Capture the Flag-Spiel durchlaufen habe, festgestellt habe , ist das Wissen, dass der Code der einfachste Weg ist, um Sicherheitslücken zu finden (und manchmal kann es der einzige Weg sein).

Ein guter Grund, nicht auf Open Source zuzugreifen, ist, dass einige Ihrer Quellen urheberrechtlich geschützt sind. Wie oft suchen Sie nicht im Web nach einer schnellen Lösung für ein Problem und nehmen nur den Code-Ausschnitt, den Sie finden?

Nun, diese sind möglicherweise urheberrechtlich geschützt, und ich weiß nicht, ob der Autor seinen Code unter einer anderen Lizenz erneut lizenzieren möchte.

Sie müssen bei der Auswahl Ihrer Lizenz vorsichtig sein, um mögliche Haftungsprobleme zu vermeiden.

Ein Anwalt ist vielleicht eine bessere Person, um darüber zu sprechen, aber die allgemeine Idee ist, was passiert, wenn jemand die Anwendung verwendet (oder missbraucht) und sie Schaden anrichtet? Bist du verantwortlich? Dies hängt natürlich davon ab, welche Art von Software Sie schreiben, aber Sie müssen immer vorsichtig sein, was Ihre Lizenz über Ihre Haftung aussagt. Es kann schwierig sein, dies zu korrigieren. Daher ist es möglicherweise einfacher, den Quellcode einfach nicht freizugeben.

Warnung: Ich bin kein Anwalt .

Nun, wenn es sich um eine gemeinnützige Organisation handelt und ihr geistiges Eigentum stark an den Code der Software gebunden ist, möchten einige möglicherweise verhindern, dass sie kommerziell wiederverwendet oder sogar missbräuchlich zum Erstellen von Kopien Ihrer Software ausgenutzt wird.

Einige andere Gründe - die wahrscheinlich tief in der ersten verwurzelt sind - sind, dass in Ihrem Fall ein Großteil der High-End-Forschung mit privater Finanzierung erfolgt und die Investoren normalerweise einen ROI sehen möchten. Und bis jetzt sind noch nicht alle Akteure der Softwareindustrie (oder Neulinge) vollständig von der Realisierbarkeit des Open-Source-Modells überzeugt worden (höchstwahrscheinlich aufgrund fehlenden Wissens und Verständnisses für Lizenzen oder einfach aufgrund der Befürchtung, dass Lizenzen schädliche Aktivitäten nicht verhindern könnten) Verwendungen und Kopien).

Darüber hinaus möchten diese Unternehmen nicht von denjenigen verklagt werden, die versucht haben, auf ihrem Rücken Gewinne zu erzielen, und die Lizenzierung wird auch in dieser Hinsicht aus gutem Grund als Schutz angesehen.

Es mag nicht so erscheinen, aber vielleicht sind gemeinnützige Organisationen für ihre Gründer oder Investoren rentabel. Die Vorteile sind einfach nicht direkt. Sie haben daher ein großes Interesse daran, dass die NFPs stark werden und nicht von Wettbewerbern an den Rand gedrängt werden (auch wenn man auf dem gemeinnützigen Markt nicht oft an "Konkurrenten" denkt), und sie möchten ihre Position bewahren IP, auch wenn es nicht darum geht, mehr freie Augäpfel zu bekommen, um ihren Code zu überprüfen, um Probleme zu finden und ihn früh zu verbessern.

Beachten Sie auch, dass das Urheberrecht von Land zu Land unterschiedlich ist. In vielen europäischen Ländern sind die US-amerikanischen Urheberrechtsgesetze und das US-amerikanische Patentsystem zum Beispiel eher verblüfft. Daher gibt es einen kulturellen Hintergrund und ein Gewicht, die nur schwer abzuschütteln sind.

Jut meine 2 Cent zu diesem Thema.

(Ich habe viel mit Universitäten zusammengearbeitet und in letzter Zeit in Bioinformatik und Gesundheitswesen ... Es ist eine immer wiederkehrende Frage für mich und meine Kollegen :))

Es gibt mindestens zwei verschiedene Arten von Open Source.

Wenn Ihre Einstellung lautet "hier ist etwas Nützliches, ich bin fertig damit" (und das ist richtig), dann gibt es wenig Nachteile.

Auf der anderen Seite, wenn Ihre Einstellung lautet "Ich bin sehr aufgeregt und möchte, dass einige echte Benutzer die zukünftige Entwicklung vorantreiben", dann überlegen Sie genau. Sie müssen Zeit damit verbringen, Benutzer zu unterstützen, von denen viele ahnungslos sind. Sie müssen widersprüchliche Anforderungen für Funktionen und Verbesserungen berücksichtigen. Es wird immer schwieriger, Änderungen vorzunehmen, um die Abwärtskompatibilität zu gewährleisten.