微软“抄袭”：开发者愤怒发文

Philip Laine 的博客文章《Getting Forked by Microsoft》详细叙述了他作为 Spegel 项目的唯一维护者，与微软之间的一段经历。

Spegel 是一个用于 Kubernetes 集群中容器镜像的点对点分发工具，旨在解决镜像仓库宕机带来的问题。

在一次与微软工程师的会面中，Laine 分享了 Spegel 的架构和实现细节，并协助他们部署该项目。

起初，他期待与微软的合作能够带来积极的反馈和贡献。

然而，在参加 KubeCon Paris 的一次演讲中，Laine 意外地发现微软发布了一个名为 Peerd 的项目，其功能与 Spegel 类似。

尽管 Peerd 的 README 文件底部提到了对 Spegel 的感谢，但 Laine 在深入研究后发现，Peerd 中存在大量直接复制自 Spegel 的代码，包括函数签名、注释和测试用例等。

更令人关注的是，Peerd 的代码中未保留 Spegel 原始的 MIT 许可证和版权声明，这违反了 MIT 许可证的要求。

Laine 表示，这一事件对他产生了负面影响，导致用户对 Spegel 和 Peerd 之间的区别感到困惑。

作为一个开源项目的维护者，他感到自己的努力和贡献被忽视，甚至质疑继续从事开源工作的意义。

他呼吁大型公司在使用开源项目时，应更加尊重原作者的劳动成果，并遵守开源许可证的规定。

此外，这一事件也引发了关于开源许可证选择的讨论。

一些开发者指出，MIT 许可证的宽松性可能使得个人开发者容易被大公司“利用”。他们建议，对于希望保护自己代码不被滥用的开发者，可以考虑采用更具限制性的许可证，如 GPL。

博文原文云头条翻译如下。

作者：DevOps工程师 Philip Laine 凭借热情开发了Spegel个人项目，Spegel 是一款用于缓存容器镜像的 Kubernetes 工具。此前，Philip 是 Flux 的核心维护者，为云原生生态系统贡献代码。

三年前，我还是负责为最终用户开发和维护 Kubernetes 集群的团队的一员。

客户环境中宕机的一个主要原因是镜像仓库（image registry）宕机。

解决这个问题的传统方法是创建一个有状态镜像，但当时客户预算和时间有限，不允许我们这么做。

在黑色星期五期间，GitHub 容器仓库宕机，这导致我们遭遇巨大的流量冲击。由于我们依赖仓库中的关键镜像，这限制了我们扩展集群的能力。

在经历这次事件之后，我就开始思考一种更好的方法来避免这类可扩展性问题，即一种不需要有状态组件、只需极少运维监护的解决方案。

于是，Spegel 这个想法应运而生。

作为一个开源项目的唯一维护者，当微软联系我安排一次会议讨论 Spegel 时，我备感兴奋。

双方谈得很顺利，我感觉将来彼此会顺利合作，也希望能借此机会招募到新的维护者。

我继续与一位微软工程师讨论，帮助他们运行 Spegel，并解答他们提出的任何架构问题。

当时我很乐观，因为我觉得微软有可能根据其经验回过头来贡献代码变更。

随着时间的推移，微软那边却毫无动静，我还以为工作优先事项发生了变化。

直到在巴黎 KubeCon大会上，我参加了一场引起我兴趣的演讲。

这场演讲的主题是加速镜像分发的策略，其中讨论的一种策略是 P2P 共享。

摘要主题听起来与 Spegel 很相似，我很高兴听到别人对这个问题的看法。

在演讲中，我很高兴听到有人讨论自己的项目 Spegel，称这是一种 P2P 镜像共享解决方案。

当有人提到 Peerd（微软开发的 Kubernetes 集群中容器内容的点对点分发器）时，我马上研究了一番。

在README文件的底部，有一段内容是对我和Spegel致谢的。

这段致谢看起来就像他们从我的项目中汲取了一些灵感，随后开发了自己的版本。

资料来源：Peerd

随着逐渐深入研究 Peerd，我越来越没兴趣了解这个问题领域的不同方法。

我看到函数签名和注释看起来很眼熟，就好像是我自己写的一样。

再深入挖掘后，我发现了引用Spegel和我前雇主的测试用例，这些测试用例直接取自我的项目。

这些引用至今依然存在。

该项目是 Spegel 的分支（forked）版，由微软维护，但遵循微软的 MIT 许可证。

资料来源：Peerd

Spegel 是基于 MIT 许可证发布的。基于 MIT 许可证发布的软件允许分支和修改，而无需回过头来贡献这些更改。我默认使用 MIT 许可证，因为它简单且宽松。该许可证不允许移除原始许可证，并表明代码是由他人创建的。该项目的大部分内容似乎直接从 Spegel 复制而来，对原始来源根本只字未提。我添加了一小段代码片段来比较添加镜像配置的代码，结果发现连函数注释都一样。

来源：Spegel

开发Peerd 带来的负面影响是它给新用户造成了困惑。

我经常被问到Spegel 和 Peerd 之间的区别。

作为一名维护者，我有责任尽可能地保持客观公正，并实事求是，但这段遭遇使这变得颇具挑战性。

微软拥有巨大的品牌知名度，因此 Spegel 很难与如此庞大的平台相抗衡。

作为一名开源维护者，我投入了大量时间来处理社区请求、编写错误修复和安全修复。

在与微软的沟通中，我乐于合作，以继续开发和完善一个造福开源社区的工具。

多年来，我为众多开源项目做出了贡献，也创建了几个属于自己的项目。

Spegel 是我从零开始创建的第一个项目，它获得了一些关注，似乎也得到了社区的赞赏。

看到我的项目被微软分支后，我感觉自己再也没有用处了。我一度怀疑是否还有必要继续开发 Spegel。

幸运的是，我坚持了下来。

Spegel 自两年多前首次发布以来，依然保持着强劲势头，拥有超过 1700 颗星（star）和 1440 万次拉取（pull）。

然而，我不是第一个、也不是最后一个遭遇这种“小不点对抗巨无霸”经历的人。

唯一的维护者如何才能与拥有数十亿美元资产的公司合作而不被利用？

随着 Hashicorp 许可证的变化对整个开源社区产生连锁反应，以及对整个开源界的投资大幅下降，社区该如何生存？

为了资助 Spegel 方面的工作，我启用了 GitHub 赞助功能。

这段经历也让我考虑改变 Spegel 的许可证，因为这似乎是我唯一能采取的手段了。

参考链接：https://philiplaine.com/posts/getting-forked-by-microsoft/