Resources/transformer.jar 随 exe 分发并在 JVM 内执行 HMCL 的 GPL-3.0 代码，仓库内无 GPL 声明与 HMCL 署名

[lfstartwq]

Note:证据收集和本文起草使用了LLM辅助，已由人工审核，如果有错误请指出，谢谢

结论

Plain Craft Launcher 2/Resources/transformer.jar 内的类构成 HMCL 某 GPL-3.0 组件的演绎作品。
它随 PCL 的 exe 分发，并由 ModLauncher 通过 SPI 在用户 JVM 内实际执行。仓库内没有 GPL-3.0
许可全文，没有 GPL 声明头，也没有针对该组件的 HMCL 署名。

按 GPL-3.0 §5(a)、§5(d)、§6，以及 HMCL 自己声明的 §7 附加条款，这些要求均未满足。

如果已经存在书面授权（issue/PR 记录、邮件，或任何形式的 HMCL 授权），请直接贴出来，
本条即降级为「授权记录未随代码入库」，争议即刻结束。

一、分发与执行链路

环节	位置
文件	Plain Craft Launcher 2/Resources/transformer.jar
工程引用	Plain Craft Launcher 2/Plain Craft Launcher 2.vbproj:840
嵌入 exe	My Project/Resources.resx:172-173，资源名 Transformer（ResXFileRef → System.Byte[]）
运行时释放	Modules/Minecraft/ModMinecraft.vb:2175-2178（依赖名含 transformer-discovery-service 时）
加载	jar 内 META-INF/services/cpw.mods.modlauncher.serviceapi.ITransformerDiscoveryService 内容为 org.jackhuang.hmcl.HMCLTransformerDiscoveryService，由 ModLauncher 经 SPI 在 JVM 内加载执行

产物坐标，便于独立复核：

大小       2243 字节
SHA-256    ea5756fec2e06d5aa5824b54f9c26ae46a7ab43ca9a57e747f1f63e1269f7dad
git blob   3ea51be50926e0b72ac87e7c8e73086edbbd6f04
引入提交   b0b0229（2022-07-27「上传公开代码」），此后未被触及

二、上游来源与许可

• 仓库：HMCL-dev/HMCL（核实于 HEAD 59bcc7fe6，2026-09-22）
• 许可：GPL-3.0。LICENSE 为 35149 字节 / 674 行的原版未修改 GPLv3，
  SHA-256 3972dc9744f6499f0f9b2dbf76696f2ae7ad8af9b23dde66d6af86c9dfb36986
• 源文件：minecraft/libraries/HMCLTransformerDiscoveryService/src/main/java/org/jackhuang/hmcl/HMCLTransformerDiscoveryService.java，
  SHA-256 698e81f946440da2f8135d2ed756b8450e9b9f5d647681597e430c32415cf002
• 该文件第 1–17 行为标准 GPL-3.0 声明头，署名
  Copyright (C) 2020 huangyuhui <huanghongxun2008@126.com> and contributors
• HMCL 另在 docs/README.md:69-77 声明两条 GPLv3 §7 附加条款：分发修改版须以合理方式
  更改软件名或版本号；以及不得移除软件中显示的版权声明（依 GPLv3 7(b)）

编译成 .class 恰好剥掉了这段声明头。 jar 内的 META-INF/MANIFEST.MF 只有 25 字节，
内容为 Manifest-Version: 1.0，不含任何许可或版权信息；而 HMCL 自身的 tasks.jar 会向
MANIFEST 注入 Created-By: Copyright(c) 2013-2020 huangyuhui.，PCL 的 MANIFEST 里没有。

这就是在二进制里搜不到 GPL 三个字的原因。不是没有义务，是构建过程把声明丢掉了。

三、认定依据

1. SPI 接口本身不含 HMCL 专有信息

minecraft/libraries/HMCLTransformerDiscoveryService/lib/modlauncher-4.1.0.jar 内的
ITransformerDiscoveryService，经 javap -p 反编译，全部内容为：

public interface cpw.mods.modlauncher.serviceapi.ITransformerDiscoveryService {
    public abstract java.util.List<java.nio.file.Path> candidates(java.nio.file.Path);
}

接口只强制一个方法名 candidates，此外没有任何 HMCL 专有的信息。

2. 常量池与源码的对应关系

class 常量池共 2480 字节，major=52。与源码逐项对应：

class 常量（索引）	源码位置
CANDIDATES (22)	L31 私有静态字段名
hmcl.transformer.candidates (73)	L31 System.getProperty(...) 字面量
java/lang/System (104)、getProperty (105)	同上
candidates (31)、(Ljava/nio/file/Path;)Ljava/util/List; (32)	L34 方法签名
Signature (35)、泛型签名 (36)	L34
gameDirectory (33)	L34 形参名
lambda$candidates$0 (37)、(Ljava/lang/String;)Ljava/util/stream/Stream; (38)	L36 path -> {...}
path (41)	L36 lambda 形参名
e (39)、Ljava/nio/file/InvalidPathException; (40)	L39 catch (InvalidPathException e)
java/io/File (79)、pathSeparator (80)、split (81)	L35
java/util/Arrays (83)、stream (84)、flatMap (92)、Collectors (94)、toList (95)、collect (97)	L35/L42
java/nio/file/Paths (99)、get (100)、of (102)	L38/L40
cpw/mods/modlauncher/serviceapi/ITransformerDiscoveryService (78)	L20 import + L30 implements
SourceFile (45)、HMCLTransformerDiscoveryService.java (46)	文件名
<clinit> (44)	L31 静态初始化

3. 按能否由 SPI 接口推出分层

上表各项的证据分量差别很大：

标识符	能否由 SPI 接口推出	证据分量
hmcl.transformer.candidates (73)	否，HMCL 专有配置键	强
org/jackhuang/hmcl/HMCLTransformerDiscoveryService (76)	否，SPI 服务文件由 PCL 自己写入，类名是 PCL 的自由选择	强
CANDIDATES (22)	否，但 static final 惯例即为此命名	弱
gameDirectory (33)	否，但为接口形参名的自然照抄	弱
path (41)、e (39)	否，但为 Java 中最常见的标识符	很弱
candidates (31)	是，接口强制	零

认定依据是前两行。hmcl.transformer.candidates 是 HMCL 专有的配置键，只出现在源码 L31，
接口里没有任何线索能推出它；包名与类名同样不在接口中，而 PCL 本可自选命名。

后四行我不作为依据。path、e、gameDirectory 都属 Java 常见或惯例命名，巧合重现完全可能。

4. 另外三项一致性观察

• 编译目标：HMCL build.gradle.kts 写死 sourceCompatibility/targetCompatibility = "1.8"，
  class major=52 即 Java 8，吻合
• SPI 文件行尾：HMCL 源码树内该文件为 51 字节 LF（git 索引 i/lf），jar 内同一文件为
  52 字节 CRLF。HMCL 的 .gitattributes 规定 * text=auto eol=lf，唯一强制 CRLF 的是 *.bat，
  所以 HMCL 自身构建流程不可能产出 CRLF
• MANIFEST：缺少 HMCL gradle 必注入的 Created-By 与 Implementation-Version，
  说明未走 HMCL 的 jar 任务

这三项都只能证明该 jar 并非 HMCL 构建流程的产物。ModLauncher 4.1 运行于 Java 8，
实现者都会选 8；Windows 下独立编写的同名文件同样是 CRLF；独立实现者也不会去跑 HMCL 的
gradle。所以三项都不具备区分力，只作佐证。

四、我考虑过的另一种解释

最合理的质疑是：类名是被 SPI 契约逼出来的，加载链按这个名字找它，PCL 可能只是自己写了一个
同名实现。这个假说比我最初评估的更有解释力：

现象	独立重写能否解释
包名/类名 org.jackhuang.hmcl/HMCLTransformerDiscoveryService	能，服务文件内容由 PCL 自己写入
方法名 candidates	能，接口强制
major=52（Java 8）	能
SPI 文件为 CRLF	能，Windows 默认
MANIFEST 缺 gradle 注入属性	能
hmcl.transformer.candidates 系统属性键	不能，HMCL 专有，接口推不出来

所以我不声称排除了这个解释。但两种情况下所负的义务相同：

• 逐字编译自 HMCL 源码，构成演绎作品，GPL-3.0 §5/§6 义务成立；
• 读过 HMCL 源码后重写，同样构成演绎作品，义务同样成立；
• 唯有真正的净室实现（编写者从未见过 HMCL 源码）不构成演绎作品。而净室实现没有理由去读
  HMCL 专有的系统属性，也不会沿用 HMCL 的包名与类名。

五、涉及条款

条款	要求	状态
GPL-3.0 §5(a)	整体作品以 GPL-3.0 分发，并提供完整对应源码	未满足
GPL-3.0 §5(d)	分发时附许可全文，并保留所有声明	未满足，既无 GPL 文本，也无 HMCL 署名
GPL-3.0 §6	同上，为 §5 的落地要求	未满足
HMCL §7 附加条款之二	不得移除软件中显示的版权声明	未满足，MANIFEST 无 Created-By，无任何版权声明
HMCL §7 附加条款之一	分发修改版须更改软件名或版本号	条件性，仅在确有修改时适用，我未确定是否修改

作者重叠检查：PCL 与 HMCL 无主体关系，故上述推论成立。

六、我查过的授权记录

为避免把「没找到」误当成「不存在」，列出检索范围：

• HMCL 仓库全树 1635 个条目，无 NOTICE / CREDITS / THIRD-PARTY / COPYING；
  docs/README.md 全文零处提及 PCL、bangbang93 或第三方启动器
• HMCL-dev/HMCL 中提及 PCL 的 117 条 issue/PR，全部是功能请求、缺陷报告或竞品比较
• Meloong-Git/PCL 中同时提及 HMCL 与 GPL 的 issue，0 条
• 全站搜索 HMCLTransformerDiscoveryService，仅 5 条命中，全部在 HMCL 自己仓库内
• HMCL 代码内提及 PCL 仅 3 处：JavaManager.java:454（缺陷 issue 引用）、
  ModAdviser.java:49（识别 PCL.ini）、I18N_zh_Hans.properties:1520（联机功能文档）

以上都是公开可查的范围。私域沟通（邮件、QQ 等）我无从查证，只能由你们确认。

七、本 issue 不主张什么

• 未做反汇编。 以上为常量池对齐、debug 符号、编译目标版本、资源行尾四类证据，属高置信，
  但不是哈希级的同一性证明。若认为仍不足，可补充更多可复现的验证。
• 不推断主观意图。「未随代码入库任何 GPL 声明」是事实陈述。为何如此、是否知情，
  本 issue 不作判断。
• 不声称排除了独立重写的可能，见第四节。
• 若已有书面授权，请贴出，本条即降级为记录缺失，无需改动代码。
• 本 issue 只针对这一条。 同批审查还有其他条目，会另行单独提交。

八、可能的整改

1. 补齐 GPL-3.0 义务：保留 GPL 声明头、随附 GPL-3.0 全文、提供对应源码与可复现构建脚本，
   并在关于页署名 HMCL + GPL-3.0。
2. 或请 HMCL 将该模块发布为正式 artifact，改为按需下载。HMCL 内部用的坐标是
   org.jackhuang.hmcl:transformer-discovery-service，但它从未被发布到任何公开仓库：
   org/jackhuang/ 在 Maven Central 为 404，org/glavo/hmcl 下 10 个 artifact 中也没有它。
   顺带一提，HMCL 自己的做法也是内嵌，该子模块的 jar 任务产物由
   HMCLCore/build.gradle.kts:46-51 打进 assets/game，运行时从
   /assets/game/HMCLTransformerDiscoveryService-1.0.jar 读取（GameLibrariesTask.java:192）。
   所以内嵌本身不是分歧点，差别在于 PCL 侧的声明与署名完全缺失。
3. 无论采用哪种，都需要一个承载 GPL-3.0 全文的第三方声明文件，目前仓库内不存在此类文件。

关于页 PageOtherAbout.xaml 已有成条的署名机制，可参考 LWJGL Unsafe Agent 条目
（:588 组件名、:589 版权与许可、:591 源码链接、:593 许可链接）。本组件看起来是从
这套机制里漏掉的，补署名的边际成本很低。

[lfstartwq]

更正正文的两处
第五节「作者重叠检查：PCL 与 HMCL 无主体关系，故上述推论成立」——这句错了
两边提交记录里有 6 个账号重叠。结论不变：这6 个账号在对方仓库的提交数都是 0，是普通贡献者，没有代表对方授权的能力。
第二节「编译成 .class 恰好剥掉了这段声明头」——写成了事实，和第四节「不声称排除了独立重写的可能」矛盾，当时我并没有确定是编译产物还是独立实现，所以第五节 §5 那几行不该标「未满足」