前面已经讨论过普通GPL类许可证的“传染性”特征，即基于GPL许可代码进行修改或者衍生开发形成的软件，在对外分发时也必须以相同或者兼容的开源许可证条款公开源代码，但传统的GPL许可证条款，其触发开源义务的关键前提，通常是“对外分发”软件（比如向用户提供可执行程序的下载安装），如果企业的商业模式是通过SaaS（软件即服务）方式，将软件部署在自己的服务器上，用户仅仅是通过网络访问使用相应的服务功能，而不涉及软件本身的实际分发交付，这种情况下，按照传统GPL许可证的字面条款理解，可能存在规避开源义务的操作空间，这也被称为“SaaS漏洞”或者“ASP漏洞”。

AGPL（Affero通用公共许可证）正是为了填补这个“SaaS漏洞”而专门设计的一种开源许可证，AGPL在GPL的基础条款之上，增加了专门的第13条网络使用条款，明确规定，如果企业修改了基于AGPL协议授权的软件，并通过网络方式与用户进行交互（也就是以SaaS等网络服务模式对外提供服务），即便企业没有向用户直接分发该软件的可执行程序，企业仍然需要向所有通过网络与该修改后软件进行交互的用户，提供获取该软件完整对应源代码（包括企业所做的全部修改内容）的途径，通常是通过提供源代码下载链接或者其他合理的获取方式实现。

这意味着，如果企业基于AGPL协议授权的开源代码，进行修改开发，并将开发形成的软件，以SaaS模式部署在自己的服务器上，对外提供网络服务，企业实际上同样面临着需要公开自己在AGPL开源代码基础上所做修改的完整源代码的义务，这跟企业可能原本预期的、通过SaaS模式规避传统GPL开源义务的商业策略，形成了直接的冲突，如果企业的SaaS产品，包含了具有重要商业价值和竞争优势的核心专有代码修改和创新，被要求依据AGPL协议开源公开，可能对企业的核心商业利益造成重大不利影响。

建议企业在评估和选择拟使用的开源代码组件时，对于计划应用于SaaS等网络服务商业模式的场景，应当特别审慎地核查所使用开源代码适用的具体许可证类型，如果发现相关代码适用的是AGPL许可证（或者其他具有类似网络使用条款设计的许可证），应当充分认识到，即便采用SaaS而非传统软件分发的商业模式，仍然可能面临相应的源代码开放义务，企业需要结合自身的商业模式和核心竞争力保护需要，审慎评估是否适合使用这类许可证的开源代码，如果确实需要使用，应当提前规划好相应的开源合规应对方案，或者考虑寻找采用其他更为宽松许可证（比如MIT、Apache 2.0等）的替代性开源组件，避免因为对AGPL许可证网络使用条款的特殊要求缺乏充分认识，给企业的核心商业代码资产带来意料之外的开源合规风险。