Madeira项目GPL与专有库兼容设计：Madeira Converter Exception完全解读
【免费下载链接】MadeiraRun x86-64 Windows PC games on jailed iOS via FEX-Emu + Wine + DXMT项目地址: https://gitcode.com/GitHub_Trending/mad/Madeira
Madeira 是一款能在 iPhone 上免越狱运行 x86-64 Windows PC 游戏的开源项目，它通过 FEX-Emu 指令翻译、Wine 模拟环境和 DXMT 图形转译实现 Windows 游戏兼容。本文完整解读它的许可设计：GPL-3.0-or-later 主许可如何与 Apple 专有动态库共存，核心就是那份名为Madeira Converter Exception（Madeira 转换器例外）的附加许可条款。
一个项目里其实藏着五六套许可
Madeira 的主仓库采用GPL-3.0-or-later（见 LICENSE 与 COPYING），但完整的应用还包含大量上游组件，每个组件保留自己的许可。项目用 THIRD-PARTY-NOTICES.md 逐条记录，许可证原文集中在 LICENSES/ 目录：
| 组件 | 上游许可 | Madeira 中的状态 |
|---|---|---|
| Wine 分支 | LGPL-2.1-or-later | 静态链接，LGPL 义务生效 |
| FEX-Emu / DXMT fork | MIT | 上游保持 MIT，Madeira 的修改为 GPL-3.0-or-later |
| rpmalloc fork | 0BSD | 上游保持 0BSD，作者修改为 GPL-3.0-or-later |
| GnuTLS / Nettle / GMP / FFmpeg | LGPL 系列 | 静态链接，源码与构建脚本全部入库 |
| Apple Metal Shader Converter | Apple 专有协议 | 以 dlopen 动态加载，仅限着色器转换用途 |
| 转换器头文件 | Apache-2.0 | 随源码树分发 |
选择 GPL 而不是更宽松的许可，目的很明确：衍生作品必须保持开源（动机详见 THIRD-PARTY-NOTICES.md 的 "Why GPL-3.0-or-later" 一节）。而 LGPL 刻意允许专有程序链接受覆盖代码，不符合这个意图。
核心矛盾：GPL 代码与 Apple 专有库相遇
问题出在 Direct3D 12 支持上。游戏的 DXIL 着色器需要转换成 Metal 库，Madeira 使用 Apple 官方的Metal Shader Converter（libmetalirconverter.dylib）在运行时完成这项工作。这是一个专有二进制：
- 它由 Apple 的许可协议管辖，不是开源的；
- 协议第 2.B 条允许分发该动态库，但仅限着色器转换目的（METAL-SHADER-CONVERTER-AGREEMENT.txt）；
- 按 GPL-3.0 的默认规则，GPL 代码与专有库组合后的"结合作品"会要求提供组合体的全部对应源码——包括 Apple 库的源码，这显然不可能。
也就是说，不加特殊条款，这个应用根本不能合法分发。
关键解法：GPL-3.0 第 7 条的"附加许可"
GPL-3.0 第 7 条允许版权方在标准条款之外附加许可。LICENSE-EXCEPTION.md 正是这样一份附加许可（additional permission），即 "Madeira Converter Exception, version 1"（2026-09-16 拟定，2026-09-24 正式采纳）。它的要点：
- 允许分发组合体：如果你将程序与
libmetalirconverter.dylib（任何版本）、或 Apple 的 Metal、Foundation、UIKit 等系统框架（包括修改版）链接或组合，许可方额外授权你分发结果； - 源码义务有边界：对应源码只需包含程序本身的代码，无需包含 Apple 库的源码；
- 不改变 Apple 许可：这些库仍受 Apple 自己的协议约束，该附加许可不及于它们；
- 可移除：按 GPL-3.0 第 7 条，你在分发副本时也可以移除这份附加许可。
仓库里还有一个工程化细节：.githooks/pre-push钩子在例外条款未正式采纳前会拒绝向远程推送，确保公开版本永远带着生效条款。
为什么例外条款"只能覆盖一部分代码"？
这是整个设计中最容易被忽略、却最关键的一环。附加许可只能由被覆盖代码的版权持有人授予。所以 LICENSE-EXCEPTION.md 的 "Scope and authority" 一节划出了清晰的边界：
✅ 例外覆盖的范围
- 主仓库中的 Madeira 应用与工具（作者自有版权）；
- madeira-d3d12 原生 Direct3D 12 运行时（同一作者，其 LICENSE 载有相同条款）；
- FEX、DXMT fork 以及 rpmalloc fork 中Madeira 作者的修改（上游 MIT/0BSD 代码本身不需要例外）。
❌ 例外无法覆盖的范围
- 上游 Wine 代码：早先的 Wine fork 曾按 LGPL-2.1 第 3 条整体转为 GPL-3.0-or-later，这一转换对那份副本不可逆，作者已无权再为它附加任何例外。为此项目专门准备了
madeira-lgpl分支：以上游 wine-11.4 为基线，将 51 个 Madeira 提交按序挑回、重新以 LGPL-2.1-or-later 发布，完整溯源记录在 docs/wine-lgpl-provenance.md； - Apple 库本身：永远只受 Apple 协议约束。
🔑 换句话说：不是"给 Wine 找个例外"，而是"让 Wine 回到 LGPL 分支，让例外只落在作者自己能授权的那部分代码上"——这就是 GPL 与专有库兼容设计里最精妙的分工。
分发时随附的义务清单
即使有了例外条款，分发构建好的应用仍需履行一揽子义务（详见 docs/LICENSING.md）：
- LGPL 静态链接义务：Wine（LGPL 分支）、GnuTLS、FFmpeg 等静态链接库要求提供完整对应源码、LGPL 副本，并让接收方能够重新链接修改后的库版本。为此项目把 GMP/Nettle/GnuTLS/FFmpeg 的未修改上游源码包和 SHA-256 校验和直接入库（THIRD-PARTY-NOTICES.md "Corresponding source" 一节）；
- Apple 协议 2.D 条：转换器不得在非 Apple 设备上使用，不得作为服务对外提供——Madeira 恰好只在 Apple 设备上运行，天然合规；
- 版权声明：每个 fork 保留上游版权声明，应用包内携带
licenses/目录（GPL-3.0、例外条款、LGPL、MIT、0BSD、LLVM 文本及 THIRD-PARTY-NOTICES.txt）； - 微软 VC++ 运行库明确不分发：MSVC 运行库只能在微软条款下原样再分发，仓库已将其移出跟踪，构建时需按 tools/fetch-vcruntime.md 自行提供。
另外文档也诚实地说明了 GPL做不到的事：不覆盖通过 Madeira 运行的游戏本身（那是独立作品）、不禁止他人独立重写、也不能收回 FEX/DXMT 已以 MIT 发布的代码授权。
新手速记：5 个要点带走 📌
| # | 要点 |
|---|---|
| 1 | 主许可GPL-3.0-or-later，目标是让所有分发出去的衍生作品保持开源 |
| 2 | GPL 代码 + 专有 Apple 转换器 = 默认不可分发，靠GPL-3.0 §7 附加许可破局 |
| 3 | Madeira Converter Exception 只豁免"组合分发"的源码义务，不改变Apple 库自身的专有性质 |
| 4 | 附加许可只能由版权持有人授予 → 上游 Wine 必须走LGPL 分支（madeira-lgpl）绕开已转 GPL 的副本 |
| 5 | 分发构建产物时须履行 LGPL 重链接、源码供应、声明随附等义务，文档均标注待律师终审 |
想深入阅读，建议按此顺序浏览：LICENSE-EXCEPTION.md（例外条款原文）→ THIRD-PARTY-NOTICES.md（组件许可清单）→ docs/LICENSING.md（组装应用的义务清单）→ docs/wine-lgpl-provenance.md（Wine LGPL 分支的逐提交溯源）。这套"主许可 + 窄范围附加许可 + 上游保持原许可"的分层设计，是 GPL 项目引入专有二进制依赖时可参考的完整范本。
【免费下载链接】MadeiraRun x86-64 Windows PC games on jailed iOS via FEX-Emu + Wine + DXMT项目地址: https://gitcode.com/GitHub_Trending/mad/Madeira
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
