Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
很多人第一次接触 GitHub，都会有一个错觉：
👉「反正是开源的，直接复制粘贴用就行了。」
但现实是：
用错 License，轻则被要求补版权声明，重则可能被要求开源你的整个项目，甚至面临法律风险。
这篇文章会从 0 开始，带你系统搞懂：
- GitHub 到底是干嘛的？
- 开源 ≠ 免费随便用？
- MIT / Apache / GPL / BSD / MPL 等 License 的区别
- 商业项目、公司项目如何安全使用开源代码？
- 新手最容易踩的 10 个坑
- 一套可直接照着执行的合规清单
如果你是程序员、自媒体站长、做工具站、做 SaaS，或者经常从 GitHub 下载源码改来用，这篇一定要收藏。
一、GitHub 是什么？为什么几乎所有程序员都在用？
简单说，GitHub 是一个全球最大的代码托管平台，你可以在上面：
- 存放自己的项目源码
- 下载别人开源的项目
- 协作开发（Issue / PR / Review）
- 管理版本（Git 版本控制）
- 构建开源社区
很多你熟悉的工具、框架、库，几乎都可以在 GitHub 上找到源码，比如：
- 各种前端框架
- 后端框架
- 爬虫工具
- 自动化脚本
- 开源桌面软件
- 录屏工具、下载工具、图片处理工具
👉 关键点：GitHub 只是“平台”，真正决定你能不能用代码的，是项目的 License（开源协议）。
二、开源 ≠ 随便用：License 是“法律合同”，不是装饰品
很多人会忽略仓库里的 LICENSE 文件，这是最危险的做法。
你从 GitHub 拿代码，本质上是在接受作者给你的使用许可合同。
不同 License 代表的权限差异巨大，比如：
- 有的允许商用
- 有的要求你必须保留版权声明
- 有的要求你修改后必须开源
- 有的禁止你闭源商用
- 有的要求你附带原作者协议文本
忽略 License 的后果：
- 项目被投诉下架
- App 被应用商店拒审
- 被要求开源商业源码
- 被追责侵权
三、最常见的开源协议详解（MIT / Apache / GPL / BSD / MPL）
下面用「能不能商用 / 要不要开源 / 要不要署名 / 风险等级」的方式，帮你一眼看懂。
✅ MIT License（最宽松，新手最爱）
适合人群：
个人开发者 / 商业项目 / 工具站 / SaaS
你可以：
- ✅ 免费使用
- ✅ 商业使用
- ✅ 修改源码
- ✅ 闭源发布
- ✅ 再授权
你必须：
- 📌 保留原作者版权声明
- 📌 保留 MIT License 原文
不能做的：
- ❌ 删除作者信息
- ❌ 声称代码是你原创
👉 风险等级：⭐（最低）
👉 商业项目首选
✅ Apache License 2.0（对商业非常友好）
特点：
比 MIT 更严谨，额外保护专利权。
你可以：
- ✅ 商用
- ✅ 修改
- ✅ 闭源
- ✅ 再授权
你必须：
- 📌 保留版权声明
- 📌 保留 LICENSE
- 📌 声明你修改过源码
- 📌 保留 NOTICE 文件（如果项目有）
👉 风险等级：⭐
👉 适合公司级项目、SaaS、工具产品
⚠️ GPL（GNU General Public License）（“传染性”最强）
常见版本：GPL v2 / GPL v3
最大坑点：
只要你的项目用了 GPL 代码，
👉 你的整个项目必须开源。
你可以：
- ✅ 使用
- ✅ 修改
- ✅ 发布
你必须：
- 📌 你的项目必须整体 GPL 开源
- 📌 提供完整源码
- 📌 允许别人二次修改
- 📌 保留协议
👉 风险等级：⭐⭐⭐⭐⭐
👉 商业闭源项目基本要避开 GPL
适合：
开源项目对开源项目，不适合闭源商业产品。
✅ BSD License（宽松但有细节差异）
常见：BSD 2-Clause / BSD 3-Clause
你可以：
- ✅ 商用
- ✅ 修改
- ✅ 闭源
- ✅ 再发布
你必须：
- 📌 保留版权声明
- 📌 不得用原作者名字做宣传（3-Clause）
👉 风险等级：⭐
👉 和 MIT 类似，适合商用
⚠️ MPL（Mozilla Public License）
特点：
- 介于 MIT 和 GPL 之间
- 只要求你修改过的文件开源
- 不要求整个项目开源
你可以：
- ✅ 商用
- ✅ 闭源整体项目
你必须：
- 📌 修改过的 MPL 文件必须开源
- 📌 保留协议
👉 风险等级：⭐⭐⭐
👉 公司可用，但要有合规流程
四、商业项目使用开源代码的安全姿势（实操清单）
如果你是：
- 建站
- 做 App
- 做工具
- 做 SaaS
- 做商业产品
强烈建议你照这个流程来：
✅ 使用前检查清单
- 仓库是否有 LICENSE 文件
- License 类型是什么
- 是否允许商用
- 是否要求开源
- 是否有 NOTICE 文件
- 是否有额外限制说明
✅ 使用后合规动作
- 在关于页 / 文档中注明使用了哪些开源项目
- 保留 License 文件
- 标注修改内容
- 不删除作者信息
- 不误导用户“这是我原创”
五、新手最容易踩的 10 个坑
❌ 1. 没 License 就默认能用
❌ 2. GPL 项目直接商用闭源
❌ 3. 删除版权头注释
❌ 4. 修改代码但不声明
❌ 5. 二次分发不附 License
❌ 6. 用作者名字宣传产品
❌ 7. 混用不兼容 License
❌ 8. 复制代码不看仓库说明
❌ 9. 把 Demo 当生产代码
❌ 10. 不关注 License 变更
六、怎么看一个 GitHub 项目是否“安全可用”？
推荐检查 5 个位置：
1️⃣ 仓库首页是否写明 License
2️⃣ 是否有 LICENSE 文件
3️⃣ README 是否有商用说明
4️⃣ 是否有 NOTICE
5️⃣ 是否注明 Third-party licenses
如果不确定：
👉 宁可不用，也不要“赌”。
七、常见问答（非常实用）
Q：MIT 项目改了源码，可以不公开吗？
A：可以，闭源商用没问题，但要保留原作者声明。
Q：GPL 代码只复制了几行算不算传染？
A：存在法律风险，实际判定复杂，商业项目建议回避。
Q：没有 License 的项目能不能用？
A：法律上默认不可使用，作者未授权。
Q：License 以后会变吗？
A：会，有些项目会从 MIT 改成商业协议，要注意版本差异。
八、结语：尊重开源，才能长期安全使用
开源世界不是“白嫖世界”，
而是一套基于信任与规则的协作体系。
你尊重 License，
作者才愿意继续开源，
社区才会越来越好，
你的项目也不会埋雷。
一句话总结：
👉 代码可以白用，但责任不能白丢。
