更新开源科普
This commit is contained in:
p81472965
parent
7cfeef0d32
commit
55ca6b46ab
|
|
@ -1,4 +1,5 @@
|
|||
- 红山开源平台使用手册
|
||||
- [开源项目使用手册](./git.md)
|
||||
- [创客使用手册](./chuangke.md)
|
||||
- [开源合规科普](./compliance.md)
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,303 @@
|
|||
### 软件供应链
|
||||
**定义：**
|
||||
|
||||
软件供应链包括软件开发证明周期中所有内容，包括需求、设计、编码、测试、交付、部署、运维等关键流程；软件需各种代码“零件”组合成型。
|
||||
|
||||
开源软件与软件供应链的关系：开源软件是软件供应链发展重要推手。
|
||||
|
||||
**面临的挑战：**
|
||||
|
||||
1.软件供应链面临“卡脖子”风险——攻击风险，以Log4j为代表的攻击事件标志着迈入软件供应链安全新时代。
|
||||
|
||||
2.软件供应链面临“卡脖子”风险——战争风险，利用软件供应链针对关键基础设施实施攻击已成为现代化战争的典型特点。
|
||||
|
||||
软件供应链安全已成为国家级战略，美国和欧盟出台多项法律法规及标准提升软件供应链安全；中国出台多项法律法规及标准提升软件供应链安全的自主可控。
|
||||
|
||||
**软件供应链代码安全研究所面临的主要问题：**
|
||||
|
||||
软件供应链代码安全研究所面临的主要问题有三个：1.漏洞检测精度低；2.漏洞数据质量差；3.漏洞检测验证难
|
||||
。因此，软件供应链代码需要高精度的漏洞检测。
|
||||
|
||||
|
||||
|
||||
### 开源合规
|
||||
|
||||
**定义：**
|
||||
|
||||
`开源合规是指在开源软件开发和使用过程中遵守相关的法律法规、知识产权原则和开源许可证，以确保开源软件的合法性、透明性和可持续性。`旨在建立一个合法、透明、公平的开源软件生态系统，使得开源软件的开发、使用和传播都在法律和伦理的框架内进行，从而促进开源社区的健康发展。
|
||||
|
||||
包括以下几个方面：
|
||||
|
||||
1. 遵循**开源许可证**：开源软件通常会使用特定的开源许可证，如MIT、GPL、Apache等。开源合规要求在开发和使用开源软件时，遵守相应的开源许可证的规定，如包含版权声明、遵守许可条件等。
|
||||
2. 尊重**知识产权**：开源合规要求在开源软件的开发和使用过程中尊重他人的知识产权，不侵犯他人的专利、商标、著作权等权利。
|
||||
3. 遵守**相关法律法规**：开源合规需要了解并遵守相关的法律法规，以确保在开源软件的开发和使用过程中不违反任何相关法律。
|
||||
4. 社区参与和贡献：开源合规鼓励和促进社区参与和贡献。开发者可以自由地参与开源项目的开发、测试和改进，并能够分享他们的成果，同时也要遵循开源许可证的规定。
|
||||
5. 合规的开放源代码管理：开源合规还包括对开放源代码的合规管理，包括代码审查、版本控制、漏洞修复等方面的要求。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 开源软件
|
||||
|
||||
- 开源软件是一种**源代码可以自由获取**的计算机软件。来源软件的源代码以开放的形式向公众发布，任何人都可以检查、修改和分发软件的源代码，而不受传统专有软件所施加的限制。
|
||||
- 发布开源软件需要附带**开源许可证**：开源许可证是对开源软件的**知识产权**进行**规范和约束**的**法律合同**。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 开源许可证
|
||||
|
||||
**定义：**
|
||||
|
||||
`开源许可证是对开源软件的知识产权进行规范和约束的法律合同。是对开源软件的使用、复制、修改和分发等行为进行规范和约束的法律合同。`
|
||||
|
||||
**许可证风险：**
|
||||
|
||||
开源软件许可证是在作者和使用者之间有法律效应和约束力的合同，类似于不可更改的制式合同，当开发者选用了开源项目/局部代码片段，则默认为签署了这份合同。如果合同违约，很有可能承担如下责任与损失：
|
||||
|
||||
- 企业法律纠纷
|
||||
- 产品召回
|
||||
- 自有代码被迫开源
|
||||
- 影响产品对外合作
|
||||
- 对企业形象带来负面影响
|
||||
|
||||
**开源许可证的标准化以及提供相关支持工具成为开源实践中的迫切需求**
|
||||
|
||||
> - 由于开源社区存在大量不同类型的许可证，仅OSI认证通过的开源许可证就有126个，不同开源许可证之闻细微的差异常常让开源参与者感到困惑；
|
||||
> - 一些开源许可证的条款表述非常晦涩，容易因误解而违约；
|
||||
> - 还有一些开源许可证对被许可方责任和义务的规定不够清晰、完善，容易导致难以解决的法律纠纷。
|
||||
>
|
||||
> `急需：开源许可证的框架的标准化和相关支持工具`
|
||||
|
||||
### 开源合规主要学术研究方向
|
||||
|
||||
**许可证识别：**
|
||||
|
||||
许可证识别分为许可声明位置和许可识别粒度。
|
||||
|
||||
其中，许可声明位置分为：Declared许可证、Inline许可证、Referenced许可证；许可识别粒度分为：许可证名称识别、许可证条款识别。
|
||||
|
||||
**许可证风险检测：**
|
||||
|
||||
风险检测分为兼容性检测和合规性检测。
|
||||
|
||||
其中，兼容性检测分为：人工检测、基于兼容性知识、基于声明条款；合规性检测：最常见的违规检测内容包括生命缺失和copyleft违规。
|
||||
|
||||
**许可证冲突检测技术：**
|
||||
|
||||
许可证冲突检测技术分为许可证及条款的识别、许可证条款极性推断和许可证兼容性的检测。
|
||||
|
||||
许可证兼容性检测研究所面临的主要问题一是条款识别精度难以保证，二是兼容性检测精度难以保证，因此，需要高精度的许可证兼容性检测。
|
||||
|
||||
**许可证冲突修复：**
|
||||
|
||||
现有研究冲突修复方案有以下类别：再许可、自定义许可证内容、协商、重构代码、更改分发方式、更换兼容组件、删除违规组件。
|
||||
|
||||
现有研究对其中四种进行了自动化实现：
|
||||
|
||||
1.再许可：即根据兼容性等信息更换冲突许可证；
|
||||
|
||||
2.自定义许可证内容：自定义许可证条款满足与其它许可证之间的兼容性；
|
||||
|
||||
3.更换兼容组件：寻找使用兼容许可证的类似功能的组件或组件的历史版本替代；
|
||||
|
||||
4.删除违规组件。
|
||||
|
||||
**许可证推荐和选择：**
|
||||
|
||||
现有研究通常基于以下方面推荐和选择许可证：
|
||||
|
||||
1、 兼容性：项目许可应满足与组件许可不发生冲突；
|
||||
|
||||
2、 项目属性：根据相似项目推荐许可证；
|
||||
|
||||
3、 开发者特征：根据相似的技术背景、开源参与度和许可偏好的开发者推荐许可证；
|
||||
|
||||
4、 开发者需求：通过问卷调查等形式获取开发者在开源参与方面的需求，推荐许可证。
|
||||
|
||||
基于不同方面推荐和选择许可证的特点：
|
||||
|
||||
1、 基于兼容性的许可证建议的主要优点是最大限度地减少与推荐许可证相关的法律风险。但是并不一定存在许可证兼顾全部兼容性要求，并且许可证不一定符合项目需求。
|
||||
|
||||
2、 基于开发者特征、项目需求以及项目属性等信息推荐许可证更注重便利性和适用性，但是无法消除法律风险。
|
||||
|
||||
|
||||
|
||||
|
||||
### 开源许可证 —— 标准
|
||||
|
||||
#### 标准名称：开源许可证框架
|
||||
|
||||
```js
|
||||
// 参编单位(按贡献排序)：
|
||||
北京大学、中国电子技术标准化研究院、中国科学院软件研究所、开放原子开源基金会、东软集团股份有限公司、烽火通信科技股份有限公司、北京大数据先进技术研究院、浪潮电子信息产业股份有限公司、九州云信息科技有限公司、浪潮云信息技术有限公司、湖南麒麟信安科技股份有限公司、中国移动信息技术有限公司、中移(苏州) 软件技术有限公司、中移雄安信息通信科技有限公司、北京百度网讯科技有限公司、中国移动通信有限公司研究院、腾讯科技有限公司、国防科技大学计算机学院并行与分布处理重点实验室、北京华胜天成科技股份有限公司、麒麟软件有限公司、华云数据控股集团有限公司、蚂蚁科技集团股份有限公司、棱镜七彩等23个单位。
|
||||
|
||||
// 主要起草人：
|
||||
周明辉 、杨丽蕴、吴欣 、李成双 、朱家鑫 、于秀明 、冯冠霖 、王荷舒 、吕雪 、赵赫 、吴江 、郭长国、刘敬民 、张百林、王旭 、章津楠 、黄先芝 、钱岭 、余跃 、马红伟 、刘伟 、金铸 、田康 、王静 、梁大功 、郁志强 、李智琪 、于听 、梁钢 、任风丽 、鞠东颖 、王溪 、李震宁 、郭智慧 、杨静 、肖丁、王佩龙 、亓开元 、但吉兵。
|
||||
```
|
||||
|
||||
#### 标准内容、范围以及拟解决的问题
|
||||
|
||||
此标准提出了开源许可证的内容框架，其规定了基本信息构成、序言构成、条款与条件构成、使用说明构成，以及许可证兼容性的定义及判定条件。适用于指导开源许可证的编制及使用。
|
||||
|
||||
拟要解决的主要问题：
|
||||
|
||||
1. 开源社区中原生中文开源许可证较少的问题
|
||||
2. 开源许可证编制和使用不规范，缺乏统一框架的问题
|
||||
3. 开源参与者难以准确理解许可证内容的问题
|
||||
4. 一些开源许可证对被许可方责任和义务的规定不够清晰完善的问题
|
||||
|
||||
#### 标准具体结构
|
||||
|
||||
`内容框架：必备内客(许可证名称及版本号、版权许可、免责声明)、可选内容(序言、定义、授权条件、违约与授权终止、准据法与规范语言、版本与次级许可证、使用说明)。`
|
||||
|
||||
> - **基本信息构成**：许可证名称及版本号、许可证发布日期、许可证版权声明、许可证原文链接地址。
|
||||
> - **序言构成**：许可证的遭用场景和适用条件、条接受说明、目的及宗旨。
|
||||
> - **条款与条件构成**：定义、擅权范围、擅权条件、违的与授权缝止、免责声明、准据法与规范语言、版本说明与次级许可证。
|
||||
> - **使用说明构成**：许可声明、许可证文件。
|
||||
> - **许可证兼容性**：转容性定义、兼容性场景、兼容性判定条件。
|
||||
|
||||
|
||||
|
||||
##### 条款与条件构成
|
||||
|
||||
>**定义**
|
||||
>
|
||||
> 定义是为准确界定许可证内容，需要对许可证条款中所使用的特定术语进行专门定义说明。
|
||||
>
|
||||
>**授权范围**
|
||||
>
|
||||
> 授权范围是贡献者就许可作品授予用户的版权、专利权、商标权等权利范围进行声明，其中：
|
||||
>
|
||||
>- 应包含**版权**许可
|
||||
>- 可包含**专利权**许可`解读:即使在没有明示专利许可(条款) 的情况下，所有的开源许可证都会通过默示方式授了一些专利权。该原则大体上基于这样一个前提，即专利权人就软件的版权授了许可，然后再就被许可方已被许可的活动提起专利侵权诉讼是不公平的。但是关于默示许可(implicdliccnsc)原则的判例法模糊且稀缺。`
|
||||
>- 宜包含**商标权**的说明`注:开源许可证可以明确对商标权的限制 (即不授予商标权) ，或禁止借商标权人的名义进行广告成宣传;开源许可证也可能不提及商标权，但原则上不对商标权默示许可，如需使用许可作品中出现的商标，须额外获得商标权人的许可。`
|
||||
>
|
||||
>**授权条件**
|
||||
>
|
||||
> 授权条件是指用户获得许可作品中相关权利的前提条件，包括用户在使用、修改、复制或分发许可作品或其衍生作品时遵守的行为规范和其他限制条件，其中:
|
||||
>
|
||||
>- 可包含使用条件
|
||||
>
|
||||
> `注:开源许可证通常不对使用的主体、领域等进行限制(参见OSI的开源定义) ; 开源应用中，一此开源厂商对F特定场景的使用条件《包括但不限于商业使用、网络服务等) 要求履行相关义务。`
|
||||
>
|
||||
>- 可包含修改条件
|
||||
>
|
||||
> `注:开源许可证通常不对个人使用成内部使用中的修改进行限制;对手修改的提交成分发可以要求展行相关义务。`
|
||||
>
|
||||
>- 可包含分发条件
|
||||
>
|
||||
> `注：开源许可证可以对**作品形式、分发媒介、再授权方式、附加的文件、分发收费**等内容的分发条件进行说明。作品形式主要包括源代码形式和可执行形式;分发媒介是指提供传输、下栈许可作品或其街生作品的中间介质，但括但不限于网络传输、物理设备(CD、磁盘等传统介质) 、像入物理设备、访问权限或繁钥等再授权方式是指分发街生作品的授权方式 (开源授权或专有授权)，至少允许它们在原始许可证的相同条款下分发；附加的文件可包括**许可证副本、版权声明、修改声明、免责声明或其他声明**等；分发收费是指传输许可作品副本成其衍生作品时所产生的必要费用以及许可方自行提供担保或服务支持的其他收费。`
|
||||
>
|
||||
>- 可附加共他限制条件
|
||||
>
|
||||
> `注: 是指在当前采川的开激许可证基础上新增的其他限制条款`
|
||||
>
|
||||
>**违约与授权终止**
|
||||
>
|
||||
> 违约与授权终止是对开源许可证授权终止条件进行说明，其中：
|
||||
>
|
||||
>- 可包含违约终止条件
|
||||
>
|
||||
> `注：对于用户违反许可证条款的行为，可以对其终止许可证中的授权(该场景较为常见)，也可以给与一定的补救机会 (该场景较为少见)。`
|
||||
>
|
||||
>- 可包含侵权诉讼终止条件
|
||||
>
|
||||
> `注：可根据需要对违反提供免费版权许可、专利许可的行为进行终止和限制。`
|
||||
>
|
||||
>- 可包含下游用户的授权不被终止的说明
|
||||
|
||||
##### 许可证兼容性
|
||||
|
||||
> **定义**
|
||||
>
|
||||
> 开源许可证兼容性是指将不同开源许可证下的作品（无论是否经过修改） 进行组合（包括但不限于 通过接口文作等方式进行链接）后合法地形成衍生作品，并合法地进行再分发的可行性。借要注意的是， 通常说的许可证兼容是有方向的，许可证A授权的作品与许可证B授权的作品组合后，所产生的衍生作品 可以使用许可证B进行分发，则认为A可以兼容B 一一 但反之不一定成立。
|
||||
>
|
||||
> **兼容性场景**
|
||||
>
|
||||
> 当组合不同开源许可证授权的作品或变更某一开源项目许可证时，需要对开源许可证的兼容性进行判定: 任何集成或衍生项目的许可证满足所复用的开源组件许可证或原项目许可证的要求。
|
||||
>
|
||||
> **兼容性判定条件**
|
||||
>
|
||||
> 不同兼容性场景的开源许可证兼容性判定条件不同，其中：
|
||||
>
|
||||
> - 次级兼容的判定条件包括：
|
||||
>
|
||||
> - 授权条件是否存在冲突
|
||||
> - 是否适用后续版本许可证
|
||||
> - 是否允许使用次级许可证再授权
|
||||
>
|
||||
> - 组合兼容的判定条件仅包括：衍生作品所包含的各部分作品的再授权方式是否存在冲突
|
||||
>
|
||||
> `注：不同著佐权型开源许可证授权的作品，如均要求与其组合形成衍生作品的其他作品部分，也均须在相同许可证下进行再授权，则因无法同时合法满是每个许可证要求而不能进行组合。`
|
||||
|
||||
**许可证兼容性判断流程图：**
|
||||
|
||||
|
||||
|
||||
#### 标准成果
|
||||
|
||||
- 起草、修订并发布了木兰宽松许可证和木兰公共许可证
|
||||
|
||||
`MulanPSL v2通过OSI认证，成为全球首个我国主导的中英双语开源许可证，打破国内许可证方面的空白得到开源组织和平台积极支持，并在工业界广泛应用。`
|
||||
|
||||
- 持续孵化相关应用和生态，包括：
|
||||
|
||||
- 创建并维护“mulanlicense-log”开源仓库
|
||||
- 构建开源许可证兼容性检查和推荐工具“RecLicense”，许可证不兼容消解工具SILENSE
|
||||
- 参与“源译识”开源许可证翻译项目
|
||||
- 在ICSE、ASE、软件学报 发表多篇学术论文等
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 开源许可证 —— 工具
|
||||
|
||||
```
|
||||
一个软件项目要开源，选择一个合适的开源许可证非常重要，开源许可证的选择对项目的开发、演化以及软件的使用和商业化非常重要，但是开发者再为项目选择许可证的时候通常会遇到一些困难，开源许可证之间非常的相似，以及复杂的法律含义会让他们困惑，选择许可证的时候还需要考虑到依赖的第三方软件的许可证，要遵从它们，否则会陷入法律诉讼。
|
||||
```
|
||||
|
||||
|
||||
|
||||
- **开源软件扫描工具**：
|
||||
- 开源软件扫描工具能够分析代码库中所使用的开源组件，并识别出每个组件所使用的许可证类型。这些工具可以帮助开发者快速了解代码库中可能存在的许可证冲突，并给出建议以解决这些问题。一些知名的开源软件扫描工具包括**Black Duck、FOSSA**等。
|
||||
- 开源软件许可证推荐工具“RecLicense” ：https://licenserec.com/
|
||||
|
||||
- **许可证兼容性工具**：
|
||||
|
||||
一些组织维护着许可证兼容性数据库，其中包含了各种开源许可证之间的兼容性信息。开发者可以通过查询这些数据库来了解不同许可证之间的兼容性情况，从而避免潜在的许可证冲突问题。
|
||||
|
||||
- **许可证不兼容消解工具SILENSE**：https://github.com/osslab-pku/SILENCE
|
||||
- **Open Source Initiative (OSI)**：OSI 维护了一个包含广泛的开源许可证列表的数据库，该列表提供了对各种开源许可证及其相互之间的兼容性情况的详细说明。开发者可以在 OSI 的网站上查找并了解不同许可证之间的兼容性信息。
|
||||
|
||||
- **Free Software Foundation (FSF)**：FSF 提供了关于自由软件许可证的详尽信息，包括它们之间的兼容性情况。开发者可以通过查询 FSF 的资源来获取有关自由软件许可证的兼容性信息。
|
||||
|
||||
- **GitHub License API**：GitHub 提供了一个 License API，其中包含了大量开源许可证的信息，开发者可以通过调用这个 API 来获取有关不同许可证的详细信息，并了解它们之间的兼容性情况。
|
||||
|
||||
|
||||
|
||||
> **`国内外开源软件合规管理平台：`**
|
||||
>
|
||||
> 1. **Black Duck by Synopsys**：
|
||||
>
|
||||
> Black Duck 提供了开源软件扫描、许可证合规性检查、安全漏洞分析等功能，帮助企业了解其软件中使用的开源代码，并确保其合规性和安全性。
|
||||
>
|
||||
> 2. **WhiteSource**：
|
||||
>
|
||||
> WhiteSource 为开发人员和企业提供了一系列的开源软件管理工具，包括自动化的开源组件识别、许可证合规性检查、安全漏洞警报等功能。
|
||||
>
|
||||
> 3. **FOSSA**：
|
||||
>
|
||||
> FOSSA 提供了针对开源许可证合规性和安全性的自动化工具，帮助企业分析其代码中的开源组件，并确保其合规性和安全性。
|
||||
>
|
||||
> 4. **OpenLogic by Perforce**：
|
||||
>
|
||||
> OpenLogic 提供了开源软件扫描和许可证合规性检查服务，帮助企业了解其软件中使用的开源组件及其合规性情况。
|
||||
>
|
||||
> 5. **棱镜七彩**：
|
||||
>
|
||||
> 棱镜七彩专注开源软件治理，牢牢抓住软件源代码安全的根源问题，以源代码安全为核心基础立足网络安全行业，同时以开源安全与合规治理、信创代码自主率测评鉴定等业务，全面深耕于开源生态。
|
||||
|
||||
Loading…
Reference in New Issue