最可靠方式是直接查看项目根目录下的 LICENSE 或 LICENSE.txt 文件；GitHub 页面协议标签可能不准确，setup.py 或 pyproject.toml 中的 license 字段可作参考，但需结合原始文件确认。
怎么快速确认一个Python项目用的是MIT还是BSD协议
直接看项目根目录下的 LICENSE 或 LICENSE.txt 文件，这是最可靠的方式。GitHub 仓库首页通常也会在右上角显示协议图标和名称，但这个信息可能滞后或被误填——比如有人把 MIT 写成 “MIT License”，而自动化工具只认标准字符串，所以不能只信那个小标签。
如果没找到 LICENSE 文件，可以查 setup.py 或 pyproject.toml：
-
setup.py中找license=字段，常见值有"MIT"、"BSD-3-Clause"、"Apache-2.0" -
pyproject.toml中找[project.license]或[project.classifiers]，后者可能含"License :: OSI Approved :: MIT License"
注意：有些项目只写 "BSD"，不注明是 2-Clause 还是 3-Clause —— 这时得翻原始 LICENSE 文件内容，因为两者对“不得用作者名做背书”的条款要求不同。
pip install 的包，协议信息藏在哪
运行 pip show ，输出里的 License 行就是元数据中声明的协议名，但它不一定准确。比如 requests 显示 Apache-2.0，但实际源码里是 Apache-2.0 + 附加 NOTICE；而某些小众包可能填了 "MIT" 却没附 LICENSE 文件，属于协议无效状态。
更稳妥的做法是：
- 用
pip show -f查看已安装文件路径，然后去对应 site-packages 目录下找LICENSE或NOTICE - 或者用
pip download --no-deps --no-binary :all:下载源码包，解压后直接读 LICENSE
别依赖 PyPI 页面上的“License”字段——它由上传者填写，没人校验。
立即学习“Python免费学习笔记（深入）”；
MIT/BSD 协议下能改代码、闭源、商用吗
能，但有条件。MIT 和 BSD-3-Clause 都允许修改、闭源、商用、卖钱，但必须保留原始版权声明和许可声明。容易忽略的关键点是：
- 不是“只要加一行注释就行”——你得把原 LICENSE 文件全文（或至少版权行+许可文本）放进你的衍生项目里，比如放在
NOTICE或文档中 - BSD-3-Clause 多一条“不得用原作者名字为产品背书”，如果你在宣传材料里写“本工具基于 XXX（MIT）开发”，没问题；但如果写“XXX 团队推荐使用本软件”，就踩线了
- MIT 不禁止 SaaS 化，但如果你把 MIT 项目打包成 API 服务并限制他人调用，这本身不违法协议，只是社区伦理问题
特别提醒：MIT/BSD 只管分发行为，不管运行时行为。你用 MIT 的库跑内部系统，哪怕加了 100 个私有模块，也不需要开源——这点和 GPL 完全不同。
公司项目里混用多个开源协议，怎么不出事
先跑 pip-licenses（需安装）生成所有依赖的协议清单：pip-licenses --format=markdown --format-file=THIRD-PARTY.md。重点不是“有没有 MIT”，而是检查有没有冲突组合，比如：
- MIT + Apache-2.0：兼容，可混用
- MIT + GPL-2.0：不兼容——一旦引入 GPL-2.0 代码，整个衍生作品就得按 GPL-2.0 开源
- BSD-3-Clause + GPL-3.0：兼容（因为 GPL-3.0 明确兼容 BSD-3）
真正麻烦的是“许可证叠加”场景：比如你用了一个 MIT 库 A，A 又依赖了 Apache-2.0 的 B，B 里又带了个 NOTICE 文件要求“单独列出贡献者”。这时候你得把 B 的 NOTICE 内容也抄进自己项目的 NOTICE 里，否则法律上不算履行义务。
最后强调一句：协议合规不是“有没有 LICENSE 文件”，而是“你分发时是否完整传递了原始许可要求”。很多团队卡在这一步，不是不懂协议，是没意识到 NOTICE、COPYRIGHT、ATTRIBUTION 这些字段也要跟着代码一起走。
