第三方开源软件引入指导

目的

OpenHarmony遵从 Open Source Definition ，满足这一定义的软件，被OpenHarmony社区认同为开源软件。 提供易用、高质量的开源软件是OpenHarmony的重要目标，因第三方开源软件数量多，而社区开发人员同样数量多、分布广，为确保OpenHarmony项目的整体质量，特别拟定本指南，供社区贡献者参考。

范围

本指导适用于所有引入到OpenHarmony项目中的第三方开源软件。

本文的改进和修订说明

1. 本文档由OpenHarmony SIG-QA主导起草和维护。本文档的最新版本总可以在 这里 找到。
2. 任何对于本文中涉及的规则的增加，修改，删除都必须被追踪，请进入该追踪系统 。
3. 最终规则经过社区充分的讨论后，由PMC评审定稿。

软件引入与引入原则

什么是软件引入

一个软件的引入指的是为满足OpenHarmony中指定SIG的业务需求，申请将其引入到OpenHarmony项目中，具体的流程请参考的SIG管理章程 进行具体的开源软件引入，并确保整个引入的过程都必须可被追踪。

软件引入的基本要求

为便于第三方开源软件的维护与演进，在引入第三方开源软件时请参考如下原则：

1. 软件必须有明确的来源，引入到OpenHarmony的软件必须有清晰定义的上游社区。

2. 必须有明确的引入理由，若需要引入的软件在OpenHarmony项目中已存在，请重用该版本，避免多版本共存增加维护的复杂性。

3. 软件应该以源码方式引入，原则上二进制不应该被引入，应从源码构建。如果需要引入二进制，经由PMC评审后决定。

4. 软件应该在OpenHarmony上可以被正确构建，若该软件有尚未被引入的依赖软件，或者软件的运行或者构建依赖一个不能引入OpenHarmony的组件，需由SIG-Architecture评审后决定。

5. 引入软件到OpenHarmony项目中必须将其放置到单独的代码仓，命名统一为third_party_软件名称，其中软件名称和其官网保持一致。

6. 应当完整保留引入软件的官方代码仓目录结构、许可证及Copyright信息，不要修改第三方开源软件的原始许可证与Copyright信息。

7. 不建议引入未发布正式版本（如只发布Beta版本）的开源软件。

8. 不能引入有高危漏洞且无解决方案的版本。

9. 若需针对引入的开源软件进行修改，请将修改的代码放在该开源软件仓中，并确保满足该开源软件的许可证要求，修改的文件应当保持其原始许可证条款，新增的文件也建议采用相同的许可证条款。

10. 新引入的开源软件必须在其根目录提供README.OpenSource文件，在该文件中准确描述其软件名、许可证、许可文件位置、版本、对应版本的上游社区地址、软件的维护Owner、功能描述以及引入的原因。

11. 引入新软件到OpenHarmony时必须有对应的SIG负责管理，原则上如果没有SIG-Compliance以及相应SIG的确认，SIG-Architecture不批准相应软件的引入。当要批量引入多个软件时，可以求助SIG-Architecture主持发起SIG间的临时评审会议，提升协调效率。如因特殊原因不能满足上述要求但又需要引入，请联系邮箱：oh-legal@openatom.io。

12. 引入新的开源软件存在依赖其他开源软件时，不允许将被动依赖软件嵌套在引入的新的开源软件子目录中，必须剥离所有依赖软件项，并将其分别放置到单独的代码仓，命名统一为third_party_依赖软件名称，原因是嵌套放置依赖软件可能导致多同一款软件多版本、旧版本安全漏洞无法及时修复、开源义务履行合规的风险问题。

    • 依赖软件在编译构建部件命名，将新引入的主软件名作为依赖软件部件前缀命名，例如 part_name = “新引入主软件名_依赖软件名”
    • 新引入软件和依赖软件分别独立构建，通过external_deps来解决部件间依赖。

13. OpenHarmony对引入三方开源软件的归档目录要求：

    • 原则上如果您没有真正充分的理由将其存储在其他地方，且满足OpenHarmony许可证引入要求三方开源软件，统一归属于third_party根目录下；
    • 针对开发板引入且无法纳入OpenHarmony系统平台的三方开源软件，可以申请在以下位置存档，要求以上游开源软件名创建目录，并在对应目录下归档README.OpenSource说明文档；采取BUILD.gn方式独立构建，支撑开源义务声明信息的自动收集。

       device/soc/$(SOC_COMPANY)/third_party
       device/board/$(BOARD_COMPANY)/third_party
       vendor/$(PRODUCT_COMPANY)/third_party
    

14. OpenHarmony平台版本或版本构建中用到的预编译二进制或工具链，需提供如下信息：

    • 预编译二进制或工具链对应的源码，需要在OpenHarmony社区托管对应的源代码，并提供对应的构建指导，开源义务履行遵从指导；
    • 预编译二进制或工具链中引入的开源三方软件，需要遵从原则1~13;
    • 预编译二进制或工具链的说明文档:包括源码获取地址、构建指导、更新方法，随OpenHarmony版本或工具链归档到对应模块的根目录中；
    • 预编译的二进制或工具链对应的根目录需要提供完整开源义务履行声明文档；
    • 如果预编译文件来源于上游社区托管平台的二进制（譬如npm包等）。我们需要在归档二进制的地方提供以下信息，首先我们需要提供一个命名为README概要性描述文件，内容包括引入的背景描述和其官方托管地址；其次我们需要提供一个命名为NOTICE的开源义务履行声明的描述文件，内容包括其中涉及的没一个开源软件名称、版本号、以及对应的开源许可协议。

软件引入流程

软件引入前检查

提交申请

如需要引入新的软件，请参考SIG管理章程 进行具体的开源软件引入，并在申请材料中包含如下内容：

1、自检表

说明：

• OAT工具的使用方式请参考 https://gitee.com/openharmony-sig/tools_oat ，如对工具有改进建议请直接在社区提交ISSUE，也可Fork下来完善工具并提交PR。
• OAT报告原则上应当是清零，格式如下：

Invalid File Type Total Count: 0
License Not Compatible Total Count: 0
License Header Invalid Total Count: 0
Copyright Header Invalid Total Count: 0
No License File Total Count: 0
No Readme.OpenSource Total Count: 0
No Readme Total Count: 0

• LicenseFile.txt位于OAT工具运行目录的log目录下，此文件记录扫描目录下所有疑似许可证的文件，格式如下：

third_party_abcde/ LICENSEFILE LICENSE Apache-2.0
third_party_abcde/doc/ LICENSEFILE LICENSE Apache-2.0

2、OAT.xml文件

请参考 https://gitee.com/openharmony-sig/tools_oat/blob/master/README_zh.md ，完成OAT扫描问题确认及OAT.xml文件配置，申请中附上此文件内容（如果无任何需确认问题则无需配置）。

3、该仓的README.OpenSource文件内容，格式如下：

[
  {
    "Name": "softwarename",
    "License": "Apache-2.0",
    "License File": "LICENSE",
    "Version Number": "1.0.0",
    "Owner": "Zhangsan@xyz.com",
    "Upstream URL": "https://gitee.com/softwarecodesite/v1.0.0.zip",
    "Description": "...."
  },
  {
  ...
  }//如有多个许可证，请一一列举
]

新增三方开源软件评审

参考SIG-Architecture，SIG-Architecture会统一安排建仓评审。

第三方开源软件许可证要求

《许可证与特殊许可证评审指导》

软件退出与退出原则

什么是软件退出

1. 一个软件的退出指的是一个软件(项目)申请从OpenHarmony项目中删除，依照本文件描述的规则讨论，最终在OpenHarmony中移除的过程。
2. 该软件相关的SIG负责申报议题到PMC评审，管理软件退出。

软件退出原则

当满足以下两个条件时，OpenHarmony中软件的退出申请可以被立即执行，对应文件将从项目中直接删除。

1. 软件的License变化，或者其他法律法规影响了目前正在使用的版本，导致OpenHarmony因为法务风险，不能继续集成该软件。
2. 存在恶意代码或严重安全隐患且OpenHarmony社区无能力修复的，要求软件被立即移除。

除以上描述两种场景外，其它场景OpenHarmony对软件的退出实行过程化管理：

1. 随着技术演进与发展，软件因技术陈旧或架构落后，不能满足现有的应用场景被其他更优秀的软件所取代。
2. OpenHarmony已经集成的版本过于老旧，且软件新版本License或其他法律法规限制导致OpenHarmony不能升级新版本。
3. 软件来自知名社区或组织，社区或组织通过发布公告、修改软件仓库状态、将仓库放到特定目录下等方式告知停止维护的。
4. 软件来自个人、小型社区或组织，两年内未发布版本（含正式版本与测试版本），无明确版本计划，社区提交了有效的Bug或PR，社区半年以上未响应的。
5. 社区运营状态不明确，通过Issue或者邮件等方式询问社区是否继续维护，社区半年以上未响应或者答复停止维护的。

如果软件符合以上任何一条退出条件，PMC与相应SIG首先分析该软件在当前OpenHarmony社区中被依赖、被使用的情况。

1. 如果OpenHarmony中存在依赖关系，且短时间内不能解除，我们建议SIG新建分支代码仓，并主动进行社区维护动作。
2. 如果OpenHarmony中不存在依赖关系，或者短时间内可以解除，则责任SIG将软件从OpenHarmony正式发行中移出，并在相应的Release Notes中说明移除的原因及影响。

你可能感兴趣的鸿蒙文章

harmony 鸿蒙FAQ

harmony 鸿蒙OpenHarmony 32/64位可移植编程规范

harmony 鸿蒙OpenHarmony应用TS&JS编程指南

harmony 鸿蒙OpenHarmony Java 安全编程指南

harmony 鸿蒙JavaScript语言通用编程规范

harmony 鸿蒙开源社区文档写作规范

harmony 鸿蒙OpenHarmony日志打印规范

harmony 鸿蒙开源构建规范

harmony 鸿蒙C语言编程规范

harmony 鸿蒙OpenHarmony C&C++ 安全编程指南