在日常开发中，很多人习惯把代码往 GitHub 或 GitLab 一扔就完事了，但你有没有想过，别人能不能用你的代码？用了出问题谁负责？这些其实都和代码托管平台上的许可证选项息息相关。
许可证不是可有可无的摆设
新建仓库时，平台通常会提供一个“Add a license”选项。跳过它看似省事，实则埋下隐患。没有明确许可证的项目，默认是“保留所有权利”，意味着别人下载你的代码哪怕只是学习参考，理论上也算侵权。
比如公司内部开源了一个小工具，同事拿去改了几行用在另一个项目上，结果被法务查到没加许可证，最后还得回溯补签，耽误进度还惹麻烦。
常见许可证怎么选
MIT 许可证最简单直接：允许任何人使用、复制、修改、分发，只要保留原许可声明就行。适合希望代码被广泛使用的个人或团队项目。
Permission is hereby granted, free of charge, to any person obtaining a copy of this software...
subject to the following conditions:
The above copyright notice and this permission notice shall be included...Apache 2.0 比 MIT 多了些条款，比如明确授予专利使用权，也规定了对修改文件的说明义务。适合企业级项目，尤其是可能涉及专利的场景。
GPL 系列（如 GPLv3）则更严格。如果你的项目用了 GPL 代码，整个项目也必须开源并采用相同协议。这像“传染性”条款，适合坚持彻底开源理念的项目，但要小心引入后对商业闭源产品的影响。
GitHub 上怎么加许可证
创建仓库时勾选 “Add a license” 下拉框，里面列了常见选项。也可以事后补加：在仓库根目录添加一个叫 LICENSE 或 LICENSE.md 的文件，内容贴对应协议原文即可。GitHub 会自动识别并在仓库顶部显示。
比如你想用 MIT，就去搜 “MIT License template”，复制标准文本，把年份和作者名替换掉，丢进 LICENSE 文件提交就行。
私有项目要不要管许可证
如果是纯内部使用的私有仓库，不对外公开，许可证影响不大。但一旦有外部协作，哪怕是外包人员参与，最好也明确授权范围，避免后续纠纷。
有些团队会在公司内网项目里统一用 COPYING 文件注明“本项目仅限员工内部使用，未经许可不得外传”，这也是一种变通做法。
别忽视第三方依赖的许可证
你项目里用了别人的库，对方的许可证照样约束你。npm install 一堆包，里面可能混着 AGPL 的组件，而 AGPL 要求网络服务也必须开源，这在商业项目中很容易踩坑。
建议用工具如 license-checker 定期扫描依赖树，提前发现高风险许可证。