Oracle难懂的许可策略最让人头痛。著名技术顾问、作家Robert Sheldon介绍了七个可能导致Oracle审查及昂贵审查费用的行为。

Oracle的许可策略极其含糊和难懂。一次失误就可能让你付出成千上万美元的审查费用。但是，由于有大量的管理包和预安装选择，因此Oracle软件很容易让人使用错误;所以在实践中你很容易违反规范和遇到上大麻烦。

一定不要幻想Oracle不会对你采取措施。根据最新的Flexera/IDC报告，在过去1年半至2年时间里有63%的受访组织遭受过一家软件供应商的审查，其中有56%的组织被迫支持额外费用，还有许多组织损失上百万美元。Oracle常常将自己置于一种凌驾于各个软件供应商之上的顶级审查者位置，热衷于挥动手中的大棒，控制客户的应用保证在限定范围内，而不管他们是否理解其中的许可规则。

想象一下，有85%的受访组织违反了他们的软件许可协议，这样你就会很清晰目前的状况。你的公司可能就是其中一个违规者，特别是如果公司恰好在使用Oracle产品。即便如此，你可能还是不清楚到底问题出现在哪里。下面我们介绍可能导致这些争议性Oracle审查及后续高昂许可费的七个最常见(通常也是最致命)的行为。

缺少许可清单

跟踪软件的许可文档是一件很棘手的工作。除了Oracle许可与服务协议(OLSA)，你还应该检查全部订单历史、续订日期、折扣产品及其他与软件采购相关的信息。如果签署了旧版本的OLSA，你还需要跟踪一些发生过变更的产品名称及指标。

对于完全理解自己购买什么产品及产品允许使用的范围，许可信息的可用性是非常重要的。例如，完全版(Full Use, FU)许可与专用应用完全版(Application-Specific Full Use, ASFU)许可就有很大的差别。如果不跟踪这些信息，那么很多方面都可能出现不确定性，其中包括OLSA与各种附加条款发生冲突时合同条款的优先级顺序。

不清楚产品安装在什么位置

与了解允许做什么同样重要的是要了解自己实际上是怎么做的。但是，很少组织有关于所实现产品的完整清单，更不用说产品的版本信息了。让问题复杂化的是你可以在未获得许可的情况下随意使用其他可选软件包和管理软件包。

具体到Oracle软件上，它的挑战在于产品的可选软件包和管理软件包已经随主产品安装了，而且默认是启用的。企业版产品更是如此。管理员可以随意使用这些特性，即使还没有获得这些特性的许可。对于在多个位置中大量服务器上部署软件的组织而言，违反规范的可能性呈指数级增长趋势。

指标误读

在软件应用了正确度量指标之后，要确定软件的正确使用是一个很有难度的工作。例如，在一台服务器上安装一个产品时，一位管理员可能可能会同时使用处理器数量(Processor)和指定用户数量(Named User Plus, NUP)指标。而另一位管理员则可能会混淆新旧指标，如并发用户数量(Concurrent Users)与NUP。

许多与指标误用相关的问题都源于计数错误。例如，一个使用处理器数量指标的组织可能没有计算核心数量或已占用插槽数，或者核心数量无法与每一个处理器的总数圆整。在使用NUP指标时，许多公司会低估实际数量，而没有计算最小需求或和间接用户数量，如通过菊链应用访问软件的用户。在处理Oracle产品时，可以肯定的一点是没有任何一个指标是很简单的。

虚拟化管理混乱

Oracle许可中最大的问题之一是虚拟化，这个方面非常容易违反规定，如果Oracle决定审查，那么很可能让你就不得不签下支票。其中一个挑战是Oracle只支持硬件分割，而不支持像VMWare那样的软件分割。因此，你必须为所有访问Oracle产品的处理器和核心购买许可。但是，人们通常都没有这样做。相反，有一些组织会购买逻辑分区许可，但是没有计算底层硬件的物理处理器。在创建一个虚拟环境时，你需要计算整个系统架，其中包括虚拟机、集群和存储。一个小小的错漏都能够让你被迫支付高于原始许可费的费用。

容错管理不当

此外，一些组织在实现灾难恢复和高可用性时也可能违反规范。例如，他们可能没有为故障恢复集群节点或镜像与备用服务器购买许可，通常只是因为他们认为这些组件不需要购买许可。另外，他们还可能使用了不同的指标去计算不同节点的许可。

还有许多组织没有计算故障修复服务器的维护作业，或者在完成一次故障恢复之后忘记从辅助节点切换回主节点。此外，他们可能会忘记为备份服务器的可选软件包和管理软件包购买许可了。而且，集群环境也可能会加重违规程度，如指标应用错误和虚拟化不当。

许可证滥用

无论原因是否相同，总之有许多组织都在未获得许可的情况下使用Oracle软件。最典型的例子是无限许可协议(Unlimited License Agreement, ULA)，它通常都被解释为自助软件许可，意思是给你权限在任何需要的位置上使用任何软件。然而，ULA限制了你可以使用的产品、使用这些产品的位置及使用的期限。

但是，ULA还不是唯一的陷阱。某个组织可能在未升级许可的前提下修改了一个Oracle应用程序，然后一台服务器上运行多个产品版本，但是只有一个许可证，或者在安装特定软件版本时违反了硬件限制规定。事实上，你可能会发现自己有许多个在未获得许可情况下使用Oracle产品的方式，如果被Oracle发现，这种情况可能导致高昂的罚款。

最后一个问题是在完全没有购买任何许可的前提下安装产品，当然这不是少出现的问题。非生产环境或许是最容易出现问题的地方。Oracle认为，就像生产环境一样，所有人都应该为开发、测试和预生产环境购买许可证。你必须计算用户数、处理器数、版本数、管理软件包及所有内置可选软件包。千万不要被Oracle Technology Network (OTN)许可所迷惑。它并不人们想象的那样可以随意而为。

然后，还有其他一些位置可能出现问题，如非人操作的设备。它们并不需要真人去操作，但是它们仍然要遵守Oracle的许可规定，并且会像其他用户一样计算许可证。此外，如果不小心，数据传输也可能落入许可黑洞。触发工人批处理的用户也必须计算许可，传输普通文件的用户(或设备)也一样。即使是通过一个多路基础架构传输数据，也要求购买用户许可。

不要成为盗窃的牺牲品

人们很容易违反Oracle软件的许可规定，特别是在分布式环境部署许多Oracle产品的时候。这里介绍的七种行为只是所有情况的一部分。Oracle故意搞得让人很容易犯错，然后这家公司又乐于把它的快乐建立在你的痛苦上。显然，如果你的组织在运行Oracle产品，那么你一定要持续监控所有平台上运行所有Oracle软件。任何疏忽都可能千万一次审查噩梦，让你的组织不得不承担原本想象不到的天文许可费用。如果这不是盗窃，那是什么?