Clarification on MIT license vs. underlying AtomUI (LGPL-3.0) compliance when publishing with Native AOT / 关于在 Native AOT 发布场景下 MIT 协议与底层 AtomUI (LGPL-3.0) 合规边界说明 #25

Hi there! First off, huge thanks for open-sourcing TKCode.Arc. After playing around with the Gallery and reading through the design docs, I'm really impressed—it's rare to see an Avalonia library nail this kind of clean Linear/Vercel aesthetic, subtle hairline borders, and smooth ArcMotion spring physics. StreamMark is also super well-executed.

While evaluating the library, I noticed a licensing detail in the dependency tree and wanted to ask for some clarification:

The repo itself is MIT-licensed, while THIRD-PARTY-NOTICES.md notes the dependency on AtomUI under LGPL-3.0. Looking at the NuGet dependency graph, aside from a few standalone packages like Fonts and Terminal, the main TKCode.Arc package and foundational packages like Core and Icons all directly depend on AtomUI.

Under standard .NET JIT deployment, referencing an unmodified AtomUI NuGet package outputs separate .dll files, which naturally satisfies the dynamic linking requirement in LGPL-3.0 Section 4.d.1. However, if a closed-source application uses .NET Native AOT (PublishAot=true) to compile into a single native binary, it hits a compliance deadlock:

• Static linking & inlining limits: The ILC compiler performs whole-program trimming, cross-assembly inlining (triggering LGPL-3.0 Section 3), and static linking into a single executable, meaning end users can no longer swap out the LGPL library (see GNU FAQ: static vs. dynamic linking).
• Standard LGPL AOT workarounds don't work for UI libraries:
  1. Shipping relinkable .obj files or IL assemblies alongside the binary per Section 4.d.0 exposes the closed-source application to trivial decompilation, defeating a primary purpose of Native AOT.
  2. Compiling the LGPL library into a standalone native shared library via [UnmanagedCallersOnly] per Section 4.d.1 isn't architecturally viable for UI controls. Since controls inherit from AvaloniaObject and must share the same managed GC heap and visual tree as the host app, we can't pass managed C# object references across a C ABI boundary.
  3. Additionally, deploying to platforms with mandatory code signing restrictions triggers the anti-tivoization clause in LGPL-3.0 Section 4.e (referencing GPL-3.0 Section 6).

Could you help clarify a few points around this?

1. Compliance for closed-source Native AOT builds: If a closed-source project uses TKCode.Arc and publishes a single-file binary with PublishAot=true (without shipping .obj / IL relinking artifacts), does that violate the underlying AtomUI LGPL-3.0 license? Would that scenario require purchasing a commercial license from AtomUI, or is there any static linking exception planned?
2. Decoupling foundational packages: Is TKCode.Arc intended to permanently build on top of AtomUI as its foundation, or are there any plans to decouple foundational packages like TKCode.Arc.Core and Icons so they can run on pure Avalonia under pure MIT terms?
3. README license note: Since the top-level MIT badge might give developers the impression that the library can be freely statically linked in closed-source Native AOT builds, would it make sense to add a brief note in the README.md License section mentioning the transitive AtomUI (LGPL-3.0) obligations?

Thanks again for bringing such a polished UI library to the Avalonia ecosystem!

作者好！首先非常感谢开源 TKCode.Arc。在体验了 Gallery 并阅读设计文档后觉得非常惊艳——目前在 Avalonia 生态里，很少见到能把干净的 Linear/Vercel 极简美学、细腻的微边框质感以及丝滑的 ArcMotion 弹簧物理动效结合得这么到位的组件库，StreamMark 的完成度也非常高。

在评估该库的过程中，我留意到依赖树上的一个开源协议细节，想向你请教并确认一下：

仓库本身采用 MIT 协议，同时在 THIRD-PARTY-NOTICES.md 中注明了依赖采用 LGPL-3.0 协议 的 AtomUI。查看 NuGet 依赖关系图可以发现，除 Fonts、Terminal 等少数独立包外，TKCode.Arc 主包以及 Core、Icons 等基础包均直接依赖了 AtomUI。

在标准的 .NET JIT 部署模式下，引用未修改的 AtomUI NuGet 包会输出独立的 .dll 文件，这天然满足 LGPL-3.0 第 4.d.1 条的动态链接要求。但如果闭源应用采用 .NET Native AOT (PublishAot=true) 编译为单一原生二进制文件，就会遇到合规死锁：

• 静态链接与内联限制： ILC 编译器会执行全局裁剪、跨程序集内联（触发 LGPL-3.0 第 3 条）并静态链接为单个可执行文件，这意味着终端用户无法再自行替换其中的 LGPL 库（参见 GNU FAQ：静态链接与动态链接的区别）。
• 常规的 LGPL AOT 绕行方案对 UI 库不适用：
  1. 若按 第 4.d.0 条随二进制文件附带可重链接的 .obj 文件或 IL 程序集，会导致闭源应用极易被反编译，失去了使用 Native AOT 的核心意义之一。
  2. 若按 第 4.d.1 条通过 [UnmanagedCallersOnly] 将 LGPL 库编译为独立的原生动态库，在 UI 控件架构上并不可行。因为控件继承自 AvaloniaObject，必须与宿主程序共享同一个托管 GC 堆和视觉树，我们无法跨越 C ABI 边界传递托管的 C# 对象引用。
  3. 此外，若部署到具有强制代码签名限制的平台，还会触发 LGPL-3.0 第 4.e 条（引用 GPL-3.0 第 6 条）中的反硬件锁定（Anti-Tivoization）条款。

能否帮忙澄清以下几个问题：

1. 闭源 Native AOT 构建的合规性： 如果闭源项目使用 TKCode.Arc 并通过 PublishAot=true 发布单文件二进制程序（且不附带 .obj / IL 等重链接产物），这是否违反了底层 AtomUI 的 LGPL-3.0 协议？这种场景下是否需要向 AtomUI 购买商业授权，或者后续是否有提供静态链接豁免（Static Linking Exception）的计划？
2. 基础包解耦规划： TKCode.Arc 的定位是长期构建在 AtomUI 底座之上，还是未来有计划将 TKCode.Arc.Core 和 Icons 等基础包解耦，使其能在纯原生 Avalonia 上以纯粹的 MIT 协议运行？
3. README 协议说明建议： 鉴于仓库顶部的 MIT 徽章可能会让开发者误以为该库可以在闭源 Native AOT 构建中自由地静态链接，是否在 README.md 的 License 章节补充一句简短说明，提示底层 AtomUI (LGPL-3.0) 的传递性协议约束会更合适？

再次感谢为 Avalonia 生态带来如此精良的 UI 组件库！