Version control 向我的项目添加开源许可证是否会应用于整个项目修订历史记录？

假设我拥有一些没有许可证信息的开源项目。此外，假设还没有人公开贡献，因此我拥有该项目的源代码和版权

假设源代码已经在线托管。如果我决定通过将相关的复制文档上传到存储库并相应地调整源文件来授予它开源许可证，那么项目的早期版本也会获得许可证吗？或者，当前版本和未来版本将受到保护，而以前的版本属于公共域

或者，假设我在本地机器上使用DVCS（例如Mercurial）启动一个新项目。我提交所有更改（本地），然后在以后的更改集中添加许可证信息。如果我是项目/存储库的宿主，那么整个历史记录将被许可，还是仅许可该变更集之后的版本

在（2）中，项目最初不是托管的，因此这似乎不是问题。但一旦上传，项目的一些历史记录将不包括许可证信息，使得结果看起来几乎与（1）完全相同

---

我这样问是因为Google代码允许您在新项目上选择许可证，即使您打算在之后导入存储库，这使得许可证似乎在某种程度上超出了实际的源代码，而bitbucket.org则不是。

我不是律师，但据我所知，网络上的代码或任何形式的内容都不会真正成为公共领域

关于许可证的时间安排：如果将许可证附加到版本100中的代码，则在再次更改该许可证之前，这只会影响版本100和将来的变更集。否则，例如，您可以在以后将代码从开源恢复

据我所知，在签出某些代码（具有给定版本）时获得的许可证是适用于该项目版本的许可证。在我看来，这也使得使用开源代码从OSI许可证到封闭许可证的项目的分叉成为可能

---

因此，您可能应该在将许可证信息放到网上之前创建一个新的回购协议

只要您不使用任何GPL库，那么您对代码的处理就取决于您自己。您可以说您的代码是追溯性的GPL，或者您可以说什么版本是GPL，什么版本是BSD，什么版本是Apache许可证。您甚至可以提供双重许可：使用GPL或支付我100美元使用BSD（有点像Qt公司在决定提供LGPL之前所做的）

---

现在，如果您使用的是GPL许可库，那么您的代码已经是GPL。

为什么要公开源历史记录？对于您的场景，最简单的解决方案是简单地复制您的代码并创建一个全新的存储库，然后将这个新的存储库与开源许可一起发布到某个地方。拉源，目前是挂在网上没有许可证，你是黄金。旧来源和新来源是完全分开的，不应该有任何问题。如果有人有一份旧来源的副本，你可能无法阻止他们用它做任何他们想做的事情，但你已经为未来的一切都做了一个清白的记录。从您的新回购协议（具有许可证的回购协议）中提取的任何内容都将包含在该许可证的范围内

我假设您是当前在线托管的源代码的作者。如果您没有，那么您还有其他问题需要解决，即您是否有权为其他人的源代码指定许可证-可能没有。

如果您使用LGPL（或Apache或Berkeley许可证）您最好使用GPL代码，因为GPL代码要求所有基于此代码编写的代码都必须作为开源代码发布。

---

请参阅，但是您可能会从这个源代码中获得有关Google代码的更好信息您可以将其视为声明其涵盖范围的许可证。。。legalbol是代码，如果您愿意，可以明确定义范围。

+1“……在将许可证信息放到网上之前，[sic]是否应该创建一个新的repo。”我同意您的看法，因为在修订版上进行分叉/克隆将延续许可证，而不同许可证下的未来版本不应影响这一点。我同意“……在将其放到网上之前。”但当您在本地拥有一个项目，并希望使用许可证发布该项目（包括其历史记录，例如Mercurial+bitbucket）时，应该有一种简单的方式来声明“我的所有工作（到目前为止）都属于此许可证。”关于使用GPL许可库的好处。我的理解是，如果您拥有源代码的版权，那么您可以根据许可条件等将其许可给其他人供其自己使用。您是对的，GPL作为copyleft许可证的条件是，如果您使用GPL库，您还必须使用GPL。我更好奇的是法律对历史的解释，尤其是反复无常的风格。嗨，谢谢你的回答。虽然在这个问题上，我更好奇的是如何发布一个项目，声明它及其源代码的每个修订版都有特定的许可证，而不是我应该使用哪个许可证。问题是，重新创建整个存储库只是在“第一个修订版”添加一个文件（复制文档）是很繁琐的您需要恢复到每个修订版本，复制到新存储库，放入新文件，并使用相同的消息/标记/分支等进行提交。可能有这样的工具。但在一些情况下，比如本地存储库尚未发布，而代码是您自己的，那么最好只声明一个许可证