事件概述 - 开发者Philip Laine指控微软在未充分沟通和署名的情况下，复制并推出了与其个人开源项目Spegel高度相似的项目Peerd [1] - 事件起因于微软主动联系开发者讨论Spegel项目，但在后续沟通停滞，开发者于KubeCon大会上发现微软推出了类似项目Peerd [7][8] - 开发者在Peerd项目代码中发现了大量与Spegel相同的示例代码、函数签名、注释以及包含其前雇主信息的测试用例 [9][11] - 微软项目仅在README文件底部以“灵感来源”致谢，被开发者认为署名归属不足 [1][8] - 该事件在开发者社区引发了关于开源伦理、开发者权益以及大公司与独立维护者关系的广泛讨论 [1][16][17] 涉及项目详情 - **Spegel项目**：由Philip Laine开发，是一个无状态的集群本地OCI注册表镜像系统，专为Kubernetes设计，采用P2P网络实现镜像缓存与共享 [4][5] - **项目背景**：为解决客户Kubernetes集群因镜像仓库服务中断导致的频繁宕机问题而创建，旨在避免可扩展性问题并减少运维负担 [4] - **项目状态**：采用MIT许可证，在GitHub上拥有超过2.3k星标，89个分支，被拉取超过1440万次，并持续维护更新 [5][15] - **Peerd项目**：由微软Azure推出，定位为面向Kubernetes集群的容器内容P2P分发工具，声称新增了Spegel设计范围之外的artifact streaming功能 [8][21] 核心争议与指控 - **代码复用争议**：Peerd项目被指大量复用Spegel的代码，包括函数注释都原封不动，但未在代码文件中充分保留原始许可证和版权声明 [11][12] - **许可证合规性质疑**：虽然Spegel采用宽松的MIT许可证，允许复制和修改，但条款要求保留原始许可证和版权声明，微软被指未完全遵守 [11] - **沟通与合作质疑**：开发者曾积极协助微软工程师部署并解答问题，期待合作，但微软在推出竞品前未进一步沟通，被质疑缺乏诚意 [7] - **社区影响**：微软的品牌影响力导致用户混淆Spegel与Peerd，给原项目维护者带来解释负担并稀释了其项目的关注度 [14] 各方回应与行业讨论 - **微软官方回应**：由Cloud Native Ecosystem团队的Lachlan回应，承认在署名归属上存在失误并致歉，已提交PR为相关文件补充许可证头和贡献标注 [19][21] - **回应解释**：微软称创建Peerd是为了加入artifact streaming功能，并理解该功能可能超出Spegel原设计范围 [21] - **开发者社区反应**：许多开发者对微软的解释不买账，质疑其行为实质是违反许可证规定的“盗版”，并批评大公司缺乏社区精神 [17][18][21] - **行业模式讨论**：事件引发对当前开源许可模式的反思，有观点呼吁建立属于社区的“社区型开源许可”，以保护独立开发者免受大公司“拥抱、扩展、消灭”策略的影响 [17][18] 事件影响与后续 - **对维护者的影响**：开发者一度感到价值被剥夺并考虑放弃维护，但最终选择继续发展Spegel项目 [14][15] - **项目持续发展**：Spegel持续获得关注，开发者启用GitHub赞助功能以资助开发，并考虑修改项目开源许可证作为保护手段 [15] - **行业警示**：事件被视为独立开源维护者与大型企业共存困境的典型案例，引发了在投资下滑和许可证变更背景下，如何维护健康开源生态的广泛思考 [15][17]