近日，开源项目AppGet作者KeivanBeigi与微软WinGet项目的“抄袭纠纷”事件迎来了最新进展。微软方面做出回应，坦承“辜负了Keivan和AppGet”，并肯定了Keivan与AppGet对微软新项目的贡献。

　　今年5月，微软在Build2020大会上发布了新的软件包管理工具WinGet，并将其开源。而就在WinGet发布之后不久，开源软件包管理工具AppGet项目作者KeivanBeigi发文宣布AppGet项目“死亡”，矛头直指微软的WinGet抄袭了AppGet。

　　AppGet是一款开源的Windows软件包管理工具，它可以在WindowsPC上自动安装软件。作者KeivanBeigi是一名居住在加拿大温哥华的软件工程师。去年7月，微软App事业部产品经理AndrewClinick开始主动接触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进行了交谈，探讨了共同提供WindowsPackageManager的潜在机会。AppGet具有许多品质，确实可以帮助我们为WinGet找到更好的产品方向。”承认了Keivan与AppGet对微软WinGet项目的贡献。“WindowsPackageManger的宗旨，是提供产品让社区和用户都能做出贡献并获得认可，这就是为什么我们要把它建立在GitHub上的原因；在过去的几天里，我们听取了社区的意见，并从中吸取了教训，显然我们有负于这个目标。更确切地说，我们辜负了Keivan和AppGet。这也是我们最不愿意看到的。”

　　Andrew还明确列出了数个AppGet“帮助WinGet变得更好”的贡献：

　　在安装过程中没有脚本——这是我们完全同意的，但不允许使用MSIX

　　GitHub中丰富的清单定义——与应用程序的丰富声明性元数据相结合的开放能力对于实现目标非常重要

　　支持所有类型的Windows应用程序安装程序（包括Win32/Win64）

　　存储库中应用程序的无缝更新

　　Andrew表示希望借此机会表达对Keivan提供的AppGet的开发思路，以及Keivan与微软合作的感谢。并希望未来能和Keivan以及其他开发者合作，把WinGet做得更好。

　　尽管微软承认了AppGet的贡献并表达了谢意，但仍然没有表达对整件事情的歉意，有网友对此表达了不满。

　　甚至有网友表示“这下所有事情都明朗了，微软之所以开始向开源靠拢，是为了更方便窃取别人的劳动成果？”

　　其实网友的嘲讽并非心血来潮，早在2018年6月，微软就曝出过类似的抄袭事件。当时，开源的多包存储库管理工具Lerna作者jamiebuilds指责微软抄袭其代码。

　　jamiebuilds表示，当自己在为Babel6工作的过程中发现所有东西都拆分成漂亮的小插件包，但同时也就需要管理数十个软件包。因此，多包存储库管理工具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、Apache2.0）来说，在使用者承诺满足一定条件（通常包括给作者署名、附带许可证）的情况下，作者会放弃、让渡部分权利，例如允许使用者将代码改编或者再发行。

　　律师介绍，使用者所承诺的条件以及作者所放弃的部分权利形成了一种合同关系，更具体来讲是许可合同，在开源软件的情况下该合同也就是我们常说的开源许可证（License）。许可证是一种无需磋商的、标准化的公共合同，降低了合同的成本。

　　理论上来说，使用MIT、Apache2.0等宽松开源许可证的项目，源代码可以被任何人拿去修改、分发、甚至闭源商业化，但必须保留项目原作者的著作权，也就是在源代码引用的部分保留项目作者的版权声明。以MIT许可协议为例，该协议规定，被授权人要履行“在软件和软件的所有副本中都必须包含版权声明和许可声明”的义务。也就是说，微软采用开源项目源代码开发新项目本身并没有任何问题，但其拒绝履行开源协议规定的“保护软件原作者著作权”的义务，事实上是违反了开源协议的。

　　尽管开源项目源代码受到开源协议的保护，但个人开发者维护的开源项目在面对微软这种级别的大型企业时，往往难以维护自己的合法权利。比较大型的开源项目通常会由专门成立的基金会来处理相关的法务问题，这些大型开源项目的版权属于中立的开源基金会，基金会享有处理项目授权、更改开源协议的权利，能够随时应对项目授权问题带来的法律纠纷。但个人开发的项目版权属于开发者自己，面对类似的侵权行为时，显然缺乏足够的人力和财力去处理这些法律纠纷，在大多数情况下只能闷声吃亏。因此，在个人开发者决定是否将自己的项目开源时，一定要衡量开源的利弊，充分理解各类开源许可证的各项条款，预测项目开源后可能带来的后果，三思而后行。同样的，当我们在使用开源项目的代码时，也要尊重原作者的劳动成果，自觉履行开源协议所要求的义务。

　　最后，以《是谁在阻碍我们创新》中的一句话作为结尾：

　　“我们总是习惯去索取，而忘记了回馈。”

　　相关阅读：

　　《微软回应“剽窃AppGet”：肯定原作者贡献》