Description: [feature] Introducing optimized process specifications for dependency software

Bug: NA
Test: It could be normally readable
Signed-off-by: NJinguang Dong <dongjinguang@huawei.com>

en/contribute/introducing-third-party-open-source-software.md

@@ -29,14 +29,17 @@ For easier maintenance and evolution, comply with the following principles when
 1. Make sure the software comes from a clearly defined upstream community.
 2. Provide a sound reason for software introduction. If the software to be introduced already exists in the OpenHarmony project, reuse it to avoid maintenance complexity caused by coexistence of multiple versions.
 3. Introduce the software in the form of source code, rather than binary files. If a piece of software needs to be introduced in the form of binary files, the PMC should review the request and make a decision.
-4. Make sure the software can be correctly built on the OpenHarmony project. If the software has dependency software that has not been introduced, or the running or build of the software depends on a component that cannot be introduced, the PMC should review the request and make a decision.
-5. Place the software in an independent code repository or directory and name it in the format of **third_party_*****softwareName***, where *softwareName* must be an official name.
+4. Make sure the software can be correctly built on the OpenHarmony project. If the software has dependency software that has not been introduced, or the running or build of the software depends on a component that cannot be introduced, the SIG-Architecture should review the request and make a decision.
+5. Place the software in an independent code repository and name it in the format of **third_party_*****softwareName***, where *softwareName* must be an official name.
 6. Retain the directory structure, license, and copyright information of the official code repository of the software. Do not modify the original license and copyright information.
 7. Do not introduce any software version that has not been officially released, for example, the Beta version.
 8. Do not introduce any software version that has high-risk vulnerabilities and does not provide solutions.
 9. If you need to modify the software, place the new code in the software repository and ensure that the new code meets the license requirements of the software. Retain the original license for the modified files, and use the same license for the new files (recommended).
 10. Provide the **README.OpenSource** file in the root directory of the software repository. Include the following information in the file: software name, license, license file location, version, upstream community address of the corresponding version, software maintenance owner, function description, and introduction reason.
-11. Make sure the software you introduce is under the custody of a domain SIG. In principle, the PMC will deny the introduction of a piece of software without the confirmation of the SIG QA and the corresponding domain SIG. When introducing multiple pieces of software at a time, you can ask the PMC to hold a temporary review meeting between SIGs for faster introduction. If you want to introduce a piece of software but fail to meet the preceding requirements, send an email to law@openatom.org.
+11. Make sure the software you introduce is under the custody of a domain SIG. In principle, the SIG-Architecture will deny the introduction of a piece of software without the confirmation of the SIG-Compliance and the corresponding domain SIG. When introducing multiple pieces of software at a time, you can ask the PMC to hold a temporary review meeting between SIGs for faster introduction. If you want to introduce a piece of software but fail to meet the preceding requirements, send an email to law@openatom.org.
+12. When software introduction depends on other dependency software, it is not allowed to nest the dependency software in the subdirectory of the software introduction, and all dependency softwares must be placed in separate repository, and name it in the format of **third_party_*****softwareName***, because nested placement of dependency software may lead to multiple versions of the same software, old versions of security vulnerabilities cannot be fixed in a timely, and will risk the opensource compliance issues.
+    - Dependency software are named in the compiled BUILD.gn with part name by prefixing the newly software introduction name, e.g. part_name = "software_introduction_name_dependency software_name".
+    - The inter-component dependencies between software introduction and dependency software are resolved via external_deps.
 
 ### Software Introduction Process
 

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

@@ -29,14 +29,17 @@ OpenHarmony遵从 [Open Source Definition](https://opensource.org/docs/osd) ，
 1. 软件必须有明确的来源，引入到OpenHarmony的软件必须有清晰定义的上游社区。
 2. 必须有明确的引入理由，若需要引入的软件在OpenHarmony项目中已存在，请重用该版本，避免多版本共存增加维护的复杂性。
 3. 软件应该以源码方式引入，原则上二进制不应该被引入，应从源码构建。如果需要引入二进制，经由PMC评审后决定。
-4. 软件应该在OpenHarmony上可以被正确构建，若该软件有尚未被引入的依赖软件，或者软件的运行或者构建依赖一个不能引入OpenHarmony的组件，需由PMC评审后决定。
-5. 引入软件到OpenHarmony项目中必须将其放置到单独的代码仓或独立的目录，命名统一为third_party_软件名称，其中软件名称和其官网保持一致。
+4. 软件应该在OpenHarmony上可以被正确构建，若该软件有尚未被引入的依赖软件，或者软件的运行或者构建依赖一个不能引入OpenHarmony的组件，需由SIG-Architecture评审后决定。
+5. 引入软件到OpenHarmony项目中必须将其放置到单独的代码仓，命名统一为third_party_软件名称，其中软件名称和其官网保持一致。
 6. 应当完整保留引入软件的官方代码仓目录结构、许可证及Copyright信息，不要修改第三方开源软件的原始许可证与Copyright信息。
 7. 不建议引入未发布正式版本（如只发布Beta版本）的开源软件。
 8. 不能引入有高危漏洞且无解决方案的版本。
 9. 若需针对引入的开源软件进行修改，请将修改的代码放在该开源软件仓中，并确保满足该开源软件的许可证要求，修改的文件应当保持其原始许可证条款，新增的文件也建议采用相同的许可证条款。
 10. 新引入的开源软件必须在其根目录提供README.OpenSource文件，在该文件中准确描述其软件名、许可证、许可文件位置、版本、对应版本的上游社区地址、软件的维护Owner、功能描述以及引入的原因。
-11. 引入新软件到OpenHarmony时必须有对应的SIG负责管理，原则上如果没有SIG-QA以及相应SIG的确认，PMC不批准相应软件的引入。当要批量引入多个软件时，可以求助PMC主持发起SIG间的临时评审会议，提升协调效率。 如因特殊原因不能满足上述要求但又需要引入，请请联系邮箱：law@openatom.org。
+11. 引入新软件到OpenHarmony时必须有对应的SIG负责管理，原则上如果没有SIG-Compliance以及相应SIG的确认，SIG-Architecture不批准相应软件的引入。当要批量引入多个软件时，可以求助SIG-Architecture主持发起SIG间的临时评审会议，提升协调效率。如因特殊原因不能满足上述要求但又需要引入，请请联系邮箱：law@openatom.org。
+12. 引入新的开源软件存在依赖其他开源软件时，不允许将被动依赖软件嵌套在引入的新的开源软件子目录中，必须剥离所有依赖软件项，并将其分别放置到单独的代码仓，命名统一为third_party_依赖软件名称，原因是嵌套放置依赖软件可能导致多同一款软件多版本、旧版本安全漏洞无法及时修复、开源义务履行合规的风险问题。
+    - 依赖软件在编译构建部件命名，将新引入的主软件名作为依赖软件部件前缀命名，例如 part_name = "新引入主软件名_依赖软件名"
+    - 新引入软件和依赖软件分别独立构建，通过external_deps来解决部件间依赖。
 
 ### 软件引入流程