别让开源许可证拖了项目后腿
刚创业那会儿，我们团队想快速推出产品原型，直接拿了一个 GitHub 上的开源项目改了改就上线了。结果半年后收到一封律师函，说我们的修改版本没按原项目的许可证要求开源代码，差点被起诉。这才意识到，开源不是免费午餐，选错许可证，轻则重构代码，重则法律纠纷。
MIT 和 Apache 2.0 是创业公司的首选
M涉诉讼风险低，适合想快速发布工具或库的团队。比如你写了个前端组件库想吸引开发者用，MIT 几乎不限制对方怎么用，连闭源商用都行，只要保留原作者声明就行。
Copyright (c) 2025 Your Company
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...<br>
...（其余省略）Apache 2.0 比 MIT 多一层专利保护。如果你的代码可能涉及算法或通信协议，别人用了你的代码反过来告你侵权，Apache 能自动授予他们专利许可，反向保护你。
慎用 GPL 类许可证
有次朋友公司做 SaaS 系统，集成了一段 GPL v3 的日志分析模块，结果整个后台被迫开源。GPL 的“传染性”太强——只要你的代码和它动态链接，整个项目就得按同样条款开源。创业公司核心逻辑还没验证，就暴露代码，等于把底牌亮给对手看。
除非你打定主意做开源生态，比如推一个开发者平台，否则别碰 GPL。LGPL 倒是可以考虑，它允许闭源程序通过动态链接调用你的库，适合做中间件。
内部工具和客户交付要分开看
自研的 CI/CD 脚本、部署工具这类不对外发布的，用什么许可证都无所谓。但一旦要发给客户或上架产品，就得留神。曾经有团队把 MIT 许可的 UI 库嵌进硬件设备固件，却忘了在设备设置页加版权说明，被原作者在社区曝光，品牌形象大受影响。
建议建立一个小清单：所有引入的开源组件，记录名称、版本、许可证类型、是否需署名、是否要求开源衍生作品。用 Excel 或 Notion 都行，每周同步一次。
别忽视贡献者协议（CLA）
当外部开发者开始给你提 PR，记得加上 contributor license agreement。不然某天有人把他写的代码撤回授权，你整个项目可能得删改。Google 和 Facebook 的开源项目都这么干，小公司可以用简单声明：
By contributing, you agree that your code can be licensed under the project's main license (e.g., MIT), and you warrant that you own the rights to the contribution.放在仓库的 CONTRIBUTING.md 里就行。
创业拼的是速度，但省掉合规这一步，跑得越快摔得越狠。花半天搞清许可证区别，比事后花十万请律师划算多了。