开源许可证为什么不能只看免费两个字
开源许可证讨论的不是价格高低，而是谁可以使用、复制、修改、分发，以及再分发时要履行哪些条件。看见免费就直接用，很容易忽略无许可证、版权声明、专利授权、商标边界和许可证兼容性。
开发者和创业团队看到一个 GitHub 仓库，常常先问两个问题：能不能用，是否免费。第二个问题看起来简单，实际并不能回答第一个问题。软件可以零价格下载，却不代表你可以复制到产品里、改成商业版本、分发给客户、放进镜像、合并进闭源代码，或把它作为服务的一部分长期运行。开源许可证要回答的是一组权利和条件，不只是价格。
更容易误会的是“代码公开”。公开仓库让你看见代码，也可能允许你 fork；但如果没有清楚的许可证，默认版权规则仍然存在。GitHub Docs 明确提醒，没有许可证时默认版权法适用，作者保留源代码的权利，其他人不能随意复制、分发或创建衍生作品。ChooseALicense 的“无许可证”说明也给了类似边界：代码托管平台的条款可能允许查看和 fork，但这不等于允许使用、修改或分享。
所以，开源许可证不是装饰文件，也不是 README 末尾的一行客套话。它更像一份机器、团队和用户都要读懂的交通规则：哪些动作被允许，哪些条件要保留，哪些风险没有被覆盖，哪些场景需要额外判断。对个人项目来说，它影响协作；对公司产品来说，它影响发布、客户交付、融资尽调、并购审查和供应链安全。
本文是面向开发者和创业者的技术科普，不替代法律意见。更稳妥的做法，是先理解许可证的结构和常见边界；遇到高风险分发、商业嵌入、专利敏感、客户合同或跨国合规场景，再让专业人士介入。至少，在把某个依赖放进产品之前，不要只看“免费”。
免费价格和使用许可是两件事
“免费”首先描述价格：你是否需要付钱才能拿到代码或软件包。许可证描述的是权利：你能不能复制、修改、分发、再授权、用于商业场景，以及做这些事时要满足什么条件。价格是交易问题，许可是权利问题。两者可能重合，也可能完全分开。
GPLv3 的序言有一句常被引用的意思：自由软件里的 free 指自由，不是价格。它还说明，分发者可以收费，也可以不收费；重点在于接收者是否继续获得复制、分发、拿到源代码、修改和再分发的自由。换句话说，一个 GPL 软件可以按零价格下载，也可以由厂商收取支持费；它的规则重点不是“不能收费”，而是“分发时要把相应自由传递下去”。
MIT 许可证也能说明这个区别。它给了使用、复制、修改、合并、发布、分发、再授权、销售副本等很宽的许可，但要求在副本或重要部分中包含版权声明和许可声明，并且软件以“按现状”方式提供，不承诺担保。价格不是它的判断轴，权利、条件和免责才是。
Apache License 2.0 进一步提醒，许可证还可能涉及专利和商标。它不仅授予版权许可，也有明确的专利许可条款；同时，它说明许可证不授予使用许可方商号、商标、服务标志或产品名称的权限，除非是合理描述来源所需。这意味着“可以用代码”和“可以用项目名称或品牌”不是一回事。
因此，当你看一个项目时，不应该只问“是否免费”，而要拆成更具体的问题：我能否商用，能否修改，能否分发二进制，能否把修改保持闭源，是否要保留 NOTICE，是否有专利授权，是否有商标限制，依赖组合是否兼容。
开源不是随便用，OSI 定义关注分发条款
Open Source Initiative 的 Open Source Definition 说得很直接：开源不只是能访问源代码，软件的分发条款还要符合一组标准。它包括自由再分发、提供源代码、允许修改和衍生作品、不得歧视个人或群体、不得限制特定使用领域、许可证不依赖某个产品、不得限制同介质上的其他软件、技术中立等。
这组标准有两个启发。第一，开源许可证要看“分发条款”，不是只看仓库是否公开。一个项目把代码放在网上，但写着不得商用、不得修改、不得用于某些行业，通常就不能简单称为符合 OSI 定义的开源许可证。第二，开源并不是没有约束。OSI 认可的是开放使用和再分发的权利，同时允许许可证设置合理条件，例如保留声明、提供源代码、标明修改、使用相同许可证等。
对创业团队来说，这个区别很实用。你可能在调研阶段看到很多“源码可见”的项目：示例代码、研究原型、公司 demo、个人脚本、课程材料、竞赛作品。它们未必都有开源许可证。即使有许可证，也要看是不是 OSI 认可的许可证、是不是适合你的分发场景、是不是和现有依赖兼容。
对项目作者来说，许可证也是协作信号。如果你希望别人可以复用、提交 PR、打包、改造或商用，就应该放清楚的许可证文件。GitHub Docs 建议把许可证文本放在仓库根目录的 LICENSE 文件中，也说明 GitHub 会识别常见许可证。README 里只写“欢迎使用”远远不够，因为机器识别、依赖扫描和合规审查通常都依赖标准化许可证文本和 SPDX 标识。
没有许可证，风险往往比限制多
很多人以为“没有写许可证”代表作者不介意别人拿去用。实际更接近相反：没有许可证时，使用者很难证明自己被授予了复制、修改、分发和制作衍生作品的权利。
GitHub Docs 的许可页面提醒，没有许可证时默认版权法适用。ChooseALicense 的“无许可证”页面也说明，如果软件没有许可证，一般意味着你没有来自创作者的许可去使用、修改或分享软件。代码托管平台可能允许查看和 fork，但那通常不足以支持常见协作目标，例如实验、修改和分享。
这对使用者意味着什么？如果一个依赖没有许可证，最稳妥的路线不是假设它可以用，而是询问维护者、寻找替代、或者通过私下许可处理。对于公司产品，把无许可证代码放进发布物里，会在后续审查中变成很难解释的问题。即使短期能运行，长期维护也不舒服：你不知道作者是否同意你的使用方式，也不知道贡献者是否拥有授权。
这对作者也有提醒。如果你的目标是让别人复用代码，就不要只把仓库设为 public。添加许可证文件，是在告诉潜在使用者：你允许哪些动作，要求哪些条件，哪些责任不由你承担。没有许可证反而会让认真做合规的人绕开你的项目。
无许可证还有一个团队协作问题。项目一旦接受外部贡献，每个贡献者都可能是其贡献部分的权利人。如果项目没有清楚的许可和贡献规则，后续想改变授权方式、商业化、并入公司产品或迁移到基金会，都可能变复杂。
许可证通常由三层组成：权限、条件、限制
ChooseALicense 的附录用一个很实用的方式展示许可证：permissions、conditions、limitations。翻成工程语言，可以理解为三层。
第一层是权限：商业使用、分发、修改、私人使用、专利使用等。读这一层，是为了知道“我可以做什么”。例如 MIT、Apache-2.0、GPLv3 都允许商业使用、分发和修改，但它们对再分发的条件差别很大。
第二层是条件：是否要包含版权和许可证声明，是否要公开源代码，是否要用相同许可证发布修改，是否要记录修改，网络使用是否触发源代码提供要求。读这一层，是为了知道“我做这些事时要带上什么”。条件不是负担的代名词，它们是许可证交换关系的一部分。
第三层是限制：免责声明、责任限制、专利或商标排除。读这一层，是为了知道“许可证没有给我什么”。很多许可证都包含无担保和责任限制，这对作者很重要；而专利和商标边界则会影响商业产品、品牌使用和客户承诺。
这三层比“宽松许可证”和“传染性许可证”这种口语说法更可靠。宽松许可证通常条件较少，但并不等于没有条件；强 copyleft 许可证条件更多，但也不是不能商用。准确做法是回到许可证文本：看权利、看条件、看限制。
MIT、Apache-2.0、GPLv3 的差异，不在于谁更免费
MIT 许可证很短，常用于希望降低复用门槛的项目。它给出的许可范围很宽，条件集中在保留版权声明和许可声明；同时，它有明确的无担保和责任限制。对使用者来说，MIT 常见且好处理，但仍要保留声明，不能把它当成“没有任何要求”。
Apache License 2.0 更长，适合对专利、NOTICE、贡献提交和商标边界有更清楚安排的项目。它授予版权许可，也授予来自贡献者的专利许可；再分发时要求给接收者许可证副本、标明修改文件、保留相关声明，并在有 NOTICE 文件时按规则处理。它还明确不授予商标使用权。对公司产品来说，Apache-2.0 的专利条款常常是重要考量。
GPLv3 的重点不是放松条件，而是确保接收者继续获得软件自由。它要求分发带有 GPL 覆盖作品时传递同样的权利；分发修改版本时，要按条款提供源代码、保留许可、标明修改，并在某些组合场景中让整个作品按 GPLv3 授权。GPLv3 也处理专利相关风险，并强调无担保。它可以商用，也可以收费分发，但它会影响你如何分发修改版和组合后的作品。
这三者都可能是“免费可获取”的代码，但工程后果完全不同。MIT 适合很多库和工具；Apache-2.0 对专利和 NOTICE 更明确；GPLv3 适合希望衍生版本继续开放的项目。选择哪一个，不是看谁名气大，而是看项目作者想保护什么、使用者如何分发、产品是否需要闭源集成、依赖链是否兼容。
专利、商标和免责声明经常被忽略
开发者读许可证时容易只看版权授权，却漏掉专利、商标和免责声明。商业场景里，这三个点常常更敏感。
专利问题常见于基础设施、中间件、编解码、AI 工具链、云平台相关代码。Apache-2.0 明确包含贡献者的专利许可，并设置相关条款；MIT 文本本身没有同样展开的专利许可结构。这里不宜简单得出“某许可证更安全”的结论，因为实际风险取决于项目、贡献者、专利持有人和使用方式，但至少应意识到：版权允许你复制代码，不等于专利风险自动消失。
商标问题也常被混淆。你可以使用某个开源项目代码，不代表可以把自己的产品叫成同一个名字，或暗示得到原项目背书。Apache-2.0 就明说许可证不授予使用许可方商号、商标、服务标志或产品名称的权限，除合理描述来源以外。很多开源项目还会有单独的商标政策。
免责声明则关系到责任预期。MIT、Apache-2.0、GPLv3 都有无担保或责任限制相关文字。对作者来说，这是发布开源代码的重要保护；对使用者来说，它提醒你不能把上游开源项目当成供应商 SLA。你把开源组件放进产品，就要自己做测试、审计、安全响应和客户承诺管理。
依赖兼容性不是凭感觉判断
单个许可证已经需要阅读，多个依赖放在一起时更复杂。一个项目可能同时用 MIT 库、Apache-2.0 库、GPL 工具、商业 SDK、字体、文档模板和示例数据。每一类材料的许可证都可能不同。
SPDX License List 的价值就在这里。它为常见自由、开源或协作软件、数据、硬件、文档许可证提供标准短标识、全名、许可证文本和永久 URL。SPDX 许可证表达式还能用 AND、OR、WITH 等操作符表达更复杂的授权关系，例如多个许可证同时适用、二选一授权，或某个许可证带例外。机器可读标识让扫描工具、SBOM、CI 检查和审计留痕更容易对齐。
但 SPDX 标识不是法律判断本身。MIT、Apache-2.0、GPL-3.0-only、GPL-3.0-or-later 这些标识能帮你准确指向文本，却不能自动告诉你某个组合能否按你的产品方式分发。许可证兼容性要看链接方式、修改范围、分发形态、是否提供源代码、是否有例外条款、是否包含生成代码或模型权重等具体情况。
创业团队的实务做法，可以把依赖治理前移：新增依赖时记录来源、版本、许可证、SPDX 标识、用途、是否进入发布物、是否修改、是否有 NOTICE 要求；发布前生成依赖清单和许可证包；高风险依赖进入人工审查。这样比上线前临时翻仓库稳得多。
作者选择许可证前，要先想清楚项目目标
如果你是项目作者，选择许可证不是填空题，而是产品策略的一部分。你希望别人怎么用你的代码？你是否允许商业使用？你是否希望修改版本继续开放？你是否介意闭源产品集成？你是否需要更清楚的专利安排？你是否会接受外部贡献？你是否还要保护项目名称和品牌？
想让别人低摩擦复用，常见选择是 MIT、BSD、ISC 等宽松许可证。想更明确处理专利，Apache-2.0 常被考虑。想要求衍生版本继续开放，可以研究 GPL、LGPL、AGPL、MPL 等 copyleft 或弱 copyleft 许可证。这里没有一个适合所有项目的答案，因为许可证表达的是作者对协作、商业化和自由传递的取舍。
也要注意项目材料不只有代码。文档、网站内容、图标、字体、数据集、模型、配置样例、测试数据，都可能需要不同许可证。把所有东西都塞进一个 LICENSE 文件，未必能覆盖真实边界。成熟项目常常会在 README、NOTICE、CONTRIBUTING、TRADEMARK 或 docs 中说明更多规则。
如果项目已经有外部贡献，再换许可证就更要小心。你可能需要所有相关权利人的同意，或者依赖贡献协议里的授权安排。早期把许可证和贡献规则写清楚，会省掉很多后续麻烦。
使用开源代码前的可执行检查清单
第一，确认是否有许可证。不要只看仓库 public，也不要只看包管理器页面。优先找根目录 LICENSE、COPYING、NOTICE、README 里的许可证说明，以及包元数据中的 SPDX 标识。
第二，确认许可证版本和例外。GPL-2.0-only、GPL-2.0-or-later、GPL-3.0-only、GPL-3.0-or-later 不应混为一谈；带例外的许可证也要完整记录。SPDX 表达式能帮助团队把这些差异写清楚。
第三，确认你的动作属于私人使用、内部部署、分发、SaaS 服务、嵌入硬件、客户端发布还是二次销售。许多条件是在分发、提供网络服务或交付产品时触发，具体要回到许可证文本判断。
第四，确认是否修改了上游代码。修改通常会带来标明变更、保留声明、公开相应源代码或用相同许可证授权等义务，具体取决于许可证文本。
第五，确认依赖是否进入发布物。只在开发阶段用的工具、构建时工具、运行时库、复制进源码的片段、静态链接库、容器镜像里的组件，审查方式可能不同。
第六，确认 NOTICE、版权声明和许可证副本是否随产品交付。很多合规问题不是因为项目不能用，而是因为交付时漏了声明和文本。
第七，确认无许可证依赖和非标准许可证。无许可证不要默认可用；不在常见列表里的许可证要读原文，必要时单独审查。
第八，保留审计留痕。记录为什么选择这个依赖、读了哪个许可证版本、采用了哪些交付措施。以后有人问起，不必从头翻仓库。
常见误区
第一个误区，是把“开源”等同于“免费商用”。很多开源许可证允许商业使用，但仍有条件；有些源码可见项目并不是开源许可证；还有些材料虽然免费访问，却没有给你想象中的复制和分发权。
第二个误区，是把 MIT 当成没有要求。MIT 很宽松，但仍要求保留版权声明和许可声明，也包含无担保文字。产品发布时漏掉许可证文本，仍然是不合格的交付。
第三个误区，是以为 GPL 不能商用。GPL 的重点不是禁止商业，而是要求在分发等场景中把相应自由传给接收者。它可以收费分发，也可以商业使用，但对衍生作品和源代码提供有明确要求。
第四个误区，是忽略专利和商标。代码许可、专利许可、商标许可不是同一个盒子。能用代码，不等于能用名称、图标或品牌背书。
第五个误区，是只审查直接依赖。很多风险藏在间接依赖、复制的代码片段、示例文件、字体、数据集和容器镜像里。现代软件供应链需要清单化管理。
第六个误区，是等融资、客户安全问卷或并购尽调时再整理。那时再找许可证和声明，往往成本高，证据也不完整。依赖进入项目的那一刻，就应该记录。
用工程习惯读许可证
许可证可以按工程文档来读。先读标题和版本，确认是不是你以为的那个许可证；再读授予的权利，确认能做什么；然后读条件，确认交付时要带什么；再读限制，确认没有得到什么；最后看项目自己的 README、NOTICE、贡献规则和商标政策。
对个人开发者来说，这能避免无意踩坑。对团队来说，这能把许可证从“法务最后看一眼”变成研发流程的一部分。依赖进入项目、版本升级、发布交付、客户审查，都能基于同一份记录继续推进。
开源让软件协作更顺畅，但它不是无边界复制。价格只是入口，许可证才是使用规则。只看“免费”两个字，就像只看地图上的绿色区域却不看道路、限速和通行方向。读懂许可证，才是在尊重作者、保护团队，也保护后续用户。