Description:[feature] optimize the management of thirdparty source software for devboard

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

@@ -12,7 +12,7 @@ This guide applies to all third-party open-source software to be introduced to t
 ## Improvements and Revisions
 
 1. This document is drafted and maintained by the OpenHarmony SIG QA. What you are reading now is the latest version of this document.
-   
+
 2. Any addition, modification, or deletion of the principles mentioned in this document can be traced in the tracing system.
 3. The PMC reviews and finalizes the principles after thorough discussion in the community.
 
@@ -40,6 +40,22 @@ For easier maintenance and evolution, comply with the following principles when
 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.
+13. OpenHarmony's archiving directory requirements for third-party software introduction.
+    - If you don't have a really good reason to store it elsewhere and under one of the permitted licenses belongs in third_party.
+    - For the dedicated third-party software introduction which belongs to the specail devboard, and is is not suitable introduced into the OpenHarmony platform, you could apply to store it in the following locations, Naming it in the format of **softwareName**, where **softwareName** must be an official name, and create README.OpenSource description file in the corresponding directory; Creating BUILD.gn to build it independently to support the automatic collection of open source obligation declaration.
+
+      ```
+       device/soc/$(SOC_COMPANY)/third_party
+       device/board/$(BOARD_COMPANY)/third_party
+       vendor/$(PRODUCT_COMPANY)/third_party
+      ```
+
+14. Precompiled binary or toolchain used in the OpenHarmony, the following information needs to be provided.
+    - The source code corresponding to the pre-compiled binary or toolchain, which needs to store the corresponding source code in the OpenHarmony community, and provide the corresponding build guide, and provide open source obligation statement guide;
+    - Third-party software introduction for precompiled binary or toolchain, need to meet the principles 1 ~ 13;
+    - The [prebuilt toolchain's description documentation](./prebuilts-readme-template.md): including source code acquisition address, build instructions, update methods, archived in the toolchain root directory with the toolchain build;
+    - The root directory corresponding to the pre-compiled binary or toolchain needs to provide notice file of the full open source obligation statement;
+    - If the precompiled binary files come from upstream service platform (e.g. npm packages, etc.). We need to provide the following information in the place where the binary is archived, first we need to provide a general description with the name **README**, include the following information: background description of the introduction and official website; next we need to provide a opensource obligation statement file with the name **NOTICE**, include the following information: software name, version, copyrights, and license information of every third-party open-source software.
 
 ### Software Introduction Process
 
@@ -64,10 +80,10 @@ Follow the process described in the [SIG Management Regulations](https://gitee.c
 | Check Item| Description| Self-Check Result Example|
 | :----- | :----- | :----- |
 | Software name| Provide the official name of the software and the repository name to which the software is introduced. The repository name is in the format of **third_party**_**softwareName**.| third_party_**softwareName**|
-| Official website| Provide the official website link of the software.| https://softwaresite |
+| Official website| Provide the official website link of the software.| <https://softwaresite> |
 | Software version| Provide the version number of the software to be introduced. The version number must be an official version number released by the community. Do not modify the version number or introduce a version that is not officially released.| 1.0.0 |
 | Software version release date| Provide the official release date of the software version.| 2021.01.01 |
-| Software version address| Provide the official download URL of the version. Note that the URL must be able to locate the release package of the specific version.| https://gitee.com/softwarecodesite/v1.0.0.zip |
+| Software version address| Provide the official download URL of the version. Note that the URL must be able to locate the release package of the specific version.| <https://gitee.com/softwarecodesite/v1.0.0.zip> |
 | Software license| Provide the official license name of the version and the relative path of the license file. If there are multiple licenses, list them all and describe their relationship, for example, And, Or, or different licenses for different directories.| Apache-2.0 |
 | Software lifecycle| Describe whether the software has an LTS version, how frequent a version is released, code submitted to the community in the last year, issue resolution status, and whether end of maintenance or evolution is notified.| No LTS version; one version released every six months; 10 code submissions in the last six months|
 | Security vulnerabilities| List disclosed security vulnerabilities in the software, including the vulnerability number, severity, link, and whether patches or solutions are available.| No disclosed vulnerabilities.|
@@ -121,9 +137,9 @@ Confirm the issues found by the OAT tool and configure the **OAT.xml** file. For
 ]
 ```
 
-#### PMC Review
+#### Open source software introduction Review
 
-Refer to the [SIG Management Regulations](https://gitee.com/openharmony/community/tree/master/sig). The PMC will arrange the SIG request review and repository construction based on the received PR.
+Refer to the [SIG-Architecture](https://gitee.com/openharmony/community/blob/master/sig/sig-architecture/sig-architecture_cn.md). The SIG-Architecture will arrange the review of the applying of creating new repository.
 
 ### License Requirements for Third-Party Open-Source Software
 
@@ -131,66 +147,66 @@ Refer to the [SIG Management Regulations](https://gitee.com/openharmony/communit
 2. The software license must be compatible with the license for the code repository.
 3. The following licenses for third-party open-source software are recommended in the OpenHarmony project:
 
-* Apache License 2.0
-* Mulan Permissive Software License, Version 2
-* BSD 2-clause
-* BSD 3-clause
-* DOM4J License
-* PostgreSQL License
-* Eclipse Distribution License 1.0
-* MIT
-* ISC
-* ICU
-* University of Illinois/NCSA
-* W3C Software License
-* zlib/libpng
-* Academic Free License 3.0
-* Python Software Foundation License
-* Python Imaging Library Software License
-* Boost Software License Version 1.0
-* WTF Public License
-* UNICODE, INC. LICENSE AGREEMENT - DATA FILES AND SOFTWARE
-* Zope Public License 2.0
+- Apache License 2.0
+- Mulan Permissive Software License, Version 2
+- BSD 2-clause
+- BSD 3-clause
+- DOM4J License
+- PostgreSQL License
+- Eclipse Distribution License 1.0
+- MIT
+- ISC
+- ICU
+- University of Illinois/NCSA
+- W3C Software License
+- zlib/libpng
+- Academic Free License 3.0
+- Python Software Foundation License
+- Python Imaging Library Software License
+- Boost Software License Version 1.0
+- WTF Public License
+- UNICODE, INC. LICENSE AGREEMENT - DATA FILES AND SOFTWARE
+- Zope Public License 2.0
 
 4. The following licenses for third-party open-source software are not recommended in the OpenHarmony project:
 
-* GNU GPL 1, 2, 3
-* GNU Affero GPL 3
-* GNU LGPL 2, 2.1, 3
-* QPL
-* Sleepycat License
-* Server Side Public License (SSPL) version 1
-* Code Project Open License (CPOL)
-* BSD-4-Clause/BSD-4-Clause (University of California-Specific)
-* Facebook BSD+Patents license
-* NPL 1.0/NPL 1.1
-* The Solipsistic Eclipse Public License
-* The "Don't Be A Dick" Public License
-* JSON License
-* Binary Code License (BCL)
-* Intel Simplified Software License
-* JSR-275 License
-* Microsoft Limited Public License
-* Amazon Software License (ASL)
-* Java SDK for Satori RTM license
-* Redis Source Available License (RSAL)
-* Booz Allen Public License
-* Creative Commons Non-Commercial
-* Sun Community Source License 3.0
-* Common Development and Distribution Licenses: CDDL 1.0 and CDDL 1.1
-* Common Public License: CPL 1.0
-* Eclipse Public License: EPL 1.0
-* IBM Public License: IPL 1.0
-* Mozilla Public Licenses: MPL 1.0, MPL 1.1, and MPL 2.0
-* Sun Public License: SPL 1.0
-* Open Software License 3.0
-* Erlang Public License
-* UnRAR License
-* SIL Open Font License
-* Ubuntu Font License Version 1.0
-* IPA Font License Agreement v1.0
-* Ruby License
-* Eclipse Public License 2.0: EPL 2.0
+- GNU GPL 1, 2, 3
+- GNU Affero GPL 3
+- GNU LGPL 2, 2.1, 3
+- QPL
+- Sleepycat License
+- Server Side Public License (SSPL) version 1
+- Code Project Open License (CPOL)
+- BSD-4-Clause/BSD-4-Clause (University of California-Specific)
+- Facebook BSD+Patents license
+- NPL 1.0/NPL 1.1
+- The Solipsistic Eclipse Public License
+- The "Don't Be A Dick" Public License
+- JSON License
+- Binary Code License (BCL)
+- Intel Simplified Software License
+- JSR-275 License
+- Microsoft Limited Public License
+- Amazon Software License (ASL)
+- Java SDK for Satori RTM license
+- Redis Source Available License (RSAL)
+- Booz Allen Public License
+- Creative Commons Non-Commercial
+- Sun Community Source License 3.0
+- Common Development and Distribution Licenses: CDDL 1.0 and CDDL 1.1
+- Common Public License: CPL 1.0
+- Eclipse Public License: EPL 1.0
+- IBM Public License: IPL 1.0
+- Mozilla Public Licenses: MPL 1.0, MPL 1.1, and MPL 2.0
+- Sun Public License: SPL 1.0
+- Open Software License 3.0
+- Erlang Public License
+- UnRAR License
+- SIL Open Font License
+- Ubuntu Font License Version 1.0
+- IPA Font License Agreement v1.0
+- Ruby License
+- Eclipse Public License 2.0: EPL 2.0
 
 If you want to introduce the software that complies with the unrecommended licenses listed in **4** or other licenses that are not mentioned, send an email to oh-legal@openatom.io.
 

en/contribute/prebuilts-readme-template.md

+Prebuilts for Clang/LLVM-based tools used in OpenHarmony
+====================================================
+
+1. For the latest version of this doc, please make sure to visit:
+[OpenHarmony Clang/LLVM-based Tools Readme Doc](https://gitee.com/openharmony/third_party_llvm-project/blob/master/llvm-build/README.md)
+
+2. Build Instructions
+------------------
+
+```
+# Get source code
+repo init -u https://gitee.com/openharmony/manifest.git -b llvm_toolchain-dev
+repo sync -c 
+repo forall -c 'git lfs pull'
+cp -r toolchain/llvm-project/llvm-build toolchain
+
+# Build Clang/LLVM-based prebuilts tool
+./toolchain/llvm-project/llvm-build/env_prepare.sh
+python3 ./toolchain/llvm-build/build.py
+```
+
+3. Update Prebuilts
+----------------
+From an OpenHarmony project run:
+
+```
+$ ./build/prebuilts_download.sh
+```

zh-cn/contribute/prebuilts-readme-template.md

+OpenHarmony中的Clang/LLVM-based预编译工具 说明
+====================================================
+
+1. 获取最新版本的说明文档，请参考如下：
+[基于Clang/LLVM-based OpenHarmony工具说明文档](https://gitee.com/openharmony/third_party_llvm-project/blob/master/llvm-build/README.md)
+
+2. 构建指导
+------------------
+
+```
+# 获取代码
+repo init -u https://gitee.com/openharmony/manifest.git -b llvm_toolchain-dev
+repo sync -c 
+repo forall -c 'git lfs pull'
+cp -r toolchain/llvm-project/llvm-build toolchain
+
+# 编译基于Clang/LLVM的 prebuilts工具
+./toolchain/llvm-project/llvm-build/env_prepare.sh
+python3 ./toolchain/llvm-build/build.py
+```
+
+3. 更新预编译工具
+----------------
+在OpenHarmony项目中运行脚本:
+
+```
+$ ./build/prebuilts_download.sh
+```

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

@@ -40,6 +40,22 @@ OpenHarmony遵从 [Open Source Definition](https://opensource.org/docs/osd) ，
 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;
+    - [预编译二进制或工具链的说明文档](./prebuilts-readme-template.md):包括源码获取地址、构建指导、更新方法，随OpenHarmony版本或工具链归档到对应模块的根目录中；
+    - 预编译的二进制或工具链对应的根目录需要提供完整开源义务履行声明文档；
+    - 如果预编译文件来源于上游社区托管平台的二进制（譬如npm包等）。我们需要在归档二进制的地方提供以下信息，首先我们需要提供一个命名为**README**概要性描述文件，内容包括引入的背景描述和其官方托管地址；其次我们需要提供一个命名为**NOTICE**的开源义务履行声明的描述文件，内容包括其中涉及的没一个开源软件名称、版本号、以及对应的开源许可协议。
 
 ### 软件引入流程
 
@@ -47,7 +63,7 @@ OpenHarmony遵从 [Open Source Definition](https://opensource.org/docs/osd) ，
 
 | 检查项 | 说明 |
 | :----- | :----- |
-| 归一化 | 1、检查该软件在OpenHarmony中是否已存在，原则上一款软件只在OpenHarmony中引入一次。 |
+| 归一化 | 1、检查该软件在OpenHarmony中是否已存在，原则上一款软件只在OpenHarmony中引入一次。|
 | 来源可靠 | 1、应该从开源软件官网获取或官网指定的代码托管地址获取。 |
 | 社区活跃 | 1、软件来自知名社区或组织，社区或组织通过发布公告、修改软件仓库状态、将仓库放到特定目录下等方式告知停止维护的，不建议引入。<br>2、软件来自个人、小型社区或组织，两年内未发布版本（含正式版本与测试版本），无明确版本计划，社区提交了有效的Bug或PR，但是半年以上未响应的，不建议引入。<br>3、社区运营状态不明确，通过Issue 或者邮件等方式询问社区是否继续维护，半年以上未响应或者答复停止维护的，不建议引入。|
 | 安全漏洞 | 1、检索业界已知公开的安全漏洞，如有高危漏洞需要有应对方案。|
@@ -61,13 +77,13 @@ OpenHarmony遵从 [Open Source Definition](https://opensource.org/docs/osd) ，
 
 1、自检表
 
-| 检查项 | 填写指导 | 自检结果示例 | 
+| 检查项 | 填写指导 | 自检结果示例 |
 | :----- | :----- | :----- |
 | 软件名 | 描述该软件官方名称以及引入后的仓名，仓名统一为**third_party**_**加上官方软件名称** | third_party_**softwarename** |
-| 软件官网地址 | 描述该软件官方网站链接地址 | https://softwaresite |
+| 软件官网地址 | 描述该软件官方网站链接地址 | <https://softwaresite> |
 | 软件版本号 | 描述该软件要引入的版本号，版本号为其社区正式发布的版本号，不要随意修改；未正式发布的版本不建议引入 | 1.0.0 |
 | 软件版本发布日期 | 描述该软件要引入的版本的社区发布日期 | 2021.01.01 |
-| 软件版本地址 | 描述该版本的官方下载链接地址，注意该地址必须为能定位到该具体版本发布包的下载URL | https://gitee.com/softwarecodesite/v1.0.0.zip |
+| 软件版本地址 | 描述该版本的官方下载链接地址，注意该地址必须为能定位到该具体版本发布包的下载URL | <https://gitee.com/softwarecodesite/v1.0.0.zip> |
 | 软件许可证 | 描述该版本的官方许可证名称及许可证文件的相对路径，如果是多许可证要完整描述，并说明各许可证的关系，如是And还是Or，或者是不同目录对应不同许可证 | Apache-2.0 |
 | 软件生命周期 | 描述该软件是否有LTS版本，多长时间发布一个版本，最近一年社区代码提交及Issue解决情况，是否有告知停止维护或演进 | 无LTS版本，6个月发布一个版本，近6个月有10次代码提交 |
 | 软件安全漏洞 | 描述该软件存在的业界公开的安全漏洞列表，包括漏洞号、级别、漏洞链接地址、是否已有补丁或解决方案 | 无业界公开漏洞 |
@@ -78,7 +94,7 @@ OpenHarmony遵从 [Open Source Definition](https://opensource.org/docs/osd) ，
 
 说明：
 
-- OAT工具的使用方式请参考 https://gitee.com/openharmony-sig/tools_oat ，如对工具有改进建议请直接在社区提交ISSUE，也可Fork下来完善工具并提交PR。
+- OAT工具的使用方式请参考 <https://gitee.com/openharmony-sig/tools_oat> ，如对工具有改进建议请直接在社区提交ISSUE，也可Fork下来完善工具并提交PR。
 - OAT报告原则上应当是清零，格式如下：
 
 ```
@@ -100,7 +116,7 @@ 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文件配置，申请中附上此文件内容（如果无任何需确认问题则无需配置）。
+请参考 <https://gitee.com/openharmony-sig/tools_oat/blob/master/README_zh.md> ，完成OAT扫描问题确认及OAT.xml文件配置，申请中附上此文件内容（如果无任何需确认问题则无需配置）。
 
 3、该仓的README.OpenSource文件内容，格式如下：
 
@@ -121,9 +137,9 @@ third_party_abcde/doc/ LICENSEFILE LICENSE Apache-2.0
 ]
 ```
 
-#### PMC评审
+#### 新增三方开源软件评审
 
-参考[SIG管理章程](https://gitee.com/openharmony/community/tree/master/sig)，PMC会根据收到的PR统一安排SIG申请评审以及建仓。
+参考[SIG-Architecture](https://gitee.com/openharmony/community/blob/master/sig/sig-architecture/sig-architecture_cn.md)，SIG-Architecture会统一安排建仓评审。
 
 ### 第三方开源软件许可证要求
 
@@ -131,66 +147,66 @@ third_party_abcde/doc/ LICENSEFILE LICENSE Apache-2.0
 2. 第三方开源软件许可证必须与使用该开源软件的代码仓许可证兼容。
 3. 如下类型许可证可以引入到OpenHarmony项目中：
 
-* Apache License 2.0
-* Mulan Permissive Software License, Version 2
-* BSD 2-clause
-* BSD 3-clause
-* DOM4J License
-* PostgreSQL License
-* Eclipse Distribution License 1.0
-* MIT
-* ISC
-* ICU
-* University of Illinois/NCSA
-* W3C Software License
-* zlib/libpng
-* Academic Free License 3.0
-* Python Software Foundation License
-* Python Imaging Library Software License
-* Boost Software License Version 1.0
-* WTF Public License
-* UNICODE, INC. LICENSE AGREEMENT - DATA FILES AND SOFTWARE
-* Zope Public License 2.0
+- Apache License 2.0
+- Mulan Permissive Software License, Version 2
+- BSD 2-clause
+- BSD 3-clause
+- DOM4J License
+- PostgreSQL License
+- Eclipse Distribution License 1.0
+- MIT
+- ISC
+- ICU
+- University of Illinois/NCSA
+- W3C Software License
+- zlib/libpng
+- Academic Free License 3.0
+- Python Software Foundation License
+- Python Imaging Library Software License
+- Boost Software License Version 1.0
+- WTF Public License
+- UNICODE, INC. LICENSE AGREEMENT - DATA FILES AND SOFTWARE
+- Zope Public License 2.0
 
 4. 如下类型许可证不建议引入到OpenHarmony项目中:
 
-* GNU GPL 1, 2, 3
-* GNU Affero GPL 3
-* GNU LGPL 2, 2.1, 3
-* QPL
-* Sleepycat License
-* Server Side Public License (SSPL) version 1
-* Code Project Open License (CPOL)
-* BSD-4-Clause/BSD-4-Clause (University of California-Specific)
-* Facebook BSD+Patents license
-* NPL 1.0/NPL 1.1
-* The Solipsistic Eclipse Public License
-* The "Don't Be A Dick" Public License
-* JSON License
-* Binary Code License (BCL)
-* Intel Simplified Software License
-* JSR-275 License
-* Microsoft Limited Public License
-* Amazon Software License (ASL)
-* Java SDK for Satori RTM license
-* Redis Source Available License (RSAL)
-* Booz Allen Public License
-* Creative Commons Non-Commercial
-* Sun Community Source License 3.0
-* Common Development and Distribution Licenses: CDDL 1.0 and CDDL 1.1
-* Common Public License: CPL 1.0
-* Eclipse Public License: EPL 1.0
-* IBM Public License: IPL 1.0
-* Mozilla Public Licenses: MPL 1.0, MPL 1.1, and MPL 2.0
-* Sun Public License: SPL 1.0
-* Open Software License 3.0
-* Erlang Public License
-* UnRAR License
-* SIL Open Font License
-* Ubuntu Font License Version 1.0
-* IPA Font License Agreement v1.0
-* Ruby License
-* Eclipse Public License 2.0: EPL 2.0
+- GNU GPL 1, 2, 3
+- GNU Affero GPL 3
+- GNU LGPL 2, 2.1, 3
+- QPL
+- Sleepycat License
+- Server Side Public License (SSPL) version 1
+- Code Project Open License (CPOL)
+- BSD-4-Clause/BSD-4-Clause (University of California-Specific)
+- Facebook BSD+Patents license
+- NPL 1.0/NPL 1.1
+- The Solipsistic Eclipse Public License
+- The "Don't Be A Dick" Public License
+- JSON License
+- Binary Code License (BCL)
+- Intel Simplified Software License
+- JSR-275 License
+- Microsoft Limited Public License
+- Amazon Software License (ASL)
+- Java SDK for Satori RTM license
+- Redis Source Available License (RSAL)
+- Booz Allen Public License
+- Creative Commons Non-Commercial
+- Sun Community Source License 3.0
+- Common Development and Distribution Licenses: CDDL 1.0 and CDDL 1.1
+- Common Public License: CPL 1.0
+- Eclipse Public License: EPL 1.0
+- IBM Public License: IPL 1.0
+- Mozilla Public Licenses: MPL 1.0, MPL 1.1, and MPL 2.0
+- Sun Public License: SPL 1.0
+- Open Software License 3.0
+- Erlang Public License
+- UnRAR License
+- SIL Open Font License
+- Ubuntu Font License Version 1.0
+- IPA Font License Agreement v1.0
+- Ruby License
+- Eclipse Public License 2.0: EPL 2.0
 
 如要引入其它类型License或上述（4）所列License，请联系邮箱：oh-legal@openatom.io。
 
@@ -219,4 +235,4 @@ third_party_abcde/doc/ LICENSEFILE LICENSE Apache-2.0
 如果软件符合以上任何一条退出条件，PMC与相应SIG首先分析该软件在当前OpenHarmony社区中被依赖、被使用的情况。
 
 1. 如果OpenHarmony中存在依赖关系，且短时间内不能解除，我们建议SIG新建分支代码仓，并主动进行社区维护动作。
-2. 如果OpenHarmony中不存在依赖关系，或者短时间内可以解除，则责任SIG将软件从OpenHarmony正式发行中移出，并在相应的Release Notes中说明移除的原因及影响。
\ No newline at end of file
+2. 如果OpenHarmony中不存在依赖关系，或者短时间内可以解除，则责任SIG将软件从OpenHarmony正式发行中移出，并在相应的Release Notes中说明移除的原因及影响。