如果您要将回购程序移植到另一种语言，那么您应该分叉它吗？

Question

我对分叉和开源很陌生，我正在将一个Rust库移植到Swift中，但我不确定是否需要分叉原始的回购文件，然后用我的新文件替换它，还是只上传我自己的回购文件，然后在自述文件中提到它是现有库的Swift端口

Answer 1

1.技术观点

在GitHub上分叉存储库会在您自己的分叉存储库和原始存储库之间创建一个双向链接。

除了社会方面(即显示它是基于别人的作品，并让原作者知道你的叉子)，主要目的是通过将它们拉回原来的项目，来促进你在回购过程中所做的改变和改进的分享。GitHub分叉指南用大量的细节来解释这一点。

在您的具体情况下，您不打算撤回更改，因为您的Swift版本与锈蚀社区无关。所以叉子没用。我甚至认为这可能是一个混乱的根源。

2.法律观点

如果您通过用另一种语言翻译和改编原始库来创建原始库的端口，即使它没有一行原始代码，您的作品也将是一部派生的作品，它受原作者的版权管辖。

你可能会忍不住说：“但我自己重写了所有东西，这怎么可能是版权呢?”这是由于非小拷贝的原理。

因此，您必须验证原始库的许可是否允许派生工作(“修改”)，以及在何种条件下。如果许可证没有透露任何信息，或者如果有疑问，最好是与原作者联系。

3.道德和实践方面

它总是好的(即使在很少的情况下，你不会被迫)，把属于凯撒的东西还给凯撒，也就是清楚地告诉我，它是一个图书馆的港口，abc从作者xyz，并提供一个链接回到原来。

与原作者联系也是一种推荐的做法，即使许可证已经给了你所有的权利:毕竟，你不感兴趣的是作者告诉他/她的社区有一个Swift端口吗？

最后但并非最不重要的是，您考虑过版本控制策略吗？如果原始图书馆不断发展，你会跟随它吗?还是你认为它的未来更加独立？

免责声明:这是软件专业人士的观点。绝不应将其视为法律咨询。如需法律咨询，请咨询您管辖范围内的律师或合格的法律顾问。

Answer 2

除了“克利斯朵夫”和“罗伯特”的另一次深思熟虑的讨论，

叉子将提供对原始项目的一些正式确认，即使从实际情况来看，您永远也不打算与原始项目合并。

你可以保留原来的版权，甚至原始的来源。我建议将您的翻译添加为某种镜像结构(例如，顶级并行树)。通过这种方式，理论上可以完成拉请求，即使这是不切实际的，或者在现实中永远不会发生。

这也可以帮助您根据需要对@Christophe所呼吁的策略进行版本控制。您可以更新您的基础，检查您是否有特定的bug和错误修复在您的分叉。

这样的事情必须在其他地方进行，至少作为概念的证明，因为API和其他东西被移植到各种编程语言中，有时是由第三方(比如您)移植到不同的编程语言。