私はソフトウェアシステムのプロトタイプを作成しています。これは（少なくとも最初は）クローズドソースになります。

時間を節約するために、GPLv3でライセンスされているライブラリを使用する（つまり静的にリンクする）ことを考えているので、設計をすばやくテストできます。この段階でソフトウェアを配布した場合、ソースコードも一緒に配布する必要があります。

そうしないが、システムが動作することを確認し、配布する前にGPLライブラリを自分のコードに置き換えたらどうなりますか？結果はGPLによって「汚染」されますか？

私は、GitライブラリーをGitの履歴に保持するかどうかが、違いを生む可能性があると感じています。

GPL は次のように書いています：

以下のすべての条件を満たしている場合、セクション4の条件に基づくソースコードの形式で、プログラムまたはプログラムから生成するための修正に基づいて作品を伝えることができます。

したがって、この条件は、作業がライブラリに「基づいている」場合にのみ適用されます。ライセンスは次のように定義します。

作品を「変更」するとは、正確なコピーを作成する以外に、著作権の許可を必要とする方法で作品の全部または一部をコピーまたは改変することを意味します。結果の作品は、以前の作品の「修正版」または以前の作品に「基づいた」作品と呼ばれます。

それはあなたのプログラムは、それがある場合にのみ、ライブラリ「に基づく」されている派生作品の著作権法に従いました。その用語の法的定義は司法管轄区によって多少異なり、通常はソフトウェアに直接対処しません。たとえば、米国著作権法は次のように書いています。

「派生作品」とは、翻訳、音楽の編曲、ドラマ化、フィクション化、映画版、録音、芸術の再現、短縮、凝縮、または作品が含まれるその他の形式など、1つまたは複数の既存の作品に基づく作品です。リキャスト、変換、または適合させることができます。全体として原作者の原作を表す編集上の改訂、注釈、詳細化、またはその他の修正からなる著作物は「派生著作物」です。

これがソフトウェアにとって何を意味するかは、以前の同様の裁定に基づいて、裁判所によって解釈されなければなりません。私は、裁判所があなたの訴訟をどのように決定するかを確実に言うために、あなたの管轄区域の関連する判例法に十分精通していません。「GPLライブラリを独自のコードに置き換える」ことは、特にコードがGPL実装に強く触発されている場合、翻訳行為であると主張することができます。GPLライブラリのAPIを再利用しても、お湯に浸かる可能性があります（OracleとGoogleを参照）。

答えがあなたにとって重要な場合は、インターネットで見知らぬ人に尋ねるのではなく、有能な法的助言を求めることをお勧めします。

GPLのライブラリにリンクしている間、誰にもソフトウェアをリリースしない限り、あなたは安全です。GPLのバイラルな側面は、ソフトウェアを配布する場合にのみ有効です。

もちろん、LGPL、APL2、またはMITなど、より寛容なライセンスのライブラリを見つけることができればさらに良いでしょう。

あなたの質問は実際にはGPLに関するものではないと思います。それはプロトタイプについてであり、将来それが成果物ソフトウェアシステムの基礎として使用されるかどうかです。

使い捨てのプロトタイプを作成していて、成果物システムでコードを再利用しない場合は、GPLライブラリを使用してください。

あなたが取ることができる3つのアプローチ

ただし、プロトタイプを進化させる場合（多くのマネージャーがプッシュします！）、次の3つのアプローチがあります。

1. 非コアパーツを、JSON、REST API、または他のプロセス間通信言語/ライブラリを介してコアと通信する個別のアプリケーションに移動します。したがって、非コアパーツもGPLにすることができ、それらのGPLライブラリを使用できます。
2. ライブラリを交換できるようにコードを設計します。これは、実装の詳細を隠すファサードを作成することを意味します。独自のライブラリまたはMIT / BSDライブラリに切り替える準備ができたとき。
3. GPLされたコードをまったく使用しないでください。

最初のアプローチを採用することをお勧めします。そうすることで、将来、プロフェッショナルなポートフォリオの一部として使用できるオープンソースの作業ができるからです。

2番目のアプローチも優れています。それは、とにかくシステムを設計し、必要な正確な関数/クラスを作成し、その機能を満たすライブラリまたはカスタムコードが得られるまでそれらをスタブする必要があるからです。

私はあなたのアプローチで考慮すべき2つの側面を考えることができます。1つ目は、プロジェクトを配布しない（またはGPLv3であるため、パブリックに使用できるようにする）ことにより、GPLの下でリリースされたコードを使用している間は、コードを配布するために必要な方法がわかりにくい再配布条件の下でもGPLライセンスの下で。

2番目の側面は、おそらくあなたにとってより重要です。GPLライブラリを置き換えるために独自の実装を作成する場合、派生物を作成しないように注意する必要があります。私はあなたがソースコードを直接コピーしないという善意を持っていると確信していますが、あなたはライブラリAPIの重要な部分をコピーしないよりも多くの可能性があります。

これが商用製品である場合、GPLv3ライセンスを注意深く読み、疑問がある場合は専門家の法的意見を求めて、このリスクを考慮および評価する必要があります。

GPLコードを置き換えるために独自のコードを記述することを計画している場合、クリーンルーム環境でコードを記述していないため、潜在的な問題が発生します。GPLコードを見たことがない人に、代替ライブラリを作成してもらいたいと思うでしょう。一方、別のライセンスに基づいて既に公開されているライブラリのGPLライブラリを単純に交換する場合、これは問題ではありません。他のライブラリはおそらくクリーンルーム環境で既に作成されています。

GPLされたコードを使用してリビジョンへのアクセスを提供すると、それらは完全にGPLされます。しかし、それはクローズドソースではないので、したくありません...

GPLのコードを使用しなくなった後の状態については、以前にGPLコードを使用したことは、単に無関係です。

GPLはディストリビューションでのみトリガーされます...変更されたバージョンまたは派生物をリリースしない場合は、何でもできます。

私は、GitライブラリーをGitの履歴に保持するかどうかが、違いを生む可能性があると感じています。

GitHubなどの公開リポジトリにソースを公開することを意味する場合、はい、問題が発生している可能性があります。gitを使用することは、プライベートの場合は無関係です。