我该如何使用别人在GitHub上发布的代码？

Question

我正在开发一个项目，想要在GitHub上发布。这个项目需要使用特定的算法Algorithm。我之前所有开发的项目都只用到我的代码（加上STL等），但是写Algorithm可能会很繁琐，所以我想使用别人的代码。相对于我的其他代码，Algorithm只是一个小子程序。

我找到了一个实现Algorithm的GitHub存储库，但是有很多无关的代码，即“Junk”。我想要从Algorithm中剥离掉所有的Junk并使用它，但我不知道该如何做到。理想情况下，Algorithm可以被轻松地清除并无缝地放置在我的项目目录中，以减少其他用户使用我的项目所依赖的因素。

我不知道使用别人的代码的礼节。我不知道如何给予信任或者许可证的内容是什么。

对于使用他人的Algorithm实现，我似乎有五个选择。

1.包含原始头文件，声明Algorithm和所有随之而来的Junk。（我需要将头文件及其所有依赖项复制到我的项目目录中吗？） 2.创建一个新的头文件和源文件，保持Algorithm实现不变，包括所有注释，并将头文件 #include 到我的项目中（省略了原始头文件中出现的其他函数和类）。 3.修改Algorithm的实现代码以删除其余的Junk。删除注释。将C数组更改为std :: vector。使用智能指针替换指针。更改抛出的异常。删除我项目不需要的“选项”。更改数据表示以将所有内容合并到我的项目中。 4.重新编写Algorithm，但是按照现有代码的模型进行建模，使实现符合我的风格，并进行轻微的性能改进（然而，这并不值得在现有存储库上进行拉取）。

对于这4种情况，礼仪规则是什么？我应该将Algorithm放在项目目录的哪个位置？如何给别人的工作贡献？如何给予修改后的工作赞誉（例如，去除原始注释）？如何避免因使用错误编码实践而被别人归功于我的工作（假设他们认为是这样的）？GitHub的哪些功能可以促进所有这些？

关于许可证，如果使用某人的算法来运行我的代码会强制我发布特定的许可证，那么我以后是否可以实现自己的Algorithm并更改许可证？我不知道我是否会关心这个问题，但知道这一点也很好。

- mana

---

复制存储库，删除不必要的内容，然后将复制的存储库作为子模块添加。 - Mansoor

这里最重要的问题是，算法的许可证是什么？因为它决定了您可以或不可以使用代码的条款，以及您需要如何进行归属。 - ypnos

@ypnos，有几种不同许可证下的算法实现。其中之一是 MPL2 许可证，另一个是 MIT 许可证（还有其他的）。评估哪个更好作为起点很难确定。有时这些许可证看起来像我只需复制粘贴代码而不必担心署名，但我不想显得像在窃取代码，特别是当我大部分的代码都是自己写的时候。 - mana

特别是当我从一个个人的GitHub上获取代码时。 - mana

如果你的问题在几个小时内没有得到充分回答，我会在那时给出答案。 - ypnos

Answer 1

通常情况下，当开发人员在Github上发布代码时，他们希望该代码根据特定的许可证被采用和使用。除了遵循许可证外，您无需以任何方式取悦开发人员。

MPL2非常开放，可以将代码并入另一个项目中，即使该项目使用不同的许可证，只要许可文件本身（以及您对其进行的任何更改）仍然在MPL2下获得许可。MIT许可证甚至更加宽松，您可以根据自己的需要重新许可。请注意，您仍然需要遵循归属条款，并引用MIT许可证：

“以上版权声明和本许可声明应包含在所有副本或实质部分的软件中。”

因此，请保持此页眉不变。有关MPL2的详细信息，请参见常见问题解答。

如果您稍后选择从项目中删除代码并以清晰的方式重新实现相同的逻辑，则已受版权保护的代码以及许可条款都将被删除。

现在来谈谈最佳实践：

如果您认为代码不需要进行大规模更改，并且没有很多的负担，那么您可以将其（基本上）不加修改地包含进来，这样您就可以轻松升级代码。但是请注意，原始实现可能会继续发展，特别是在修复错误方面。尽量保持接近原始代码，以便从中获益，而不是最终得到一堆需要自己维护的代码。

如果您有重大的、普遍适用的代码改进计划，例如现代化，可以考虑以拉取请求的形式提交它们。为此，您需要保持原始代码的总体结构不变，以便拉取请求确实只包含这些改进。原始作者现在可以选择从您的改进中受益或不受益。如果他们选择受益，我们回到了第1点：即使您对代码进行了重大更改，您仍然可以从原始作者的维护中获益。

如果有很多垃圾代码与您的项目无关，而且您觉得它是一个维护负担或带有额外的依赖项，或者如果您的更改既重要又特定于您自己的实现，因此您认为它们对原始作者没有帮助（或者普遍看来拉取请求成功的机会很小），那么就勇敢地完全吸收代码。当原始项目看起来“死亡”，例如很长时间没有重大提交活动等时，这也是最好的选择。

显然，没有通用的规则来确定哪种选项最好，因此这只是为了指导您做出决定。

请注意，还有一个“如何”采用代码的技术考虑。对于您来说，保持代码的干净副本（即自包含且不是您更大项目的一部分），并在您明确从Github上的原始存储库（“上游”）中派生的单独存储库中进行更改可能是有益的（但您也可以使用git私下进行）。这使您能够利用git的功能来跟踪更改并在上游和您的分支之间合并它们。您更大的项目使用的源是您自己的分叉存储库，您可以将其与上游同步或不同步。这个分支也是您可能考虑向上游提出拉取请求的起点。

当您在GitHub上分叉存储库时，原始作者能够看到您的分叉，从而知道他们的工作正在被使用。如果您发现并报告错误或建议改进，您会给作者积极的反馈。最后，拉取请求是展示您欣赏的皇冠上的珠宝。但作为在GitHub上发布东西的开发人员，我从来没有期望收到任何回报。

- ypnos