Armbian 构建框架 GPL 合规实践：xiaomi-sheng 镜像随附 libssc 源码全解析
Armbian 构建框架 GPL 合规实践：xiaomi-sheng 镜像随附 libssc 源码全解析
导读
本文以 packages/bsp/xiaomi-sheng/source/README.md 为核心，剖析 Armbian 官方构建框架（bu/build）在面向小米平板 Xiaomi Pad 6S Pro（代号 xiaomi-sheng）定制镜像时，如何通过"二进制包 + 对应源码随附"的方式满足 GNU GPL 分发义务。读完本文，你将理解：为什么预编译的 libssc deb 包必须附带源码、git archive 产出的源码包保留了哪些内容、子模块为何被有意排除，以及 Debian 风格版权文件（DEP-5）如何记录许可证与来源信息；同时结合构建脚本，掌握这些文件在镜像制作流程中的实际落地方式。
一、背景：xiaomi-sheng 镜像与 libssc 的角色
xiaomi-sheng 是 bu/build 仓库中针对小米平板 Xiaomi Pad 6S Pro 的板级配置，对应文件为 config/boards/xiaomi-sheng.csc。该平板基于 Qualcomm SM8550 八核 SoC，构建框架为它定制了 edge / bleedingedge 内核、ABL 启动镜像与完整的板级 BSP 包（board-specific package）。
libssc（Library to expose Qualcomm Sensor Core sensors）是 Qualcomm 传感器核心（Sensor Core）的用户空间访问库，负责将 SoC 内部的传感器数据暴露给上层系统。在 xiaomi-sheng 镜像中，它通过本地 deb 包 libssc_0.4.2-1_arm64.deb 安装进 rootfs。构建脚本中可以看到这一安装动作：
# config/boards/xiaomi-sheng.csc
install_deb_chroot "${SRC}/packages/bsp/xiaomi-sheng/libssc_0.4.2-1_arm64.deb"
install_deb_chroot "${SRC}/packages/bsp/xiaomi-sheng/xiaomi-sheng-thp_0.3.9_arm64.deb"
install_deb_chroot 会把 deb 复制进 rootfs 并通过 apt-get 安装，从而自动解析 bluez、libprotobuf-c1 等仓库依赖（见 xiaomi-sheng.csc 中注释）。
二、为什么必须随附源码：GPL 分发义务
libssc 以 GPL-3.0-or-later 许可证发布。GPL 的核心义务之一在于：任何以二进制形式再分发 GPL 软件的人，都必须向接收方提供对应的完整源代码，并且不得加以额外限制。
因此，bu/build 仓库虽然以二进制 deb 的形式分发 libssc，但同时在 packages/bsp/xiaomi-sheng/source/ 目录下随附了与二进制完全对应的上游源码。这正是 source/README.md 开篇所强调的定位：该目录"shipped the corresponding source"，使再分发 GPL 许可的 libssc 二进制符合 GNU GPL 的要求。
需要澄清的是：同一镜像中安装的另一个 deb 包
xiaomi-sheng-thp（NT36532E 触控主处理器守护进程）使用的是 Apache-2.0 许可证，其授权协议允许直接以二进制形式再分发而无需随附源码。因此整个 xiaomi-sheng BSP 中，只有 libssc 需要源码伴随分发——这正是该 source 目录存在的唯一且明确的原因。
三、上游元数据：可追溯的版本与来源
source/README.md 中记录了完整的上游溯源信息，这是 GPL 合规中"来源可追溯"的关键部分：
| 元数据项 | 值 |
|---|---|
| 项目 | libssc（Library to expose Qualcomm Sensor Core sensors） |
| 上游仓库 | codeberg.org/DylanVanAssche/libssc |
| 版本 | 0.4.2 |
| 提交 | 300a2a070e6dca5618334fd31d2516dc50bce8aa |
| 许可证 | GPL-3.0-or-later |
记录到具体 commit 而非仅仅版本号，意味着源码包与二进制 deb 之间可以建立精确到单个提交的对应关系。任何拿到镜像的用户都能依据该 commit 从上游仓库逐字节核验二进制是否由这份源码构建。
这份元数据同样被结构化为 Debian 风格版权文件 packages/bsp/xiaomi-sheng/source/libssc-0.4.2-copyright，采用 DEP-5 机器可读格式：
Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: libssc
Upstream-Contact: Dylan Van Assche
Source: https://codeberg.org/DylanVanAssche/libssc
Version: 0.4.2
Upstream-Commit: 300a2a070e6dca5618334fd31d2516dc50bce8aa
Files: *
Copyright: 2022-2026 Dylan Van Assche
License: GPL-3.0-or-later
该文件以 Files: * 声明覆盖全部源码文件，版权归属为上游作者，并完整引用 GPL-3.0-or-later 的授权文本，让自动化许可证扫描工具（如 licensecheck、reuse 等）也能正确识别。
四、源码包内容与 git archive 的取舍
source/ 目录下随附两个文件：
libssc-0.4.2.tar.gz—— 上游在v0.4.2标签处的精确源码快照，由git archive生成；libssc-0.4.2-copyright—— Debian 风格版权记录（见上一节）。
README 明确说明了 tarball 的内部构成：包含 libssc 的 meson.build 构建系统、src/、data/、utils/、mocking/、tests/ 与 docs/，以及根部的 LICENSE 和 README.md。
其中值得注意的实现细节是子模块处理策略：tarball 由 git archive 生成，因此 .gitmodules 中引用的 git 子模块（libqmi、mocking/qrtr）不会被展开。这两者分别属于可选的测试/模拟工具链，被有意排除在源码包之外。这一设计有两个合理考量：
- 减小源码包体积，只保留构建与运行 libssc 本体所必需的代码；
- 避免 GPL 合规义务被不必要地扩散到非必需的第三方测试依赖上（前提是这些子模块不参与二进制构建链路）。
从合规角度理解：GPL"对应源码"（Corresponding Source）指的是用于构建所分发二进制的源码。既然 libqmi 与 mocking/qrtr 是可选测试/模拟工具，不进入 libssc 二进制的编译路径，那么将其排除并不会造成合规缺口。README 对此的披露也体现了透明原则——明确告知使用者"排除了什么、为什么排除"。
五、从构建脚本看源码合规的落地
将 source/README.md 放回整个 BSP 构建流程中，可以更清楚地看到"二进制 + 源码"配套分发的完整链路：
- 打包阶段：
libssc_0.4.2-1_arm64.deb与xiaomi-sheng-thp_0.3.9_arm64.deb存放在 packages/bsp/xiaomi-sheng/； - 安装阶段：config/boards/xiaomi-sheng.csc 中
post_family_tweaks__xiaomi-sheng_enable_services通过install_deb_chroot将两者装入 rootfs，并启用qbootctl、usbgadget-rndis、bt-fixed-mac、sheng-ucm-init等服务； - 源码随附阶段：
source/目录随仓库一并发布，与二进制 deb 保持同版本（0.4.2）、同 commit（300a2a0...）的严格对应。
换言之，任何从该仓库构建 xiaomi-sheng 镜像并对外分发的人，天然就带上了满足 GPL 义务的源码包，无需额外手工操作——合规性被内置进构建框架本身，这是 bu/build 作为官方构建框架在许可证治理上的一个具体实践。
顺带一提，同目录下的其他 BSP 文件（如 sheng-ucm-init.sh、90-alsa-dsp.conf）与本文主题无直接关系：前者负责在启动早期加载 ALSA UCM 配置以启用扬声器功放（cs35l43 x4），后者用于 WirePlumber 禁用 ACP 探测以避免音频回退到 Dummy Output。它们与 libssc 同属 xiaomi-sheng 板级定制，但许可证性质不同，这正是 README 特意区分 libssc（GPL）与 xiaomi-sheng-thp（Apache-2.0）的原因。
六、小结与合规检查清单
围绕这份 README，可以提炼出一份面向其他 GPL 组件接入 Armbian 构建框架的合规检查清单：
- [ ] 二进制 deb 是否记录了精确的上游 commit，而非仅仅版本号；
- [ ] 源码 tarball 是否由
git archive从该 commit 生成，确保与二进制严格对应； - [ ] 是否随附了 DEP-5 格式的 copyright 文件，完整声明许可证与版权归属；
- [ ] 若排除了子模块，是否在文档中明确说明排除对象与理由，并确认它们不参与二进制构建链路；
- [ ] 同镜像中的其他包若使用宽松许可证（如 Apache-2.0），是否在文档中说明"仅此组件需源码随附"以划定义务边界。
这些做法保证了 Armbian 生态在分发预编译闭源不可行的 GPL 组件时，既能保持镜像的即装即用体验，又能完整履行开源许可证义务。