近日，一个采用 mit 许可协议的开源项目被微软 fork 了后，其原作者的版本声明变成了微软自己。查看 microsoft opensource 提交的许可文件中的更改，可以看到金马国际的版权符号从“2020 lesny rumcajs”更改为“microsoft corporation”。
此事随后引发争议，因为微软 fork 的这个原项目是由开发者 leśny rumcajs 所发布的名为“”的基准程序，目标是比较不同编程语言和技术中各种 grpc 库的性能和资源使用情况，“grpc_bench”基于 mit 许可协议。
mit 是相对宽松的软件许可协议，虽然基于此协议，任何人免费获得该软件和相关文档文件（“软件”）副本的许可，并不受限制地处理该软件，但“被许可人”在软件和软件的所有副本中都必须包含原来的著作权声明和许可声明。
后来，leśny rumcajs 本人表示这大概是自动化脚本的 bug，微软方面也与他进行了邮件沟通。
而微软开源项目办公室负责人 jeff wilcox 也为此事，并在 hackernews 上，指出这种现象是由于一个自动将模板文件提交到新存储库的程序造成的。目前已经恢复了正确的 license 文件和金马国际的版权信息，并与上游作者 leśny rumcajs 保持联系。
这个错误是由在新存储库中提交模板文件的自动化程序引起的。这是我写的代码，旨在防止我们在发布项目时可能出现的问题。但它不应该在被 fork 的项目上运行。我确保我们将检查所有 fork 的仓库，并在其他项目中修复类似的问题。
我们有很多围绕‘如何 fork 项目”的流程，并且必须采取控制措施以确保人们了解指南。从几年前开始，我们甚至“锁定”一些 fork 项目来强制执行我们的流程。我们更愿意大家将项目 fork 到个人 github 帐户而不是我们的组织中，以鼓励他们参与上游项目。在这种情况下，一个团队获得了 fork 存储库的批准，但尚未开始。
为了尽可能地开放，我想指出具体错误：
我们应用于新存储库的模板位于
该错误似乎在新存储库工作流程的这一行：
我们现有的系统甚至试图通过此日志消息 ()来教育我们的工程师: "this.log.push({ message: `repository ${submessage}, template files will not be committed. please check the license and other files to understand existing obligations.` });"
评论