如果依据实际使用的虚拟资源或者使用的人数作为另一种授权方案，那么对应用程序而言就会比较公平了。从前面提到的例子来看，通常数据库厂商还是会坚持依据 CPU 型号，不过依据 SAP 的方式，相同数据库的产品可以整体规划为同一个数据库，这样就会以用户的数量执行授权。
从上述的例子来看，我们可以发现云的优势会因为受限于旧有的授权模式而荡然元存。 虽然有提供商提供诱人的定价来减少使用基础设施服务的成本，增加经济效益和服务的延展性，但却会让用户因为软件的授权方式负担额外的成本。 优势与劣势互相抵消的结果，最差的情况就会演变成云方案毫无任何的效益。
不过在实际应用方面，大部分软件提供商会体贴地尽量满足客户的需求，也不会依循理论上应强制执行的部分要求硬性执行，尤其会针对有长期合作关系的优良客户或供应商，额外做授权定价调整。通常厂商非常清楚需要调整授权模式，也会特别告知客户已经着手为云服务架构规划新的授权模式。不过，如果提供商在审核可能的授权方式时，仍然坚持对于既有合同从严解读，最后将导致用户不得不选择"移情别恋"，另外再找一家软件提供商，或者考虑采用"开放源代码"的产品。开放源代码的授权方式大多采用简易的方案，来协助降低云授权面临的风险。 虽然通常会需要验证使用开放源代码软件，能否确实做到有效授权管理，但大部分的开放源代码授权都会包含较广泛的用途，如发行权等。
