为什么开源 VPN 在采购中会被否决

援引开源而作出的否决，很少真正关于许可证。评审人通常是在保护一项要求：有人维护已部署的版本、已安装的构建可以被识别、评估覆盖了即将接入的对象，或者连接可以被撤回。随后的争论，往往在回答一个没人提出的问题。

在为许可证辩护之前，先问清适用的是哪一项要求。答案决定了你需要哪份文件。

标签不等于要求

可读的源代码意味着公开的实现可以被检查。它并不意味着有人检查过、网关上的构建与公开版本一致，也不意味着维护者对你的部署负有修复义务。这些分别是独立的声明，各有各的责任方；需要其中一项的评审人，不会因为其他几项而满意。把这项声明说出口，通常就足以改变对话。

反向的错误同样常见。商业许可证不能证明支持覆盖了你所依赖的功能，不能证明评估检查了你部署的组件，也不能证明供应商会在你的维护窗口内交付修复。许可证描述的是分发条款，而采购决策关心的是可依赖性。无论哪种情况，许可证都是答案中信息量最少的部分。

还要把客户端与服务端分开。对桌面客户端的审计，说明不了合作方网关的配置、其身份提供方，也说明不了其运维人员如何处理账号注销。你收集的任何证据，都必须与合作方被要求信任的那条边界一致。

请审批人用一句话说明这项要求，然后指出能满足它的材料。正是含糊的安抚，把这类对话变成了意识形态之争。

What the reviewer is protecting	Artifact that answers it	Who can sign it
The deployed release keeps getting fixes	Named maintainer, supported version list and the cadence for security releases	The operating team, with the maintainer's published policy attached
The build is the one that was reviewed	Package source, version string and the checksum or signature you verify at install	The team that builds or vendors the package
An assessment covers the right scope	Component and version assessed, findings raised, corrections made, retest date	Whoever performed the assessment
The access can be withdrawn	Identities granted, resources reachable, and the tested removal procedure	The service owner on the partner side

NIST Secure Software Development Framework 在这里有用，原因很窄：它把采购对话框定在实践与供应商沟通的共同语汇之上。这支持的是索要明确的证据，而不是围绕标签争论；它并不是任何特定 VPN 都能通过的认证。

注意中间那一列的作用。每一行要求的都是一份存在或不存在的文件，从而把观点变成某人可以交付或拒绝的成果。

客户端应用的支持合同，并不是对流量所抵达服务器的承诺。在提交证据之前，先标出路径中哪些部分由合作方运营，哪些部分由你代其运营。把两者混在一起，只会得到一份看起来很周全、却什么也没回答的材料。

如果部署是你自己的，合作方可能只需信任一个身份和一条访问规则，这比信任你整条软件供应链要小得多。如果部署是对方的，你偏好的客户端可能无关紧要，网关配置反而成为主题。在第二次会议之前弄清属于哪种情况，可以省下一轮评审。

接着检查评审真正会卡住的运维问题：谁负责注销账号、多快完成，以及事后有什么证据。一份文档写得漂亮却没有注销流程的评估，仍然是未关闭的发现。

以书面结论结束这次往来：被接受的版本、随之附加的控制措施、指定的运维人员、仍然缺失的证据以及提交期限。任何未解决的事项都应记为条件，而不是并入一份笼统的批准声明。

如果政策点名了某个已批准的产品，就走例外程序，而不是搭建一套无人授权的平行安排。有说服力的技术论证并不等于许可，非正式部署则是一项等待被发现的发现。

如果某项要求确实无法满足，就转向已批准的替代方案，并说明原因。这项工作的目的是确定组织可以依赖什么；一个明确的“不”，好过一份日后无人能够辩护的批准。