!399 Add checklist and examples

* Update pmc to QA-SIG
* Add link to license and copyright check tool
* Add checklist and examples
* Add checklist and examples
* Add checklist and examples

zh-cn/contribute/第三方开源软件引入指导.md

 # 第三方开源软件引入指导
 
 ## 目的
+
 OpenHarmony遵从 [Open Source Definition](https://opensource.org/docs/osd) ，满足这一定义的软件，被OpenHarmony社区认同为开源软件。
 提供易用、高质量的开源软件是OpenHarmony的重要目标，因第三方开源软件数量多，而社区开发人员同样数量多、分布广，为确保OpenHarmony项目的整体质量，特别拟定本指南，供社区贡献者参考。
 
 ## 范围
+
 本指导适用于所有引入到OpenHarmony项目中的第三方开源软件。
 
 ## 本文的改进和修订说明
-1. 本文档由OpenHarmony PMC主导起草和维护。本文档的最新版本总可以在 [这里](https://gitee.com/openharmony/docs/blob/36955109ed21d73afe09fcb5a5bc7067ad6ce18b/zh-cn/contribute/%E7%AC%AC%E4%B8%89%E6%96%B9%E5%BC%80%E6%BA%90%E8%BD%AF%E4%BB%B6%E5%BC%95%E5%85%A5%E6%8C%87%E5%AF%BC.md) 找到。
+
+1. 本文档由OpenHarmony SIG-QA主导起草和维护。本文档的最新版本总可以在 [这里](https://gitee.com/openharmony/docs/blob/36955109ed21d73afe09fcb5a5bc7067ad6ce18b/zh-cn/contribute/%E7%AC%AC%E4%B8%89%E6%96%B9%E5%BC%80%E6%BA%90%E8%BD%AF%E4%BB%B6%E5%BC%95%E5%85%A5%E6%8C%87%E5%AF%BC.md)
+   找到。
 2. 任何对于本文中涉及的规则的增加，修改，删除都必须被追踪，请进入该追踪系统 。
-3. 最终规则经过社区充分的讨论后，由PMC定稿。
+3. 最终规则经过社区充分的讨论后，由PMC评审定稿。
 
 ## 软件引入与引入原则
+
 ### 什么是软件引入
+
 一个软件的引入指的是为满足OpenHarmony中指定SIG的业务需求，申请将其引入到OpenHarmony项目中，具体的流程请参考的[SIG管理章程](https://gitee.com/openharmony/community/tree/master/sig) 进行具体的开源软件引入，并确保整个引入的过程都必须可被追踪。
 
 ### 软件引入的基本要求
+
 为便于第三方开源软件的维护与演进，在引入第三方开源软件时请参考如下原则：
 
 1. 软件必须有明确的来源，引入到OpenHarmony的软件必须有清晰定义的上游社区。
@@ -26,43 +33,101 @@ OpenHarmony遵从 [Open Source Definition](https://opensource.org/docs/osd) ，
 5. 引入软件到OpenHarmony项目中必须将其放置到单独的代码仓或独立的目录，命名统一为third_party_软件名称，其中软件名称和其官网保持一致。
 6. 应当完整保留引入软件的官方代码仓目录结构、许可证及Copyright信息，不要修改第三方开源软件的原始许可证与Copyright信息。
 7. 不建议引入未发布正式版本（如只发布Beta版本）的开源软件。
-8. 若需针对引入的开源软件进行修改，请将修改的代码放在该开源软件仓中，并确保满足该开源软件的许可证要求，修改的文件应当保持其原始许可证条款，新增的文件也建议采用相同的许可证条款。
-9. 新引入的开源软件必须在其根目录提供README.OpenSource文件，在该文件中准确描述其软件名、许可证、许可文件位置、版本、对应版本的上游社区地址、软件的维护Owner、功能描述以及引入的原因。
-10. 引入新软件到OpenHarmony时必须有对应的SIG负责管理，原则上如果没有相应SIG的确认，PMC不批准相应软件的引入。当要批量引入多个软件时，可以求助PMC主持发起SIG间的临时评审会议，提升协调效率。
-如因特殊原因不能满足上述要求但又需要引入，请请联系邮箱：law@openatom.org。
+8. 不能引入有高危漏洞且无解决方案的版本。
+9. 若需针对引入的开源软件进行修改，请将修改的代码放在该开源软件仓中，并确保满足该开源软件的许可证要求，修改的文件应当保持其原始许可证条款，新增的文件也建议采用相同的许可证条款。
+10. 新引入的开源软件必须在其根目录提供README.OpenSource文件，在该文件中准确描述其软件名、许可证、许可文件位置、版本、对应版本的上游社区地址、软件的维护Owner、功能描述以及引入的原因。
+11. 引入新软件到OpenHarmony时必须有对应的SIG负责管理，原则上如果没有SIG-QA以及相应SIG的确认，PMC不批准相应软件的引入。当要批量引入多个软件时，可以求助PMC主持发起SIG间的临时评审会议，提升协调效率。 如因特殊原因不能满足上述要求但又需要引入，请请联系邮箱：law@openatom.org。
 
 ### 软件引入流程
+
 #### 软件引入前检查
 
-| 检查点 | 说明 |
+| 检查项 | 说明 |
 | :----- | :----- |
 | 归一化 | 1、检查该软件在OpenHarmony中是否已存在，原则上一款软件只在OpenHarmony中引入一次。 |
 | 来源可靠 | 1、应该从开源软件官网获取或官网指定的代码托管地址获取。 |
 | 社区活跃 | 1、软件来自知名社区或组织，社区或组织通过发布公告、修改软件仓库状态、将仓库放到特定目录下等方式告知停止维护的，不建议引入。<br>2、软件来自个人、小型社区或组织，两年内未发布版本（含正式版本与测试版本），无明确版本计划，社区提交了有效的Bug或PR，但是半年以上未响应的，不建议引入。<br>3、社区运营状态不明确，通过Issue 或者邮件等方式询问社区是否继续维护，半年以上未响应或者答复停止维护的，不建议引入。|
-| 规范化软件名称 | 1、 仓库命名统一为third_party_软件名称，其中软件名称和其官网保持一致。<br>2、 不允许以软件的子模块作为软件名。<br>3、 当软件是某个语言的开发库时，可以追加python-、perl-等前缀予以规范化管理。 |
+| 安全漏洞 | 1、检索业界已知公开的安全漏洞，如有高危漏洞需要有应对方案。|
+| 规范化软件名称 | 1、 仓库命名统一为third_party_软件名称，其中软件名称和其官网保持一致。<br>2、 不允许以软件的子模块作为软件名。<br>3、 当软件存在多个语言的开发库时，可在其官方命名前追加python-等前缀予以规范化管理。 |
 | 官网信息 | 1、在申请引入请求中准确描述该软件官方网址，如无正式官网则提供主流代码托管商上面对应的项目网址，不能使用maven、mvnrepository、springsource等托管库地址。<br>2、必须同时提供要引入版本的官方源代码包下载地址，以达到可溯源，如需要二进制包，请提供官方的二进制包下载地址。 |
 | License检查 | 1、待引入软件是否有license。 <br>2、入库的License是否和官网对应版本的License保持一致。<br>3、高风险license的开源软件谨慎引入，在引入前请充分评估并在申请时附上分析结论。 |
 
 #### 提交申请
 
-如需要引入新的软件，请参考的[SIG管理章程](https://gitee.com/openharmony/community/tree/master/sig) 进行具体的开源软件引入，并在申请材料中包含如下内容：
-1、引入该软件的具体价值，被哪些仓使用解决什么问题
-2、引入软件的相关信息：
-1）引入的软件名称及版本
-2）官网链接地址
-3）软件的许可证以及引入后以什么方式使用，如静态、动态链接到哪个模块，或跨被哪个进程跨进程调用等
-4）是否OpenHarmony项目已存在，如果存在要引入新版本的原因
-5）该软件的社区活跃情况
-3、引入该软件的具体方案：
-1）引入SIG名称及责任人
-2）引入后开源仓名称
-3）针对该软件进行OAT扫描的结果及OAT.xml内容，对于GPL、LGPL等非开放型许可证要描述具体的使用方式
-4）该仓的README.OpenSource内容
+如需要引入新的软件，请参考[SIG管理章程](https://gitee.com/openharmony/community/tree/master/sig) 进行具体的开源软件引入，并在申请材料中包含如下内容：
+
+1、自检表
+
+| 检查项 | 填写指导 | 自检结果示例 | 
+| :----- | :----- | :----- |
+| 软件名 | 描述该软件官方名称以及引入后的仓名，仓名统一为third_party_加上官方软件名称 | third_party_softwarename |
+| 软件官网地址 | 描述该软件官方网站链接地址 | https://softwaresite |
+| 软件版本号 | 描述该软件要引入的版本号，版本号为其社区正式发布的版本号，不要随意修改；未正式发布的版本不建议引入 | 1.0.0 |
+| 软件版本发布日期 | 描述该软件要引入的版本的社区发布日期 | 2021.01.01 |
+| 软件版本地址 | 描述该版本的官方下载链接地址，注意该地址必须为能定位到该具体版本发布包的下载URL | https://gitee.com/softwarecodesite/v1.0.0.zip |
+| 软件许可证 | 描述该版本的官方许可证名称及许可证文件的相对路径，如果是多许可证要完整描述，并说明各许可证的关系，如是And还是Or，或者是不同目录对应不同许可证 | Apache-2.0 |
+| 软件生命周期 | 描述该软件是否有LTS版本，多长时间发布一个版本，最近一年社区代码提交及Issue解决情况，是否有告知停止维护或演进 | 无LTS版本，6个月发布一个版本，近6个月有10次代码提交 |
+| 软件安全漏洞 | 描述该软件存在的业界公开的安全漏洞列表，包括漏洞号、级别、漏洞链接地址、是否已有补丁或解决方案 | 无业界公开漏洞 |
+| 业务场景 | 描述该软件被哪些仓使用,解决什么业务场景的问题 | 被XX仓静态链接使用，提升YYY能力 |
+| 归一化 | 描述社区是否已有此软件或类似软件，业界类似软件有哪些，为什么要新引入该软件或该版本 | 本社区还未引入此软件，业界相似软件有B、C，只有本软件许可证友好，且该软件生态较好，X、Y等公司也在使用 |
+| 许可证兼容性 | 1、描述使用该软件有哪些进程，各进程的许可证是什么，与要引入软件的许可证是否兼容。<br>2、使用OAT工具扫描要引入软件的源代码，申请时附上OAT工具生成的扫描报告（扫描问题应当清零）、LicenseFile.txt内容 | 1、此软件在用户态X进程中，静态链接使用，该进程的许可证为Apache-2.0，与该软件许可证一致，无兼容性问题；<br>2、OAT工具扫描生成的Result.txt, LicenseFile.txt内容<br>  |
+| 责任人 | 描述该软件引入到本社区后的SIG名称及维护责任人的Gitee用名及邮箱 | SIG XXX，Zhangsan，Zhangsan@xyz.com |
+
+说明：
+
+- 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": "...."
+  },
+  {
+  ...
+  }//如有多个许可证，请一一列举
+]
+```
+
+#### PMC评审
+
+参考[SIG管理章程](https://gitee.com/openharmony/community/tree/master/sig)，PMC会根据收到的PR统一安排SIG申请评审以及建仓。
 
 ### 第三方开源软件许可证要求
+
 1. 第三方开源软件许可证类型必须是[OSI](https://opensource.org/osd-annotated) 明确定义的。
 2. 第三方开源软件许可证必须与使用该开源软件的代码仓许可证兼容。
 3. 如下类型许可证可以引入到OpenHarmony项目中：
+
 * Apache License 2.0
 * Mulan Permissive Software License, Version 2
 * BSD 2-clause
@@ -85,6 +150,7 @@ OpenHarmony遵从 [Open Source Definition](https://opensource.org/docs/osd) ，
 * Zope Public License 2.0
 
 4. 如下类型许可证不建议引入到OpenHarmony项目中:
+
 * GNU GPL 1, 2, 3
 * GNU Affero GPL 3
 * GNU LGPL 2, 2.1, 3
@@ -116,7 +182,7 @@ OpenHarmony遵从 [Open Source Definition](https://opensource.org/docs/osd) ，
 * Sun Public License: SPL 1.0
 * Open Software License 3.0
 * Erlang Public License
-* UnRAR License 
+* UnRAR License
 * SIL Open Font License
 * Ubuntu Font License Version 1.0
 * IPA Font License Agreement v1.0
@@ -126,11 +192,14 @@ OpenHarmony遵从 [Open Source Definition](https://opensource.org/docs/osd) ，
 如要引入其它类型License或上述（4）所列License，请联系邮箱：law@openatom.org。
 
 ## 软件退出与退出原则
+
 ### 什么是软件退出
+
 1. 一个软件的退出指的是一个软件(项目)申请从OpenHarmony项目中删除，依照本文件描述的规则讨论，最终在OpenHarmony中移除的过程。
 2. 该软件相关的SIG负责申报议题到PMC评审，管理软件退出。
 
 ### 软件退出原则
+
 当满足以下两个条件时，OpenHarmony中软件的退出申请可以被立即执行，对应文件将从项目中直接删除。
 
 1. 软件的License变化，或者其他法律法规影响了目前正在使用的版本，导致OpenHarmony因为法务风险，不能继续集成该软件。
@@ -145,5 +214,6 @@ OpenHarmony遵从 [Open Source Definition](https://opensource.org/docs/osd) ，
 5. 社区运营状态不明确，通过Issue或者邮件等方式询问社区是否继续维护，社区半年以上未响应或者答复停止维护的。
 
 如果软件符合以上任何一条退出条件，PMC与相应SIG首先分析该软件在当前OpenHarmony社区中被依赖、被使用的情况。
+
 1. 如果OpenHarmony中存在依赖关系，且短时间内不能解除，我们建议SIG新建分支代码仓，并主动进行社区维护动作。
 2. 如果OpenHarmony中不存在依赖关系，或者短时间内可以解除，则责任SIG将软件从OpenHarmony正式发行中移出，并在相应的Release Notes中说明移除的原因及影响。
\ No newline at end of file

zh-cn/readme.md

@@ -61,6 +61,7 @@
     -   media：[媒体](application-dev/media/Readme-CN.md)
     -   connectivity：[网络与连接](application-dev/connectivity/Readme-CN.md)
     -   js-reference：[JS参考规范](application-dev/js-reference/Readme-CN.md)
+-   许可证及版权信息检查工具：[开源合规审查工具](https://gitee.com/openharmony-sig/tools_oat)    
 -   glossary：[术语](device-dev/glossary/术语.md)
 
 ## 版本更新<a name="section8910101119262"></a>