安全にオープンソースバージョンとクローズドソースバージョンを並べて提供する最良の方法は何ですか？

私の会社は、4.0より前のVirtualBoxと同様に、独自の拡張バージョンとともに、オープンソースソフトウェアプロジェクトの開発とリリースを目指しています。

2つのコードベースを維持して、オープンソース製品への変更を簡単に商用バージョンに組み込み、誤ってプロプライエタリコードをオープンソース製品にプッシュするリスクを最小限に抑えるための最良の方法は何ですか？

2つのプロジェクトを作成します。

1. スタンドアロンで実行できるOSSプロジェクト。
2. OSSプロジェクトコードに依存する独自のコード。

依存関係は、ビルド時または実行時の依存関係にすることができます。各パッケージをスタンドアロンにする場合は、ビルド/パッケージの作成中に必要なOSSファイルを独自のパッケージでプルすることができます。実行時の依存関係に問題がない場合は、独自のコードだけをパッケージ化して、実行時にOSSパッケージに依存させることができます。

利点：

• コードの重複から解放されます。
• 1つで取得するためのコストで、両方のバグ修正を取得します。
• OSSとProprietaryの明確な説明。

ソース管理と分岐

ルートは、両方のディストリビューションに共通のコードです。また、（おそらく）ルートから2つのブランチを作成します。

Open Source

Closed Source

Open Sourceこのシナリオでは、おそらくルートをミラーリングします。定期的に、あなたはマージうOpen SourceとClosed Source手で（Closed Sourceおそらく多くの更新として取得しません）。

このようにして、拡張をClosed Sourceブランチに保持し、オープンソースバージョンから新しい変更を取り込むことができます。

質問に記載されていないオープンソースライセンスによって異なります。GPLはこの点でほとんどの問題を引き起こし、静的リンクまたは実行時リンクが疑われます。

最良の結果については、FAQをお読みください。他の答えを信用しないでください。プラグインの使用は本当に合法ではありません。多くの商用製品は、さまざまな点でGPLに違反しており、基本的には逆に見えます。

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

GPLの下でリリースされたプログラムがプラグインを使用する場合、プラグインのライセンスの要件は何ですか？これは、プログラムがプラグインを呼び出す方法によって異なります。プログラムがforkとexecを使用してプラグインを呼び出す場合、プラグインは別個のプログラムであるため、メインプログラムのライセンスではそれらの要件はありません。

プログラムがプラグインを動的にリンクし、プラグインが相互に関数呼び出しを行い、データ構造を共有する場合、それらは単一のプログラムを形成し、メインプログラムとプラグインの両方の拡張として処理する必要があります。つまり、プラグインはGPLまたはGPL互換のフリーソフトウェアライセンスの下でリリースする必要があり、プラグインを配布する際にはGPLの条件に従う必要があります。

プログラムがプラグインを動的にリンクしているが、それらの間の通信が、いくつかのオプションを指定してプラグインの「メイン」機能を呼び出し、プラグインが戻るのを待つことに限定されている場合、それは境界線の場合です。