【开源许可与版权工程】红芯浏览器与「国产内核」往事：披皮事件的工程复盘

一、事件背景与时间线

1.1 红芯浏览器事件经过

2018 年 8 月 15 日，红芯时代（北京）科技有限公司发布红芯浏览器企业版，并同步宣布完成由晨兴资本领投的 C 轮 2.5 亿元融资。官方宣传材料中多次出现”自主研发的中国芯”、“打破美国垄断”等表述，并声称产品基于”自主研发浏览器内核 RedCore”。

8 月 16 日凌晨，多名网友对安装包进行解压和分析，在安装目录下发现了 chrome.dll、chromium_version_info.h 以及版本字符串 49.0.2623.110。该版本对应 Chromium 2016 年前后的稳定版本。消息在微博、微信朋友圈和技术论坛迅速扩散，IT之家、36kr、虎嗅、钛媒体等媒体相继跟进报道（见参考资料 [3]）。

8 月 17 日，红芯时代通过官方渠道发布《声明》，承认产品基于 Chromium 开发，但强调在企业应用层（SSO 集成、安全管控、国密算法支持）进行了大量创新，并表示此前的宣传措辞存在不当之处（见参考资料 [4]）。

从法律角度看，红芯并未违反 Chromium 所使用的 BSD-3-Clause 开源协议——该协议允许以任何形式（含闭源商业产品）分发修改版。事件的核心争议在于商业宣传层面，而非开源合规层面。

1.2 Chromium 的协议结构

Chromium 项目本身的主体代码采用 BSD-3-Clause 授权（也称三条款 BSD 许可证）。该协议对再分发的核心要求是：

1. 源码或二进制再分发时必须保留原始版权声明；
2. 文档或宣传材料中如果引用了原始软件名称，需要事先获得书面许可（此条款在实践中争议较大，通常理解为不得用”Chromium”本身为商业产品背书）；
3. 不得使用贡献者名称为衍生产品做背书。

Chromium 同时内嵌了大量第三方组件，这些组件有各自的许可证，包括 MIT、Apache 2.0、LGPL、MPL 等。在分发 Chromium 衍生品时，这些第三方组件的声明也必须随包附带。

红芯安装包中是否附带了完整的版权声明，公开信息中未见明确说明。但从协议角度，这是一个可以通过规范的合规流程解决的问题，而非根本性的违规。

1.3 BSD-3-Clause 允许”换皮”的法律含义

红芯事件在舆论场上引发了巨大争议，但如果把讨论严格限定在”是否违反开源协议”这一层面，答案基本是否定的。要理解这一结论，必须先厘清 BSD-3-Clause 这一许可证的设计哲学及其与 GPL、MIT、Apache 2.0 等协议的关键差异。

1.3.1 闭源分发的明确允许

BSD-3-Clause 的核心特征是允许”任何形式的再分发”，包括二进制形式、闭源形式乃至商业销售。协议文本中没有 Copyleft 条款（Copyleft 指要求衍生品也以相同许可证发布的条款，典型代表为 GPL）。这意味着：

• 接受者可以对源码进行任意修改，而无须将修改后的源码回馈社区；
• 接受者可以将修改后的版本以闭源二进制方式进行商业分发；
• 接受者可以在修改版基础上构建完全专有的商业产品，并对用户收取授权费用；
• 接受者无须披露内部构建脚本、补丁集、或定制化代码。

这一设计是 BSD 家族协议的历史传统，可追溯至加州大学伯克利分校 20 世纪 80 年代 BSD UNIX 的发布策略。相比之下，GPL 从设计之初就强调”以许可证作为杠杆，迫使衍生作品同样开源”，两者的哲学差异根深蒂固。

1.3.2 修改后无须公开源码

对 Chromium 这类采用 BSD-3-Clause 的项目而言，下游团队可以对渲染引擎、JavaScript 引擎、网络栈做任何程度的修改，且：

• 修改后的代码可以作为公司的内部资产，不在任何公开仓库、邮件列表或 Issue 中披露；
• 修改后的版本可以永不 rebase 到上游，形成长期 fork；
• 修改后的二进制产品可以不附带任何源码，用户购买后也无权索要。

这与 Linux 内核（GPLv2）的情况完全不同。Linux 内核的分发者必须向接受者提供获取”对应源码”（Corresponding Source）的途径，无论通过随盘附送、FTP 链接还是书面承诺。而 Chromium 的分发者没有这一义务。

1.3.3 仅要求保留版权声明

BSD-3-Clause 的实际合规义务极其轻量，主要集中在”声明完整性”上：

• 源码再分发时，须在源码中保留原始版权行与许可证声明；
• 二进制再分发时，须在文档、“关于”页面、或附随材料中重现该版权声明与免责声明；
• 对于 Chromium，具体实现是 chrome://credits 页面，列出所有第三方组件的许可证与版权声明。

对红芯这类产品，理论上只要在”关于”对话框中保留了 Chromium 的版权声明与许可证文本，即满足协议的字面要求。在 2018 年的公开讨论中，并未出现红芯完全剥离所有版权声明的证据。

1.3.4 非背书条款的实践含义

BSD-3-Clause 相对于 BSD-2-Clause 多出的”第三条款”是所谓”非背书条款”（Non-endorsement Clause），原文大意是：未经事先书面许可，组织或贡献者的名称不得用于为衍生产品做背书或推广。这一条款在工程实践中的含义常被忽略，但其实际边界包括：

• 不得在产品宣传中声称”由 Google Chromium 团队背书”；
• 不得在商业材料中暗示产品是 Chromium 项目的”官方版本”、“认证版本”；
• 不得使用 Chromium 贡献者个人姓名来为产品站台；
• 不得使用与 Chromium 项目高度相似的 Logo、配色、视觉元素，使用户误以为产品与 Chromium 项目存在官方关联。

第三条款本身是一条关于名誉权与商标法的约束，严格讲属于合同法范畴。违反非背书条款通常不会立即触发协议终止，但可能在商标诉讼或反不正当竞争案件中成为不利证据。

1.3.5 与其他常见协议的权限对比

下表横向比较 BSD-3-Clause 与 MIT、Apache 2.0、GPL 在几个关键合规点上的差异（简表，仅作工程参考，不构成法律结论）：

从表中可见，BSD-3-Clause 与 MIT 在授予接受者的自由度上几乎等价，两者均属于”高度宽松型”许可证。Apache 2.0 在宽松的基础上增加了专利授权和专利反诉终止，更适合商业场景下的大型项目（如 Kubernetes、Hadoop、Android AOSP 上层框架）。GPL 则是完全不同的哲学路线，以”源码可得性”为核心诉求。

1.3.6 “换皮”并非贬义——协议意义上的中性评价

回到红芯事件：从纯粹的协议角度，“基于 Chromium 换皮”是一个中性事实描述，并非违法行为，也不构成开源合规问题。类似的产品在全球大量存在，Microsoft Edge（基于 Chromium，2020 年切换）、Brave、Vivaldi、Opera（2013 年切换）等主流产品都可以被归入”基于 Chromium 的衍生品”。

真正的争议点在于：

• 商业宣传层面：将”基于 Chromium 换皮”包装为”完全自主研发浏览器内核”，可能触发《反不正当竞争法》《广告法》中的虚假宣传条款，以及《消费者权益保护法》的相关规定；
• 资本市场层面：在融资材料、路演文件中夸大技术独立性，可能触及《证券法》的信息披露要求（若该主体进入公开资本市场）；
• 政府采购层面：在信创目录申报、国产化替代方案评估中，若夸大”自主可控”程度，可能构成对采购方的欺诈或不诚信投标。

工程团队在评估此类产品时，应将”协议合规”与”商业宣传诚信”两个维度分开讨论：前者是一个法律问题，后者是一个商业伦理与监管问题。

二、Chromium 魔改识别工程方法

工程团队在评估一款浏览器产品时，可以通过以下多个层次的技术手段判断其是否基于 Chromium。

2.1 用户界面与版本信息

最直接的方法是访问特殊地址：

chrome://version

Chromium 内核内置了这个内部地址，会显示完整的版本号和构建信息。即使产品对 UI 进行了深度定制，这些内部页面通常仍然存在。常见的内部诊断地址包括：

chrome://version        -- 内核版本、用户数据目录、命令行参数
chrome://flags          -- 实验性功能开关
chrome://gpu            -- GPU 信息与 WebGL 支持
chrome://net-internals  -- 网络栈详情
chrome://components     -- 内置组件版本

如果上述地址可以访问，基本可以确认内核为 Chromium（或基于 Blink/V8 的派生，如 CEF、Electron）。

2.2 User-Agent 字符串分析

Chromium 衍生浏览器即使修改了 UA 字符串，通常也会保留 Chrome/X.X.X 的部分，因为大量网站的服务端特性检测依赖于此。通过 JavaScript 访问 navigator.userAgent 或通过开发者工具的网络面板观察请求头，可以看到原始 UA。

典型格式如下：

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.110 Safari/537.36

版本号 Chrome/49.0.2623.110 中，49 即主版本号，可以和 Chromium 的历史版本表对应（Chromium 49 于 2016 年 2 月到 3 月发布）。

2.3 文件与目录结构指纹

Chromium 安装后产生的文件结构具有较强的特征性。关键文件和目录包括：

chrome.dll / libchrome.so  -- 主体引擎库
chrome.exe / chrome         -- 主进程
resources/                  -- 资源包
locales/                    -- 本地化文件（包含大量 .pak 文件）
Extensions/                 -- 扩展目录
User Data/                  -- 用户数据目录（Windows 路径结构）
chromium_version_info.h     -- （源码目录中，标注版本信息）
CHROMIUM_BUILD               -- （源码目录中的构建标记文件）

即便应用程序重命名了主可执行文件，chrome.dll 这一核心库文件的名称在历史版本中变化不大，是识别 Chromium 来源的有效指纹。

2.4 二进制字符串扫描

通过 strings 命令（Linux/macOS）或等效工具对主二进制文件进行字符串提取，通常可以找到大量 Chromium 特征字符串：

strings chrome.dll | grep -i chromium
strings chrome.dll | grep "Chromium [0-9]"
strings chrome.dll | grep "blink/"
strings chrome.dll | grep "v8/"

典型输出示例（说明性，非实测）：

Chromium 49.0.2623.110
blink/public/web/
v8/include/v8.h
chrome/browser/
src/third_party/WebKit/

2.5 网络行为特征

Chromium 内核会向特定 Google 域名发出后台请求（Safe Browsing、Variations、Extensions 更新等）。即使产品关闭了部分服务，若内核未经深度改造，仍可能通过网络流量分析观察到这些特征请求。

2.6 源码构建信息

对于能获取源码的项目，可以检查：

chrome/VERSION              -- 版本号文件
build/util/LASTCHANGE       -- 最后一次提交信息（指向 Chromium 仓库）
chromium_version_info.h     -- 版本信息头文件

这些文件是 Chromium 构建系统自动生成的，在基于 Chromium 的项目中往往原样保留，除非团队有意删除。

2.7 DevTools 协议与 V8 版本指纹

前述方法主要依赖静态特征（文件、字符串、UA）。在更深入的鉴别场景下，可以通过运行时协议交互来获取更精细的指纹，其中最重要的是 Chrome DevTools Protocol（简称 CDP）以及 V8 引擎的内部版本信息。

2.7.1 CDP 协议与远程调试端口

Chromium 内核支持通过 --remote-debugging-port=9222（或任意端口）启动一个本地 HTTP + WebSocket 调试服务。所有未明确关闭该特性的 Chromium 衍生品，在加启动参数或修改配置后，通常都能暴露该接口。探测方法：

# 在启动命令行中加参数
/path/to/vendor-browser --remote-debugging-port=9222 --user-data-dir=./tmpprofile

# 探测元信息
curl http://127.0.0.1:9222/json/version
curl http://127.0.0.1:9222/json/list

/json/version 返回的 JSON 中包含 Browser 字段（形如 Chrome/120.0.6099.71）、Protocol-Version、V8-Version、WebKit-Version、User-Agent 等字段，是判断底层 Chromium 版本最权威的来源之一。若产品声称”完全自研内核”，却能响应 CDP /json/version 请求并返回 V8-Version，结论基本可以确定。

2.7.2 通过 Runtime.evaluate 获取 V8 版本

通过 CDP 的 WebSocket 通道下发 Runtime.evaluate，在页面上下文中执行 JavaScript 并回收结果：

{
  "id": 1,
  "method": "Runtime.evaluate",
  "params": {
    "expression": "JSON.stringify({ chrome: !!window.chrome, ua: navigator.userAgent })"
  }
}

V8 本身未直接暴露版本号给 JavaScript，但若进程可以通过 CDP 访问到 Debugger、Profiler 域，则可以进一步比对其方法签名与 V8 不同版本之间的差异。另外，许多 Chromium 构建会在 process.versions（Electron）或 chrome.runtime.getManifest()（扩展上下文）中直接暴露 V8 版本字符串。

2.7.3 chrome-extension:// URL Schema 与扩展生态

Chromium 内置扩展系统遵循 Chrome Extensions Manifest（V2 / V3）规范，其扩展页面使用 chrome-extension://<extension-id>/... 这一特定 URL Schema。判断方法：

• 在被测浏览器中安装一个合法的 Chrome 扩展（从 Chrome Web Store 离线下载 .crx，或手动 load-unpacked）；
• 如果能正常加载并通过 chrome-extension://... 访问扩展资源，则几乎可以确认其为 Chromium/Blink 派生；
• 若产品对扩展 Schema 做了重命名（如 vendor-extension://），可进一步检查其扩展 API 命名空间是否仍暴露 chrome.*。

少数 Chromium 衍生项目（如 Brave）会扩展或重写部分扩展 API，但核心 chrome.* 命名空间因兼容性原因基本保留。

2.7.4 Blink 与 V8 的 CSS/JS 指纹

Blink 与 V8 作为独立引擎，各自留有可在 JavaScript 层观察到的指纹：

• Blink 特有 CSS 前缀：-webkit- 与 -webkit-appearance 等属性在 Blink 中的行为细节与 Safari 的 WebKit 不完全相同，可通过测试已知行为差异（如 -webkit-line-clamp、overscroll-behavior 的具体回落行为）加以辨别；
• Blink DOM 接口：document.all 的 typeof 结果、InputEvent.inputType 的取值集合、ShadowRoot.innerHTML 的序列化细节在 Blink 与 Gecko/WebKit 之间存在可测差异；
• V8 JIT 特征：Function.prototype.toString 的输出格式、Error.stack 的栈帧格式、Symbol(@@toPrimitive) 的实现细节均具有 V8 指纹性；
• V8 错误消息：TypeError: Cannot read properties of undefined (reading 'x') 是 V8 较新版本的特定措辞，SpiderMonkey（Firefox）与 JavaScriptCore（Safari）输出的错误信息格式明显不同。

实践中可以构造一组”指纹测试脚本”，批量触发上述差异点，在几秒内完成对渲染引擎/JS 引擎身份的推断。

2.7.5 navigator.userAgentData 与 Client Hints

自 Chromium 89（2021 年）起，Chromium 引入了 User-Agent Client Hints（UA-CH），并通过 navigator.userAgentData 暴露结构化字段：

navigator.userAgentData.getHighEntropyValues([
  "architecture",
  "model",
  "platform",
  "platformVersion",
  "fullVersionList"
]).then(console.log);

fullVersionList 中会列出 "Chromium"、"Google Chrome" 或厂商自定义品牌，并附带具体版本号。即便厂商试图在 UA 字符串中隐藏版本，这一结构化接口仍可能泄露实际内核版本。Firefox 与 Safari 均未实现 navigator.userAgentData，因此该接口存在本身就是一个强 Chromium 指纹。

2.7.6 完整指纹识别清单

下表汇总了前文出现的各类识别方法，按取证强度排序，供工程团队在合规审计或选型时使用：

实践中，任意两条以上的强证据组合即可得出可靠结论。反之，若产品通过了全部 13 项且均未露出 Chromium 痕迹，则其”非 Chromium 内核”的声明可以获得初步支持（但仍不能排除是 WebKit/Gecko/自研的其他可能）。

三、Chromium 协议的合规要求与工程实践

3.1 BSD-3-Clause 的实际要求

BSD-3-Clause（也写作 Modified BSD License、New BSD License）是一份极为宽松的许可证。对于商业产品（含闭源分发）的核心要求：

对于 Chromium 衍生产品，合规的最小操作是：

1. 在产品的”关于”页面或安装目录中附带 LICENSE 文件；
2. LICENSE 文件中包含 Chromium 的版权声明及第三方组件的声明（Chromium 提供了完整的 LICENSE 汇总文件）；
3. 不在宣传材料中直接以”Chromium”名义背书，也不暗示得到了 Google 的官方支持。

3.2 第三方组件的处理

Chromium 包含超过 100 个第三方依赖，各自有不同的许可证。Chromium 仓库在 third_party/ 目录下维护了每个依赖的 README.chromium 文件，记录了名称、URL、版本、许可证类型和许可证文件路径。Chromium 官方提供了汇总脚本和生成工具来自动化这一过程。

对于基于 Chromium 的商业产品，建议通过以下工具辅助合规审查：

# 生成 Chromium 的许可证汇总（在 Chromium 源码目录中）
python tools/licenses/licenses.py credits > ABOUT_CREDITS.html

该命令生成的 ABOUT_CREDITS.html 是 Chrome 浏览器自身在 chrome://credits 页面展示的内容，包含所有第三方组件的声明。基于 Chromium 的产品应当以某种形式保留并展示这些声明。

3.3 营销宣传的边界

BSD-3-Clause 第三条（非背书条款）的实践含义：

• 允许：声明产品基于 Chromium 开源项目开发；声明使用了 Google Chromium 的技术基础；
• 允许：声明在 Chromium 基础上做了专项优化、定制开发；
• 需谨慎：在未经授权的情况下，在宣传材料中以 Chromium 名义背书（如”经 Chromium 官方认可”）；
• 工程/商业层面有风险：宣称产品为”自主研发内核”，若内核实质上是 Chromium（主要逻辑未改变），可能引发消费者保护层面的争议，以及投资人、客户的信任问题。

3.4 Chromium 相关商标与品牌的合规边界

除 BSD-3-Clause 文本本身的约束外，Google 针对 Chrome/Chromium 品牌与视觉元素另外发布了商标使用指引。工程团队在命名、包装衍生产品时，应同时遵守以下几点：

• 不得在产品名称中使用”Chrome”、“Chromium”作为主词（如”XX Chrome”、“Chromium Pro”类命名应避免）；
• 不得使用 Chrome 的经典四色图标或其近似变体；
• 在产品的版本号、内部页面（如 chrome://version）保留 Chromium 字样是允许的，因为这是技术实现层面的标识，不构成品牌使用；
• 在宣传材料中描述”基于 Chromium 开源项目”属于事实描述，不构成侵权；但不得以任何方式暗示官方合作关系。

3.5 内嵌编解码器与专利风险

Chromium 作为一个浏览器项目，涉及多项音视频编解码标准：

• H.264 / AVC：受 MPEG LA 专利池约束，商业分发需专利许可；
• H.265 / HEVC：受多个专利池约束，专利许可结构比 H.264 更复杂；
• AAC：受 MPEG LA 专利池约束；
• VP8 / VP9 / AV1：开放免版税标准（AV1 由开放媒体联盟推动）；
• Opus / Vorbis：免版税开放标准。

Google 发布的 Chrome 浏览器对 H.264/H.265/AAC 的支持，是由 Google 向 MPEG LA 统一支付专利许可费的结果。基于 Chromium 的衍生产品在默认启用这些编解码器时，并不自动继承 Google 的专利许可。工程团队在分发前应：

• 评估目标市场是否需要这些专有编解码器；
• 若需要，与 MPEG LA 或相关专利池单独商谈许可；
• 或关闭对应编解码器，仅保留 VP9 / AV1 / Opus / Vorbis 等开放格式；
• 对 Widevine DRM、Flash 等专有组件同理，Chromium 开源代码中并不默认包含 Widevine 二进制模块，分发者需单独向 Google 申请 Widevine 分发授权。

3.6 合规发版 Checklist

在每一次对外发版前，基于 Chromium 的产品应当至少完成以下检查：

[ ] LICENSE 文件已包含 Chromium BSD-3-Clause 原文
[ ] chrome://credits 或等效页面可访问并内容完整
[ ] 第三方组件许可证清单与 SBOM 一致
[ ] 专有编解码器（H.264/H.265/AAC）授权已落实，或已关闭
[ ] Widevine DRM 授权已落实，或已关闭
[ ] 产品名称与图标不涉及 Chrome/Chromium 商标侵权
[ ] 宣传文案经法务审阅，未暗示 Google 官方背书
[ ] 安全补丁对齐至上游 Chromium 最近三个版本以内
[ ] 内部诊断页（chrome://version）展示的基础版本与 SBOM 一致

Checklist 本身应作为 CI/发布流水线的阻塞项，不通过不得发版。

四、国产浏览器与桌面系统的开源合规现状

4.1 国产浏览器生态

在红芯事件后，国产浏览器的”内核来源”透明度问题引发了更广泛的讨论。以下是几类典型情况的梳理（信息来源：各厂商公开文档和公开报道）：

基于 Chromium 的国产浏览器：360 安全浏览器、QQ 浏览器、搜狗浏览器、猎豹浏览器等主流产品均明确基于 Chromium（或早期的 Webkit）。这些产品在宣传上通常不声称”自主内核”，合规层面争议较小。

声称自研内核的产品：需要从技术层面区分”基于标准构建自研渲染引擎”（如 Firefox 的 Gecko、Safari 的 WebKit 起源）与”基于 Chromium 源码大幅定制”两种情况。

政府采购合规场景：国家标准和政府采购要求中对”自主可控”有特定界定。工程团队在评估此类产品时，应以官方测评机构的评测结论为准，而非单纯依赖厂商自我描述。

4.2 深度操作系统（Deepin）与统信 UOS 的合规分析

深度操作系统（Deepin，现统信 UOS 的社区版）基于 Debian GNU/Linux。Debian 作为上游，其发行版管理遵循严格的 DFSG（Debian 自由软件指导方针）。

协议结构： - Linux 内核：GPLv2（Kernel syscall exception 适用，用户态程序不受 Copyleft 传染） - GNU 工具链（bash、coreutils 等）：GPLv3 - 桌面环境 DDE（Deepin Desktop Environment）：GPLv3，源码在 GitHub 公开 - 深度应用（深度文件管理器、深度终端等）：GPLv3，源码在 GitHub 公开 - 部分商业应用（WPS、微信 Linux 版等）：商业许可，不在发行版 GPL 组件范畴内

从 GPL 合规角度，Deepin/UOS 作为 Debian 衍生版，其开源组件的源码可通过官方 apt 源或 GitHub 仓库（github.com/linuxdeepin）获取，满足 GPLv2/GPLv3 的”对应源码提供”要求。

统信 UOS 的商业版本将部分企业功能以闭源方式实现，但这些功能与 GPL 组件的边界处理是否完全合规，需要结合具体版本和具体组件分析。统信软件（深度科技的商业主体）公开表示遵循相关开源协议。

4.3 麒麟操作系统（Kylin）的路径

麒麟操作系统存在两个独立品牌：银河麒麟（Kylin）由天津麒麟信息技术（原国防科大麒麟系统）主导，中标麒麟由中标软件（北京）主导，两者于 2019 年合并为麒麟软件有限公司。

麒麟（Kylin）基于 Ubuntu LTS 的衍生版本，内核为 Linux，桌面环境 UKUI 以 GPL 许可证在 GitHub 公开。麒麟软件在政府合规和等保测评方面通过了相关认证，其 GPL 组件的合规性可通过官方软件源核实。

4.4 中科曙光与华为欧拉（openEuler）的路径

中科曙光的曙光 Empyrean Linux 基于 CentOS/Red Hat 衍生路线，其 GPL 合规实践与通用 RHEL 衍生版基本一致。

openEuler（华为 2019 年开源，2021 年捐赠给开放原子开源基金会）基于 CentOS 7 演化，内核为 Linux。openEuler 在 Gitee 上完整公开源码，满足 GPL 的源码可获取要求。作为捐赠给开放原子基金会的项目，其治理架构和许可证合规性受到基金会规范约束。

五、深度 Deepin 的 Ubuntu→Debian 基线切换

深度操作系统（Deepin）是中国大陆投入最持久、知名度最高的桌面 Linux 发行版之一。其商业主体从”武汉深之度科技”演化为”统信软件（UnionTech）“，产品形态也从面向个人的 Deepin 扩展为面向政企信创市场的 UOS（Uniontech OS）。在十余年的发展历程中，Deepin 曾经经历过一次关键的上游切换：从基于 Ubuntu 转为直接基于 Debian。这一切换的工程动机、技术代价与合规收益，对于任何计划构建”本土化 Linux 发行版”的团队都有参考价值。

5.1 早期基于 Ubuntu 的历史阶段

Deepin 项目最早可追溯至 2004 年前后的 Hiweed Linux（基于 Debian），其由刘文欢等人发起，目标是打造一款”对中文用户友好的桌面 Linux”。2008 年前后，项目更名为 Linux Deepin，核心策略调整为基于 Ubuntu LTS 构建，以获取 Ubuntu 相对成熟的桌面体验和硬件兼容性。

这一阶段的典型特征：

• 以 Ubuntu LTS（如 10.04、12.04、14.04）为直接上游，使用 Ubuntu 的 APT 源作为基础软件仓库；
• 在 Ubuntu 基础上替换 Unity/GNOME 为自研的 DDE（Deepin Desktop Environment）；
• 通过中文化补丁、深度截图、深度影音等自研应用形成差异化；
• 版本号、发布节奏与 Ubuntu LTS 大致对齐。

采用 Ubuntu 作为上游的好处显而易见——Ubuntu 拥有更完善的硬件驱动（尤其是显卡与无线网卡）、更及时的商业驱动打包、更稳定的用户社区。对于一个资源有限的中小团队，“踩在 Ubuntu 肩膀上”比直接对接 Debian 要省力很多。

5.2 2015 年前后切换到 Debian 的技术原因

从 2014 年底到 2015 年，Deepin 逐步完成了从 Ubuntu 到 Debian 的基线切换。这一决策背后是一系列工程和合规因素的综合考量。

5.2.1 Ubuntu 引入的专有或半开源组件

Ubuntu 在 2010–2015 年前后主导了两项在社区中颇具争议的技术：

• Unity 桌面环境（2010–2017）：Canonical 自研，以 Compiz 作为合成器，代码由 Canonical 主导，社区参与度较低；
• Mir 显示服务器（2013 年起）：作为 Wayland 的替代方案由 Canonical 主导开发，与上游 X.Org/Wayland 社区存在路线分歧。

此外还有 Upstart（init 系统，最终被 systemd 取代）、部分 Canonical 自研的云/容器工具等。这些组件带来了三个问题：

1. 路线不稳定：Canonical 在市场反馈不佳时多次调整战略，Mir 从”默认显示服务器”改回”次选方案”、Unity 最终让位给 GNOME；
2. 社区生态脱节：大量上游应用优先适配 GNOME + Wayland，对 Unity + Mir 支持滞后；
3. 对于需要长期维护的商业发行版，每一次 Canonical 的技术转向都会造成下游的高昂迁移成本。

5.2.2 Debian 对 DFSG 的严格坚持

Debian 社区以 DFSG（Debian Free Software Guidelines，Debian 自由软件指导方针）为选包基准，将软件分为 main、contrib、non-free、non-free-firmware 四个区：

• main 区内的所有软件必须满足 DFSG 的九条标准，保证”无附加限制的再分发”；
• contrib 与 non-free 区只作为可选提供，不构成默认系统的一部分；
• Debian 的发布策略从协议角度最为纯粹，每一个 main 区的包都有明确的许可证出处。

对以政企采购为目标市场的 Deepin/UOS 而言，上游选择 Debian 意味着更易于构建完整的开源合规链条：每一个包的来源、协议、补丁都可以向 Debian 追溯，无须处理 Ubuntu 引入的 Canonical 专有组件的授权复杂性。

5.2.3 减少中间层的工程收益

Ubuntu 本身基于 Debian。一个典型的 Ubuntu 衍生版，其软件包路径是 Debian unstable → Debian testing → Ubuntu → Ubuntu Deepin，中间经过两到三次 rebase 与打包调整。直接基于 Debian 后：

• 维护链路缩短：bug 追踪与补丁同步只需对接 Debian 一端；
• 发布窗口更灵活：不再受 Ubuntu LTS 6 个月窗口与 2 年 LTS 周期的约束；
• 安全响应更直接：Debian 的 DSA（Debian Security Advisory）与 DLA（Debian Long Term Support）机制覆盖时间更长（Debian LTS 支持 5 年，ELTS 可达 10 年），对信创场景契合度更高；
• 减少”第三方补丁的第三方补丁”：Ubuntu 对 Debian 打的补丁，Deepin 原本需要在其上再打补丁；切换到 Debian 后减少了一层补丁栈。

5.3 统信 UOS 的 GPL 合规机制

切换到 Debian 为直接上游后，统信 UOS 在 GPL 合规层面具备了更清晰的链路。其主要合规机制包括：

5.3.1 官方源码镜像站

统信软件运营官方源码镜像（以实际官网信息为准）：

https://mirrors.uniontech.com/uos/

该镜像站通常同时提供：

• 二进制包仓库（deb 仓库，供 apt 使用）；
• 源码包仓库（deb-src 仓库，供 apt-get source <package> 使用）；
• ISO 镜像下载入口；
• GPG 签名与校验和文件。

对 GPLv2/v3 组件而言，“提供对应源码”的义务可以通过”在用户可访问的网络地址上持续提供源码”来满足。源码镜像站的长期可用性是 GPL 合规的关键抓手。

5.3.2 源码可追溯性的工程实践

在 Debian 打包体系下，每一个二进制 .deb 包都对应一个源码包（.dsc + .orig.tar.* + .debian.tar.*）。用户可以用一条命令获取任意已安装包的原始源码：

# 在 sources.list 中启用 deb-src 源后
apt-get source <package-name>

# 获取包含构建脚本的完整源码树
apt-get source --compile <package-name>

这一机制相比”用户需要发邮件向厂商索要源码”的做法，合规性显著更强，也显著减少了运营成本。

5.3.3 商业版与社区版的组件边界

UOS 有桌面社区版（Deepin）与商业版（UOS Desktop / UOS Server）两条线。二者在 GPL 合规上的处理原则是：

• 所有 GPL 组件（含 DDE 桌面、深度应用、Linux 内核补丁）无论在社区版还是商业版中均保持开源，源码公开；
• 商业版中的闭源增值模块（如统一管控平台、企业 AD 集成、部分国密模块）作为独立包提供，不以静态链接方式”传染”核心 GPL 组件；
• 商业版的”付费价值”主要来自服务与合规认证（等保测评、信创认证），而非 GPL 组件的闭源化。

这一模式与 Red Hat 的”RHEL 订阅制”有一定相似性：代码本身开源，商业价值来自发行版的集成、测试、认证与支持服务。

5.4 麒麟操作系统（Kylin）的历史与合规

麒麟操作系统的历史比 Deepin 更为复杂，涉及军工科研、国企改制与多个品牌合并。

5.4.1 国防科大起源（2001 年前后）

“麒麟”（Kylin）最早是国防科技大学（国防科大）主导的自研操作系统研究项目，时间约为 2001 年前后。早期版本”银河麒麟”面向军工与高性能计算场景，内核曾经尝试过 FreeBSD 路线，后切换为 Linux 内核。这一时期的目标用户主要是军工、国防、科研院所，商业化程度较低。

5.4.2 中标软件（NeoKylin）与麒麟软件的合并

与国防科大路线并行的，是”中标软件”（原”上海中标软件”、“北京中标软件”）运营的 NeoKylin（中标麒麟）。中标软件的 NeoKylin 基于 Red Hat / CentOS 路线，在政府 OA、电力、金融办公场景中占有相当份额。

2019 年，天津麒麟（银河麒麟主体）与中标软件合并，成立新的”麒麟软件有限公司”，两条产品线整合为”银河麒麟 V10”（面向党政军与信创）与”中标麒麟”（保留原有兼容性产品线）。合并后的麒麟软件成为中国电子信息产业集团（CEC）旗下的重要子公司。

5.4.3 UKUI 桌面的 GPL 合规

麒麟的桌面环境 UKUI（Ubuntu Kylin User Interface）是基于 Qt 构建的自研桌面，代码托管在 GitHub 的 ukui 组织下，采用 GPL 许可证。组件包括 ukui-panel、ukui-menu、peony（文件管理器）、kylin-video（视频播放器）等。

UKUI 最早出现于 Ubuntu Kylin 发行版（Canonical 官方认可的中文衍生版），后被麒麟软件继承并作为银河麒麟 V10 的默认桌面。UKUI 的 GPL 合规性可以通过 GitHub 公开仓库直接验证。

5.5 中科方德（NFSChina）与 RHEL 路线

中科方德软件股份有限公司（NFSChina，简称”方德”）的操作系统产品”方德桌面操作系统”与”方德服务器操作系统”走的是 CentOS/RHEL 衍生路线，这与 Deepin/麒麟（Debian/Ubuntu 系）形成对比。

主要背景：

• 中科方德与中国科学院软件研究所存在技术合作关系，具备科研背书；
• 产品线以服务器端为主，桌面端主要面向党政办公场景；
• 包管理采用 RPM + DNF/YUM，与 RHEL 生态兼容；
• 在 CentOS 停服后，方德的上游策略转向 CentOS Stream / RHEL 源码重建，并参与国内的龙蜥（Anolis OS）、OpenCloudOS 等替代项目生态。

从协议合规角度，方德作为 RHEL 衍生路线的厂商，继承了 RHEL 的 GPL 合规框架：srpms 源码包可以从官方源或镜像站获取，GPL 组件满足”源码可得”要求。

5.6 红旗 Linux 的历史路径

红旗 Linux 是中国大陆最早具备广泛知名度的商业 Linux 发行版之一，其历史有几个关键节点：

• 2000 年：北京中科红旗软件技术有限公司成立，背景是中科院软件所与上海联创等方面的联合投资；
• 2000–2010 年：红旗 Linux 桌面版与服务器版在政府与教育市场占有相当份额，曾短暂进入 OEM 预装渠道（与部分国产 PC 品牌合作）；
• 2014 年 2 月：中科红旗因经营问题宣布解散，这一事件在当时的国产操作系统领域造成了较大震动；
• 2014 年后：红旗品牌与部分资产由”中科红旗（北京）信息科技产业集团有限公司”接手，产品线重组，逐步基于 CentOS/Fedora 路线重新构建；
• 近年：红旗 Linux 更多以”信创工程参与方”的身份出现在公开材料中，具体产品路线以官方发布为准。

红旗 Linux 的兴衰对后来者的启示是：单纯依靠国产化政策红利而缺乏可持续商业模式与技术纵深的发行版难以长期存续。Deepin/UOS 与麒麟软件在商业化与技术投入两方面的持续投入，是其今天能够在信创市场立足的关键。

5.7 基线选择的工程权衡

综合上述历史经验，一个计划构建本土化 Linux 发行版的团队，在选择上游基线时通常面临以下权衡：

没有”最好的”基线，只有”最适合你团队能力与市场定位”的基线。

六、合规上游化（Upstream-First）vs 下游魔改

在”基于开源二次开发”这一光谱上，还存在另一个更深层的选择：对于自己做出的改动，是推动合入上游（upstream-first），还是保留在自己的 fork 中长期维护（downstream patch）。这一选择对工程团队的长期成本、安全态势与合规风险都有显著影响。

6.1 upstream-first 策略的工程含义

upstream-first（上游优先）是一种工程文化，核心原则是：任何对开源项目的修改，如果具备通用价值，应优先尝试提交到上游；只有在上游明确拒绝或不适合通用化的修改，才保留为本地补丁。

这一策略的典型实践：

• 提交前做同上游的规划对齐：通过邮件列表、RFC、Design Doc 与上游维护者沟通；
• 拆分大补丁为小的、可审查的独立 commit；
• 遵循上游的编码规范、测试要求、签名规则（DCO/CLA）；
• 积极响应 code review 反馈，做多轮迭代；
• 把合入上游作为一项核心 OKR，而不是”附加任务”。

对于企业而言，upstream-first 的长期收益包括：减少本地补丁维护成本、降低安全补丁回溯复杂度、提升在开源社区中的技术影响力、改善招聘品牌。

6.2 downstream patch 的典型问题

相反，长期维护大量 downstream patch 会积累以下问题：

• 安全补丁追踪困难：当上游发布 CVE 修复时，需要评估本地补丁是否与 CVE 修复冲突、是否需要重新实现修复；
• 合并冲突持续增长：随着上游代码演进，本地补丁与上游的 diff 距离越来越远，每次 rebase 的成本指数级上升；
• 社区分裂与兼容性问题：本地补丁可能改变了 API/ABI 行为，导致上游生态（插件、扩展、第三方驱动）不兼容；
• 许可证审计复杂度提高：每一个本地补丁都需要独立的许可证声明、贡献者追踪、专利清单；
• 知识转移风险：补丁作者离职后，维护者接手困难，“黑盒补丁”长期存在；
• 法律风险积累：对 GPL 项目，若本地补丁涉及第三方代码或与非 GPL 代码链接，可能产生合规瑕疵。

6.3 上游贡献 vs 下游魔改 的代价对比

6.4 “主动防御”型开源合规

把 upstream-first 作为开源合规的”主动防御”手段，意味着：

6.4.1 贡献代码给上游，减少 fork 维护成本

华为对 Linux 内核的贡献是一个典型案例。自 2010 年代中期以来，华为在 arm64 架构支持、调度器优化（如 CFS、EAS 相关补丁）、内核调试能力、文件系统等方向向 Linux 内核提交了大量补丁，近年来稳居 Linux 内核贡献者排行榜前列。这种上游贡献模式相比”直接 fork 一个华为内核并长期维护”的代价，差异是数量级的。

相对应的，企业可以在内部建立”upstream liaison”职能：由经验丰富的工程师专职负责与上游社区的沟通、补丁提交、冲突协调，把”合入上游”作为绩效目标。

6.4.2 CLA/DCO 在企业合规中的作用

• DCO（Developer Certificate of Origin，开发者原创声明）：由 Linux 基金会推广，开发者通过在 commit 末尾添加 Signed-off-by: 行声明”本提交由我原创或我有权提交”。Linux 内核、Kubernetes 等大量项目采用 DCO；
• CLA（Contributor License Agreement，贡献者许可协议）：由项目基金会或维护方与贡献者签署的正式法律文件，通常包含版权许可与专利许可条款。Apache 软件基金会、CNCF 大量项目采用 CLA。

企业在内部建立对应的流程：

• 对开发者外投代码进行 DCO/CLA 签署的内部审批；
• 维护贡献者名单与其代表公司签署的 CCLA（Corporate CLA）；
• 定期审计员工的外部贡献，避免合规瑕疵。

6.4.3 工程团队的决策树

对于任何一次”我要不要改一下这个开源组件”的决策，建议采用以下决策树：

(1) 这个改动是否能通用化（对其他用户也有价值）？
     是  → 进入 (2)
     否  → 作为本地补丁保留，严格控制范围

(2) 上游社区对这类改动的接受度如何？
     欢迎 → 走 upstream-first 流程
     保守 → 先发 RFC 试水，再决策
     明确拒绝 → 考虑替代方案（独立项目 / 插件机制）

(3) 是否涉及商标、专利、商业秘密？
     否 → 继续 upstream
     是 → 法务评估后决定；必要时替换为等价非商密实现

(4) 安全补丁是否必须自己先落地？
     否 → 等上游节奏
     是 → 本地打补丁 + 同步向上游提交，标记为"pending upstream"

(5) 改动是否影响 API/ABI？
     否 → 直接 upstream
     是 → 先与上游沟通兼容性策略，再提交

这一决策树的核心价值在于：把”改还是不改、怎么改”从个人偏好升级为团队级的工程治理。长期来看，这直接决定了一家企业在开源生态中是”消费者”还是”共建者”。

七、三个层次：自研、基于开源、换皮

5.1 概念厘清

红芯事件暴露了一个长期存在于技术宣传领域的模糊地带——“自主研发”究竟意味着什么？从工程和协议角度，可以区分以下三个层次：

层次一：从零自主研发（Greenfield）

完全由团队自行设计、实现的核心引擎，不依赖上游开源项目的代码库。典型例子：Mozilla 从 Netscape 代码库演化的 Gecko 渲染引擎，WebKit 最初由 Apple 基于 KHTML 开发并重构。

在浏览器内核领域，从零研发一个现代化的渲染引擎（支持 HTML5、CSS Grid、JavaScript JIT 等）需要数百工程师年的投入，几乎没有新进入者能独立完成。

层次二：基于开源进行实质性二次开发

以开源项目为基础，在核心逻辑上进行大量修改和扩展。典型例子：三星的 Tizen 浏览器引擎（基于 WebKit 进行大幅改造）、中国移动的自研 AI 能力集成到 Chromium 框架。

这一层次的判断标准：修改的代码量占核心功能的比例，以及是否存在明确的技术差异化。

层次三：最小修改换皮（Rebranding）

在开源项目基础上进行最小化修改（更换 UI 皮肤、修改默认主页、添加书签）后以新品牌发布。大多数”定制浏览器”属于这一层次，这在协议上完全合法，但在宣传上不应声称”自主研发内核”。

5.2 宣传边界的工程建议

对于工程和产品团队，建议建立以下内部基线：

这些边界不仅是开源合规的要求，也是商业诚信和防范消费者保护风险的基本规范。

5.3 “自主可控”认定的官方路径

在中国政府采购和关键信息基础设施保护场景下，“自主可控”有官方测评路径：

• 软件著作权登记（国家版权局）：仅证明代码著作权归属，不能证明技术独立性；
• 国家密码管理局认证（商密/国密）：针对密码算法实现的合规性；
• 公安部等保测评：信息系统安全等级保护，不评估内核来源；
• 工业和信息化部信创目录（信息技术应用创新）：有专项评测机构对产品技术路线进行审查，包括内核来源。

工程团队在进入政府采购流程时，应以信创目录的入选条件为准，而非依赖自我宣传。

八、工程坑点

6.1 版本滞后与安全漏洞

Chromium 每隔 4 周发布一个主版本，安全补丁频率更高。基于 Chromium 的衍生产品如果无法跟上上游的安全更新节奏，会积累大量已知 CVE（Common Vulnerabilities and Exposures，公共漏洞和暴露）。

红芯使用的 Chromium 49（2016 年）版本，距离 2018 年发布时已经两年以上，期间积累了数十个已公开的严重漏洞（CVSS 评分 7.0 以上的高危漏洞多达数十个）。这是”换皮浏览器”在安全上的核心风险，也是企业用户评估此类产品时最需要关注的技术指标。

工程建议：在评估浏览器产品的安全性时，应要求厂商提供当前基础版本（Base version），并对比该版本与最新 Chromium 稳定版之间的 CVE 差距。

6.2 第三方组件声明缺失

许多基于 Chromium 的产品忽略了附带完整的第三方组件声明（ABOUT_CREDITS.html 或等效文件）。这是 BSD-3-Clause 的明确要求，缺失可能构成协议违反。

检查方法：在浏览器地址栏中输入 chrome://credits，查看是否存在该页面及完整的声明内容。

6.3 商标与品牌风险

Chromium 的商标政策明确规定：Google 的”Chrome”和”Chromium”商标不得用于衍生产品的品牌命名，也不得暗示产品是 Google 的官方产品或受到 Google 支持。使用”Chromium”作为产品名或核心宣传词可能构成商标侵权。

6.4 GPL 组件的”传染”风险

Chromium 主体代码虽然是 BSD-3，但其部分第三方依赖（如历史版本中的某些 libav/ffmpeg 组件）使用了 LGPL 或 GPL 协议。如果产品以静态链接方式集成了这些组件，根据 GPL/LGPL 的条款可能产生相应的源码开放义务。建议对 Chromium 的 third_party/ 目录进行系统性协议扫描。

6.5 浏览器指纹与隐私合规

基于 Chromium 的衍生产品如果未修改浏览器指纹相关逻辑（如 Canvas fingerprint、WebGL fingerprint、AudioContext fingerprint），其用户在访问互联网时会被识别为普通 Chrome 用户。这在多数场景下不构成问题，但在以下情境下需要关注：

• 面向合规市场的产品：如果宣传”更好的隐私保护”，却未做任何指纹阻断，属于虚假宣传风险；
• 进入欧盟市场：GDPR 对用户画像构成限制，若产品默认启用与 Google 相关的 Variations、Safe Browsing 等服务，可能涉及跨境数据传输问题；
• 面向党政军市场：默认的 Google 相关后台连接是信息安全评估的明确红线，必须在编译期或运行期关闭。

6.6 构建系统与 GN/Ninja 的学习成本

Chromium 的构建系统基于 GN（Generate Ninja）+ Ninja，与传统的 Makefile/CMake 差异较大。团队在接手 Chromium 源码后，若缺乏对 GN 语法的掌握，常见问题包括：

• 修改编译选项但未传播到所有目标；
• args.gn 配置与官方文档的最佳实践不一致，导致构建产物膨胀或性能下降；
• 跨平台构建（Windows / macOS / Linux / Android / iOS）时忽略平台特定差异，生成的二进制在部分平台崩溃；
• 对 is_debug、is_component_build、symbol_level 等关键参数理解不够，最终版本体积与性能严重偏离目标。

解决方法是在团队内沉淀《Chromium 构建指南》，并将关键参数固化在 CI 脚本中，而非依赖个别工程师的经验。

九、选型建议

7.1 企业内部使用 Chromium 衍生产品

• 优先选择版本滞后不超过 3 个主版本的产品，超过此界限安全风险急剧上升；
• 要求厂商提供 CVE 响应承诺和补丁发布时间线；
• 验证产品的 chrome://version 页面确认基础版本，评估已知高危漏洞敞口；
• 确认产品附带了完整的第三方许可声明（chrome://credits）。

7.2 自研基于 Chromium 的产品

• 在代码库中建立 LICENSE 和 CREDITS 的自动化生成流程，避免发版时遗漏；
• 建立上游追踪机制，定期 rebase 到 Chromium 稳定版（或主动 cherry-pick 安全补丁）；
• 在产品对外宣传材料、融资文件、政府申报材料中，明确区分”核心技术独创性”与”基于开源二次开发”的边界；
• 如需进入信创认证，提前与测评机构确认内核来源对认证结论的影响。

7.3 国产操作系统选型

9.4 若你是首席安全官（CISO），应该怎么做

对组织的首席安全官而言，红芯事件揭示的核心风险不是”厂商撒谎”，而是”组织在选型时缺乏技术验证能力”。建议的行动框架：

9.4.1 建立”内核来源”技术验证清单

无论厂商如何宣传，对任何拟引入的浏览器、操作系统、中间件都强制执行技术验证：

• 要求厂商在合同附件中填写”基础开源组件清单”，具体到版本号；
• 由内部安全团队独立验证（通过本文前述的 13 项指纹方法）；
• 验证结果与厂商填报一致，才进入下一步商务流程；
• 不一致的差异计入供应商信用档案。

9.4.2 CVE 暴露面量化评估

对每一个拟引入的组件，计算”CVE 暴露面”：

暴露面 = (上游最新版本) - (产品声称基础版本)
      = 两者之间的 CVE 数量（按 CVSS 评分加权）

制定组织内部的红线（例如：高危 CVE 未修复数量不得超过 5 个，或版本滞后不得超过 12 个月）。红线之外的产品原则上不得引入生产环境。

9.4.3 供应链补丁响应 SLA

在合同中明确要求：

• 上游发布严重级别（Critical）安全公告后，厂商必须在 N 工作日内发布对应补丁（N 根据组织风险偏好设置，一般为 7–14 日）；
• 厂商定期（季度）提供安全补丁响应报告；
• 未达标时的违约金或替换权条款。

9.4.4 对”自主可控”宣传的内部解读规范

组织内部建立对”自主可控”、“国产化”、“完全自研”等营销用语的解读规范：

• 采购评估报告中不得使用营销用语作为事实描述；
• 强制用”基于 XX 开源项目 + 自研 YY 模块”的结构化描述；
• 任何涉及”内核”、“引擎”、“底层”的表述需要附带技术验证结论。

9.4.5 审计轨迹与监管报告

涉及关键信息基础设施的组织，其安全选型结果可能被监管机构（如网信办、工信部、行业主管部门）核查。CISO 应确保：

• 选型过程的技术评估报告完整留档；
• 厂商提供的合规声明、源码获取途径、许可证清单归入供应商档案；
• 每一次版本升级、补丁应用都有对应的审计记录。

9.5 若你是开源合规工程师，应该怎么做

开源合规工程师（Open Source Program Office，OSPO；或法务团队的技术接口人）的职责在于把前文讨论的协议框架落实为可操作流程。以下是实操清单：

9.5.1 建立 SBOM（Software Bill of Materials）体系

• 对组织内所有自研或采购的软件，强制生成 SBOM，格式采用 SPDX 或 CycloneDX；
• SBOM 中记录每一个组件的：名称、版本、许可证、来源 URL、哈希值；
• SBOM 与软件制品绑定，一同入库；
• 定期运行 SBOM 差分，识别新增/移除/升级的组件。

9.5.2 许可证冲突扫描

• 使用 FOSSology、ScanCode、ORT（OSS Review Toolkit）等工具对代码库进行扫描；
• 维护组织内部的”许可证兼容性矩阵”（哪些协议与哪些协议可以共存）；
• 发现冲突时触发告警与人工评审流程；
• 对 BSD/MIT 宽松协议、Apache 2.0、LGPL、GPL、AGPL 分别制定引入策略。

9.5.3 Notice/Credits 自动化生成

• 在 CI 中集成”NOTICE 文件生成器”：从 SBOM 自动生成 THIRDPARTYNOTICES.txt、CREDITS.html、或 chrome://credits 等效页面；
• 确保每一个对外发版的产品都附带最新的声明文件；
• 声明文件的缺失或错误列入发版 checklist 的阻塞项。

9.5.4 上游补丁贡献流程

• 建立”员工向开源社区提交补丁”的标准流程：包括内部安全审查、专利/商密评估、DCO/CLA 签署审批、署名规范；
• 维护组织签署的 CCLA 列表与对应项目；
• 对上游的 rebase/升级节奏建立内部追踪；
• 定期对外发布”开源贡献报告”，提升组织在社区中的透明度。

9.5.5 事件响应演练

• 定期演练”上游 CVE → 组织应急响应”的全链路：从 CVE 公开、到 SBOM 匹配、到受影响产品识别、到补丁获取、到灰度发布；
• 演练结果写入年度 OSPO 报告；
• 重大事件（如 Log4Shell、OpenSSL Heartbleed 级别）之后做复盘，把经验沉淀到流程文档中。

9.5.6 合规培训与文化

• 定期对工程师开展开源许可证培训，至少覆盖 MIT、BSD、Apache 2.0、LGPL、GPLv2、GPLv3、AGPL 七类；
• 在代码 review 环节加入”许可证检查”作为强制项；
• 鼓励工程师在个人能力范围内参与上游社区，把个人成长与组织合规对齐。

本文为工程参考，不构成法律意见。涉及具体法律风险请咨询专业法律顾问。本文所述事件均来自公开报道与公开判决书，如有偏差以官方渠道为准。

参考资料

1. Chromium 项目许可证声明：chromium.googlesource.com/chromium/src/+/main/LICENSE
2. BSD-3-Clause 许可证原文：spdx.org/licenses/BSD-3-Clause.html
3. IT之家 2018 年 8 月 16 日报道：《国产红芯号称自主研发浏览器核心，结果被扒是谷歌Chrome换层皮》：ithome.com/0/377/148.htm；《换壳谷歌Chrome的红芯浏览器，曾拿数百万政府和国企订单》：ithome.com/0/377/189.htm；《深扒红芯浏览器”骗局”：浏览器只是外壳，本质是个外包公司？》（凤凰科技）：ithome.com/0/377/310.htm
4. 红芯时代官方声明（联合创始人高婧回应），2018 年 8 月 16 日，IT之家报道：《被指使用谷歌Chrome内核，红芯浏览器回应：有其他创新》：ithome.com/0/377/218.htm；光明网评论转载：《光明网评红芯浏览器被爆伪创新：岂止是胆大》：ithome.com/0/377/280.htm
5. Chromium 第三方组件管理说明：chromium.googlesource.com/chromium/src/+/main/docs/adding_to_third_party.md
6. 深度操作系统源码仓库：github.com/linuxdeepin
7. 麒麟 UKUI 桌面环境：github.com/ukui
8. openEuler 项目主页：openeuler.org，Gitee 仓库：gitee.com/openeuler
9. 信息技术应用创新工作委员会（信通院）相关标准：中国信息通信研究院公开文件
10. Chromium CVE 数据库参考：cve.mitre.org，Google Chrome 安全公告：chromereleases.googleblog.com
11. DFSG（Debian 自由软件指导方针）：debian.org/social_contract
12. 统信软件官方网站与源码镜像站（以官网实际信息为准）：uniontech.com、mirrors.uniontech.com/uos/
13. Debian 社会契约与自由软件指导方针：debian.org/social_contract
14. Debian 安全公告（DSA）与长期支持（LTS）：debian.org/security、wiki.debian.org/LTS
15. Chrome DevTools Protocol 官方文档：chromedevtools.github.io/devtools-protocol
16. User-Agent Client Hints 规范：wicg.github.io/ua-client-hints
17. 开放原子开源基金会（OpenAtom Foundation）官网与项目清单：openatom.org
18. 中国信息通信研究院（信通院）《开源生态白皮书》等年度报告：caict.ac.cn
19. 信创工作委员会（信创工委会）公开材料：以工委会官网与信通院发布文件为准
20. Developer Certificate of Origin (DCO) v1.1：developercertificate.org
21. Apache 软件基金会 Individual/Corporate CLA：apache.org/licenses/#clas
22. SPDX 软件物料清单规范：spdx.dev
23. OWASP CycloneDX SBOM 规范：cyclonedx.org
24. 中国电子信息产业集团（CEC）麒麟软件公开资料：以麒麟软件官网与 CEC 年报为准
25. 龙蜥（Anolis OS）与 OpenCloudOS 项目主页：openanolis.cn、opencloudos.org
26. FOSSology 开源合规扫描工具：fossology.org
27. OSS Review Toolkit（ORT）：github.com/oss-review-toolkit/ort
28. ScanCode Toolkit：github.com/nexB/scancode-toolkit
29. MPEG LA 专利池信息（H.264/AVC、H.265/HEVC 授权）：mpegla.com
30. 开放媒体联盟（AOMedia）与 AV1 标准：aomedia.org
31. Chromium GN 构建系统官方文档：gn.googlesource.com/gn/+/main/docs
32. Linux 基金会开源合规培训：linuxfoundation.org/training
33. GNU 通用公共许可证（GPLv2/GPLv3）官方文本：gnu.org/licenses
34. Apache License 2.0 官方文本：apache.org/licenses/LICENSE-2.0
35. Chromium 项目安全公告列表：chromium.org/Home/chromium-security
36. Widevine Content Protection 分发授权说明：widevine.com
37. Mozilla Gecko 引擎源码与协议：firefox-source-docs.mozilla.org
38. WebKit 项目与 Safari 引擎：webkit.org

上一篇：文档、数据、模型的许可：CC、ODbL、OpenRAIL、LLaMA 协议

下一篇：CentOS 停服与生态重组：Rocky、Alma、openEuler、龙蜥