微软抄袭 AppGet 始末 | 观点
近日，开源项目 AppGet 作者 Keivan Beigi 与微软 WinGet 项目的“抄袭纠纷”事件迎来了新进展。微软方面做出回应，坦承“辜负了 Keivan 和 AppGet”，并肯定了 Keivan 与 AppGet 对微软新项目的贡献。
- https://my.oschina.net/editorial-story/blog/4300683
- 作者：开源中国
近日，开源项目 AppGet 作者 Keivan Beigi 与微软 WinGet 项目的“抄袭纠纷”事件迎来了新进展。微软方面做出回应，坦承“辜负了 Keivan 和 AppGet”，并肯定了 Keivan 与 AppGet 对微软新项目的贡献。
今年 5 月，微软在 Build 2020 大会上发布了新的软件包管理工具 WinGet，并将其开源。 而就在 WinGet 发布之后不久，开源软件包管理工具 AppGet 项目作者 Keivan Beigi 发文宣布 AppGet 项目“死亡”，矛头直指微软的 WinGet 抄袭了 AppGet 。
AppGet 是一款开源的 Windows 软件包管理工具，它可以在 Windows PC 上自动安装软件。作者 Keivan Beigi 是一名居住在加拿大温哥华的软件工程师。去年 7 月，微软 App 事业部产品经理 Andrew Clinick 开始主动接触 Keivan，表达了微软对于 AppGet 的兴趣，并表示可以给 Keivan 提供在微软的职位，共同开发 Windows 系统的软件包管理项目。期间，Andrew 多次与 Keivan 以交换意见为由进行面试沟通，获取了 AppGet 的开发思路。去年 12 月，Keivan 在微软位于西雅图的总部接受了一整天的采访，事情本来正向着好的方向发展。
然而此后的 6 个月里，微软没有再与 Keivan 联系。直到今年 5 月，Keivan 突然收到了一封来自微软的邮件：“我想花点时间告诉你，我们非常感谢你的投入和见解。我们一直在构建 windows 包管理器，个预览版将于明天在 Build 上线，我们的包管理器也将是开源的，我们欢迎您的任何贡献。”随后，微软就在 Build 上发布了 WinGet 。
Keivan 表示，当他看到公告和 WinGet 的代码时感到很震惊。Keivan 认为 WinGet 的核心机制、术语、manifest 格式和结构，甚至是包存储库的文件夹结构都有 AppGet 的影子。而微软在公告中对于 AppGet 的描述仅有一句 “ ……还有许多其他类似 AppGet、Npackd 和基于 PowerShell 的 OneGet 包管理器。”
Keivan 对微软的做法感到非常失望，他认为微软抄袭他的开源软件没有问题，但希望自己的工作获得适当的荣誉。为此他发表了“AppGet 之死”一文，宣布放弃 AppGet 项目的更新，因为与微软这种量级的开发者竞争没有任何意义。
而对于微软面试官 Andrew 的做法，Keivan 在推特中表示：“我并不想站在 WinGet 的对立面，我也不希望任何人因这件事被解雇，我只是想分享我在这个故事中遭遇的一些不公平对待。”同时他也不想因为一些私人恩怨而毁掉一款好的产品，希望微软方面能给出适当的答复。
5 月 30 日，微软产品经理 Andrew 在微软官方发文回应称，“去年夏天，我们与 Keivan 进行了交谈，探讨了共同提供 Windows Package Manager 的潜在机会。AppGet 具有许多品质，确实可以帮助我们为 WinGet 找到更好的产品方向。” 承认了 Keivan 与 AppGet 对微软 WinGet 项目的贡献。“Windows Package Manger 的宗旨，是提供产品让社区和用户都能做出贡献并获得认可，这就是为什么我们要把它建立在 GitHub 上的原因；在过去的几天里，我们听取了社区的意见，并从中吸取了教训，显然我们有负于这个目标。更确切地说，我们辜负了 Keivan 和 AppGet 。这也是我们不愿意看到的。”
Andrew 还明确列出了数个 AppGet “帮助 WinGet 变得更好”的贡献：
- 在安装过程中没有脚本 —— 这是我们完全同意的，但不允许使用 MSIX
- GitHub 中丰富的清单定义—— 与应用程序的丰富声明性元数据相结合的开放能力对于实现目标非常重要
- 支持所有类型的 Windows 应用程序安装程序（包括 Win32/Win64）
- 存储库中应用程序的无缝更新
Andrew 表示希望借此机会表达对 Keivan 提供的 AppGet 的开发思路，以及 Keivan 与微软合作的感谢。并希望未来能和 Keivan 以及其他开发者合作，把 WinGet 做得更好。
尽管微软承认了 AppGet 的贡献并表达了谢意，但仍然没有表达对整件事情的歉意，有网友对此表达了不满。
甚至有网友表示“这下所有事情都明朗了，微软之所以开始向开源靠拢，是为了更方便窃取别人的劳动成果？”
其实网友的嘲讽并非心血来潮，早在 2018 年 6 月，微软就曝出过类似的抄袭事件。当时，开源的多包存储库管理工具 Lerna 作者 jamiebuilds 指责微软抄袭其代码。
jamiebuilds 表示，当自己在为 Babel 6 工作的过程中发现所有东西都拆分成漂亮的小插件包，但同时也就需要管理数十个软件包。因此，多包存储库管理工具 Lerna.js 应运而生。为让项目更好用，他对项目进行了 5 次重写，试图让架构更完善。之后某天，jamiebuilds 发现了微软推出了由许多小包组成的新的设计体系，本以为是微软在项目中使用了 Lerna ，结果发现他们使用的是一个名为 “Rush” 的东西。
Rush 或许是微软在 Lerna 的基础上开发的一个分支？抱着这样的想法，jamiebuilds 进一步查看了 Rush 的 Git 日志，结果发现该项目是在 Lerna 创建几天之后创建的，同时在文档中介绍了包括 Lerna 在内的其他类似工具，并称之为“不够好的产品”，俨然一副 “Rush 是比这些产品都要好的原创工具”的样子。为了解二者的区别，jamiebuilds 对两个项目进行了对比，结果发现 Rush 的文件和目录命名、核心功能的代码都与 Lerna 完全相同，甚至连提交记录都是一致的，也就是说 Rush 在不断复制 Lerna 的更改，然后声称其是微软开发的原创作品。
jamiebuilds 称自己主动与认识的微软员工联系说明此事后，对方感到震惊并道歉，但之后并没有任何来自官方的合理解释。Rush 项目也没有去更改许可证，或者添加补充说明，而是将提交记录进行了混淆，将代码位置进行移动，并重新编写或重命名了一些函数。
jamiebuilds 提到，如果是其他人做了这件事，他或许会有点不高兴但仍然把他忽略掉。但微软这样一个万亿市值的软件业巨头做这样的事情，这令他非常生气。
这件事后不了了之。值得一提的是，这一次 Lerna 的开发者并没有选择向微软屈服。如今 Lerna 在 GitHub 上拥有 23k 的 Star ，成为名副其实的明星项目，以至于微软后来在自己的项目 Just 中也把多包存储管理工具改为使用 Lerna 。
尽管这些抄袭事件或许只是由微软个别员工的不当做法引起，但微软的一系列抄袭行为还是引发了开源界的担忧。事实上，在开源社区中 fork 或 copy 某人的代码并不是什么坏事。但微软这种将别人的劳动成果归功于己的行为，显然违反了开源社区应有的道德规范，当然也违反了开源协议。
目前，很多软件工程师普遍对于开源协议仍然不够了解。有人甚至认为：开源软件就是免费的软件，所以我可以不受限制地随意使用。这显然是一种误解。
据业内律师介绍，开源软件与专有软件等闭源软件一样，都是受法律保护的。开源软件的著作权既没有放弃也没有过期，作者仍然是享有著作权的。除了著作权外，开源软件还可能被合同法、专利法、商标法等法律所规制。在著作权法的语境下，软件代码是类似于文字作品一样被保护的。在获得了一段源代码之后，默认情况下不能对该源代码进行改编或者再发行。而开源软件的特点在于，对于部分宽松开源协议（如 MIT、Apache 2.0）来说，在使用者承诺满足一定条件（通常包括给作者署名、附带许可证）的情况下，作者会放弃、让渡部分权利，例如允许使用者将代码改编或者再发行。
律师介绍，使用者所承诺的条件以及作者所放弃的部分权利形成了一种合同关系，更具体来讲是许可合同，在开源软件的情况下该合同也就是我们常说的开源许可证（License）。许可证是一种无需磋商的、标准化的公共合同，降低了合同的成本。
理论上来说，使用 MIT、Apache 2.0 等宽松开源许可证的项目，源代码可以被任何人拿去修改、分发、甚至闭源商业化，但必须保留项目原作者的著作权，也就是在源代码引用的部分保留项目作者的版权声明。以 MIT 许可协议为例，该协议规定，被授权人要履行 “在软件和软件的所有副本中都必须包含版权声明和许可声明” 的义务。也就是说，微软采用开源项目源代码开发新项目本身并没有任何问题，但其拒绝履行开源协议规定的“保护软件原作者著作权”的义务，事实上是违反了开源协议的。
尽管开源项目源代码受到开源协议的保护，但个人开发者维护的开源项目在面对微软这种级别的大型企业时，往往难以维护自己的合法权利。比较大型的开源项目通常会由专门成立的基金会来处理相关的法务问题，这些大型开源项目的版权属于中立的开源基金会，基金会享有处理项目授权、更改开源协议的权利，能够随时应对项目授权问题带来的法律纠纷。但个人开发的项目版权属于开发者自己，面对类似的侵权行为时，显然缺乏足够的人力和财力去处理这些法律纠纷，在大多数情况下只能闷声吃亏。因此，在个人开发者决定是否将自己的项目开源时，一定要衡量开源的利弊，充分理解各类开源许可证的各项条款，预测项目开源后可能带来的后果，三思而后行。同样的，当我们在使用开源项目的代码时，也要尊重原作者的劳动成果，自觉履行开源协议所要求的义务。
后，以《是谁在阻碍我们创新》中的一句话作为结尾：
“我们总是习惯去索取，而忘记了回馈。”
参考链接：
- Microsoft Continues to Attack and Steal From the Open Source/Free Software Communities
- 开源软件及其法律风险
相关文章