以服务化方式提供扫描分析软件仓、PR 的license、Copyright功能,支持Gitee、Github、Gitlab、http、purl链接输入。
本规则旨在帮助社区开发者了解仓库中存在的合规问题,对于项目的合规而言,本规则是 License 合规的最低要求。License 的合规问题包括但不限于此,下面列出的是一些常见的 license 合规问题。
问题 | 基线 | 说明 |
---|---|---|
1. 项目缺乏整体的 License | 在根目录(license、readme、copyright、notice 等)或者 1 层子目录(/License(s)/License, Notice/License 等)下有文件中有 License 的完整文本的说明。 | 项目 License 文本内容应保证完整性 |
2. 项目 spec 文件的 License 不规范 | License 名称清晰性、规范性,不产生歧义 | 项目的 License 名称不产生歧义,如 License 名称错误、未携带 License 版本号等 |
3. 缺乏项目级的 Copyright 声明 | 在根目录或者 1 层子目录,包括但不限于以下文件:License, copyright, readme, notice 中的任何一个文件中包含 copyrights 字段描述 | 项目级的 Copyright 声明清晰性、规范性 |
4.项目使用非 FSF 或 OSI 认证的 License | 定义的可引入 license 合集 | 建议使用经过 FSF 或 OSI 认证的许可证,非认证许可证需经过评审 |
本规则旨在提供项目的 License 合规优秀实践案例,是 License 合规基线要求的补充。License 的合规项目包括但不限于此,下面列出的是一些常见的 license 合规项目。
描述 | 最佳实践 | |
---|---|---|
1. 项目整体的 License | 建议使用以下两种方式之一: 1.在根目录下放单独的 License 文件。 2.在 Licenses/License 子目录下放单独的完整 License 文件。 |
|
2. License 名称 | 使用统一格式的 spdx-indentifier | |
3. 项目级的 Copyright 声明 | 建议使用以下两种方式之一: 1. 在根目录下放单独的 Copyright Notice 文件。 2.在 Notice 子目录下放单独的完整 Notice 文件。 |
|
4 项目所使用的 License | 项目全部使用经过 FSF 或 OSI 认证的 License |
许可证准入列表参考: https://compliance.openeuler.org/license-list