Was ist der beste Weg, um Open- und Closed-Source-Versionen sicher nebeneinander bereitzustellen?

Mein Unternehmen möchte ein Open-Source-Softwareprojekt zusammen mit einer proprietären erweiterten Version entwickeln und veröffentlichen, die der VirtualBox vor 4.0 ähnelt.

Was ist der beste Weg, um die beiden Codebasen so zu pflegen, dass Änderungen an der Open Source-Version problemlos in die kommerzielle Version integriert werden können, ohne dass das Risiko besteht, dass proprietärer Code versehentlich auf das Open Source-Produkt übertragen wird?

open-source proprietary version-control

— rkjnsn
quelle

Antworten:

Ich würde 2 Projekte erstellen.

OSS-Projekt, das eigenständig ausgeführt werden kann.
Proprietärer Code, der vom OSS-Projektcode abhängt.

Die Abhängigkeit kann eine Build- oder Laufzeitabhängigkeit sein. Wenn Sie möchten, dass jedes Paket eigenständig ist, können Sie die OSS-Dateien, die während der Erstellung / Paketerstellung benötigt werden, durch proprietäres Paket abrufen. Wenn Sie mit einer Laufzeitabhängigkeit zufrieden sind, können Sie den proprietären Code einfach alleine verpacken und ihn zur Laufzeit vom OSS-Paket abhängig machen.

Leistungen:

Befreit Sie vom Duplizieren von Code.
Holen Sie sich Fehlerbehebungen in beiden für die Kosten, um es in einem zu bekommen.
Klare Abgrenzung zwischen OSS und Proprietary.

— Dietbuddha
quelle

+2: Wenn möglich, machen Sie die proprietären Funktions-Plugins. Die Erfahrungen der Benutzer mit der OSS-Version machen Appetit und sie können die neuen Funktionen direkt kaufen / installieren, während sie die App ausführen. Sie können es sogar so einrichten, dass jedes proprietäre Plugin eine Testphase von X Tagen hat. Dies löst nicht nur Ihr Problem mit der Codebasisverwaltung, sondern erleichtert auch das Marketing.

— Peter Rowell

Quellcodeverwaltung und Verzweigung

Die Wurzel wäre der Code, der beiden Distributionen gemeinsam ist. Sie würden auch (vermutlich) zwei Zweige aus Ihrer Wurzel erstellen:

Open Source

Closed Source

Open Sourcewürde wahrscheinlich Ihre Wurzel in diesem Szenario spiegeln. Regelmäßig würden Sie zusammenführen Open Sourceund Closed Sourcevon Hand ( Closed Sourcewürde wahrscheinlich nicht so viele Updates erhalten).

Auf diese Weise können Sie die Verbesserungen in Ihrem Closed SourceZweig behalten und neue Änderungen aus der Open Source-Version übernehmen.

— Craige
quelle

Gibt es eine Möglichkeit, dies mithilfe separater Repositorys zu tun? Wir hoffen, dass das Repository mit dem Open Source Code öffentlich sichtbar ist.

— rkjnsn

Hängt von der Open-Source-Lizenz ab, die in der Frage nicht angegeben ist. GPL gibt diesbezüglich die meisten Probleme und jede statische Verbindung oder Laufzeitverbindung ist verdächtig.

Lesen Sie die FAQ, um die besten Ergebnisse zu erzielen. Traue anderen Antworten nicht. Die Verwendung von Plugins ist nicht wirklich legitim. Viele kommerzielle Produkte verletzen die GPL auf unterschiedliche Weise und sehen im Grunde genommen anders aus.

http://www.gnu.org/licenses/gpl-faq.html

Wenn ein unter der GPL veröffentlichtes Programm Plug-Ins verwendet, welche Anforderungen gelten für die Lizenzen eines Plug-Ins? Dies hängt davon ab, wie das Programm seine Plug-Ins aufruft. Wenn das Programm Fork und Exec verwendet, um Plug-Ins aufzurufen, sind die Plug-Ins separate Programme, sodass die Lizenz für das Hauptprogramm keine Anforderungen an sie stellt.

Wenn das Programm Plug-Ins dynamisch verknüpft und Funktionsaufrufe miteinander ausführt und Datenstrukturen gemeinsam nutzt, bilden sie unseres Erachtens ein einziges Programm, das als Erweiterung sowohl des Hauptprogramms als auch der Plug-Ins behandelt werden muss. Dies bedeutet, dass die Plug-Ins unter der GPL oder einer GPL-kompatiblen Lizenz für freie Software veröffentlicht werden müssen und dass die Bedingungen der GPL eingehalten werden müssen, wenn diese Plug-Ins verteilt werden.

Wenn das Programm Plug-Ins dynamisch verknüpft, die Kommunikation zwischen ihnen jedoch darauf beschränkt ist, die Hauptfunktion des Plug-Ins mit einigen Optionen aufzurufen und auf die Rückkehr zu warten, ist dies ein Grenzfall.

— Jonathan Cline IEEE
quelle

Wenn Sie das Urheberrecht an der GPL-Software besitzen, können Sie Closed-Source-Plugins selbst verteilen. Der ursprüngliche Inhaber des Urheberrechts ist derjenige, der die Lizenzregeln festlegt und sicherlich nicht an die Lizenz gebunden ist. Auf der anderen Seite bedeutet dies, dass 1) Sie keine GPL-Beiträge akzeptieren können, ohne dass Sie eine Urheberrechtszuweisung benötigen, und 2) dass andere die Plugins nicht mit der GPL-Software vertreiben können.

— Han

Warum sollten Sie den FAQ gegenüber anderen Quellen vertrauen? Es kommt aus der vielleicht voreingenommensten Quelle, die man sich vorstellen kann. Und wenn ich meine Arbeit unter die GPL stelle, spielt es keine Rolle, ob die FSF sagt, dass die GPL sagt, dass Sie X können. Wenn das Gesetz und die Lizenz sagen, dass Sie nicht können, kann ich Sie immer noch verklagen und ich werde immer noch gewinnen.

— David Schwartz

"Warum sollten Sie den FAQ gegenüber anderen Quellen vertrauen?" Da die FAQ auf früheren Fällen aus der realen Welt basiert, nicht auf der Sesselhypothese von Stack Exchange-Blog-Autoren, deren technischer Ruf nur durch Punkte sichtbar wird, die eher durch Popularität als durch Korrektheit vergeben werden.

— Jonathan Cline IEEE

Wir haben noch keine Lizenz für die Open Source-Version ausgewählt. Wir haben das Urheberrecht für den gesamten Code, daher sollte es kein Problem sein, ihn unter zwei separaten Lizenzen freizugeben.

— rkjnsn

Wenn Sie keine Lizenz ausgewählt haben, ist es viel besser, eine BSD-basierte Lizenz als eine virale zu verwenden (viral = bedeutet GPL-basiert). Viele Produkte verwenden erfolgreich netbsd, das in ein Serverprodukt eingebettet ist, wobei proprietärer Code (die Mehrwertteile) direkt in den Baum integriert ist. Obwohl, wie ein anderer Autor angibt, Sie die Veröffentlichung mit einer Doppellizenz durchführen können, ist dies für Sales & Mkting möglicherweise nur verwirrend. Vielleicht ein erfolgreiches Beispiel als Referenz ist Apple Darwin ("Apple Public Source License", jetzt Apache-Lizenz): en.wikipedia.org/wiki/Darwin_(operating_system)#License

— Jonathan Cline IEEE