编程与软件工程mfkl.github.io
Unity 的开源双重标准：封禁 VLC
Unity's Open-Source Double Standard: The Ban of VLC
2024 — 2025，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章讲述 VLC 相关团队被 Unity 资源商店封禁的经历：Unity 以 LGPL 许可证不兼容为由禁止其插件上架，作者认为这是对开源许可证的误解和双重标准，并在文中宣布推出自己的商店作为替代渠道。文章还指出 Unity 自身和大量 Unity 资产都在使用 LGPL 依赖，禁令逻辑难以自洽。
为什么经久不衰：它触及 LGPL 与应用商店分发模式的深层冲突，以及大平台对开源许可证的误解，对游戏开发者和开源社区至今仍有参考价值。
HN 评论精选
为文章辩护：自建商店的公告放在事件文章里合理，LGPL 经 PInvoke 完全可用于 Unity，且不应滥用“标题党”一词。
我觉得这里的负面反应令人费解。他们被商店下架了，于是推出了自己的商店，并把公告写进这篇讲述起因的文章里——这通常就是该做的事，否则读者会以为他们没有出路，后续公告触达的人也会更少。另外，C# 集成一般用 PInvoke 吧？这是最动态的链接方式，LGPL 库没有理由不能用于 Unity 游戏。VideoLAN 是长期做开源、备受尊敬的组织，我不信他们会如此根本性地误解自己使用的许可证。最后拜托：别把一切不喜欢的东西都叫“标题党”，这篇文章主要就是在讲封禁事件。
jchw查看英文原文
I find the negative reception here confusing. Seems to me they got removed from a marketplace, so they launched their own. They put the announcement into an article about the thing that motivated what's being announced. That is generally what you do, because otherwise the article would leave you with the impression that you have no option going forward, and a follow-up would reach fewer people. Just doesn't make sense. Also, I'm no Unity expert, but C# integrations generally use PInvoke right? It's the most dynamic of linking, there's really no inherent reason LGPL libs can't be used in Unity games. At worst, Unity should make sure you know your obligations, but I don't understand the necessity of a blanket ban. I'd be very surprised if VideoLAN, a well-respected organization that has been doing open source work for a very long time, had such a fundamental misunderstanding of the software licenses they use. Either way, a request: please stop using "clickbait" to describe literally anything you don't like. The article is chiefly about their ban, even the announcement is. By all means, critique whatever you want, but that's simply not what clickbait is. Clickbait is more like "actually we didn't get banned, But..."
指出 LGPL 的用户替换权与应用商店封闭分发模式存在真实冲突。
LGPL 赋予最终用户用修改版替换 LGPL 部分的权利，而用户显然无法修改下载的 Unity 应用。所以使用 LGPL 库的软件似乎确实无法在 Unity 或大多数现代应用商店上分发并保持合规。它不是病毒式的，但确实赋予了应用商店分发模式下用户本来没有的权利。
ghusbands查看英文原文
The LGPL gives end users the right to replace the LGPLed part with a modified version, and users presumably cannot alter parts of a downloaded Unity app. So it does seem that software using an LGPL library cannot be distributed on Unity or most any modern app store and still be in compliance with the LGPL. It's not viral, but it does give users rights that aren't natural under the app store distribution model.
LGPL 作者现身说法：该许可证诞生于动态链接时代，无法适应签名应用商店，但这未必是 Unity 的责任。
我当年写 LGPL v1（1991 年前后）时，完全无法想象应用商店和签名二进制这类东西。动态链接为用户升级库代码提供了简单途径。既然用户在 iOS 等平台上没有更新库的自由，我认为无法在这些平台部署 LGPL 代码；而使用 Unity 的卖点之一就是跨平台，这意味着除非只部署在真正的操作系统上，否则你得另找库。但这算 Unity 的问题吗？
gumby查看英文原文
When I originally wrote the LGPL (v1, back around 1991) we could not imagine anything like an App Store or signed binaries. Dynamic linking provided an easy way for users to upgrade the library code. Since the user doesn’t have the freedom to update the libs on ios etc I don’t see how you could deploy LGPL code on those platforms; since one of the points of using unity is its cross-platform support, that suggests you’d have to find another library unless you were only deploying on real OSes. But is that Unity’s problem?
认为 Unity 法务混淆了 GPL 与 LGPL，禁令本意可能只针对 GPL。
显然是法务团队得到了错误信息并写进了协议。正如文章所说，不仅大量 Unity 资产使用 LGPL 依赖，Unity 自己也在用，甚至用 Unity 做的已发售游戏也包含 LGPL 资产。本意可能只是想筛掉 GPL 依赖。科普一下：GPL 和 LGPL 差别巨大——LGPL 专门设计为允许专有应用在满足条件时链接开源库而不必开源整个应用；GPL 则要求整个衍生作品都以 GPL 授权并公开源码。
jdlyga查看英文原文
Clearly, the legal team got bad information and made it part of their agreement. Like the article says, not only do tons of Unity assets use LGPL dependencies, but Unity uses LGPL assets themselves. Even shipped games created using Unity use LGPL assets. The intent was probably only to screen out GPL dependencies. For those who don't know, there's a huge difference between the GPL and LGPL. The LGPL is specifically designed to allow proprietary applications to link to open-source libraries without requiring the proprietary application’s source code to be released, provided certain conditions are met. This is particularly true when the LGPL-licensed library is used in a way that allows users to modify or replace it independently of the proprietary application. In contrast, the GNU General Public License (GPL) has stricter requirements. If your software incorporates GPL-licensed code, the entire derivative work must also be licensed under the GPL, which includes releasing the source code.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选