0cbff81d创建于 2024年12月25日历史提交

第三方开源软件引入指导

目的

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

范围

本指导适用于所有引入到ArkUI-X中的第三方开源软件。

本文的改进和修订说明

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

软件引入与引入原则

什么是软件引入

一个软件的引入指的是为满足ArkUI-X中指定的业务需求，申请将其引入到ArkUI-X中，并确保整个引入的过程都必须可被追踪。

软件引入的基本要求

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

软件必须有明确的来源，引入到ArkUI-X的软件必须有清晰定义的上游社区。
必须有明确的引入理由，若需要引入的软件在ArkUI-X中已存在，请重用该版本，避免多版本共存增加维护的复杂性。
软件应该以源码方式引入，原则上二进制不应该被引入，应从源码构建。如果需要引入二进制，经由PMC评审后决定。
软件应该在ArkUI-X上可以被正确构建，若该软件有尚未被引入的依赖软件，或者软件的运行或者构建依赖一个不能引入ArkUI-X的组件，需由PMC评审后决定。
引入软件到ArkUI-X中必须将其放置到单独的代码仓或独立的目录，命名统一为third_party_软件名称，其中软件名称和其官网保持一致。
应当完整保留引入软件的官方代码仓目录结构、许可证及Copyright信息，不要修改第三方开源软件的原始许可证与Copyright信息。
不建议引入未发布正式版本（如只发布Beta版本）的开源软件。
不能引入有高危漏洞且无解决方案的版本。
若需针对引入的开源软件进行修改，请将修改的代码放在该开源软件仓中，并确保满足该开源软件的许可证要求，修改的文件应当保持其原始许可证条款，新增的文件也建议采用相同的许可证条款。
新引入的开源软件必须在其根目录提供README.OpenSource文件，在该文件中准确描述其软件名、许可证、许可文件位置、版本、对应版本的上游社区地址、软件的维护Owner、功能描述以及引入的原因。

软件引入流程

软件引入前检查

检查项	说明
归一化	1、检查该软件在ArkUI-X中是否已存在，原则上一款软件只在ArkUI-X中引入一次。
来源可靠	1、应该从开源软件官网获取或官网指定的代码托管地址获取。
社区活跃	1、软件来自知名社区或组织，社区或组织通过发布公告、修改软件仓库状态、将仓库放到特定目录下等方式告知停止维护的，不建议引入。 2、软件来自个人、小型社区或组织，两年内未发布版本（含正式版本与测试版本），无明确版本计划，社区提交了有效的Bug或PR，但是半年以上未响应的，不建议引入。 3、社区运营状态不明确，通过Issue 或者邮件等方式询问社区是否继续维护，半年以上未响应或者答复停止维护的，不建议引入。
安全漏洞	1、检索业界已知公开的安全漏洞，如有高危漏洞需要有应对方案。
规范化软件名称	1、仓库命名统一为third_party_软件名称，其中软件名称和其官网保持一致。 2、不允许以软件的子模块作为软件名。 3、当软件存在多个语言的开发库时，可在其官方命名前追加python-等前缀予以规范化管理。
官网信息	1、在申请引入请求中准确描述该软件官方网址，如无正式官网则提供主流代码托管商上面对应的项目网址，不能使用maven、mvnrepository、springsource等托管库地址。 2、必须同时提供要引入版本的官方源代码包下载地址，以达到可溯源，如需要二进制包，请提供官方的二进制包下载地址。
License检查	1、待引入软件是否有license。 2、入库的License是否和官网对应版本的License保持一致。 3、高风险license的开源软件谨慎引入，在引入前请充分评估并在申请时附上分析结论。

提交申请

如需要引入新的软件，请向ArkUI-X PMC提交开源软件引入请求，并在申请材料中包含如下内容：

1、自检表

检查项	填写指导	自检结果示例
软件名	描述该软件官方名称以及引入后的仓名，仓名统一为third_party_加上官方软件名称	third_party_softwarename
软件官网地址	描述该软件官方网站链接地址	https://softwaresite
软件版本号	描述该软件要引入的版本号，版本号为其社区正式发布的版本号，不要随意修改；未正式发布的版本不建议引入	1.0.0
软件版本发布日期	描述该软件要引入的版本的社区发布日期	2021.01.01
软件版本地址	描述该版本的官方下载链接地址，注意该地址必须为能定位到该具体版本发布包的下载URL	https://gitcode.com/softwarecodesite/v1.0.0.zip
软件许可证	描述该版本的官方许可证名称及许可证文件的相对路径，如果是多许可证要完整描述，并说明各许可证的关系，如是And还是Or，或者是不同目录对应不同许可证	Apache-2.0
软件生命周期	描述该软件是否有LTS版本，多长时间发布一个版本，最近一年社区代码提交及Issue解决情况，是否有告知停止维护或演进	无LTS版本，6个月发布一个版本，近6个月有10次代码提交
软件安全漏洞	描述该软件存在的业界公开的安全漏洞列表，包括漏洞号、级别、漏洞链接地址、是否已有补丁或解决方案	无业界公开漏洞
业务场景	描述该软件被哪些仓使用,解决什么业务场景的问题	被XX仓静态链接使用，提升YYY能力
归一化	描述社区是否已有此软件或类似软件，业界类似软件有哪些，为什么要新引入该软件或该版本	本社区还未引入此软件，业界相似软件有B、C，只有本软件许可证友好，且该软件生态较好，X、Y等公司也在使用
许可证兼容性	描述使用该软件有哪些进程，各进程的许可证是什么，与要引入软件的许可证是否兼容。	此软件在用户态X进程中，静态链接使用，该进程的许可证为Apache-2.0，与该软件许可证一致，无兼容性问题；
责任人	描述该软件引入到本社区后的维护责任人的GitCode用名及邮箱	Zhangsan，Zhangsan@xyz.com

2、OAT.xml文件

请参考，完成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://gitcode.com/softwarecodesite/v1.0.0.zip",
    "Description": "...."
  },
  {
  ...
  }//如有多个许可证，请一一列举
]

PMC评审

PMC会根据收到的PR统一安排ArkUI-X PMC申请评审以及建仓。

软件退出与退出原则

什么是软件退出

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

软件退出原则

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

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

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

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

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

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