diff --git "a/zh-cn/contribute/OpenHarmony-TPC\344\273\243\347\240\201\350\256\270\345\217\257\350\257\201\346\214\207\345\257\274.md" "b/zh-cn/contribute/OpenHarmony-TPC\344\273\243\347\240\201\350\256\270\345\217\257\350\257\201\346\214\207\345\257\274.md"
new file mode 100755
index 0000000000000000000000000000000000000000..73e8edcb41f1f84ee532a814f7741f835dbb11a4
--- /dev/null
+++ "b/zh-cn/contribute/OpenHarmony-TPC\344\273\243\347\240\201\350\256\270\345\217\257\350\257\201\346\214\207\345\257\274.md"
@@ -0,0 +1,80 @@
+# OpenHarmony-TPC 代码许可证指导
+
+本指导明确了 OpenHarmony-TPC 中分发的代码的许可证的指导和规则。
+
+## 定义
+
+1. **原创代码**：指由贡献者独立创作并编写的源码软件代码，此类代码不含任何其它个人、法人和其他组织的第三方代码。
+2. **衍生作品代码**：指贡献者在上游开源软件基础上进行修改所编写或衍生创作的代码，包括对开源软件进行语言改写或功能适配（新增/修改特性、文件）等形式的衍生创作。
+3. **上游软件**：贡献者创作衍生作品代码的基础软件，一般情况下都是开源软件。
+
+## OpenHarmony-TPC 许可证指导
+
+原则上，OpenHarmony-TPC项目内的贡献代码均应提供源代码，并采用开源促进会OSI批准的开源许可证进行分发。
+
+1. 针对贡献者完全原创的代码，建议采用 Apache License 2.0(Apache-2.0)。
+
+2. 针对衍生作品代码，建议贡献者**必须检视并判断**本衍生作品代码的上游软件的许可证是否允许贡献者将本衍生作品代码进行开源贡献，以及上游软件的许可证允许贡献者采用何种许可证进行贡献。上述检视和判断的规则与指导请参照如下表格：
+
+ | 上游软件许可证类型 | 示例 | 上游软件许可证是否允许制作衍生作品以及进行开源贡献 | 衍生作品可以采用的许可证 | 建议衍生作品可以采用的许可证 |
+ | -------------------------- | ----------------------------------------- | -------------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
+ | Permissive License | MIT/BSD/ISC/Apache2.0等 | 是 | 通常无限制可 | Apache License 2.0 或者上游软件的原开源许可证 |
+ | Weak Copyleft License | MPLv2/CDDL/EPLv2/LGPLv2等类型许可证 | 是 | 多数情况下，衍生作品的许可证受到上游软件许可证约束，应该沿袭采用上游软件原许可证 | 上游软件的原开源许可证 |
+ | Copyleft License | GPLv2，GPLv3等类型许可证 | 是 | 多数情况下，衍生作品的许可证受到上游软件许可证约束，应该沿袭采用上游软件原许可证 | 上游软件的原开源许可证 |
+ | 特殊许可证/非开源许可证 | EULA/SSPL/Elastic License/BSL等类型许可证 | 需特别判断 | 需特别判断 | 需特别判断 |
+ | 多个上游软件对应多个许可证 | / | 需特别判断 | 需特别判断 | 需特别判断，建议的规则：
1.如所有许可证均为Permissive License， 建议采用Apache License 2.0；
2.如多个许可证中包含（Weak ）Copyleft License，建议采用（Weak ）Copyleft License。 |
+
+ 注：
+ 1.为便于理解：上表"Copyleft License"即指"Strong Copyleft License"，该类许可证明确要求所有基于原始作品的衍生作品亦须遵循相同的许可条款进行发布
+ 与传播。
+ 2.若上游软件许可证为Apache2.0，则衍生作品不可采用GPLV2许可证。
+
+## 上游软件许可证选择指导
+
+##### 引入：按照如下步骤完成引入环节的许可证选择
+
+1. 利用[许可证识别工具](https://compliance.openeuler.org/lvmeng-show)确定上游软件是否采用了标准许可证；对于非标准或变体许可证，需自行评估其规定的义务是否可履行。
+2. 识别上游软件是否包含依赖组件，并自行记录依赖组件的许可证。
+3. 若存在多许可证情况，根据实际使用场景，明确所需遵循的许可证。
+4. 综合前述信息，判断所识别的许可证属于哪一类型，并完成与项目许可证的兼容性分析。建议优先选择采用Permissive License的开源软件进行引用或适配；对于Weak Copyleft License的软件，应在选型阶段基于实际应用场景进行合理性评审；不建议引用或适配使用对商用有限制或包含不合理义务的License的上有软件。
+5. 若在查询过程中遇到不明确或未解决的问题，可以选择：a. 咨询公司法务部门，以获得专业的许可证阅读和实际情况判断；b. 与OpenHarmony社区合规SIG进行交流，通过提交issue的方式，在开源社区中寻求解答和指导。
+
+##### 开发：
+
+1. 开发过程中引入新上游开源软件时，需参考[引入阶段许可证选择规则](#####引入：按照如下步骤完成引入环节的许可证选择)。
+2. 原创代码：针对贡献者完全原创的代码，建议采用 Apache License 2.0。
+3. 衍生作品代码：
+
+ a. 功能适配：
+
+ 1）原有文件修改：针对源代码的调整，需完整保留原始上游软件的License和Copyright信息。
+
+ 2）新增文件：所有新增文件应遵循指导表格中提供的许可证判断规则，维护项目整体的合规性。
+
+ 3）语言改写：需保留原上游软件许可证信息，并在版权头中注明改写者信息，同时增加base on(上游软件信息)，例如test.ets文件由上游test.java衍生而来
+
+ 的，则其许可证与版权头写法如下：
+
+```
+/* xxx-License-Identifier: SBD-2.0 */
+/**
+* CopyRight (c) 2024 zhangsan
+*
+* Based on test.java originally written by
+* CopyRight (C) 2010 lisi
+**/
+```
+
+
+
+##### 发布：发布开源软件时，必须严格遵守以下规则
+
+1. 开源以为履行：版本发布时必须严格遵守所选许可证（需特别注意Copyleft License）的要求，包括但不限于提供完整的源代码、清晰的开源软件使用申明、列出所有组件及其对应的许可证信息，确保与上游软件的原始版权和许可声明一致。
+2. 许可证兼容性评估：版本发布前必须进行许可证兼容性风险评估，确保项目内各组件的许可证相互兼容。
+
+
+
+
+
+
+