随手拿来的代码，收到了律师函
发生了什么
一个商业产品中使用了带有严格开源许可协议的代码库。该协议要求任何使用了它的项目都必须同样开源。产品发布后，原作者发现了这一违规行为，发来了法律函件要求整改。
缺失了哪块知识地图
在引入第三方代码时，完全没有检查其开源许可协议的条款。既不知道不同协议之间的差异，也没有意识到"免费可用"不等于"可以随意商用"。
那天发生了什么
你做了一个小产品，打算靠它赚点钱。在开发过程中，AI 帮你引入了好几个开源的代码库来加速开发——日期处理、图表渲染、界面组件，每一个都让你的产品变得更好。你很感激开源社区的慷慨，但你从来没有想过去看一眼这些代码库附带的"许可协议"文件。
产品上线后，一切顺利。直到某一天，你收到了一封措辞严肃的邮件。一个你使用的代码库的作者指出：他的代码采用的是 GPL 协议，这意味着任何使用了它的项目，都必须以同样的方式开源自己的全部源代码。而你的产品是闭源商用的——你违反了协议。
对方要求你要么立即公开你的全部源代码，要么停止使用他的代码库并下架相关功能。如果你两样都不做，他保留采取法律行动的权利。
问题出在哪里
"开源"并不意味着"没有规则"。恰恰相反，几乎每一个开源项目都附带了一份许可协议，明确规定了你能用它做什么、不能做什么。
常见的协议大致分为两类：
宽松型（如 MIT、Apache 2.0）：基本上你可以随便用，包括商用，只需要在项目中保留一份原始的版权声明。大多数流行的前端框架和工具库都采用这类协议。
传染型（如 GPL、AGPL）：如果你的项目使用了采用这类协议的代码，你的整个项目也必须以同样的协议开源。这对商业产品来说可能是致命的——因为它意味着你必须公开自己的源代码。
问题在于，AI 在帮你选择代码库时，通常不会主动告诉你它的许可协议是什么。它关心的是"能不能用"，而不是"你有没有权利用"。
怎么避免重蹈覆辙
每当 AI 在你的项目中引入一个新的第三方代码库时，花一分钟做一件事：查看它的许可协议。
在大多数代码库的项目主页上，你都能找到一个名为 LICENSE 的文件，或者在页面显眼位置看到协议名称（如"MIT License"或"GPL-3.0"）。
对于商业项目，有一个简单的经验法则：
- 看到 MIT 或 Apache 2.0：通常可以放心使用。
- 看到 GPL 或 AGPL：需要非常谨慎，除非你也打算把自己的项目完全开源。
- 看到 不确定的协议 或 没有协议：不要使用——没有许可协议的代码在法律上意味着你没有任何使用权利。
你也可以在让 AI 推荐技术选型时，加上一句："请确认你推荐的每个库都使用 MIT 或 Apache 2.0 兼容的许可协议。"这不是多余的谨慎，这是对你自己的产品负责。
如何预防