同じリポジトリの異なるブランチに異なるライセンスを使用する
GitHubに中規模のプロジェクトがあるGitリポジトリがあります。GPLライブラリに依存するコンポーネントがいくつかあるため、リポジトリは現在GPLの下でもライセンスされています。ただし、GPLライセンスのライブラリは一部のコンポーネント（分離可能）でのみ使用され、プロジェクトの残りの部分はそれらのコンポーネントがなくても完全に使用できます。したがって、MITライセンスの下でGPLライブラリに依存しないすべてのライセンスを取得したいと思います。これを達成するためのベストプラクティスは何ですか？
私の考えは、2つの異なるブランチを持つことです。1つのブランチには完全なコードが含まれており、GPLの下でライセンスされています。もう一方のブランチは、GPLコードに依存し、MITの下でライセンスされているすべての機能を削除します。同じリポジトリの異なるブランチに対して異なるライセンスを持つことは実行可能および/または一般的ですか？そうでない場合、より良い選択肢は何でしょうか？
技術的には、その新しい非GPLブランチの完全な履歴にかつてGPLコードが含まれていたことは問題でしょうか？または、ブランチに新しいMITライセンスファイルを追加する前に、そのブランチからすべてのGPLコードが削除されている限り、問題はありませんか？
ことに注意してくださいこの質問はやや似ていますが、私は私がより多くに関与していることを感じてい技術的な実装を。つまり、現在使用しているブランチに応じて、リポジトリのルートディレクトリに2つの異なるLICENSEファイルを配置できますか？
回答
Gitブランチは、同じプロジェクトの異なる「エディション」を維持するのにあまりうまく機能しません。ブランチ間で変更を完全にマージせずに共有する良い方法がないためです。したがって、単に技術的な理由から、ライセンスの異なるブランチを使用しないことをお勧めします。このようなブランチも、ユーザーにはあまりわかりません。
代わりに、すべてのコードを1つのメインブランチに保持しますが、ライセンスの異なるコードを異なるフォルダーに保持し、どのコードがどのライセンスの下にあるかを明確にします。
GPLは、ダウンストリームコードがGPLの下にあることを必要としません。派生物は（全体として）同じGPLライセンスの下にある必要があります。しかし、これは、自分で作成したコンポーネントがMITなどのGPL互換ライセンスの下にある場合に満たすことができます。誤解を避けるために、これらのコンポーネントを「MITまたはGPL」としてデュアルライセンスすることもできます。これは、「Apache-2.0またはGPL-2.0のみ」など、互換性のないライセンスにとって重要です。
したがって、ベストプラクティスは、GPLでカバーされている部分を、自分で完全に書いた部分から分離し、トップレベルのライセンスを使用して、どの部分がどのライセンスで利用できるかを説明することです。これを非常に正確に実行したい場合は、globパターンをライセンスに関連付けるDebianの機械可読copyrightファイル形式を採用することもできます。別々のファイルを好きなようにあなたは多分同じライセンスファイル内のいずれかのフルライセンステキストを保存する、または可能性がありLICENSE.GPL.txt、LICENSE.MIT.txtまたはそれぞれのディレクトリに。
現在、GPLでコード全体を提供しているため、一部の部分でMITを移動するには、再ライセンスが必要になります。あなたが唯一の寄稿者である場合、これは些細なことです。あなたが唯一の著作権所有者として、あなたが好きなようにライセンスを発行できるからです。ただし、他の寄稿者がいる場合は、再ライセンスに同意するか、寄稿を削除する必要があります（通常、GPLの対象となる寄稿の前の最後の状態からコンポーネントを書き換える必要があるため、非常に注意が必要です）。再ライセンス後でも、Gitの履歴にGPLでカバーされているものと同じファイルが表示されることは重要ではないと思います。古いライセンスはこれらの古いバージョンでも引き続き有効であり、新しいライセンスはこれらの新しいバージョンでも引き続き有効です。