是否存在第三方组件或授权限制，导致源码无法自由使用？

正常做下来的项目不会出现这种情况。滚水科技在合同里就会明确"不得引入侵权代码与授权不清晰的组件"，一旦出现因第三方组件许可证问题导致客户无法自由使用源码的情况，由我们承担全部责任并负责替换。

但具体到技术细节，第三方组件本身是几乎不可能完全避免的，关键看怎么选、怎么用。我们的做法分几条线：

• 开源组件优先选商业友好的许可证：MIT、Apache 2.0、BSD 这类是默认池子。GPL、AGPL 这类传染性强的协议除非客户明确要求，否则不会用在闭源商业系统里。
• 商业 SDK 走客户名义购买：例如百度/高德地图、极光推送、阿里云短信、微信支付等，账号、合同、计费都挂在客户主体下，授权范围是客户自己签的。
• 底座代码自有：滚水科技内部的脚手架、组件库基于自研，可在项目里自由复制使用，不会附加任何对客户的牵制条款。
• AI 模型与算法：如果项目用到第三方大模型 API（如 DeepSeek、通义、Claude 等），按各家厂商的接入协议走，客户拥有自己的密钥与调用配额。

交付时我们会一并提供一份《依赖清单》，列出项目里用到的所有开源库和商业 SDK，标注许可证类型、版本、用途。这份清单方便客户内部做合规审查，也方便后续换团队接手时一眼看清依赖结构。

如果客户对开源协议有特别要求——比如完全规避 GPL/LGPL，或者必须通过内部安全扫描——前期告诉我们，方案设计阶段就会把对应限制带进来，避免上线后再返工。

我们做过的项目里，从 App、小程序到工厂内部系统，没有出现过因为开源协议问题导致客户被迫开源或停用的情况。万一真的踩到雷，按合同条款由滚水科技承担替换成本并配合处理，客户拿到的源码使用、修改、二次开发权不会受影响。