Unity 的开源双重标准：VLC 的封禁

Unity 的 Asset Store 封禁与政策理由

• Unity 的提供方条款明确按名称禁止 Asset Store 资产中使用 GPL 和 LGPL，以及“类似”的 copyleft 许可证。
• 一些评论者认为这是合理的风险管理：Unity 会成为受 LGPL 义务约束的再分发者，而它不想承担这种合同或审计负担。
• 另一些人则认为这过于谨慎，甚至对 copyleft 怀有敌意，目的是让游戏开发者觉得许可“无摩擦”，因为他们期望商店资产能在所有平台上即插即用。

LGPL、链接与应用商店

• 讨论的重点在于 LGPL 到底要求什么：
  • 如果你修改了一个 LGPL 库，就必须提供源代码；用户必须能够用修改后的版本重新链接。
  • 动态链接是常见的合规路径，但如果你提供对象文件或等效材料，静态链接也可以合规。
• 应用商店（iOS、Android、主机）让这件事复杂化：代码签名、DRM 和商店规则常常阻止终端用户替换库，这可能使严格遵守 LGPL 在实践中变得不可能。
• 有人认为，如果修改在“技术上可行”，LGPLv2 也许仍然兼容，即便很难实现（例如侧载、越狱）；也有人说那实际上已经被“tivoization”搞坏了。
• 对于通过这类商店分发 LGPL 代码是否早已普遍不合规，存在分歧。

选择性执法与双重标准指控

• 文章声称，VLC 的 Unity 资产因为 LGPL 被封禁，但许多其他 Unity 资产据称在没有后果的情况下也包含 LGPL 依赖（例如 FFmpeg）。
• 评论者指出，Unity 自己据称在编辑器和运行时中也使用 LGPL 组件；一些人认为这就是双重标准，另一些人则回应说，Unity 控制着自己的构建/分发流程，而第三方资产并非如此。
• 还有不少人认为封禁体现了懒惰：最省事的法律路径就是把被举报的资产踢出去，而不是与对方一起处理合规问题。

对 VLC 帖子和新商店的反应

• 一些读者认为文章在后半段拐去推广一个新商店显得很突兀，像“标题党”或广告；另一些人则认为这只是自然的“我们被封了，所以这里是我们的替代方案”叙事。
• 文章强调 Unity 插件本身仍然是开源的；付费产品覆盖预编译二进制和支持服务。

更广泛的主题

• 关于“传染性许可”与“copyleft”的争论，有人反对把“viral”当作贬义词。
• LGPL（v1 时代）的原始作者指出，当时并没有预见到应用商店和签名二进制；他认为 iOS 风格的平台与 LGPL 的用户修改目标在根本上不相容。
• 更广泛的批评还包括应用商店权力、任意式审核，以及 Unity 近来的领导层和商业决策。