!1508 【孵化出口标准】补充棱镜七彩FossLicense告警清零要求及合规SIG运作共识

* 提交合规SIG运作，开源合规培训计划，开源合规角色文档

sig/sig_compliance/docs/合规SIG运作治理章程.md

+# Compliance-SIG 治理公约
+
+## 合规SIG能力小组设置
+
+合规SIG 根据工作内容需要，设置以下4个能力型小组，以支撑合规相关工作开展。
+- 流程规范文档组: 负责拟定社区开源合规运作的规范、流程、基准、行为准则
+- 知识体系及布道推广组：负责组织赋能培训、推广交流，包括对应业界最佳实践洞察和开源合规培训教材
+- 工程工具组：负责开源合规工程工具方案及落地，包括对应设计及IT操作文档
+- 合规评审及治理组：负责社区开源合规事务，包括开源合规评审，开源合规ISSUE等的治理、组织代码开源合规审查等
+
+基于业界标准+OpenHarmony社区开发痛点等业务驱动，通过上述能力组的例行运作，不断完善社区的合规治理能力。
+
+## 合规SIG例会运作
+合规SIG例会采取轮值主持形式，以Co-Chair 进行轮值，每位Co-Chair主持周期为一个月，每月轮换一次，以自然月为准。
+合规SIG能力小组所有输出的评审，在合规sig例会共同评审，通报进展及风险，协同各小组工作的开展。
+
+## 合规SIG角色设置
+为了使社区席位设置规范化和标准化，让社区参与者更好的融入社区,
+- Compliance-SIG 基于[OpenHarmony社区角色定义](https://gitee.com/openharmony/community/blob/master/zh/guidelines_role_growth.md)，继承三种角色：**SIG Leader**、**committer**和**contributer**。
+- 基于能力小组形式，新增**能力组 Leader** 角色
+- 基于例会运作形式，新增**Co-Chair** 角色
+
+
+## 选举与退出
+
+合规SIG成员，整体遵从社区[OpenHarmony社区角色定义及晋升机制](https://gitee.com/openharmony/community/blob/master/zh/guidelines_role_growth.md),并为进一步保证SIG成员的多样性和贡献优先导向，细化补充以下规则
+
+- SIG Leader： 作为社区标准角色，合规SIG内部进行提名和投票，推举最终候选人后，报送PMC项目管理委员会后批准后，可担任对应角色。合规SIG内部共识：SIG Leader 每次任期为1年，最多连任1次，SIG内选举时，存在多名提名候选人时，以获得票数最多者作为最终候选人； 若SIG内选举时，仅一名候选人，需获得committer总数 2/3以上同意票, 若未达到 2/3 同意票，则需在合规SIG例会澄清，并最终经PMC审核是否可以担任SIG Leader。
+
+- SIG Committer： 作为社区标准角色，合规SIG内部进行提名和投票，满足要求后，报送PMC项目管理委员会后批准后，可担任对应角色。合规SIG内部共识：合规SIG 候选committer由现Committer提名，由于合规SIG非业务部件，无独立代码仓，且交付件具有多样性，在贡献衡量中不仅包括代码和文档贡献，因此对[OpenHarmony社区角色定义及晋升机制](https://gitee.com/openharmony/community/blob/master/zh/guidelines_role_growth.md)中Committer晋升标准中的贡献要求进行适配，并不再区分Approver和Reviewer，合规SIG成员均可进行Review，贡献要求以**合规SIG贡献衡量指标**中的贡献行为均可认定为合规SIG有效贡献，原则上Committer候选人需有至少3个月以上在合规SIG贡献的记录，有效贡献次数不少于10次。
+
+- SIG 能力组Leader： 作为合规SIG扩展角色，由合规SIG自行管理，每次任期为1年，为保持能力建设的延续性，可连任，可基于SIG共识直接推选，如有多人竞选则，参考SIG Leader竞选规则。
+
+- Co-Chair： 作为合规SIG扩展角色，由合规SIG自行管理，当前开放报名担任，可基于SIG共识直接推选，如有多人竞选则，参考SIG Leader竞选规则。待SIG成熟后，由commiter中推选，。
+
+
+Compliance-SIG 选举周期初步设置时间为每年的6月份和12月份（SIG Leader和 能力组 Leader 任期为一年，按任期选举）。
+
+合规SIG组应定期审视项目贡献者和活跃度，在选举周期内，设置以下衡量指标：
+
+## 贡献衡量指标
+
+合规SIG对社区参与者的贡献做出了一系列衡量指标，衡量时间为当前选举周期，包括但不限于以下内容：
+
+流程规范类：
+
+1、提交PR数（包括制定、翻译、修复问题等）
+
+2、提交ISSUE数（自己修复的PR不重复计划Issue）
+
+3、提交Review数
+
+赋能培训及布道推广类：
+
+1、输出培训教材数（包括拟定、翻译等）
+
+2、提供培训次数
+
+3、外部布道活动
+
+工程工具类：
+
+1、提交PR数（包括制定、翻译、修复问题等）
+
+2、提交ISSUE数（自己修复的PR不重复计划Issue）
+
+3、提交Review数
+
+4、输出工具方案、改进意见数（非PR承载的）
+
+5、输出指导文档数（非PR承载的，包括翻译等）
+
+社区合规治理类：
+
+1、提交PR数（包括制定、翻译、修复问题等）
+
+2、提交ISSUE数（自己修复的PR不重复计划Issue）
+
+3、提交Review数
+
+4、评审会议提出的评审意见数（推荐通过Issue承载，无Issue的可单独举证）
+
+5、回答社区问题数
+
+SIG运作类：
+
+1、议题分享次数
+
+2、引入新成员数
+
+3、会议主持次数
+
+4、担任导师
+
+成员都可能在上述不同维度有贡献，每个单项项目的贡献不限制次数门槛，以整体的贡献来衡量。
+
+合规SIG仓库创建一个相应的贡献指标表格，用于统计相应的贡献指标，各参与者可自行提交PR到表格中，并由轮值Co-Chair完成合入。表格内容如下：
+
+| 参与者 | 合规SIG例会参与次数 | 例会或线下meetup分享次数 | issue或PR闭环 | 发现或提出工具相关的bug、改进意见 | 流程、教程、翻译等文档类工作 | 技术贡献 | 担任导师 | 其它特殊贡献 |
+| ------ | ------------------- | ------------------------ | ------------- | --------------------------------- | ---------------------- | -------- | -------- | ------------ |
+|        |                     |                          |               |                                   |                        |          |          |              |
+
+合规SIG遵从[openHarmony社区行为准则](https://www.openharmony.cn/rule)，若出现恶意刷指标、发布垃圾信息等行为，合规SIG可能采取的措施包括但不限于：
+
+- 删除内容
+- 屏蔽内容
+
+
+## SIG **contributer**
+
+### 成为contributer
+
+contributer定义是长期活跃在社区的参与者。其社区行为符合上述定义的贡献指标一条或以上，或者获得当前committer一半以上的认可。
+
+### contributer权利
+
+合规SIG组contributer有希望晋升成为committer。
+
+- 合规SIG首页展示当前的contributer名单
+- 获得社区活动、meetup等活动讲师资格
+
+## SIG committer
+
+### Committer 权利
+
+- OpenHarmony社区合规SIG Committer身份席位
+- 合规SIG Leader的选举和被选举权、合规SIG Committer的提名和投票权
+- 例行开源合规评审的评审和投票权
+- 合规SIG 所有关键决策的投票权，一人一票，决策投票按照半数以上原则
+
+### Committer 义务
+
+合规SIG Committer继承社区[OpenHarmony社区角色定义及晋升机制](https://gitee.com/openharmony/community/blob/master/zh/guidelines_role_growth.md), 并补充以下要求：
+
+- 参与合规SIG的双周例会次数不低于70%，例会时间冲突应委托他人参与
+
+## Co-Chair
+
+### Co-Chair的权利与义务
+
+合规SIG按照[Co-Chari成员列表](https://shimo.im/sheets/B1Aw1d18GeFygLqm/gofnm) 的顺序进行轮值，轮值周期为一个自然月，在轮值期间，主要负责这一段时间合规SIG的例会主持、运营工作等，并做好交接工作。
+
+
+## 能力组 Leader
+
+### 能力组 Leader的权利与义务
+
+能力组 Leader负责本能力领域的能力建设和能力积累，协同本能力领域内的成员，共同建设本能力域的相关知识和实践。
+
+## 章程修改
+
+sig-compliance的章程修改，由committer提出修改意见，所有committer参与投票，获得2/3 committer同意方可修改。

sig/sig_compliance/docs/开源合规培训计划.md

+| 课程                       | 描述                                                                          | 培训时间    | 工委会 | 合规SIG Leader | 法务顾问 | Committer | PMC | 架构SIG | Release SIG | 基础设施SIG  | 资料SIG Leader | QA SIG Leader | 合规SIG-合规流程规范文档组组长 | 合规SIG-合规知识体系及布道推广组 | 合规SIG-工程工具组 | 合规SIG-合规评审及治理组 |
+|--------------------------|-----------------------------------------------------------------------------|---------|-----|--------------|------|-----------|-----|-------|-------------|----------|--------------|---------------|-------------------|--------------------|-------------|----------------|
+| OpenChain简介              | OpenChain项目。一个简短的历史。谁受益，它是如何运作的，关键概念，为什么它对OpenHarmony社区有利。                  | 2023.8  | √   | √            | √    | √         | √   | √     | √           |          |              |               | √                 | √                  | √           | √              |
+| OpenHarmony社区中的OpenChain | OpenHarmony社区如何实现开源。软件开发和项目结构。谁是关键人物？社区开源合规政策简介、在哪里可以找到以及如有疑问可以联系谁          | 2023.8  | √   | √            | √    | √         | √   | √     | √           | √        | √            | √             | √                 | √                  | √           | √              |
+| 什么是知识产权？                 | 介绍与软件有关的版权、专利和其他知识产权。什么是许可证，如果不合规会发生什么？                                     | 2023.7  | √   | √            |      | √         | √   | √     | √           |          | √            | √             | √                 | √                  | √           | √              |
+| 开源合规及开源许可证简介             | 为什么我们需要遵守。 “合规”是什么样的？开源许可证要求我们遵守的典型事情； 开源许可证的主要类型。开源定义和四种自由。与专有和其他非开源许可证的对比 | 2023.7  | √   | √            |      | √         | √   | √     | √           |          |              |               |                   |                    |             |                |
+| 开源审核的关键软件概念              | 软件与其他软件组合的不同方式，以及对合规的影响                                                     | 2023.7  | √   | √            |      | √         | √   | √     | √           |          |              |               | √                 |                    |             | √              |
+| 开源合规评审规则及流程指导            | 社区如何管理其流程以确保遵守开源许可义务                                                        | 2023.9  | √   | √            | √    | √         | √   | √     | √           |          |              |               |                   |                    |             |                |
+| OpenHarmony社区开源合规治理简介    | 社区如何使用端到端的合规管理来确保合规的持续性。                                                    | 2023.9  | √   | √            | √    | √         | √   | √     | √           |          |              |               |                   |                    | √           |                |
+| 避免合规陷阱                   | 可能出现的典型问题以及如何报告和纠正违规行为。如何识别问题。了解入站和出站许可                                     | 2023.√0 | √   | √            |      | √         | √   | √     | √           |          |              |               |                   |                    |             |                |
+| 社区开发者合规指南                | 首先如何尽量减少出现的问题。解释公司的代码选择政策如何运作。                                              | 2023.√0 |     | √            | √    |           |     |       |             |          |              |               |                   |                    |             |                |
+

sig/sig_compliance/docs/开源合规角色职责及能力要求.md

+| 示例角色          | openharmony社区对应角色  | 角色代码       | 姓名          | 角色描述                                                         | 能力和理解力（概要）                    | 能力和理解力（详情）                                                          | 主要职责                                                                                                                                                                                          |
+|---------------|--------------------|------------|-------------|--------------------------------------------------------------|-------------------------------|---------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| 开源合规委员会成员     | 工委会执行总监            | cbm        | 张明修         | openharmony工委会执行总监，全面负责社区开源合规和战略。问题从开源合规主管上报给工委会             | 知识产权风险（开源）、开发过程               | 社区治理架构、沟通技巧                                                         | 工委会执行总监负责：应负责openharmony 社区整体开源合规政策的审定，关键合规行为的审核和授权，重大合规问题的统筹，负责社区的外联职责，包括社区联络、项目社区管理和回答有关社区开源战略的一般性问题                                                                                        |
+| 开源合规主管        | 合规sig leader       | clead      | 陈雅旬         | 合规sig leader，负责社区开源合规日常执行。向openharmony工委会及pmc成员报告            | 社区治理、开源政策（流程）、软件架构            | 知识产权风险、开发过程、沟通技巧                                                    | 开源合规主管应负责： 应主要负责解决日常内部合规问题，以及更新和审核本政策。a.审核、实施和传达本政策；b.审核和实施开源合规相关问题的培训和评估；c.对已识别的许可证进行分类；d.不断评估有关开源合规的最新问题，包括参与适当的论坛、用户组和邮件列表，并定期与法律[和合规]顾问保持联系；e.让openharmony工委会成员了解受开源政策影响的活动的最新情况;         |
+| 开源合规法律顾问      | 法务与合规组组长           | extcounsel | 沈芬/余甜       | 负责接受与开源许可问题相关的外部咨询，并负责确保按照开源政策进行处理。就开源许可的合规和流程提供法律建议。        | 社区治理、开源政策（流程）、软件架构            | 知识产权风险和许可问题、开源政策和流程（法律问题）、开源许可。                                     | 法务与合规组组长负责为a.协助pmc及合规sig进行项目相关代码的合规管控工作，包括但不限于评审项目代码扫描结果，分析许可证相关问题等；b.制订和修改本开源项目相关的各法律合规制度；c.参与和设计本开源项目合规赋能方案、整体战略合规体系等;d.本开源项目日常合规审查及合规纠纷支撑处理；e.向openharmony工作委员会等openharmony项目治理组织提供法律咨询意见; |
+| 开发组组长/开源联络人   | pmc 主席             | devlead    | 任革林         | pmc主席，负责新技术项目引入和孵化流程、社区技术治理和运作规范流程                           | 社区治理、开源政策（流程）、软件架构            | 知识产权风险和许可问题、团队管理结构、开源政策、编码技巧。沟通技巧。管理技能。                             | 负责整体协调开源合规与社区规划、特性开发及issue处理工作 a.负责社区管理工作，包括开源社区版本规划、架构看护、特性代码开发维护、版本及补丁规划等；b.发布和处理社区需求，为开源社区提供技术架构指导和技术决策；c.处理社区bug、issue、邮件列表等渠道开发者反馈问题；d.负责pmc、committer成员的 选举和退出，制定pmc、committer协作机制；     |
+| 架构师           | 架构sig leader       | arch       | 任革林         | 架构sig leader，负责制定openharmony架构设计原则，oopenharmony架构定义、设计、演进和看护 | 社区开发治理。 openchain 政策和计划。      | openharmony整体架构。了解行业标准和市场发展。了解架构选择引发的知识产权问题。对产品功能的深入了解。沟通技巧。了解客户需求。 | 负责开源三方见选型符合开源合规要求 a.负责openharmony架构（包括子系统/部件/代码仓的增加，合并，拆分和删除）相关的设计评审，《架构设计原则》和《openharmony 系统架构》修订。b.负责新增三方开源软件选项评估，包含合规中license审核                                                            |
+| 发布工程师         | releasesig  leader | releng     | 赵鹏          | 确保在计划下开发的软件打包发布                                              | 社区开发治理。 openchain 政策和计划。      | 与许可、入站和出站许可的兼容性有关的知识产权问题。访问 bom 和审核合规文件。                            | 负责发布过程满足开源合规要求。负责规划和计划版本的发行时间表。a. 在开发/测试周期中跟踪（更新updates或功能feature）的开发状态。b. 发布协调（在qa，发布工程师，技术委员会等范围内），参与相关组和发布相关等会议。c. 负责项目的交付过程协调和发布质量标准的审核（包含合规要求）                                           |
+| 开发运维专家        | 基础设施sig leader     | devops     | 王意明         | 管理开发工具链                                                      | 社区开发治理。 openchain 政策和计划。      | 本开源项目的整体架构。了解行业标准和市场发展，以及工具链的可用性。了解工具链选择引发的知识产权问题。沟通技巧。了解开发人员的需求。   | 负责提供开源合规所需的工具链支撑。a.负责将openharmony官网源码开源, 并更新、维护、升级官网架构和内容 sig组将不断的吸引开发者为网站不断完善、更新、升级、修正; b. 将openharmony cicd门禁源码开源, 并更新、维护、升级门禁功能 sig组将不断的吸引开发者为 cicd 门禁不断完善、更新、升级、修正;                       |
+| 软件开发人员（高级）    | 业务committer        | seniordev  | 业务committer | 各sig下的committer，具有代码审核权限                                     | 社区治理、开源政策（流程）、软件架构            | 团队管理结构。开源政策。与项目相关的编码技能。                                             | 负责在门禁层面审核提交者的pr是否符合开源合规要求，并进行指导                                                                                                                                                               |
+| 资料专家          | 资料sig leader       | doc        | 杨妮          | 为本开源项目开发的软件准备用户文档                                            | 涵盖作为计划的一部分发布的任何产品的知识产权事务的法律矩阵 | 了解任何计划的产品功能。沟通技巧                                                    | 负责审核文档中合规问题。a. 处理openharmony版本配套开发者文档的构建和发布; b. 参与讨论openharmony文档的规划，并及时响应用户反馈; c. 检查文档，发现文档问题并修改; d. 帮助开发者参与openharmony的文档贡献，提供标准和内容编辑上的支持。                                                  |
+| 质量管理专家        | qa sig leader      | qm         | 邢文华         | 负责软件质量管理                                                     | 团队管理结构。 openchain 政策和计划。      | 了解开发过程和计划的产品架构。对工具链的理解。沟通技巧。安全问题和补救方面的专业知识                          | 负责社区开发过程中对合规质量的审查，特别是sig孵化毕业，版本发布等环节; 组织制定社区开发相关流程，组织sig组转正评审。 审视社区开发、运营各sig组运作，发现并推动相关团队优化改进                                                                                                 |
+| 内部openchain讲师 | 合规sig committer    | octrain    | 高亮          | 就社区实施 openchain 规范对项目人员进行培训                                  | 社区开源合规治理                      | openchain 目标、政策、社区实践和计划、沟通技巧                                        | 负责openharmony openchain规范的布道和落地，负责推进openharmony社区 通过openchain认证                                                                                                                               |
+| 扩展角色          | 合规sig-合规流程规范文档组组长  |            | 高亮          | 负责拟定和起草合规流程及文档                                               | 社区开发治理。 openchain 政策和计划。      | 了解社区合规开发流程                                                          | 负责拟定和起草合规流程及文档 ，如以下1. 《开源政策指导》;2. 《合规角色、职责、要求》;3. 《开源合规类issue管理指导》; 4. 《义务履行交付制品说明》 等"                                                                                                        |
+| 扩展角色          | 合规sig-合规知识体系及布道推广组 |            | 赵鹏（软通）      | 负责制定合规培训计划等                                                  | 社区开发治理。 openchain 政策和计划。      | 了解业界最佳合规实践，了解推广布道方式                                                 | 负责组织洞察和了解合规业界最佳实践，负责制定布道推广计划                                                                                                                                                                  |
+| 扩展角色          | 合规sig-工程工具组        |            | 杨灏为         | 负责合规工具链                                                      | 社区开发治理。 openchain 政策和计划。      | 了解业界合规工具链最佳实践，熟悉社区开发流程                                              | 负责openharmony 合规工具链的设计和实现                                                                                                                                                                     |
+| 扩展角色          | 合规sig-合规评审及治理组     |            | 陈一雄         | 负责合规评审及治理                                                    | 社区开发治理。 openchain 政策和计划。      | 了解业界合规治理最佳实践，熟悉社区开发流程                                               | 负责openharmony社区孵化毕业及版本发布中开源合规相关评审                                                                                                                                                             |
+

sig/sig_compliance/sig_compliance_cn.md

@@ -39,6 +39,12 @@
 - 社区合规及法务问题的最终解释权
 - 社区合规治理标准规范的最终审核权
 
+
+## 代码仓
+- 代码仓地址：
+  - SIG-Compliance ：https://gitee.com/openharmony/community/tree/master/sig/sig_compliance
+  - OAT开源审查工具 ：https://gitee.com/openharmony-sig/tools_oat
+
 ## SIG组成员
 
 ### Leader
@@ -58,25 +64,37 @@
 - 欢迎加入
 ### Contributor列表
 - 欢迎加入
+- @lainslin(https://gitee.com/lainslin)
+- @bayanxing(https://gitee.com/bayanxing)
+- @pengzhaon(https://gitee.com/pengzhaon)
+- @chaowang96(https://gitee.com/chaowang96)
+- @hawiii(https://gitee.com/hawiii)
+- @shihuanan(https://gitee.com/shihuanan)
+- @fang-xiao-100(https://gitee.com/fang-xiao-100)
+- @zw0601(https://gitee.com/zw0601)
+- @pratinaGAO(https://gitee.com/pratinaGAO)
+- @YixiongChen(https://gitee.com/YixiongChen)
 
 ## 会议
- - 会议时间：公开的会议时间：北京时间，每周五 下午，14:00点~15:00点
- - 会议申报：[OpenHarmony sig_compliance Meeting Proposal](https://etherpad.openharmony.cn/p/compliance)
- - 会议链接：[见链接](https://etherpad.openharmony.cn/p/compliance)
+ - 会议时间：公开的会议时间：北京时间，每周五 上午，10:45~11:45
+ - 会议申报：[OpenHarmony SIG-Compliance Meeting Proposal](https://shimo.im/sheets/B1Aw1d18GeFygLqm/MODOC)
+ - 会议链接：[见链接](https://shimo.im/sheets/B1Aw1d18GeFygLqm/MODOC)
  - 会议通知：请[订阅](https://lists.openatom.io/postorius/lists/dev.openharmony.io)邮件列表 dev@openharmony.io 获取会议链接
- - 会议纪要: [归档链接地址](https://gitee.com/openharmony-sig/sig-content)
-
+ - 会议纪要: [归档链接地址](https://gitee.com/openharmony-sig/sig-content/tree/master/compliance)
+ - 协作文档：[重点工作及核心组成员](https://shimo.im/sheets/B1Aw1d18GeFygLqm/gofnm)
 ## 联系方式(可选)
 
 - 邮件列表：dev@openharmony.io
-- 微信群：NA
+- 邮件列表tag [compliance-sig]
+- Zulip群组：已停止
+- 微信群：Openharmony合规SIG ，可加微信：gaoliang021
 
 ## 加入我们（Join Us）
 
 合规SIG欢迎所有对开源合规有兴趣的爱好者、志愿者、学者、专家、律师、学生的加入， 加入合规SIG无需特殊的技能要求和经验要求，您可以通过以下**任意一个途径**，明示您有意愿加入合规SIG，我们接到您的明示后，会在本文件的Contributor列表中添加您的基本信息以将您确认为合规SIG的成员
   - 邮件声明加入：通过向[dev@openharmony.io](https://lists.openatom.io/postorius/lists/dev.openharmony.io)邮件列表发送加入合规SIG申请，并同时主送SIG Leader, 请注意在邮件主题前增加[compliance]字样，以便更快的找到您的邮件，邮件内容至少明确包含您希望申请加入合规SIG组的意愿即可。 如果个人自愿，可以增加简要经验说明，后续希望重点参与的工作及可投入时间等内容，但请注意此部分内容不做强制。
   
-  - 参加SIG会议加入：通过在例行的合规SIG例会中[自行申报议题](https://etherpad.openharmony.cn/p/compliance)，新增议题标题为**新成员加入申请** 并按时参加会议，会议中明确表示申请加入合规SIG，并记录为会议纪要. **注意，即使您不想成为合规SIG的成员，仍然可以不受任何限制的参加合规SIG的会议**
+  - 参加SIG会议加入：通过在例行的合规SIG例会中[自行申报议题](https://shimo.im/sheets/B1Aw1d18GeFygLqm/MODOC)，新增议题标题为**新成员加入申请** 并按时参加会议，会议中明确表示申请加入合规SIG，并记录为会议纪要. **注意，即使您不想成为合规SIG的成员，仍然可以不受任何限制的参加合规SIG的会议**
 
 
 ## 开始参与贡献（Get Involved）

sig/sig_qa/guidance_for_incubation_project_graduation_cn.md

@@ -42,6 +42,7 @@ SIG孵化项目毕业评审组织
 | 法务  | 许可证  |项目依赖的库必须是开源软件，可公开获得。保留原开源软件的提交记录 |  工具+人工：通过社区FOSSSCAN门禁扫描三方代码匹配度，人工确认是否是开源软件 | QA SIG  |
 | 法务  | 许可证  |项目所引用的开源软件需要增加README.OpenSource、OAT.xml以及在BUILD.gn中增加生成开源软件使用NOTICE|  人工：check以上三个文件 | QA SIG  |
 | 法务  | 许可证  | 项目的许可证文件在项目仓库中的标准位置并且命名符合社区规范。  | 工具：通过社区OAT工具门禁，检查项目的LICENSE文件  | QA SIG  |
+| 法务  | 许可证  |项目中不能篡改第三方开源软件的许可证和版权声明              | 工具：通过棱镜七彩FossLicense检测，告警清零      | QA SIG  |
 | 项目运作  | 问题响应  |项目必须提供issue跟踪所有问题，并对登记的issue应进行合理的分类、分级。   |  人工：审核issue清单 | SIG Owner  |
 | 项目运作  | 问题响应  | 项目必须响应过去2~12个月的大多数Issues（>80%)。  | 工具+人工：社区Issue平台统计问题关闭情况，人工审核  | SIG Owner  |
 | 项目运作  | 问题响应  | 项目在过去6个月收到的本项目涉及的三方软件的任何漏洞报告的初始响应时间必须小于或等于14天。  | 人工：审核漏洞报告的响应记录  | SIG Owner  |

sig/sig_qa/版本质量要求.md

@@ -10,6 +10,7 @@
 | :------------ | :------------ | :------------ | :------------ | :------------ |
 | 社区门禁| 通过  |通过   |通过   |  |
 | 静态检查| NA  |清零   |清零   | 包括代码规范检查、合规检查、安全检查报告 |
+| 开源义务履行| NA  |通过  |通过   | 二进制分发时镜像包中system/etc下是否包含NOTICE.txt |
 | 冒烟测试通过率 | >95%  |100%   | 100%  |  |
 | XTS测试通过率| NA  |100%   |100%   |   |
 | 测试用例通过率|NA   |>95%   |100%   |   |