开源，版权和普通错误修正

假设开发人员已为其封闭源商业应用程序开发了一个库。由于他们想回馈给开源社区，因此他们在GPL等标准下发布了该库，但是继续在自己的应用程序中使用它。由于它们拥有版权，所以很好。

现在，GPL版本的用户发现了一个错误，对其进行了修复并将修补程序提交给原始开发人员。据我了解，要在其封闭源应用程序中使用此错误修正，开发人员需要获得提交者的许可。如果提交者拒绝，则开发人员必须找到另一种方法来修复封闭源版本中的错误。

但是，如果错误修正本身真的不重要怎么办？像正确初始化变量还是检查空指针？给定错误描述，任何半熟练的程序员都可以在几分钟内找到并解决问题？此补丁仍受版权保护吗？还是原始开发人员可以在未经提交者同意的情况下在其封闭源应用程序中实施相同的修复程序？

注意：这确实是一个假设的场景，而不是那些“我的“朋友”有此问题”的问题

警告：我不是律师！

更新：琐碎的错误修正可能不受版权保护。有关更多信息，请参阅Michael Shaw的答案，我相信它的答案比我最初说的要准确。

但是，即使这样，这种情况也不理想：

• 对于您所设想的示例而言，这可能是相当清楚的，因为它带来了微不足道的更改，而不是添加了重要的功能。但是，在现实生活中，这将是对情况的判断。您将被留在版权灰色区域。
• 理想情况下，您只想将更新的文件合并到程序中；即使是微不足道的，您也不想添加自己的代码。它只是重复不必要的工作。
• 现在将有两个版本的文件：您的版本和开源的版本。如果您想稍后将代码的更新版本发布给社区，这只会使事情变得一团糟。

结论： Gnu公共许可证特别限制了封闭源程序中代码的使用。因此，根据GPL释放您的代码就等于故意创建了无法合并回原始程序的代码分支。这没有多大意义。

在更为宽松的许可（例如BSD许可或艺术许可）之一下发布代码会更好地为您服务。这些许可证允许代码无需额外许可即可包含在封闭源代码软件中。通常，社区的任何进一步开发都将在您使用的相同许可证下进行，因此您将能够将所做的（较小或重要的）任何更改合并到您的软件中。

从技术上讲，有人可以决定更新您的代码，然后在GPL下发布它，但他们必须积极做出选择。这不是默认位置。这样一来，他们就会从您所做的任何更新中切断发行版本，因此这可能对他们没有好处（鉴于它是您的软件，因此您可能会比其他任何人都进行更多的开发）。

如果该错误修复确实很琐碎，那么它可能根本就没有版权，特别是如果确实没有其他方法可以编写该代码。有数亿种写爱情诗或电子游戏的方式，实际上只有一种或两种以上的书写方式if (*p == NULL)。版权是一个想法的表达，因此，如果一个想法的表达方式实际上没有任何选择，就不会有版权。

但是，如果该错误修复仍然相当琐碎，则可能有数十种表达方式，因此它可能具有版权。而且，很难说出一件相当琐碎的东西是几乎没有版权还是几乎没有版权。

它也可能是受版权保护的，但使用它将是合理的使用。合理使用有点复杂，因为它取决于权衡多个因素，并且可能无济于事，因为是否适用合理使用将由法院决定-理想情况下，您根本不想提起诉讼，无论您的案情有多强。合理使用的因素之一是所使用作品的比例（这不利于您，因为您将整个作品都拿走了），另一个因素是该作品的商业潜力（这对您来说，是因为其商业价值）一个简单的错误修正本身为零），因此猜测法院可能以哪种方式裁定容易出错。

解决此问题的最佳方法可能是将错误的确切描述及其确切位置交给尚未看过补丁的开发人员。然后，他们可以独立修复该错误（由于此错误是微不足道的，因此将花费很少的时间），并且所有潜在的版权问题都将消失，因为如果具有版权，则您拥有版权。您的开发人员最终可能会获得与补丁几乎完全相同的代码，因为本质上只有一种编写方式，但是在这种情况下，它不具有版权。

在阅读http://www.ifosslr.org/ifosslr/article/view/30/64之后，我的专家意见是：

原始作品拥有唯一作者权，该人拥有版权，可以选择以自己希望和确实拥有的方式许可该作品。

现在，开发人员发现了一个错误并做出了贡献。可以认为这不具有版权（贡献太小），但说这是实质性的贡献。由于两个人都同意合并，因此原始作者接受该贡献，从而使该作品成为集体作品。

在集体著作中，每个作者都拥有各自的部分，但每个人都对整个作品拥有不容置疑的兴趣，因此，每个人都可以按照他们希望的任何条件发布整个作品。

如果这是一个合理的解释，那么争论的焦点就不是原始作者是否可以在其商业版本中使用该错误修复程序，而他们可以使用IMO。潜在的冲突是错误修复程序是否认为他们在整个作品中拥有自己的独立所有权。在这种情况下，建议原始作者从错误修复程序中获取版本，以明确表明他们不接受该作品的所有权。