我正在开发一个软件系统的原型，该原型（至少在开始时）将是封闭源代码。

为了节省时间，我正在考虑使用（即静态链接）在GPLv3下获得许可的库，因此我可以快速测试设计。如果在此阶段分发软件，则必须随同分发源代码。

如果我不这样做，但是让自己确信我的系统可以运行，然后在分发之前用我自己的代码替换GPL库，该怎么办？结果会被GPL“污染”吗？

我感觉是否在我的Git历史记录中保留GPL库可能会有所作为。

GPL 写道：

您可以根据第4节的条款，以源代码的形式，根据本程序或为从本程序产生的修改而传达的作品，但前提是您还满足以下所有条件：

因此，此条件仅在您的工作“基于”库的情况下适用，该许可证的定义如下：

“修改”作品是指除需要进行精确复制外，还需要获得版权许可才能从全部或部分作品中复制或改编全部或部分作品。产生的作品称为早期作品的“修改版本”或“基于”早期作品的作品。

也就是说，当且仅当它是根据版权法的衍生作品时，您的程序才“基于”该库。在不同的司法管辖区中，该术语的法律定义有所不同，通常不会直接针对软件。例如，美国版权法规定：

“衍生作品”是指基于一种或多种先前存在的作品的作品，例如翻译，音乐编排，戏剧化，虚构化，电影版本，录音，艺术品复制，删节，缩编或任何其他形式的作品可以重铸，转换或改编。由编辑性修订，注解，细化或其他修改组成的作品，总体上代表着原创性作品，是“衍生作品”。

这对软件意味着什么，必须由法院根据较早的类似裁决加以解释。我对您所在管辖区的相关判例法还不太熟悉，无法确定地说法院将如何判决您的案件。有人可能会说“用自己的代码替换GPL库”是一种翻译，尤其是在您的代码受GPL实现强烈启发的情况下。即使重用GPL库的API也会使您陷入困境（请参阅Oracle vs. Google）。

如果答案对您很重要，我建议您寻求有能力的法律建议，而不要在互联网上询问陌生人。

只要您在链接到GPL的库时不向任何人发布该软件，就可以保证安全。仅当您分发软件时，GPL的病毒性方面才会发挥作用。

当然，如果您可以找到许可更宽松的图书馆，那就更好了，例如LGPL或APL2或MIT。

我认为您的问题实际上不是关于GPL的。它涉及原型以及将来是否将其用作可交付软件系统的基础。

如果您要制作一次性原型，并且不打算在可交付使用的系统中重用任何代码，请继续使用GPL库。

您可以采取的三种方法

但是，如果您要发展原型（很多管理人员都在努力争取！），则可以采用以下三种方法：

1. 将非核心部分移动到单独的应用程序中，这些应用程序通过JSON或REST API或某些其他进程间通信语言/库与您的核心进行通信。因此，您的非核心部分也可以是GPL，并且您可以在其中使用任何GPL库。
2. 设计代码，以便可以换出库。这意味着创建一个隐藏实现细节的外观。当您准备切换到专有库或MIT / BSD库时。
3. 完全不要使用GPL代码。

我建议您采用第一种方法，因为这样您便拥有开源的工作，将来可以将它们用作专业产品组合的一部分。

第二种方法也很好，因为无论如何这就是您应该设计系统的方式，创建所需的确切函数/类，然后将它们存根，直到您拥有可以填充该功能的库或自定义代码。

我可以考虑您的方法要考虑的两个方面。第一个很简单，在使用GPL发行的代码时，不分发您的项目或（或者因为它是GPLv3，使其可公开使用），很难理解您将如何要求分发代码根据GPL许可，也根据重新分发条款。

第二个方面对您可能更重要。当您创建自己的实现以替换GPL库时，需要注意不要创建派生作品。尽管我确定您有良好的意愿，但不要直接复制源代码-比不复制库API的重要部分更有可能。

如果是商业产品，则需要仔细阅读GPLv3许可并在有疑问的情况下寻求专业法律意见，以考虑和评估这种风险。

如果您打算编写自己的代码来替换GPL代码，则可能会遇到问题，因为您不是在洁净室环境中编写代码。您确实希望有一个从未看过GPL代码的人编写任何替换库。另一方面，如果您只想将GPL库换成已获得另一许可的已发布库，那么这就不成问题了，该另一个库可能已经在洁净室环境中编写了。

如果您使用GPL代码提供对修订的访问权限，则将完全使用GPL。但是您不想要，因为那样就不会封闭源代码...

对于以后不再使用任何GPL代码的状态，您之前使用GPL代码根本无关紧要。

GPL仅在发布时触发...如果不发布修改版本或衍生作品，您可以做任何想做的事情。

我觉得在我的Git历史记录中保留GPL库可能会有所作为。

如果您打算将源发布到诸如GitHub的公共存储库，那么可以，则可能有问题。如果它是私有的，则仅使用git无关紧要。