微软被指“抄袭”个人千星项目，开发者控诉：代码大段照搬，我只在README里被说了声谢谢！

编译 | 苏宓

出品 | CSDN（ID：CSDNnews）

开源项目被 Fork，本是社区共建的一部分——但当一个个人项目被大厂“选中”，这究竟是荣誉加冕，还是原作者心血被悄然稀释？

最近，开发者 Philip Laine 发长文分享了自己与微软之间一段错综复杂的经历。在开发了一个个人开源项目后，微软主动“找上门”沟通，Philip 原以为微软的主动接触意味着一次潜在的合作，然而没等来进一步的沟通，却在一次偶然的参会中发现自己的项目早已被对方“借鉴”并改头换面。

查阅对方项目代码后，Philip 还惊讶地发现大量示例代码与自己的相同、以及自己的个人注释也出现在对方项目代码中。而对方给出的致谢，仅仅是一句藏在 README 最后一行的“灵感来源”。

这一事件迅速引发了关于开源伦理与开发者权益的讨论。事情的经过究竟如何？接下来我们来看看。

“我开发了一个无状态的集群本地 OCI 注册表镜像系统”

事情的起点要追溯到三年前，Philip Laine 在一个负责为终端客户开发和维护 Kubernetes 集群的团队中工作。在实际工作中，他发现导致客户系统频繁宕机的主要原因之一是镜像仓库服务的中断。

解决这个问题的传统方法是搭建一个有状态的镜像站点（stateful mirror），但由于客户的预算和时间限制，这种方式在实际操作中行不通。

后来，在某个星期五，GitHub 的容器镜像仓库宕机，导致 Philip 团队的项目遭遇巨大的流量冲击，这一事件严重影响了集群扩容能力，因为他们依赖的关键镜像正好来自于那个出故障的仓库。

这次经历促使 Philip 开始思考如何避免此类可扩展性问题，且不依赖有状态组件，同时还需要尽量减少运维负担。正是在这样的背景下，Spegel 项目（https://github.com/spegel-org/spegel）的想法诞生了。

简单来看，Spegel 是一个开源的、无状态的本地 OCI（Open Container Initiative）镜像注册表镜像工具，专为 Kubernetes 集群设计。它通过在每个节点上运行 Spegel 实例，形成一个点对点（P2P）网络，实现容器镜像的本地缓存和共享，从而提高镜像拉取速度，减少对外部镜像仓库的依赖，降低网络带宽消耗，并增强系统的可靠性。

当时，Philip 是这个开源项目的唯一维护者。某天，他突然收到微软的消息，对方表示希望就 Spegel 项目进行会谈，这让他感到非常兴奋。首次会议进行得十分顺利，Philip 看到了合作的希望，甚至开始期待借此机会引入新的项目维护者。之后，他与微软的一位工程师保持密切沟通，不仅协助对方顺利部署了 Spegel，还积极解答了架构相关的技术问题。

基于此，Philip 对这次交流充满期待，认为微软未来可能会根据使用过程中的反馈，为项目带来一些改进建议。但随着时间推移，对方渐渐失去了回应，他也开始觉得，或许只是微软的工作重心、内部优先级发生了变化。

转折出现：微软开发的项目直接引用原作者的一些信息

事情的转折出现在巴黎举办的 KubeCon 大会上。Philip 在现场听到一场主题为“提升镜像分发速度策略”的演讲，内容提到了 P2P（点对点）共享机制。演讲摘要的方向与 Spegel 的设计理念高度契合，这让他非常期待能听到其他人对这一问题的思考与探索。

然而，在这位演讲嘉宾分享过程中，Philip 意外地发现 Spegel——也就是他自己一手打造的项目——被当作 P2P 镜像分发的案例在台上公开介绍，这一度令他感到惊喜。

还没高兴多久，他还听到演讲中提到了微软开发的一个名为 Peerd 的新项目——这是一个面向 Kubernetes 集群的容器内容 P2P 分发工具。出于好奇，Philip 立刻上网搜索相关信息，并在 Peerd 的 GitHub 仓库 README（https://github.com/Azure/peerd）底部，发现了对他本人和 Spegel 项目的署名致谢。这条致谢看上去像是微软从 Spegel 项目中获得了灵感，并据此开发出了自己的版本。

来源：https://github.com/Azure/peerd

Philip Laine 在深入研究微软的 Peerd 项目时，心情也从最初的好奇转为不解以及愤怒。

因为他在 Peerd 代码中发现了极为熟悉的函数签名和注释，几乎就像是他自己写的一样。随着进一步查看，他发现了一些测试用例，直接引用了 Spegel 项目和他前雇主的信息——这些测试用例原封不动地被复制过来，而且至今仍未被移除。

来源微软的项目：https://github.com/Azure/peerd/blob/e0c0c5442f74937d56b70c3325d97bc9533f130e/pkg/oci/distribution/v2_test.go#L49-L57

来源微软的项目：https://github.com/Azure/peerd/blob/e0c0c5442f74937d56b70c3325d97bc9533f130e/pkg/discovery/content/provider/provider_test.go#L21-L26

遵循 MIT 发布的开源项目

Philip 指出，Spegel 是在 MIT 许可证下发布的。根据该许可证，任何人都可以自由地 Fork（复制）和修改相关软件，无需将修改内容回馈给原作者。他之所以默认使用 MIT 协议，是因为感觉它简单、宽松。然而，这份许可证并不允许在移除原始许可证的前提下，假装代码是由他人原创的。

从目前情况来看，Spegel 项目的大量代码似乎被直接复制了过去，却没有提及原始来源。为此，Philip 还附上了一段用于配置镜像功能的对比代码片段，其中甚至连函数注释都完全相同。

来源：Peerd

来源：Spegel

此外，Philip 认为，Peerd 的出现也给他带来了一些负面影响，因为很多新用户根本分不清 Spegel 与 Peerd 之间的区别，由此经常跑来询问 Philip 这两个项目之间的关系。

Philip 称，自己作为维护者，尽力保持客观中立，以事实为依据地去解释，但这种纷扰的历史让解释工作变得十分艰难。微软的品牌影响力极大，使得一个小型开源项目很难在这样一个“巨头”旁边获得足够的关注和空间。

Philip 表示，作为一名开源维护者，他长期以来一直积极响应社区需求、修复漏洞并处理安全问题。他在与微软沟通时也始终持开放态度，愿意合作，共同完善一个服务于整个开源社区的工具。多年来，他参与了多个开源项目的开发，并亲力亲为地开发了多个项目。Spegel 是他首个从零开始打造且获得广泛认可的作品。本以为 Spegel 被微软 Fork 是一种认可，但随着项目逐步被“取代”，他一度感到自己失去了价值，甚至怀疑是否还应该继续维护 Spegel。

所幸的是，Philip 并未放弃。自两年多前首次发布以来，Spegel 仍在持续发展，目前已获得超过 1700 颗 GitHub 星标，镜像被拉取次数超过 1440 万次。

然而，Philip 也坦言，他并不是第一个、也不会是最后一个经历这种“弱者对抗巨头”的开源开发者。他发问：在如今开源生态受投资下滑、如 HashiCorp 许可证变更引发广泛连锁反应的背景下，独立维护者如何在不被利用的前提下与大型企业共存？社区又该如何在这样的环境下继续前行？

为继续资助 Spegel 的开发工作，Philip 启用了 GitHub 赞助功能。同时，这段经历也促使他认真考虑修改 Spegel 的开源许可证——因为这似乎是他唯一还能握在手中的“投石器”。

微软回应：“没有给予你应有的署名归属，这是我们的失误”

随着 Philip 将自己的经历发出，在多个平台尤其是 HN 上引发了大量网友的讨论。

其中，有网友作为过来人，同样分享自己与微软之前沟通的经历，要学会“首先谈好条件再去解答问题”：

在很久以前（也就是微软进入 Satya 纳德拉时代之前），我曾是一个流行开源项目的维护者，这个项目主要解决了早期云计算从业者的一些专业痛点。它最初是为了解决我自己的问题开发的，我并不想把它商业化，所以愿意以开源形式发布。后来，微软一位负责多个产品团队的总监联系我，表示希望“合作”。我说可以，把我的咨询服务协议发给他们看。他们对费用有点抱怨，但我只是重申了那是我的标准价格。经历了一轮法律上的来回之后，他们最终签了协议，我在为期两天的工作坊中解答了他们一堆问题，他们也如约付款了。如果他们真的很想要你的东西，他们就会愿意付钱。别免费打工。

也有开发者认为当前行业缺乏一种更可靠的开源许可方式：

我个人认为，我们需要一种全新的许可证模式：社区型开源许可。不为企业服务，只属于社区。

这里的问题并不是微软 Fork 了某个项目，而是在于，当像微软这样的大公司这么做时，往往会对我们的社区造成伤害。开源之所以能够蓬勃发展，是因为无数个体和小团体在共同协作。

而微软的运作逻辑，是围绕“为股东创造利润，不惜一切代价”。只要有利可图，他们也会参与协作，但一旦无利可图，便会回到那套熟悉的“拥抱、扩展、消灭”策略。这种缺乏社区精神的行为在企业中相当普遍，也正因此，它对我们的开源社区构成了生存威胁。将利润凌驾于一切之上，不是合作，而是一种掠夺。

激烈争论之下，还有一位自称是来自 微软 Cloud Native Ecosystem 团队的人现身回应道：

你好 Philip，我是 Lachlan，来自微软 Cloud Native Ecosystem 团队。我们团队长期在云原生开源社区中工作，目标是成为这些项目和社区中的优秀合作伙伴。对于你经历的这件事，我深感抱歉。

我们非常认可你在 Spegel 项目上的领导力和付出，也看到这个项目确实为云原生社区解决了实际难题。感谢你发布的博客文章（https://philiplaine.com/posts/getting-forked-by-microsoft/），我想借此机会告诉你我们目前的做法，并回应几个关键点。

我们刚刚提交了一个 Pull Request（https://github.com/Azure/peerd/pull/110），用于修正源码文件中的许可证头。我们在这方面确实做得不够好：根据公司政策，应该在文件中保留版权声明——目前我们已经为相关文件补充了许可证头，并标注了你在项目中的贡献。

我也想解释一下我们为什么会选择创建一个新项目：Peerd 之所以诞生，主要是为了加入 artifact streaming（制品流式传输）功能。当时你与我们工程师交流时提到，这个功能可能超出了 Spegel 的设计范围，这个看法我们非常理解。我们确保在项目中致谢了 Spegel 并承认其对 Peerd 的启发作用，就像你在博客中提到的那样，但我们没有给予你应有的署名归属，这是我们的失误，对此我感到抱歉。你的声音我们已经听到，我们会改进流程，努力成为更负责任的开源参与者。

再次感谢你指出这个问题。我们会不断改进在开源领域的合作方式，也始终欢迎你的反馈。

不过，显然不少开发者对这样的解释并不买账。有网友质问：“如果有家公司‘忘了’为 Windows/Office 或其他产品申请许可证，微软会怎么处理？这不就是违反了许可证规定吗？那微软现在做的事，和盗版有什么区别？”

对此，你怎么看？

https://philiplaine.com/posts/getting-forked-by-microsoft/

https://news.ycombinator.com/item?id=43750535