Description:[fix] update legal email address for OpenHarmony

Bug: NA
Test: Email can be accessed normally
Signed-off-by: NJinguang Dong <dongjinguang@huawei.com>

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

@@ -30,13 +30,13 @@ For easier maintenance and evolution, comply with the following principles when
 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 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.
+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 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.
+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 oh-legal@openatom.io.
 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.
@@ -51,7 +51,7 @@ For easier maintenance and evolution, comply with the following principles when
 | Source| Check whether the software is downloaded from its official website or source specified on the official website.|
 | Community activeness| 1. Do not introduce software from a community or organization that notifies users of software maintenance termination by releasing a bullet, modifying the software repository status, or moving the software repository in a specified directory.<br>2. Do not introduce software from an individual, a small community, or an organization that has not released a version (either official or test version) within two years, does not have a clear version roadmap, or does not respond to any valid bug or pull request in the community.<br>3. Do not introduce software from a community that is not longer maintained or does not respond to any operating status related issue or email for more than half a year.|
 | Security vulnerability| 1. Search for disclosed security vulnerabilities in the industry, and check whether solutions are provided if there are high-risk vulnerabilities in the software.|
-| Software name| 1. Name the repository in the format of **third_party_*****softwareName***, where *softwareName* must be the same as the official name.<br>2. Do not use the sub-module name of the software as the software name.<br>3. If the software has development libraries in multiple languages, add prefixes such as **python-** to the official software name for standardized management.|
+| Software name| 1. Name the repository in the format of **third_party**_**softwareName**, where **softwareName** must be the same as the official name.<br>2. Do not use the sub-module name of the software as the software name.<br>3. If the software has development libraries in multiple languages, add prefixes such as **python-** to the official software name for standardized management.|
 | Official website information| 1. Describe the official website of the software in the request. If there is no official website, provide the project URL on a mainstream code hosting platform. Dot not use the hosting library addresses such as Maven, mvnrepository, and SpringSource.<br>2. Provide the official download address of the software version source package for traceability. If a binary package is required, provide the official download address of the binary package.|
 | License| 1. Check whether the software to be introduced has a license.<br>2. Check whether the imported license is consistent with the license of the corresponding version on the official website of the software.<br>3. Exercise caution when introducing open-source software with high-risk licenses. Before introducing the software, fully evaluate the risk and attach the analysis conclusion in the request.|
 
@@ -63,7 +63,7 @@ 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*|
+| 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 |
 | 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 |
@@ -192,7 +192,7 @@ Refer to the [SIG Management Regulations](https://gitee.com/openharmony/communit
 * 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 law@openatom.org.
+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.
 
 ## Software Exit and Exit Principles
 

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

@@ -30,13 +30,13 @@ OpenHarmony遵从 [Open Source Definition](https://opensource.org/docs/osd) ，
 2. 必须有明确的引入理由，若需要引入的软件在OpenHarmony项目中已存在，请重用该版本，避免多版本共存增加维护的复杂性。
 3. 软件应该以源码方式引入，原则上二进制不应该被引入，应从源码构建。如果需要引入二进制，经由PMC评审后决定。
 4. 软件应该在OpenHarmony上可以被正确构建，若该软件有尚未被引入的依赖软件，或者软件的运行或者构建依赖一个不能引入OpenHarmony的组件，需由SIG-Architecture评审后决定。
-5. 引入软件到OpenHarmony项目中必须将其放置到单独的代码仓，命名统一为third_party_软件名称，其中软件名称和其官网保持一致。
+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间的临时评审会议，提升协调效率。如因特殊原因不能满足上述要求但又需要引入，请请联系邮箱：law@openatom.org。
+11. 引入新软件到OpenHarmony时必须有对应的SIG负责管理，原则上如果没有SIG-Compliance以及相应SIG的确认，SIG-Architecture不批准相应软件的引入。当要批量引入多个软件时，可以求助SIG-Architecture主持发起SIG间的临时评审会议，提升协调效率。如因特殊原因不能满足上述要求但又需要引入，请请联系邮箱：oh-legal@openatom.io。
 12. 引入新的开源软件存在依赖其他开源软件时，不允许将被动依赖软件嵌套在引入的新的开源软件子目录中，必须剥离所有依赖软件项，并将其分别放置到单独的代码仓，命名统一为third_party_依赖软件名称，原因是嵌套放置依赖软件可能导致多同一款软件多版本、旧版本安全漏洞无法及时修复、开源义务履行合规的风险问题。
     - 依赖软件在编译构建部件命名，将新引入的主软件名作为依赖软件部件前缀命名，例如 part_name = "新引入主软件名_依赖软件名"
     - 新引入软件和依赖软件分别独立构建，通过external_deps来解决部件间依赖。
@@ -51,7 +51,7 @@ OpenHarmony遵从 [Open Source Definition](https://opensource.org/docs/osd) ，
 | 来源可靠 | 1、应该从开源软件官网获取或官网指定的代码托管地址获取。 |
 | 社区活跃 | 1、软件来自知名社区或组织，社区或组织通过发布公告、修改软件仓库状态、将仓库放到特定目录下等方式告知停止维护的，不建议引入。<br>2、软件来自个人、小型社区或组织，两年内未发布版本（含正式版本与测试版本），无明确版本计划，社区提交了有效的Bug或PR，但是半年以上未响应的，不建议引入。<br>3、社区运营状态不明确，通过Issue 或者邮件等方式询问社区是否继续维护，半年以上未响应或者答复停止维护的，不建议引入。|
 | 安全漏洞 | 1、检索业界已知公开的安全漏洞，如有高危漏洞需要有应对方案。|
-| 规范化软件名称 | 1、 仓库命名统一为third_party_软件名称，其中软件名称和其官网保持一致。<br>2、 不允许以软件的子模块作为软件名。<br>3、 当软件存在多个语言的开发库时，可在其官方命名前追加python-等前缀予以规范化管理。 |
+| 规范化软件名称 | 1、 仓库命名统一为**third_party**_**软件名称**，其中软件名称和其官网保持一致。<br>2、 不允许以软件的子模块作为软件名。<br>3、 当软件存在多个语言的开发库时，可在其官方命名前追加python-等前缀予以规范化管理。 |
 | 官网信息 | 1、在申请引入请求中准确描述该软件官方网址，如无正式官网则提供主流代码托管商上面对应的项目网址，不能使用maven、mvnrepository、springsource等托管库地址。<br>2、必须同时提供要引入版本的官方源代码包下载地址，以达到可溯源，如需要二进制包，请提供官方的二进制包下载地址。 |
 | License检查 | 1、待引入软件是否有license。 <br>2、入库的License是否和官网对应版本的License保持一致。<br>3、高风险license的开源软件谨慎引入，在引入前请充分评估并在申请时附上分析结论。 |
 
@@ -63,7 +63,7 @@ OpenHarmony遵从 [Open Source Definition](https://opensource.org/docs/osd) ，
 
 | 检查项 | 填写指导 | 自检结果示例 | 
 | :----- | :----- | :----- |
-| 软件名 | 描述该软件官方名称以及引入后的仓名，仓名统一为third_party_加上官方软件名称 | third_party_softwarename |
+| 软件名 | 描述该软件官方名称以及引入后的仓名，仓名统一为**third_party**_**加上官方软件名称** | third_party_**softwarename** |
 | 软件官网地址 | 描述该软件官方网站链接地址 | https://softwaresite |
 | 软件版本号 | 描述该软件要引入的版本号，版本号为其社区正式发布的版本号，不要随意修改；未正式发布的版本不建议引入 | 1.0.0 |
 | 软件版本发布日期 | 描述该软件要引入的版本的社区发布日期 | 2021.01.01 |
@@ -192,7 +192,7 @@ third_party_abcde/doc/ LICENSEFILE LICENSE Apache-2.0
 * Ruby License
 * Eclipse Public License 2.0: EPL 2.0
 
-如要引入其它类型License或上述（4）所列License，请联系邮箱：law@openatom.org。
+如要引入其它类型License或上述（4）所列License，请联系邮箱：oh-legal@openatom.io。
 
 ## 软件退出与退出原则