プロトタイピングに一時的にGPLライブラリを使用して、将来のコードをクローズドソースにすることはできますか？
私はソフトウェアシステムのプロトタイプに取り組んでいます（少なくとも最初は）クローズドソースになります。
時間を節約するために、私は GPLv でライセンスされているライブラリを使用する（つまり、静的にリンクする）ことを考えているので、デザインをすばやくテストできます。この段階でソフトウェアを配布した場合、ソースコードも一緒に配布する必要があります。
そうでない場合はどうなりますか？しかし、私のシステムが機能していることを納得してから、配布する前にGPLライブラリを自分のコードに置き換えますか？結果はGPLによって「汚染」されますか？
Git の履歴にGPLライブラリを保持することで、違いが生じると感じています。
GPL 書き込み ：
プログラムに基づく作品、またはプログラムからそれを作成するための変更を、セクション4の条件に基づくソースコードの形式で、次の条件もすべて満たす場合に提供できます。
したがって、この条件は、作業がライブラリに「基づいて」いる場合にのみ適用されます。このライブラリは、次のように定義されています。
作品を「変更する」とは、正確なコピーを作成する以外に、著作権の許可を必要とする方法で、作品の全部または一部をコピーまたは改変することを意味します。結果として生じる作品は、以前の作品の「変更されたバージョン」または以前の作品に「基づいた」作品と呼ばれます。
つまり、あなたのプログラムは、著作権法に従って 派生物 である場合に限り、ライブラリに「基づいて」います。その用語の法的定義は管轄区域によって多少異なり、通常はソフトウェアに直接対応していません。たとえば、米国著作権法は次のように書いています。
「派生著作物」とは、翻訳、編曲、ドラマ化、架空化、映画版、サウンドレコーディング、アートの複製、要約、凝縮、その他の形式など、1つまたは複数の既存の作品に基づく作品のことです。リキャスト、変換、または改造することができます。編集上の改訂、注釈、詳細、またはその他の変更で構成される作品は、全体として、オリジナルの著作物を表し、「派生作品」です。
ソフトウェアにとってこれが何を意味するかは、以前の同様の判決に基づいて、裁判所によって解釈されなければなりません。裁判所があなたの訴訟をどのように決定するかを確実に述べるには、私はあなたの法域の関連する訴訟法を十分に理解していません。 「GPLライブラリを独自のコードで置き換える」ことは、特にコードがGPL実装に強く触発されている場合、翻訳の行為であると主張することができます。 GPLライブラリのAPIを再利用するだけでも、お湯に浸かってしまう可能性があります（ Oracle vs. Google を参照）。
答えがあなたにとって重要である場合、私はインターネットで見知らぬ人に尋ねるのではなく、有能な法的助言を求めることをお勧めします。
GPL化されたライブラリにリンクしている間、誰にもソフトウェアをリリースしない限り、あなたは安全です。ソフトウェアを配布する場合にのみ、GPLのバイラルな側面が機能します。
もちろん、LGPLやAPL2やMITのような、より寛容なライセンスを持つライブラリを見つけることができればもっと良いでしょう。
あなたの質問は実際にはGPLに関するものではないと思います。それはプロトタイプについてであり、成果物ソフトウェアシステムのベースとして将来的に使用されるかどうかです。
使い捨てプロトタイプを作成していて、成果物システムでコードを再利用しない場合は、GPLライブラリを使用してください。
あなたが取ることができる3つのアプローチ
ただし、プロトタイプを進化させる場合（多くのマネージャーがプッシュするもの！）、次の3つの方法があります。
- 非コアパーツを、JSONまたはREST APIまたはその他のプロセス間通信言語/ライブラリを介してコアと通信する別のアプリケーションに移動します。非コアパーツは、GPLとしてまあ、あなたはそれらの中でGPLライブラリを使うことができます。
- ライブラリを交換できるようにコードを設計します。これは、実装の詳細を非表示にする ファサードの作成 を意味します。独自のライブラリまたはMIT/BSDライブラリに切り替える準備ができたとき。
- GPL化されたコードを使用しないでください。
最初のアプローチを使用することをお勧めします。そうすれば、将来的にプロのポートフォリオの一部として使用できるオープンソースの作業ができるからです。
2番目のアプローチも適切です。それは、システムを設計してとにかくシステムを設計し、必要な正確な関数/クラスを作成し、ライブラリまたはカスタムコードが得られるまでスタブ化するからです。その機能を埋めます。
あなたのアプローチで考慮すべき2つの側面を考えることができます。 1つ目は簡単です。GPLの下でリリースされたコードを使用しているときに、プロジェクトを配布しないか、（または GPLv を使用できるようにして）、GPLの下でリリースされたコードを使用している場合、再頒布条件の下でも、GPLライセンスに基づいてコードを頒布する必要があります。
2番目の側面は、おそらくあなたにとってより重要です。 GPLライブラリを置き換えるために独自の実装を作成するときは、派生物を作成しないように注意する必要があります。私はあなたがソースコードを直接コピーしないことに善意を持っていると確信していますが、ライブラリAPIの重要な部分をコピーしないよりも可能性が高いです。
これが商用製品である場合、このリスクは、GPLv3ライセンスを注意深く読み、疑わしい場合は専門家の法的意見を求めて、検討および評価する必要があります。
独自のコードを記述してGPLコードを置き換えることを計画している場合は、クリーンルーム環境でコードを記述していないため、問題が発生する可能性があります。あなたは本当に、GPLコードを見たことのない人に置換ライブラリを書かせたいと思うでしょう。一方、GPLライブラリを別のライセンスに基づいて既に公開されているライブラリと単純に交換したい場合、これは問題ではありません。他のライブラリはおそらくクリーンルーム環境で既に作成されています。
GPLされたコードを使用してリビジョンへのアクセスを提供する場合、それらは完全にGPLされます。しかし、それはクローズドソースではないので、したくありません...
GPLされたコードを使用しなくなった後の状態の場合、GPLコードを以前に使用したことは単に無関係です。
GPLはdistribution ...でのみトリガーされます。変更されたバージョンや派生物をリリースしなければ、何でも好きなことができます。
GPLライブラリをGitの履歴に保持するかどうかで、違いが生まれるかもしれません。
GitHubのような公開リポジトリにソースを公開するつもりなら、はい、問題がある可能性があります。 gitを使用するだけでは、それがプライベートである場合は無関係です。