发布时间： 2025-12-16 20:12:09 更新时间： 2025-12-16 20:50:10

🕒 阅读时间：2 分钟 📝 字数：531 👀 阅读量： Loading...

前言

上一篇文章，讲的是我博客主题获得软著了，很高兴。但心中还是有些疑虑，我这个项目使用的是MIT协议授权开放源代码分发的，我怕我的硬依赖里有GPL相关协议，怕其它开发者被我的MIT协议迷惑，如果存在的话，我必需声明出来，当然MIT和GPL是兼容的，如果真存在gpl相关协议的话，我的MIT协议也是可以保存的，于是我安装了NPM License Checker

npm install -g license-checker

这个全局npm依赖来检测我的项目依赖许可证，我看到了绝大部分都是MIT协议，还有两个LGPL协议，还有有一个是自定义协议，类似于LGPL，MIT也都能兼容它们，唯独那个@fancyapps/ui,却是没完整地提供协议文本，当我去自己寻找的时候，发现一个更严重的事…

fancybox? 不，是fancyapps!

fancyapps官网

众所周知，通过搜索引擎可以找到许多关于这个世界上最著名的前端灯箱库的文章，而且大多都历史悠久。如今，它已发展为一个完整的品牌，提供更多组件和服务。

许可问题

当然，发展壮大之后，它采用了自定义的 商业许可，并非是开源许可。尽管源代码可见，你仍需参阅其许可页面了解具体限制。下面我谈关键的几点：

Fancyapps 商业许可的特殊性

• 生产环境与分发受限：fancyapps 的商业许可条款将生产部署、商业用途或有偿服务中的使用视作需授权的场景。即使个人免费使用或项目在开发阶段免费测试，一旦将含有该组件的站点或应用部署到线上并向外提供服务（无论是否直接收费），在很多情况下都被视为“需要授权”并因此构成许可违规。
• 非商业使用也可能被限制：许可页面中对“免费/非商业”与“商业/生产”使用的区分意味着仅因项目以非商业名义发布并不能自动豁免对商业许可的要求；关键在于“是否对外提供服务或分发”。换言之，线上部署或向公众提供访问通常并不被视为完全免费的内部使用。

实务建议

我认为，对于大部分个人网站来说，追责的可能性较低，因此很多并未购买商业授权。实际上，fancyapps确实无能为力

但我的博客主题已获得软著，为确保合规性并避免未来潜在的法律风险，我决定替换为PhotoSwipe（MIT 许可证）的灯箱库。

结论

开放源代码!==开源

• Fancyapps 采用的商业许可对生产部署和对外分发有明确限制，单纯依靠项目的 MIT 许可证不能免除对该依赖的授权要求。
• 若项目会对外发布或作为主题/模板分发，推荐不要将带有商业使用限制的依赖直接打包进分发物中。
• 最稳妥的处理方式是替换为开源许可兼容的组件（例如 PhotoSwipe）。