为什么许可证不是随便选的
很多人在创建新项目时，习惯性地点一下“添加许可证”，然后随手选个 MIT 或 Apache 就继续往下走。但你有没有想过，这个看似不起眼的选择，可能决定了别人能不能商用你的代码，甚至影响你自己的后续开发权利？
比如你在公司做前端开发，业余时间写了个小工具上传到 GitHub，选了 GPL 许可证，结果公司想用你的工具优化内部系统——不好意思，GPL 要求衍生作品也必须开源，这可能会踩到公司的红线。
常见许可证的实际差异
MIT 是最宽松的一种，基本等于说：“拿去用吧，只要保留我的署名，爱干嘛干嘛。” 适合个人项目或想广泛传播的工具库。
Apache 2.0 比 MIT 多了一层保护：如果有人用了你的代码还告你侵犯他的专利，那他自动失去使用权限。对团队协作或企业级项目更友好。
GPLv3 则是“开源硬核派”的选择。只要你用了带这个许可证的代码，整个项目都得跟着开源。如果你希望推动开源生态，这是利器；但想留点私心，就得绕着走。
GitHub 上怎么选才不踩坑
新建仓库时，GitHub 会提示是否添加 LICENSE 文件。点开下拉菜单，常见的几个都会列出来。建议别跳过这一步，哪怕先选 MIT 占个位，也比空着强。
如果你是团队协作，最好在项目初期就定好许可证策略。可以像写 README 一样，在根目录加个 LICENSE 文件，内容直接从官方复制：
Copyright (c) 2025 你的名字
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:这段就是 MIT 许可证的开头部分，完整版一般存为纯文本文件。
换许可证？没那么简单
项目火了之后想换个更宽松或更严格的许可证？小心了。只要有人提过 Pull Request，他的代码也受原许可证约束。想改，得所有贡献者点头才行。所以一开始选清楚，比后期补救省心得多。
有些团队会在 CONTRIBUTING.md 里写明：“提交代码即视为同意本项目当前许可证”，提前规避法律风险。
别让许可证成为文档的盲区
很多人花大力气写接口文档、更新日志，却把 LICENSE 文件扔在角落。其实它和 README 一样重要。可以在文档首页加个小图标，标明当前项目的许可证类型，比如用 Shields.io 生成一个徽章：https://img.shields.io/badge/license-MIT-blue，插进 README 就一目了然。
代码托管平台不会替你做决定，但它们提供了清晰的选项和模板。与其等到被别人问“这项目能商用吗”，不如早点把许可证写明白，省得来回解释。