为什么选择合适的许可证

选择合适的软件许可证至关重要，它定义了用户使用、修改和分发软件的方式，关乎创建者权利及社区类型的塑造。

无明确许可证时，软件受默认版权法保护，创建者保留所有权利。

即使代码托管在 GitHub 等公共平台，他人也无明确许可使用、修改或分发代码，可能阻碍协作，限制项目影响力。

正确的许可证有诸多意义：

• 明确使用方式：清晰阐述他人对软件的操作权限，避免歧义误解，建立信任，鼓励采用。
• 保护创建者权利：在法律上保护创建者知识产权，使其获应有认可，按意愿控制软件使用。
• 促进社区参与：影响社区参与程度和性质，某些许可证鼓励贡献和开放共享改进。
• 商业化考量：规定软件能否及如何用于盈利，包括创建衍生作品及其分发。
• 法律合规：避免潜在法律风险，确保项目在法律允许范围内运行，整合第三方代码时尤为关键。

最初决定是否包含许可证至关重要，忽视此步骤会使项目处于法律灰色地带，限制其协作和被使用潜力。

选择特定许可证是战略决策，反映项目所有者核心价值观和长远愿景。不同许可证服务于不同目标和软件所有权及共享理念。

开源许可证详解

什么是开源许可证

开源软件源代码可自由获取、使用、修改和分发，促进透明度和社区创新。

开源许可证是授予这些权利的法律机制，提供用户与软件代码互动的清晰框架。

开放源代码促进会（OSI）是权威机构，通过开放源代码定义界定 “开放源代码”，批准符合定义的许可证，确保开放源代码生态系统标准化和信任。

其网站（opensource.org）是理解批准许可证的宝贵资源。“开源” 和 “自由软件” 常互换使用，但 “自由软件” 强调软件自由伦理方面，侧重用户运行、学习、共享和修改软件的权利；开源更实用，接受商业用途。

“开源” 包含源代码可访问性和通过许可证授予的特定自由，非 “免费” 使用，而是 “使用自由”。

常见的开源许可证类型

1. 宽松型许可证 ：限制最少，允许用户在遵守最低限度义务下，自由使用、修改和分发软件。主要要求署名，即保留原始版权声明和许可证文本。适用于广泛采用和集成到其他项目（包括专有项目）中，主要要求是署名。

   • MIT 许可证 ：简单且使用广泛，简洁明了。允许用户将软件用于任何目的，包括商业用途，可修改、合并、发布、再许可和销售软件副本，即使闭源项目也可。主要条件是包含原始版权声明和许可证文本。Babel、.NET 和 Rails 等项目使用此许可证，其直接性和广泛自由受优先考虑易用性和软件广泛适用性的开发者青睐。
   • Apache 许可证 2.0 版 ：流行宽松型许可证，与 MIT 许可证类似，但对专利权有附加条款。允许用户修改、分发和再许可代码，用于任何目的，包括专有软件。明确允许商业用途、担保和专利声明。主要条件包括包含原始版权声明、许可证文本副本、对原始代码重大更改通知。若原始软件有 “NOTICE” 文件，衍生作品也须包含。Kubernetes 和 Swift 等项目使用此许可证，适用于企业级项目，其明确的专利授权为项目提供额外法律保护，对涉及潜在可专利技术的项目有价值。
   • BSD 许可证 ：一系列宽松型许可证，限制极少。3 条款 BSD 许可证常见，条件包括保留版权声明、条件列表和免责声明，禁止未经许可使用版权所有者或贡献者名称宣传；2 条款 BSD 许可证省略非认可条款。BSD 许可证软件可自由修改用于专有或商业软件，以其极端宽松性适用于希望最大程度自由使用和修改代码的开发者，仅承担极少义务。

2. 保留型许可证（Copyleft 许可证）：确保原始软件的修改和衍生作品保持开源，并以相同或兼容许可证分发，旨在促进协作生态系统，改进回馈社区。与强保留型许可证（如 GPL）相关的 “病毒式” 许可概念指包含 GPL 许可代码，则许可条款可扩展到整个作品。

   • GNU 通用公共许可证（GPL） ：自由和开源软件领域广泛使用和受欢迎的保留型许可证。授予用户运行、研究、共享和修改软件的权利，但衍生作品也须以 GPL 或兼容自由软件许可证发布，确保软件及其改进对所有用户保持自由和开放。存在不同版本，GPLv3 解决了 GPLv2 问题和模糊之处，提供更强保留型保护。Linux 内核和 GNU 编译器集合（GCC）等使用 GPL 许可，适用于坚定确保软件及其所有衍生作品保持自由和开源，培养强烈社区和共同所有权意识的项目。
   • GNU Affero 通用公共许可证（AGPL） ：本质是 GPL 增加额外条款，针对旨在服务器上运行并通过网络访问的软件（如 Web 应用程序），解决 “SaaS 漏洞”，要求即使软件未直接分发给用户，也须向通过网络交互的所有人提供源代码。适用于主要以服务形式提供的软件项目，而非可下载应用程序，将 GPL 的保留型原则扩展到基于网络的软件领域，确保修改和使用该软件的服务提供商有义务共享更改。

3. 弱保留型许可证：介于强保留型和宽松型许可证之间，允许在某些条件下将许可代码用于专有项目，主要对许可组件本身的修改须保持开源，在促进开源开发和启用商业用途间平衡。

   • GNU 宽通用公共许可证（LGPL） ：通常用于软件库，允许专有软件链接和使用该库，无须要求整个应用程序以 GPL 许可。主要要求是 LGPL 许可的库本身被修改，则须以 LGPL 发布修改。在与专有代码链接方面比 GPL 更灵活，是旨在广泛使用的库的流行选择，允许专有应用程序受益于开源库，同时确保对库本身改进修改回馈开源社区。
   • Mozilla 公共许可证 2.0 版（MPL 2.0） ：处于宽松型和保留型许可证中间，允许在专有项目中使用 MPL 许可代码，但对 MPL 许可文件的修改须以 MPL 发布。保留型要求在文件级别，大型项目其他部分可使用不同许可证，包括专有许可证。提供更细粒度保留型方法，集中在最初采用 MPL 的特定文件上，在许可整个项目方面提供更大灵活性。

不同开源许可证的适用场景

选择开源许可证取决于项目目标和期望结果。例如，若追求简单宽松使用，MIT 许可证、Apache 许可证 2.0 版合适，限制少易理解；若要确保所有改进共享，GNU GPLv3、GNU AGPLv3 是好选择。

商业和专有许可证概述

商业许可证的特点

商业软件为盈利分发，通常要求用户支付许可费使用，与通常免费的开源软件对比，但也有商业开源模式。商业许可证通常附带额外优势，如专门技术支持、定期更新和为商业或组织用途定制的特定功能，这些服务使与许可证相关的成本合理。一些商业软件可能提供有限源代码访问，但通常是专有的，用户受限制。商业许可证面向需要特定功能或保证的企业等，其特点在于关注软件供应商收入产生，与提供支持和附加功能结合，但限制用户访问和修改源代码自由。

专有许可证的限制

专有软件由个人或公司拥有，赋予其使用、修改和分发专有权，通过版权和知识产权法执行。专有许可证严重限制用户访问源代码能力，通常仅提供编译后的可执行形式软件，缺乏透明度限制用户理解软件工作方式或定制能力，修改和重新分发通常被禁止。用户购买许可证获使用权利，而非修改共享权利。专有许可证可能含各种使用限制，如设备数量或部署环境类型限制。虽一些专有许可证提供源代码访问，但禁止未经许可的公开再分发或修改。专有许可证优先考虑软件所有者对软件的控制，对用户访问、修改和共享代码施加重大限制。

何时考虑商业或专有许可证

当主要目标是通过许可费直接从软件产生收入，或软件含独特算法等需保密源代码的知识产权，或软件为组织内部特定用途开发不打算公开分发，或向付费客户提供专门技术支持等服务是商业模式关键部分时，会考虑商业或专有许可证。其决定受对软件分发使用严格控制需求及通过许可获利并提供增强支持服务意图驱动。

选择许可证的关键考虑因素

项目目标和愿景

清晰定义项目目标和愿景是选择许可证的关键。若鼓励广泛采用和使用，宽松型许可证合适；若确保改进回馈社区，保留型许可证更好；若商业化是关键目标，需考虑不同许可证对收入产生影响，可选择商业 / 专有许可证、宽松型开源许可证或双重许可模式。项目根本目标应是选择合适软件许可证的指导原则。

社区参与和贡献

考虑项目期望的社区互动水平。保留型许可证 “共享相同” 要求能确保贡献回馈，带来活跃协作开发；宽松型许可证允许更广泛使用，但不强制共享修改，可能导致项目出现专有分支。还要考虑目标社区或依赖社区的许可偏好，与现有开源生态系统贡献时，使用社区普遍许可证兼容；预计收到来自具有特定法律要求的公司开发者贡献，可考虑企业认可的许可证如 MIT 或 Apache 2.0。

法律影响和知识产权保护

理解每种许可证相关的法律义务和限制至关重要。仔细阅读许可证全文，考虑其提供的知识产权保护级别，如 Apache 许可证 2.0 版明确授予专利权，而 MIT 许可证未提及。了解不遵守条款的潜在法律后果，必要时寻求法律专业人士建议。透彻理解条款确保法律合规性及选择合适保护级别许可证。

商业化意图

商业化计划显著影响许可证选择。宽松型开源许可证与商业化兼容，允许他人将代码合并到专有产品中；强保留型许可证可能更具限制性，阻止公司在专有产品中使用代码；可考虑双重许可模式，开源用于非商业用途，提供商业许可证给企业；若主要目标是商业化且希望完全控制软件，专有商业许可证合适。商业化意图是选择软件许可证的关键决定因素，不同许可证在商业活动兼容性方面提供不同程度自由。

与其他软件的兼容性

若项目依赖或集成其他软件，考虑依赖项许可证并确保与所选许可证兼容。合并不同许可证代码可能出现兼容性问题，如 GPLv2 与 GPLv3 不兼容。宽松型许可证通常兼容性好，但也有例外。选择宽松型许可证可减少潜在兼容性问题，使用保留型许可证时合并其他保留型代码要小心。FSF 和 OSI 等机构提供许可证兼容性信息。确保项目许可证与依赖项许可证兼容，避免未来冲突，确保组件顺利集成。

如何将许可证应用于你的项目

创建 LICENSE 文件

标准方法是在项目存储库根目录创建 LICENSE 文件，通常命名为 LICENSE，也可根据格式命名为 LICENSE.txt 或 LICENSE.md。从 choosealicense.com 或 OSI 网站获取所选开源许可证完整文本，复制粘贴到 LICENSE 文件。许多许可证含占位符，需替换为项目正确信息。在根目录创建清晰命名的 LICENSE 文件，含完整文本和准确版权信息，是正式许可软件项目的普遍方法。

在代码中声明许可证

在项目每个源代码文件开头包含简短许可证头，表明文件许可条款。典型的许可证头包括版权声明和声明文件依特定许可证分发及提供许可证文件链接或名称。此做法确保许可信息随代码传播，使他人易理解权利义务。

利用平台工具

许多代码托管平台如 GitHub 和 GitLab 提供添加许可证功能。创建新存储库时，可选择 “选择许可证模板”，平台会创建含完整文本的 LICENSE 文件并预填版权信息。对于无许可证的现有存储库，可通过创建 LICENSE 文件并使用平台模板功能或手动粘贴文本添加许可证。利用平台工具提供简化方式为项目应用标准开源许可证，确保法律框架。