许可证生成器

下一个

在未提供许可证文件的情况下发布项目,从技术层面而言即意味着“保留所有权利”,任何人都不得重用该代码。本生成工具可生成最受欢迎的开源许可证的完整原始文本,并自动将您的姓名及当前年份填入版权声明栏;将其粘贴至仓库根目录下的许可证文件后即可提交。

如何选择和生成许可证

  1. 1

    选择许可证

    MIT许可证适用于宽松许可模式;Apache 2.0许可证适用于宽松许可并包含专利授权;GPLv3许可证则适用于Copyleft许可模式。

  2. 2

    输入您的姓名和年份

    版权持有者,您的法定名称或公司名称。年份为作品发布的首年。

  3. 3

    查看全文

    许可证文本完全保持OSI/FSF发布的原样;仅版权信息行有所变更。

  4. 4

    放入许可证中

    保存至您的仓库根目录。GitHub会自动检测该路径并显示在侧边栏中。

在热门选项之间进行选择

并不存在一种普遍适用的“最佳”开源许可证。具体选择取决于您希望下游用户能够或无法实现哪些功能。

许可证 类型 专利授予 Copyleft? 主要使用者
MIT 宽松型 隐含 Rails、Node 包、jQuery
Apache-2.0 宽松型 明示 Kubernetes、Android AOSP
BSD-3-Clause 宽松型 Go 标准库、Nginx
GPL-3.0 强 Copyleft GCC、Bash、GIMP
LGPL-3.0 弱 Copyleft 部分 glibc、Qt(历史上)
MPL-2.0 弱 Copyleft 部分 Firefox、Thunderbird
AGPL-3.0 网络 Copyleft MongoDB(2018 年前)、Grafana
Unlicense / CC0 公共领域贡献 - 小型实用库

三个实际问题

  1. 您是否需要闭源的分支? 宽松许可协议(MIT、Apache、BSD)→ 是;Copyleft许可协议(GPL、 AGPL)→ 否。

  2. 您是否关注专利报复问题? Apache-2.0、GPLv3 和 MPL-2.0 均包含明确的专利授权条款,这些条款在诉讼发生时即终止;而 MIT 和 BSD-2/3 则没有此类条款。

  3. 您的代码是作为网络服务运行的吗? AGPL 3.0 修复了“SaaS漏洞”,该服务的用户也被计入分发范围。若此点重要,请选择该版本;否则 GPLv3 更为简洁。

需避免的常见错误

  • 不得修改许可证文本。“MIT-附我的修订版”许可证属于一种全新的、不兼容的许可证类型。法院不会接受临时性修改。
  • 在未确认兼容性的情况下,请勿同时使用两种许可证。Apache-2.0 与 GPLv2 不兼容;而 Apache-2.0 与 GPLv3 则兼容。
  • 请勿忘记在源文件头中注明 SPDX 标识符:第1行的SPDX-License-Identifier: MIT可帮助检测设备识别您的选择。
  • 不要将“知识共享”许可用于软件。CC许可适用于创意作品;请将其用于文档和图像,而非代码。

双重授权

部分项目采用两种许可证组合发布,通常一种为开源许可,另一种为商业许可,以便企业可根据自身需求选择适用的条款。Qt和MySQL便是典型代表。这种做法在法律层面较为复杂;若项目不用于盈利,则应坚持使用单一的OSI认证许可证。

常见问题

MIT许可证是小型开源项目的最常用默认许可协议:条款简短、授权宽松、广为人知,且几乎与所有其他许可证均兼容。若您的项目具有可申请专利的独特创新性,Apache-2.0则是更为稳妥的选择。

是的。若未添加许可证,您的代码将完全受版权保护,任何人均不得合法重用;GitHub公开访问并不构成有效的许可协议。请在将仓库公开当天一并上传相应的许可证文件。

发布首年(单一年度)或以当前年份结尾的时段(例如“2019–2026”)。每年1月更新年份仅为礼节性要求,在大多数司法管辖区并非法律强制规定。

不,替换操作仅在您的浏览器中完成,您的姓名、年份及许可证选择均不会发送给我们。

相关工具

此工具还提供其他语言版本