【开源许可与版权工程】OpenHarmony 与开放原子基金会：大厂捐赠意味着什么

2019 年 8 月，华为在开发者大会上发布 HarmonyOS，彼时华为正处于美国实体清单的巨大压力之下，“备胎”叙事使这一操作系统引发广泛关注。2020 年 9 月，华为将操作系统的开源版本——OpenHarmony——捐赠给刚刚成立的开放原子开源基金会。

这一系列动作在技术社区产生了截然不同的解读：有人认为这是真正意义上的开源治理探索，有人认为这不过是换一种形式的”华为主导”。本文从工程角度分析 OpenHarmony 的许可证结构、开放原子基金会的治理机制、商标归属与 Fork 权利，以及这套模式与 Android/AOSP 的本质差异。

OpenHarmony 生态治理架构

开放原子开源基金会 OpenAtom Foundation · 2020 年 6 月 · 民政部登记

OpenHarmony Apache 2.0 为主

openEuler GPL/MulanPSL v2

MindSpore Apache 2.0

OpenGauss MulanPSL v2

龙蜥 Anolis OS GPL/MulanPSL v2

HarmonyOS NEXT 与 OpenHarmony 的关系

OpenHarmony（开源版） 开放原子基金会持有商标 Apache 2.0 为主 · 社区 PMC 治理 · 任何人可 Fork HarmonyOS NEXT 是其商业发行版

HarmonyOS NEXT（纯血鸿蒙，2024） 华为商业版 · 不含 AOSP 代码 HarmonyOS 商标由华为持有 闭源应用层 + OpenHarmony 开源底座

一、背景：华为、鸿蒙与开放原子基金会

1.1 HarmonyOS 的诞生背景

2019 年 5 月，美国商务部将华为列入实体清单，直接导致 Google 暂停向华为提供 Android GMS（Google Mobile Services）授权。华为随即对外宣布，其早已准备了”备胎”操作系统方案——HarmonyOS（鸿蒙操作系统）。

2019 年 8 月 9 日，华为在开发者大会上正式发布 HarmonyOS，宣称这是一个”面向全场景的分布式操作系统”，支持手机、平板、穿戴、车载、智慧屏等多种终端。

从技术路线看，早期 HarmonyOS（1.x 和 2.x 版本）的手机部分在底层仍包含大量 AOSP 代码，并非从零构建的”纯血”系统。华为官方对此的解释是，AOSP 部分属于”兼容层”，上层架构（特别是分布式能力）是自研的。

1.2 开放原子开源基金会的成立

2020 年 6 月 11 日，开放原子开源基金会（OpenAtom Foundation）在北京正式成立，经民政部登记注册为社会服务机构（非营利性）。这是中国第一个专注于开源软件的基金会，初始理事成员包括华为、阿里、腾讯、百度、浪潮、360、招商银行等企业。

基金会的定位是”支持、孵化、推广开源项目”，其模式参考了 Apache 软件基金会（ASF）和 Linux 基金会的部分治理经验，但结合了中国的社会组织注册要求。

2020 年 9 月，OpenHarmony 作为开放原子基金会的首批捐赠项目正式进入基金会托管。随后，openEuler（华为，2021 年 11 月）、龙蜥 Anolis OS（阿里，2021 年）、OpenGauss（华为，2021 年）、MindSpore（华为，2021 年）等项目陆续捐赠进入基金会。

1.3 开放原子基金会的治理结构

基金会的官方治理层级包括：

• 理事会：成员为赞助企业代表，负责基金会整体战略和财务决策；
• 技术监督委员会（TOC）：对各开源项目的技术方向进行宏观监督；
• 各项目 PMC（Project Management Committee，项目管理委员会）：负责具体项目的技术决策、版本发布、贡献者管理；
• SIG（Special Interest Group，特别兴趣小组）：专注于某个子模块或特定领域的技术研究。

1.4 开放原子基金会治理层级详解

开放原子基金会的治理模型部分借鉴了 ASF 和 Linux 基金会的经验，但在组织形式上做了中国化调整。下面按层级逐一梳理。

1.4.1 理事会（Board of Directors）

理事会是基金会的最高决策机构，负责整体战略、预算分配、重大对外合作、基金会章程修订以及秘书长人选等事务。理事会的构成方式是按”赞助企业—理事席位”对应，赞助级别越高（白金、黄金、白银等），获得理事席位的概率越大。

初始公开披露的理事成员单位包括：

• 华为技术有限公司
• 阿里巴巴（中国）有限公司
• 腾讯科技（深圳）有限公司
• 百度在线网络技术有限公司
• 浪潮电子信息产业股份有限公司
• 奇虎 360 科技有限公司
• 招商银行股份有限公司

从构成可以看出，理事会并非以个人身份选举，而是以”赞助企业代表”身份存在，这一点与 ASF 理事会（Board of Directors）以”个人成员选举”的模式有本质差别。ASF 的 Board 九名成员全部由 Apache Members 投票选出，不与公司席位绑定；开放原子基金会的理事会更接近 Linux 基金会的”企业会员制”。

1.4.2 技术监督委员会（TOC, Technical Oversight Committee）

TOC 负责跨项目的技术协调、项目孵化评审、毕业评审、技术标准和最佳实践的制定，是基金会技术侧的核心机构。职责主要包括：

• 审核新项目的捐赠申请与孵化计划；
• 对孵化项目进行定期评估，判断是否具备毕业条件；
• 制定跨项目共享的工程规范，如 CLA 模板、代码托管规范、版本发布流程等；
• 协调跨项目的技术冲突与资源分配。

TOC 成员通常由各项目 PMC 主席、资深技术贡献者以及受邀的独立技术专家组成，任期制。TOC 下设若干工作组，针对特定议题（如安全、合规、知识产权）开展专项工作。

1.4.3 项目管理委员会（PMC, Project Management Committee）

每个进入基金会的项目都设有独立的 PMC，负责项目级决策：

• 版本规划与发布节奏；
• Committer 和 Maintainer 的提名与表决；
• 项目路线图（Roadmap）的制定与调整；
• 贡献者晋升（Contributor → Committer → PMC Member）的评审；
• 社区规范和行为守则的执行。

PMC 成员的选举规则因项目而异，但基金会鼓励各项目建立”多元化要求”——即单一公司占比不宜超过某个阈值（通常为 50% 或 2/3），以避免项目事实上被单一企业控制。这一机制借鉴了 ASF 的 “Apache Way”，但在执行层面，多数基金会旗下项目仍处于”捐赠方主导”阶段。

1.4.4 SIG（Special Interest Group，特别兴趣小组）

SIG 是项目内部的专项小组，聚焦某一子模块或技术方向。以 OpenHarmony 为例，常见的 SIG 包括：

• Kernel SIG：负责 LiteOS、Linux 内核适配、调度器、内存管理等；
• Graphics SIG：负责图形渲染栈、Window Manager、合成器等；
• ArkCompiler SIG：负责 ArkTS/JS 运行时、AOT 编译器；
• Distributed SIG：负责分布式软总线、跨设备任务调度；
• Security SIG：负责安全子系统、TEE 适配、漏洞响应流程；
• Compatibility SIG：负责 OpenHarmony 兼容性测试套件（XTS）。

SIG 的设立、合并、解散由 PMC 决定。SIG 内部设有 Chair 角色负责协调，其决策结果需提交 PMC 审批后生效。

1.4.5 与 ASF 治理结构的层级对比

二者的根本差异在于“个人 vs 企业”的治理基调：ASF 以个人成员选举 Board、以 Committer 个人身份参与决策；开放原子基金会以企业赞助席位决定理事会构成，个人贡献者通过项目 PMC 晋升通道参与治理。这一差异决定了两种基金会面对”单一公司主导项目”问题时的处理方式和力度不同。

1.5 OpenHarmony 项目捐赠时间线

开放原子基金会自 2020 年成立以来，陆续接纳了多个主流中国开源项目的捐赠。下表整理了公开信息中可查的主要项目：

上述时间与项目范围以基金会公开披露为准，部分项目的”捐赠”在法律形式上是版权转让，部分则是”商标/治理权的转让”，代码版权仍保留在原贡献者处，具体以各项目协议为准。

二、OpenHarmony 的许可证结构

2.1 主体许可证

OpenHarmony 代码仓库采用多协议并存的许可证结构，主体遵循以下规则：

具体到代码仓库，OpenHarmony 在 Gitee（openharmony 组织）维护了约数百个代码仓，每个仓库的根目录下有 LICENSE 文件。官方文档中提供了许可证合规说明，开发者在集成前应检查具体组件的许可证。

2.2 Apache 2.0 的选择理由

OpenHarmony 主体采用 Apache 2.0 有清晰的工程理由：

1. 专利授权条款：Apache 2.0 包含明确的专利授权条款，贡献者向接受者授予专利许可。这对于硬件 OEM 和应用开发者在商用场景中更安全。
2. 商用友好：允许闭源分发衍生产品，有利于基于 OpenHarmony 构建商业发行版（如华为 HarmonyOS NEXT、荣耀 MagicOS 的底座）。
3. 与 Android/AOSP 许可证生态接近：AOSP 的大部分上层代码也采用 Apache 2.0，开发者迁移成本相对较低。
4. 非 Copyleft：不要求衍生作品开源，避免了 Copyleft 传染在商业合作中造成的障碍。

2.3 Mulan PSL v2 组件

部分 OpenHarmony 的工具和少量组件采用木兰宽松许可证（第 2 版，Mulan PSL v2）。Mulan PSL v2 是中国开源云联盟（COSCL）主导开发的许可证，在 OSI（开源倡议组织）于 2021 年获得批准，是第一个获得 OSI 认可的中文许可证。

Mulan PSL v2 在功能上与 Apache 2.0 类似，包含专利授权条款，采用中英双语文本，中文文本具有同等法律效力。详细分析见本系列第 09 篇。

2.4 GPLv2 组件的处理

OpenHarmony 对于集成 Linux 内核的设备，相关内核模块遵循 GPLv2。根据 Linux 内核的 syscall exception 惯例，用户态应用程序（ArkTS/Java 应用）通过系统调用接口访问内核，不被认为是内核的”衍生作品”，因此不触发 GPLv2 的 Copyleft 要求。

但需要注意：任何需要加载到内核地址空间的内核模块（如自定义驱动），在 GPLv2 的标准解释下，通常需要以 GPLv2 兼容的许可证发布。OEM 厂商在开发专有驱动时，应特别注意这一边界。

2.5 代码仓库许可证分布实况

OpenHarmony 在 Gitee 的 openharmony 组织下维护了 200 多个代码仓库，横跨内核适配、系统服务、应用框架、测试工具、文档等领域。按许可证类型的大致分布（基于公开仓库抽样观察，具体以各仓库 LICENSE 文件为准）：

2.5.1 如何检查具体仓库的许可证

推荐的检查方式：

1. 直接访问 Gitee 仓库：以 URL https://gitee.com/openharmony/<仓库名>/blob/master/LICENSE 打开每个代码仓的 LICENSE 文件；部分仓库可能使用 NOTICE 或 LICENSE.txt 作为补充。
2. 使用 SBOM 工具扫描：对于集成多个 OpenHarmony 仓库的工程，推荐使用 SBOM（Software Bill of Materials，软件物料清单）工具（如 SPDX 工具链、ORT、FOSSology、Syft 等）自动识别各子模块的许可证。SBOM 工具链的详细使用方式见本系列第 16 篇。
3. 阅读 bundle.json / ohos.build：OpenHarmony 的构建系统在每个模块根目录下通常有构建配置文件，其中会声明当前模块依赖的其他组件，可用于追溯许可证依赖关系。

2.5.2 需重点注意的 GPL 驱动仓库

以下几类代码仓通常涉及 GPLv2，OEM 团队在集成或修改时需注意 Copyleft 义务：

• Linux 内核主线代码及其移植：如 kernel/linux-5.10、kernel/linux-6.x 等分支仓库；
• 设备驱动仓（drivers）：大多数字符/块设备驱动遵循 Linux 内核的 GPLv2；
• LiteOS 内核相关部分：LiteOS 主体为 BSD-3，但某些与 Linux 兼容的移植代码仍为 GPLv2；
• 工具链中的 GPL 组件：例如 GCC、Binutils 相关的定制补丁。

对专有驱动而言，如果驱动以内核模块（LKM）形式加载，通常需要采用 GPLv2 兼容许可证；若要规避 GPLv2，可考虑将驱动实现在用户态（例如通过 UIO、VFIO、FUSE、libusb 等用户态框架），或通过 HDI（Hardware Driver Interface）抽象层进行隔离——HDI 的合规模式将在第六节展开。

2.6 与 AOSP 许可证结构的对比

OpenHarmony 与 AOSP 在许可证选择上的逻辑高度相似，但在若干细节上各有差异：

两者共同选择 Apache 2.0 作为主体许可证的原因一致：专利授权明确、对 OEM 商用友好、允许闭源衍生。差异主要体现在：

• ArkTS 生态层：OpenHarmony 将自研的 ArkTS/ArkCompiler 作为一等公民纳入开源底座，这是 AOSP 没有的模块；
• 分布式能力：OpenHarmony 的分布式软总线、跨设备任务调度是自研且开源的，AOSP 中没有对应的开源实现；
• C 库实现：Bionic 是 Android 原生的 C 库，OpenHarmony 使用 musl-libc 的变体，二者技术路线不同但许可证选择一致。

2.7 Mulan PSL v2 与 Apache 2.0 的条款级对比

OpenHarmony 的少部分自研组件、以及旗下姊妹项目（openEuler、OpenGauss）使用 Mulan PSL v2。工程和法务团队在实操中，经常需要回答”MulanPSL v2 和 Apache 2.0 相比，日常合规动作是否有差异”。

对集成方的工程含义：

1. 合规流程基本一致：保留许可证全文、保留版权头、在被修改文件中做修改声明，两者都必须执行；
2. NOTICE 文件差异：Apache 2.0 工程使用 NOTICE 做归属与法律声明的传递，MulanPSL v2 没有对应机制；
3. 法律解释语言：中国本土诉讼中，Mulan PSL v2 中文文本可直接作为合同依据，免去翻译争议；
4. SBOM 标识：建议在 SBOM 中严格使用 SPDX 标识符，避免以”木兰协议”模糊描述。

代码示例：一个典型的 Mulan PSL v2 文件头应包含：

/*
 * Copyright (c) 2024 XYZ Corporation. All rights reserved.
 *
 * XYZ is licensed under Mulan PSL v2.
 * You can use this software according to the terms and conditions of the
 * Mulan PSL v2.
 * You may obtain a copy of Mulan PSL v2 at:
 *         http://license.coscl.org.cn/MulanPSL2
 * THIS SOFTWARE IS PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OF
 * ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
 * NON-INFRINGEMENT, MERCHANTABILITY OR FIT FOR A PARTICULAR PURPOSE.
 * See the Mulan PSL v2 for more details.
 */

对比 Apache 2.0 的标准文件头：

/*
 * Copyright (c) 2024 XYZ Corporation. All rights reserved.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

两者在工程实操中几乎可以”对等处理”，区别主要在 NOTICE 文件处理和文本语言层面。

三、商标归属与 Fork 权利

3.1 OpenHarmony 商标

根据开放原子基金会的官方说明，“OpenHarmony”商标由开放原子开源基金会持有，而非华为。这一设计参考了 ASF 持有 Apache 商标的模式。

实际含义：

• 使用”OpenHarmony”品牌名称需要符合开放原子基金会的商标使用规范；
• OEM 厂商基于 OpenHarmony 开发的商业产品，通常会使用自己的品牌名称（如华为 HarmonyOS、荣耀 MagicOS），而非直接使用”OpenHarmony”；
• 若项目被 Fork，Fork 版本不能继续使用”OpenHarmony”品牌，这与 Apache 项目的商标机制一致。

3.2 HarmonyOS 商标

与 OpenHarmony 不同，“HarmonyOS”和”鸿蒙”商标由华为持有。这是华为商业版本的品牌，与开放原子基金会持有 OpenHarmony 商标相互独立。

这一双轨商标结构反映了华为的战略安排：将底层开源生态（OpenHarmony）置于中立的基金会治理下，同时保留商业发行版（HarmonyOS）的品牌控制权——这与 Red Hat 持有 RHEL 商标同时向 CentOS 捐赠基础设施的模式有相似之处。

3.3 Fork 权利

OpenHarmony 的主体代码采用 Apache 2.0，任何组织或个人均可 Fork，并以任意名称（不得使用 OpenHarmony 商标）发布衍生版本。已知的基于 OpenHarmony 的商业发行版或衍生版包括：

• HarmonyOS NEXT（华为）：纯血版，2024 年正式发布，底座为 OpenHarmony，应用层为华为自有 ArkTS 生态
• MagicOS（荣耀）：基于 OpenHarmony 的独立商业版，荣耀从华为独立后自行演化
• 欧拉鸿蒙融合版（实验性）：openEuler 与 OpenHarmony 内核融合的探索，主要面向 IoT/边缘场景

3.4 与 Android/AOSP 治理的对比

AOSP 模式下，Google 既是商标持有者，也是代码托管方，还是主要决策者，三权高度集中；OpenHarmony 在名义上做了商标和代码托管的分离，但由于华为在项目中的绝对贡献量，PMC 的实际决策权仍然高度向华为集中。

3.5 商标使用的具体边界

在工程和市场实践中，“OpenHarmony” 商标使用的边界有若干常见场景，列举如下以供参考：

3.5.1 可以做的使用（事实陈述）

• 在产品技术文档中写”本设备基于 OpenHarmony XXX 版本构建”；
• 在学术论文、技术博客、演讲中以事实方式提及 OpenHarmony；
• 在源码仓库的 README、LICENSE、NOTICE 文件中保留 OpenHarmony 的版权与归属声明；
• 参与 OpenHarmony 官方组织的技术活动（Meetup、Hackathon、开发者大会）时，在个人或组织介绍中自称”OpenHarmony Contributor”（若确实为贡献者）。

3.5.2 不宜做的使用（可能构成商标侵权）

• 以 “OpenHarmony” 作为公司名、产品名、品牌名或其显著组成部分；
• 在消费者产品包装、UI、广告中以视觉设计上的”标识化”方式突出 OpenHarmony 字样与 Logo；
• 暗示自身产品是 OpenHarmony 官方版本、“认证版”、“授权版”（未经基金会商标授权）；
• 注册包含 OpenHarmony 字样的域名、商标、社交账号，用于误导消费者。

3.5.3 模糊地带（建议提前与基金会沟通）

• 使用 “OHOS”、“Harmony”、“OH” 等字符串作为产品名（可能被判断为”近似商标”）；
• 在应用市场、开发者平台的分类中以”OpenHarmony 专版”命名产品；
• 针对 OpenHarmony 开发培训课程，命名中含”OpenHarmony 官方课程”之类的描述；
• 硬件产品正面丝印 OpenHarmony Logo。

对这类模糊地带，建议在商业上线前取得开放原子基金会的商标使用许可书面文件，避免事后争议。

四、开放原子基金会旗下的其他重要项目

4.1 MindSpore（昇思 MindSpore）

MindSpore 是华为于 2020 年 3 月开源的 AI 计算框架，2021 年捐赠给开放原子基金会。采用 Apache 2.0 许可证。

主要特点： - 支持全场景训练与推理，面向昇腾（Ascend）NPU 有专项优化 - 与 TensorFlow/PyTorch 的主要差异在于其自动并行（Auto Parallel）和”图算融合”的编译优化路线 - 已进入 Gitee 开放原子组织，社区贡献包含华为外的高校和企业成员

在协议层面，MindSpore 使用 Apache 2.0，商用无限制。但其硬件加速的最优效果依赖昇腾芯片（华为商业产品），这在架构上形成了与 NVIDIA CUDA/PyTorch 类似的”软件开源、硬件生态半封闭”的商业模式。

4.2 OpenGauss

OpenGauss 是华为于 2020 年 6 月开源的关系型数据库，基于 PostgreSQL 11 进行了大量优化（存储引擎、NUMA 调优、主从复制、安全增强）。2021 年捐赠给开放原子基金会。

许可证：MulanPSL v2

衍生版本：华为推出了基于 OpenGauss 的商业版本 GaussDB，在华为云上提供服务。多家国内数据库厂商（如云和恩墨的 MogDB）也基于 OpenGauss 构建了各自的商业版。

4.3 TDengine

TDengine 由涛思数据（TAOS Data）开发，是一个专为时序数据优化的数据库。2022 年在开放原子基金会孵化。核心代码采用 AGPL v3（服务端），客户端 SDK 采用 MIT。

TDengine 选择 AGPL v3 的动机与 MongoDB 早期选择相似：防止云厂商在不回馈社区的情况下将其作为服务提供。关于 AGPL 对云厂商的影响，详见本系列第 08 篇。

4.4 dubbo-go

dubbo-go 是 Apache Dubbo 的 Go 语言实现，由 Apache 软件基金会孵化，不在开放原子基金会旗下。这里提及是为了说明：不是所有知名中国开源项目都归属于开放原子基金会，Apache 基金会（Dubbo、ShardingSphere、SkyWalking、APISIX 等）和 CNCF（Argo、Chaos Mesh 等）仍然是中国公司项目出海的重要路径。

4.5 开放原子基金会的孵化机制

与 Apache 软件基金会的”孵化器（Incubator）“类似，开放原子基金会设有项目孵化流程。项目进入基金会后需要：

1. 提交捐赠协议，转移版权或授予使用权（具体形式因项目而异）；
2. 签署贡献者许可协议（CLA）；
3. 接受基金会 TOC 的技术审查；
4. 建立项目 PMC，推动社区多元化。

与 ASF 相比，开放原子基金会在社区多元化要求上的执行力度目前仍处于早期阶段，多个项目的 PMC 成员仍以捐赠方（如华为、阿里）的员工为主。

4.6 项目毕业与生命周期管理

开放原子基金会对捐赠项目设有”孵化—毕业—长期维护—归档”的完整生命周期设计：

• 孵化期（Incubating）：项目初入基金会阶段，需完成 CLA 签署、知识产权清晰化、PMC 组建、代码托管迁移等工作；
• 毕业（Graduated）：通过 TOC 评审后成为基金会的顶级项目，获得独立的版本发布与社区治理权；
• 长期维护（Mature）：毕业项目按既定节奏发布 LTS 与常规版本，按需引入新的 SIG；
• 归档（Archived）：社区活跃度下降、维护乏力的项目进入归档状态，代码只读保留，与 ASF Attic 机制类似。

这一机制的意义在于，为项目的整个生命周期——包括其衰退阶段——提供了规范化的处理路径，避免代码与贡献记录的突然丢失。

五、其他开放原子孵化项目：从 ShardingSphere 到 Kata Containers

开放原子基金会并不是中国开源项目走向国际化的唯一路径。为了更准确地评估”托管于开放原子”在工程上的含义，有必要对比中国公司选择不同基金会的典型案例。

5.1 进入 Apache 基金会的中国项目（对比参照）

以下几个项目由中国公司或社区发起，选择了 Apache 软件基金会（ASF）作为托管方：

• Apache Dubbo：阿里巴巴开源的高性能 RPC 框架，最初于 2011 年开源，2014 年内部维护放缓，2017 年重新开源并于 2018 年进入 ASF 孵化器，2019 年毕业成为 Apache 顶级项目（TLP）。
• Apache ShardingSphere：起源于当当网开源的 Sharding-JDBC，后由 SphereEx 等团队持续维护，2018 年进入 ASF 孵化器，2020 年毕业为 Apache 顶级项目，是分库分表与分布式数据库中间件的代表作。
• Apache SkyWalking：由吴晟发起的 APM（应用性能监控）系统，2017 年进入 ASF 孵化器，2019 年毕业。其社区治理是 Apache Way 在中国发起项目中执行较为彻底的例子。
• Apache APISIX：支流科技（api7.ai）开源的 API 网关，2019 年捐赠给 ASF，2020 年毕业。
• Apache RocketMQ：阿里巴巴开源的消息中间件，2016 年进入 ASF 孵化器，2017 年毕业。
• Apache Kylin：eBay 上海团队发起的 OLAP 引擎，2015 年进入 ASF 孵化器，2015 年毕业。

这些项目选择 ASF 而非开放原子基金会的典型动因：

1. 国际化定位：从一开始目标客户群就以全球用户为主，Apache 品牌在国际社区认可度更高；
2. 中立性需求：作为中间件或工具链类项目，需要最大限度减少单一公司背书带来的排他性；
3. 成熟的治理框架：Apache Way 对项目多元化的强制要求，反向为项目创始公司提供了”不受内部人事变化影响”的保护；
4. 历史路径依赖：早期开源项目进入 Apache 已是行业默认路径，路径切换成本较高。

5.2 进入 CNCF 的中国项目（对比参照）

云原生领域的中国项目大多选择 CNCF（Cloud Native Computing Foundation，归属 Linux 基金会）：

• TiKV：PingCAP 开源的分布式 K-V 存储，2018 年进入 CNCF 孵化，2020 年毕业；
• Chaos Mesh：PingCAP 开源的混沌工程平台，2020 年进入 CNCF 沙箱；
• Harbor：VMware 中国团队发起的容器镜像仓库，2018 年进入 CNCF 孵化，2020 年毕业；
• KubeEdge：华为发起的边缘计算框架，2019 年进入 CNCF 沙箱，后进入孵化，同时也捐赠给了开放原子基金会；
• Volcano：华为发起的批处理调度引擎，2019 年进入 CNCF 沙箱；
• OpenYurt：阿里巴巴发起的边缘 K8s，2020 年进入 CNCF 沙箱；
• Dragonfly：阿里巴巴发起的 P2P 镜像分发系统，2018 年进入 CNCF 沙箱，2020 年进入孵化。

CNCF 的路线选择对应的工程含义：

1. 与 Kubernetes 生态深度绑定：云原生基础设施项目几乎必须进入 CNCF，才能获得 K8s 生态的采纳；
2. 企业会员体系：CNCF 的白金、黄金会员体系明码标价，为企业赞助者提供清晰的话语权通道；
3. 毕业路径明确：Sandbox → Incubating → Graduated 三级制度，每级有明确的量化门槛（如采用者数量、贡献者多样性、CI 合规等）；
4. 国际大厂的联合背书：Google、AWS、Microsoft、Red Hat、IBM 等均为 CNCF 铂金会员，单一中国公司即便发起项目也能在国际社区获得平等地位。

5.3 开放原子基金会孵化器对比 ASF 孵化器

下表对比两种孵化器在关键维度上的差异：

选择哪一个基金会，并非纯技术问题，而是项目方对目标市场、地缘环境、合作伙伴等综合考量的结果。对同一家公司（如华为）而言，同时向开放原子（OpenHarmony、openEuler）、ASF（通过员工贡献 Apache 项目）、CNCF（KubeEdge、Volcano）三处投资，本身就是一种风险对冲策略。

六、基于 OpenHarmony 构建商业产品的工程落地

本节从工程实操角度，梳理基于 OpenHarmony 构建商业产品时需要关注的合规要点。

6.1 Fork 义务 vs 贡献义务

Apache 2.0 许可证对 Fork 的处理非常宽松：

• 允许任意 Fork：任何组织或个人可基于 OpenHarmony 代码建立私有分支；
• 不强制回馈上游：Fork 后的修改不需要贡献回 OpenHarmony 社区；
• 允许闭源衍生：基于 OpenHarmony 构建的产品可以闭源发布；
• 保留义务：分发时必须保留原始版权声明、Apache 2.0 许可证全文、NOTICE 文件（若存在），并对修改部分做标注。

但即便 Apache 2.0 不强制回馈，基于长期工程可维护性考虑，OEM 厂商通常采用”部分回馈”策略：

1. 通用 Bug 修复回馈上游：避免每次 rebase 带来大量冲突；
2. 专有增值功能保持私有：品牌差异化能力不开源；
3. 跟随社区主版本：以社区 LTS（Long Term Support）版本为基准构建内部分支。

6.1.1 商标限制

即便代码可以自由 Fork，商标使用仍受限：

• 商业产品不得使用 “OpenHarmony” 或 “鸿蒙” 作为品牌（除非取得相应商标权利人的许可）；
• 可以在 About 页面、许可证声明中注明”基于 OpenHarmony 构建（Based on OpenHarmony）“，作为技术来源事实陈述；
• OEM 应建立自有品牌，例如荣耀的 MagicOS、小米 Vela、OPPO 的自有系统等均采用独立品牌策略。

6.1.2 代码修改的义务

Apache 2.0 对代码修改的要求：

• 不要求开放修改后的源代码：这与 GPL 类 Copyleft 许可证有本质区别；
• 要求在被修改文件中添加”显著通知（prominent notices）“：说明文件已被修改，以及修改日期；
• 保留原始版权头：不得删除或修改原文件的版权头、专利授权声明等；
• NOTICE 文件传递：若原分发包含 NOTICE 文件，衍生分发也须附带 NOTICE 文件（可附加自己的条目，但不能删除原有条目）。

6.2 GPLv2 内核驱动合规要求

OpenHarmony 上运行的 Linux 内核遵循 GPLv2。GPLv2 对内核模块（Loadable Kernel Module, LKM）的解释，在社区长期以来形成了相对稳定的实践：

6.2.1 内核模块的 GPL 污染边界

• 加载到内核地址空间的模块通常被视为内核的”派生作品（derivative work）“，需采用 GPLv2 兼容的许可证；
• 纯粹通过系统调用与内核交互的用户态程序，根据 Linus Torvalds 多次声明的 “syscall exception” 惯例，不构成内核衍生作品，因此不受 GPL 传染；
• EXPORT_SYMBOL_GPL 导出符号：Linux 内核将部分内部 API 标记为仅供 GPL 模块使用，专有模块调用此类 API 通常被视为构成派生作品。

6.2.2 专有驱动的替代方案

OEM 若需保留专有驱动代码不开源，常见的工程路径有：

1. 用户态驱动（User-Space Driver）：
   • 通过 UIO（Userspace I/O）、VFIO 等机制将硬件控制权移到用户态；
   • 使用 FUSE（Filesystem in Userspace）实现用户态文件系统；
   • 使用 libusb 直接在用户态操作 USB 设备。
2. 双层驱动架构：
   • GPL 兼容的内核态”胶水层（shim）“只实现硬件无关的接口适配，以 GPLv2 开源；
   • 专有的用户态服务实现具体的算法和业务逻辑，可闭源。
3. 固件下载模式：
   • 硬件驱动本身开源，但运行所需的二进制固件（firmware blob）不在 GPL 覆盖范围之内，通过单独的固件协议分发。

6.2.3 OpenHarmony 的 HDI（Hardware Driver Interface）抽象层

OpenHarmony 设计了一层 HDI（Hardware Driver Interface） 抽象，用于隔离上层系统服务与具体硬件驱动。HDI 的工程意图在于：

• 接口在用户态稳定化：HDI 接口以 IDL（Interface Definition Language）描述，通过 IPC 暴露给上层系统服务；
• 实现层可分置于内核态或用户态：HDI 实现可以是内核驱动的 thin wrapper，也可以完全运行在用户态；
• 隔离 GPL 传染：上层业务逻辑通过 HDI 调用，不直接 link 内核代码；内核态实现部分遵循 GPLv2，用户态实现部分可采用 Apache 2.0 或专有许可证。

这一设计在工程上类似 Android 的 HAL（Hardware Abstraction Layer），其 HIDL/AIDL 机制也用于将 GPL 内核与 Apache 2.0 用户态隔离。HAL/HDI 模式是规避 GPL 传染的主流工程实践。

一个典型的 HDI IDL 接口定义示意（以摄像头驱动为例）：

package ohos.hdi.camera.v1_0;

interface ICameraHost {
    GetCameraIds([out] String[] cameraIds);
    GetCameraAbility([in] String cameraId, [out] CameraAbility ability);
    OpenCamera([in] String cameraId,
               [in] ICameraDeviceCallback callback,
               [out] ICameraDevice device);
    SetCallback([in] ICameraHostCallback callback);
}

上述接口通过 OpenHarmony 的 HDF（Hardware Driver Foundation）框架在用户态暴露。其 接口使用方（上层系统服务、应用） 链接的是 Apache 2.0 许可证下的 stub 代码；接口实现方（OEM 驱动） 可以选择：

• 在用户态完全实现（以 Apache 2.0 或私有许可证发布）；
• 在用户态做业务逻辑，内核态只放置薄薄一层 GPLv2 胶水代码与硬件寄存器打交道。

这样的分层使得 OEM 可以在不触发 GPLv2 传染的前提下，将主要的专有算法（ISP、AI 图像增强、降噪算法等）保留在用户态闭源。

6.3 商业产品合规检查清单

下面提供一份决策树式的合规检查清单，供 OEM 工程和法务团队在量产前执行：

• 品牌合规：产品名称、包装、营销材料未使用 “OpenHarmony” 或 “鸿蒙” 商标；若有提及，仅限”基于 OpenHarmony 构建”的事实陈述。
• Apache 2.0 版权声明：产品中已附带完整的 Apache License 2.0 文本（通常通过”关于本机” → “法律信息”页面展示）。
• NOTICE 文件传递：若 OpenHarmony 源分发包含 NOTICE 文件，已将其内容纳入最终产品的法律信息页。
• 修改声明：对 Apache 2.0 代码的修改，已在被修改文件中添加”显著通知”。
• GPLv2 合规：
  • 所有加载到内核地址空间的模块均采用 GPLv2 兼容许可证；
  • 专有驱动已通过用户态实现或 HDI 层隔离；
  • 内核源码（含 OEM 修改）可按 GPLv2 要求向用户提供（书面 offer 或随产品分发）。
• HMS Core / 华为服务集成：若产品集成华为 HMS Core、地图、支付等闭源服务，已与华为签订 商业授权协议。
• 第三方组件 SBOM：已生成产品级 SBOM 清单（SPDX 或 CycloneDX 格式），覆盖所有直接和间接依赖，并完成许可证审查。
• CLA 签署：若团队有计划向 OpenHarmony 社区回馈代码，已完成基金会的 CCLA（企业贡献者许可协议） 签署，且内部贡献者已签署 ICLA（个人贡献者许可协议）。
• 出口管制审查：若产品面向海外市场，已完成目标国家 / 地区的出口管制和进口合规审查（特别是被列入美国实体清单的上游代码或库）。
• 专利授权合规：确认未集成任何未授权的专利实施，特别是涉及多媒体编解码（H.265、VP9）、通信协议栈等的 SEP（Standard Essential Patents）许可谈判。
• 法律信息页可达性：最终用户可以通过设备 UI 在三级菜单内访问到完整的开源许可证声明。

6.4 已知商业发行版案例

下面是已公开的基于 OpenHarmony 的商业发行版或衍生系统案例：

6.4.1 HarmonyOS NEXT（华为）

华为 2024 年正式发布的”纯血鸿蒙”。底层基于 OpenHarmony 内核和系统框架，华为在其上叠加了闭源的 HMS Core、华为自有系统 UI、华为应用市场、华为账号体系等商业组件。

许可证方面：

• 开源底座部分继续遵循 Apache 2.0；
• 华为叠加的闭源部分受华为软件许可协议（EULA）保护；
• 第三方应用的分发通过华为应用市场，受华为开发者协议约束。

6.4.2 MagicOS（荣耀）

荣耀在从华为独立后，持续演进自有的 MagicOS。早期版本保留了 Android 兼容性（对应 HarmonyOS 2.x 的双栈策略），新版本向 OpenHarmony 底座迁移。荣耀作为 OpenHarmony 社区成员之一，部分代码回馈到社区。

6.4.3 IoT 设备厂商

基于 OpenHarmony LiteOS 的 IoT 产品在以下类目中已有规模化部署：

• 智能家居：路由器、空调、净化器、扫地机器人（美的、海尔、九阳等品牌的部分产品线）；
• 工业物联网：智能电表、工控网关；
• 视频设备：部分 IP 摄像头厂商（如海康威视、大华）在评估或已推出基于 OpenHarmony 的产品线；
• 车载辅助系统：部分国产车机在评估 OpenHarmony 作为底层 OS。

6.4.4 行业定制版

面向金融、政务、教育等行业的定制版本，通常由集成商基于 OpenHarmony 底座开发：

• 金融终端（智能 POS、金融 PAD）；
• 政务平板与移动办公终端；
• 教育电子白板与学生平板。

这些行业定制版的合规重点在于：国家行业标准（如金融行业 JR/T 系列、政务信息化相关规范）与 OpenHarmony 原生能力之间的适配，以及对”信创目录”的入围情况。

七、HarmonyOS NEXT（2024 纯血版）与 OpenHarmony 的关系

7.1 HarmonyOS 1.x/2.x 与 AOSP 的关系

HarmonyOS 1.x（2019–2020）主要部署于 IoT 设备，手机版基于 Android 改造。HarmonyOS 2.x（2021）在手机上正式发布，底层包含 AOSP 兼容层，Android 应用可直接运行。

华为官方的表述是 HarmonyOS 不等于 Android，并声称 Harmony 内核（LiteOS 或 Linux）与 Android 不同；但第三方技术分析（如 Android 开发者 Emil Lundmark 的解包报告，2021 年）指出 HarmonyOS 2.x 的手机版本包含大量 AOSP 组件，其差异化主要体现在分布式能力的应用层。

7.2 HarmonyOS NEXT 的技术路线

2024 年发布的 HarmonyOS NEXT（被媒体称为”纯血鸿蒙”）对架构进行了重大调整：

• 移除 AOSP 代码：不再包含 Android 兼容层，Android 应用在此版本上无法直接运行；
• 全面切换至 OpenHarmony 底座：内核基于 OpenHarmony 的 LiteKernel 或 Linux 定制版；
• ArkTS 原生应用生态：只接受基于 ArkTS/ArkUI 的原生应用，华为通过华为应用市场构建独立应用生态；
• HMS Core 替代 GMS：推送、地图、支付等核心服务由华为移动服务（HMS Core）替代。

从许可证角度，HarmonyOS NEXT 的底座（基于 OpenHarmony）使用 Apache 2.0；华为在此基础上叠加的闭源应用层（HMS Core、系统 UI、部分系统服务）属于商业闭源软件，符合 Apache 2.0 允许衍生商业闭源产品的规定。

7.3 OpenHarmony 对 OEM 厂商的开放性

对于非华为的 OEM 厂商，基于 OpenHarmony 开发商业系统是合法且可行的。已有案例包括：

• 荣耀（Honor）：荣耀与华为分拆后，独立开发 MagicOS，底层基于 OpenHarmony。荣耀作为 OpenHarmony 社区的成员企业参与代码贡献；
• 多家 IoT 硬件厂商：基于 OpenHarmony LiteOS 开发智能家居、穿戴设备的固件；
• 国内终端厂商：部分国内手机/平板厂商在评估基于 OpenHarmony 构建自己的 Android 替代系统的可行性。

7.4 HarmonyOS NEXT 的应用分发与开发者协议

HarmonyOS NEXT 的应用分发通道由华为掌控：

• 华为应用市场（AppGallery）：是 HarmonyOS NEXT 上最主要的应用分发入口；
• 企业签名与内部分发：企业客户可以通过 MDM（Mobile Device Management）分发内部应用；
• 开发者协议：开发者上架应用需接受华为开发者联盟的开发者协议，其中包含内容合规、安全审核、支付分成（应用内支付涉及分成比例）等条款；
• 分成比例：与 App Store、Google Play 的”70/30”模式类似，具体比例以华为开发者联盟当期政策为准。

与 Android/AOSP 相比，HarmonyOS NEXT 的”纯血”路线下，华为掌握了从操作系统到分发到支付的完整闭环。对应用开发者来说，这是一把双刃剑：

• 好处：单一分发渠道意味着标准化的审核与支付流程，无需像 Android 阵营那样适配多个厂商的应用市场；
• 风险：对单一渠道的依赖度更高，议价能力更弱；渠道规则变化直接影响应用的可达用户。

7.5 开源底座与商业层的边界

HarmonyOS NEXT 的”开源底座 + 商业上层”架构，在边界上大致可以这样划分：

这个分层与 Google 的 “AOSP + GMS” 分层高度类似：上层的商业组件是真正的盈利与差异化所在，下层的开源底座保证了生态的最低可用性与兼容性。

八、开放原子基金会与 Apache/Linux 基金会的治理对比

8.1 法律地位对比

8.2 出口合规的差异

开放原子基金会注册于中国，不受美国出口管制法规（EAR、ITAR）的直接约束。这对于某些被实体清单列入的中国企业（如华为）有重要意义：

• Apache 基金会和 Linux 基金会受 EAR 约束，理论上在向被列入实体清单的实体提供服务前需要进行合规审查；
• 开放原子基金会不受这一约束，理论上可以接受来自华为等实体清单企业的代码贡献而无需特别审批。

这也是华为选择在国内基金会托管 OpenHarmony 而非直接向 ASF 捐赠的重要背景之一。出海合规的详细分析见本系列第 19 篇。

8.3 工程实践上的影响

对于中国工程团队，选择基于开放原子基金会项目与基于 Apache/Linux 基金会项目的工程含义差异：

8.4 基金会品牌与公众认知的差异

即便在合同与许可证层面，开放原子、ASF、Linux 基金会的运作机制可以相互对应，在公众与行业认知上仍存在若干显著差异：

• ASF 品牌：几乎等同于”Apache Way”在工程界的代名词，项目名为”Apache X”往往意味着项目已获得一定的社区质量认证；
• CNCF（LF 旗下）品牌：与”云原生”绑定紧密，其 CNCF Landscape 已成为云原生技术栈选型的事实标准地图；
• 开放原子品牌：国内信创与政企采购中的认可度较高，国际认可度仍在建设期。

对项目创始者而言，选择基金会时应同时考虑法律、治理、品牌三层面的因素。对使用者和集成商而言，同样应把”基金会托管”这一事实与”项目治理质量”做合理区分——基金会托管是必要条件，不是充分条件。

8.5 基金会可持续性的观察指标

开放原子基金会作为 2020 年才成立的年轻基金会，其可持续性仍需要观察下列指标：

1. 赞助企业的持续投入：赞助费、派驻员工、捐赠项目的持续性；
2. 项目多元化程度：各项目 PMC 成员中单一公司占比是否逐步下降；
3. 毕业项目数量：进入基金会的项目最终达到”孵化毕业”标准的比例；
4. 国际参与度：非中国贡献者占比、与国际基金会的合作；
5. 危机应对能力：面对赞助企业战略调整（例如某一公司退出赞助）时，基金会是否能保证项目的连续性。

这些指标需要 5–10 年的长周期观察，才能给出可靠评估。短期内，开放原子基金会的实际可用性，主要取决于其旗下核心项目（OpenHarmony、openEuler）的工程质量与生态活跃度。

九、工程坑点

9.1 OpenHarmony 多仓库许可证不一致

OpenHarmony 代码分散在 Gitee 上的数百个代码仓库中，不同仓库的许可证类型有差异（Apache 2.0、MIT、BSD、MulanPSL v2、GPL）。工程团队在集成 OpenHarmony 组件时，不能假设所有代码都采用同一许可证，需要逐仓检查 LICENSE 文件。

推荐做法：使用 SBOM（软件物料清单）工具对 OpenHarmony 集成的组件进行系统性扫描，SCA 工具链详见本系列第 16 篇。

9.2 CLA 签署要求

向开放原子基金会旗下项目（如 OpenHarmony、openEuler）贡献代码，需要签署基金会的 CLA（贡献者许可协议）。CLA 赋予基金会以所有者身份管理贡献代码，包括在未来更换许可证的权利（前提是基金会章程允许）。

工程团队在代表雇主签署 CCLA（企业级 CLA）前，应确认法务部门已审阅 CLA 条款，尤其是版权转让 vs 许可授权的区别。详见本系列第 18 篇。

9.3 “纯血鸿蒙”的应用生态碎片化

HarmonyOS NEXT 切断与 Android 的兼容，意味着原有的 Android 应用需要重新以 ArkTS/ArkUI 开发 HarmonyOS 原生版本。对于计划支持 HarmonyOS NEXT 的应用开发团队，这是一个实质性的工程投入。

在协议层面，ArkTS 框架本身属于 OpenHarmony 开源代码（Apache 2.0），但 ArkUI 的某些高级组件和 HMS Core 的 API 属于华为专有技术，开发者在使用前应查阅华为开发者联盟服务条款。

9.4 GPL 内核模块与 OEM 合规

基于 OpenHarmony 构建产品时，若需要加载自定义内核模块（如专有驱动），应确保这些模块以 GPLv2 兼容的许可证发布，或采用 LGPL 例外的方式处理。参照 Linux 内核社区的惯例，华为在 OpenHarmony 的内核文档中提供了驱动合规的指引，OEM 团队应在量产前完成法务审查。

9.5 双 CLA 与交叉贡献的复杂性

若 OEM 或应用开发团队同时向 OpenHarmony（需要签 OpenAtom CLA）与其他基金会项目（ASF 需签 ICLA/CCLA，CNCF 项目需签 DCO 或 CLA）贡献代码，会出现”同一段代码涉及多份 CLA”的情况。典型场景如：

• 华为员工同时给 OpenHarmony 和 Apache Dubbo 做贡献；
• 一段通用工具代码（例如某个日志库）同时被集成到 OpenHarmony 与某 Apache 项目。

合规上需要注意：

• 检查雇主的”员工发明与著作权归属”条款，确定在这些贡献中个人的署名权与处置权；
• 避免将雇主未授权的商业机密代码贡献到开源社区；
• 在不同基金会之间迁移代码时，检查两边的 CLA 是否允许重许可证（relicensing）。

9.6 签名与可信启动的合规

对于商用硬件产品，OpenHarmony 的 Secure Boot、可信固件、DRM 模块等可能涉及商用组件（如 TEE OS、Widevine/PlayReady 许可等），这些商用组件不属于 OpenHarmony 开源范围，需与相应厂商签订商业授权。

• 若设备需要播放受保护的流媒体内容，需向 Google（Widevine）、Microsoft（PlayReady）、Apple（FairPlay）等申请授权；
• 若设备的 TEE 使用 OP-TEE（BSD）以外的商业 TEE OS（如 Trustonic Kinibi、Qualcomm QTEE），需签订商业许可；
• 国产可信计算标准（如 TCM、SM2/SM3/SM4）可能涉及国密算法合规要求，需对照国家密码管理局相关规定。

9.7 版本兼容性与长期维护

OpenHarmony 的发布节奏：

• LTS 版本：每年发布一个，维护期 3–4 年；
• Release 版本：每季度小版本，主要用于快速试水新特性；
• Master 分支：持续更新，不建议直接用于产品。

工程团队常见的坑：

1. 跟进 Master 分支：短期尝鲜可接受，但量产产品建议锁定 LTS 版本；
2. LTS 版本间的 ABI 兼容性：OpenHarmony 不保证跨 LTS 版本的驱动 ABI 稳定性，OEM 需在每次升级时回归测试所有内部驱动；
3. 社区补丁积压：某些修复只存在于 Master，未回溯到 LTS，需要 OEM 自行 backport。

十、选型建议

10.1 是否选择基于 OpenHarmony 开发

10.2 对开放原子基金会项目的引用评估

引用开放原子基金会项目（OpenHarmony、openEuler、OpenGauss 等）前，建议：

1. 检查具体组件的 LICENSE 文件，确认许可证类型；
2. 确认是否需要签署 CLA，评估公司法务是否有审阅要求；
3. 评估项目的 PMC 多元化程度和华为依赖度，判断项目长期可持续性；
4. 若用于出海产品，评估地缘政治因素对合作方（客户、投资人）的潜在影响。

10.3 若你是 OEM 硬件厂商：分步决策框架

面向硬件 OEM 厂商（消费电子、IoT、工业设备等）基于 OpenHarmony 构建商业产品时，推荐按下列顺序决策：

10.3.1 第一步：产品定位与形态评估

• 设备资源级别：
  • 高资源（512MB+ RAM、多核 CPU）：可选 OpenHarmony 标准系统（Linux 内核）或 HarmonyOS NEXT 对应的富体验方案；
  • 中等资源（128MB–512MB RAM）：OpenHarmony 标准系统 + 裁剪；
  • 轻量资源（< 128MB RAM、单核 MCU）：OpenHarmony 轻量系统（LiteOS-M/LiteOS-A）；
• 目标市场：国内为主 vs 海外为主决定是否需要兼容 Android / 避开 HMS Core 闭源依赖；
• 分布式能力需求：若产品强依赖多设备协同（多屏互联、跨设备控制），OpenHarmony 分布式软总线是差异化优势。

10.3.2 第二步：技术栈选型

• 内核选型：LiteOS（自研，BSD-3）、Linux 内核定制（GPLv2）；
• 文件系统：LittleFS（MIT）、F2FS（GPLv2）、ext4（GPLv2）——注意许可证差异；
• 通信协议栈：lwIP（BSD）、NimBLE（Apache 2.0）；
• UI 栈：ArkUI（Apache 2.0）vs 轻量 LiteUI（Apache 2.0）；
• 应用运行时：ArkTS/ArkCompiler（Apache 2.0）或 JS 引擎。

10.3.3 第三步：合规与法务流程

• 落地第 6.3 节的合规检查清单，逐项审查；
• 确认专利实施清单（SEP 与非 SEP），特别注意编解码、无线通信相关的专利授权谈判；
• 确认 CLA 签署策略：仅消费代码（不贡献）vs 双向贡献；
• 建立内部 SBOM 生成与 License Compliance 的 CI 环节。

10.3.4 第四步：供应链与长期维护

• 选择 OpenHarmony 的 LTS（Long Term Support）版本作为基准，而非跟进最新 Release；
• 建立内部 fork 的 rebase 节奏（建议每季度或每个 LTS 发布周期同步一次）；
• 评估关键子系统的多来源维护情况（例如内核补丁是否仅由华为一家贡献）；
• 储备核心子系统（内核、图形栈、IPC）的内部专家。

10.3.5 第五步：商业模式与生态对接

• 若需集成华为 HMS Core，提前与华为商业合作部门接洽，签订商业协议；
• 若需接入信创目录，评估入选流程与所需资质；
• 建立自有开发者生态（SDK、应用市场、支付与账号体系）或选择接入现有生态。

10.4 若你是应用开发者（非华为生态）：HarmonyOS NEXT 支持评估框架

对于已有 Android / iOS 应用的团队，是否投入资源支持 HarmonyOS NEXT，是一个需要量化评估的业务决策。推荐按以下框架评估：

10.4.1 市场因素

• 目标用户的 HarmonyOS 设备占比：参考华为和荣耀在目标细分市场的出货占比；
• 用户生命周期价值（LTV）：HarmonyOS 用户的 ARPU 是否足以覆盖额外的开发维护成本；
• 应用分类：
  • 工具类 / 内容类：通常利润率低，需要谨慎评估；
  • 社交 / 通信类：网络效应强，一旦关键竞品支持 HarmonyOS，其他玩家跟进压力大；
  • 金融 / 政务 / 医疗：国内政策因素影响显著，HarmonyOS 支持往往是强制要求而非可选项；
  • 游戏：渲染栈差异较大，需重新适配。

10.4.2 技术因素

• UI 栈改写成本：Android 使用 Kotlin/Jetpack Compose，HarmonyOS NEXT 使用 ArkTS/ArkUI，UI 层需近乎完全重写；
• 业务逻辑复用：纯业务逻辑部分，若原代码采用 Kotlin Multiplatform、C/C++ 或 Rust 实现，可部分复用；
• 原生模块依赖：若应用依赖大量 Android 专有 API（如 Google Play Services、WorkManager、CameraX），需寻找 HarmonyOS 对等 API；
• 第三方 SDK 支持度：验证关键第三方 SDK（支付、分享、推送、分析、地图）是否已有 HarmonyOS 版本。

10.4.3 投入产出评估

• 开发成本：一个中等复杂度应用的 HarmonyOS 原生版本，通常需要 2–4 名工程师的 6–12 个月投入；
• 长期维护成本：双端甚至三端（Android + iOS + HarmonyOS）并行维护的边际成本需持续评估；
• 替代路径：
  • Web 应用 + 浏览器：在 HarmonyOS NEXT 浏览器内运行 PWA，作为低成本过渡方案；
  • 快应用 / 元服务：华为的轻量级应用形态，开发成本低于完整原生应用；
  • 跨平台框架：关注 Flutter、React Native 等跨平台框架的 HarmonyOS 支持成熟度。

10.4.4 决策表

参考资料

1. 开放原子开源基金会官网：openatom.org
2. OpenHarmony 项目官网与代码仓：openharmony.cn；gitee.com/openharmony
3. OpenHarmony 许可证说明文档：Gitee 各仓库 LICENSE 文件及官方合规说明
4. HarmonyOS NEXT 开发者文档：developer.huawei.com/consumer/cn/harmonyos-next
5. Mulan PSL v2 官方文本：license.coscl.org.cn/MulanPSL2；OSI 批准记录：opensource.org/licenses/MulanPSL-2.0
6. openEuler 官网：openeuler.org
7. OpenGauss 官网：opengauss.org
8. MindSpore 官网：mindspore.cn；开放原子捐赠页：openatom.org/projects
9. Apache 软件基金会治理文档：apache.org/foundation/governance/
10. Linux 基金会治理文档：linuxfoundation.org/about/bylaws
11. 华为实体清单相关报道：美国商务部 BIS 官方公告，2019 年 5 月
12. 开放原子开源基金会章程与治理文档：openatom.org/governance（章程、理事会议事规则、TOC 章程、捐赠流程）
13. OpenHarmony 代码仓列表：gitee.com/openharmony（含各子系统仓库、SIG 仓库、三方库适配仓等）
14. HarmonyOS NEXT 开发者白皮书与迁移指南：developer.huawei.com/consumer/cn/doc/harmonyos-guides
15. 华为开发者联盟服务条款与 HMS Core 商业授权说明：developer.huawei.com/consumer/cn/legal/
16. CNCF 中国项目列表与毕业路径：cncf.io/projects
17. Apache 孵化器中国项目目录：incubator.apache.org
18. SPDX 规范与 SBOM 工具链：spdx.dev；CycloneDX 规范：cyclonedx.org
19. Linux 内核 GPL 与 syscall exception 讨论历史：Linus Torvalds 在 LKML 上的多次声明与 COPYING 文件头部说明
20. Mulan PSL v2 中英文对照本与常见问答：license.coscl.org.cn

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

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

下一篇：中国开源数据库的协议选择：OceanBase、TiDB、Apache Doris