自从亚马逊网络服务、谷歌和 Rackspace 等强大的云服务提供商出现以来，软件开发和部署越来越多地在云端进行。根据 Gartner 的数据，云计算预计今年将增长 19%。包括 Netflix 和 eBay 在内的大型行业参与者已经转向云端，以处理其运营和产品的重要部分。在未来几年，我们可能会看到更多像 Coupa 这样完全悬浮在云端的创新型初创公司，将本地计算降级为往日时代的遗迹。

在企业从传统解决方案转向云端的同时，开源软件也因类似的原因获得了显著的吸引力。Gartner 预测，到 2016 年，99% 的全球 2000 强企业将把开源纳入其运营中。云和开源解决方案的采用者都被协作潜力增加和总体拥有成本降低所吸引。

开源云项目（想想 OpenStack、CloudStack、Eucalyptus）的激增以及在云中使用开源软件的增加表明，企业需要了解云环境如何影响开源许可证合规性。在云出现之前，限制性开源许可证通过规范分发来维护软件自由。然而，由于在云中软件是以服务形式提供的，因此与分发行为相关的许可义务不再适用。这导致了更新的云驱动型限制性开源许可证的开发，例如 AGPL。云对传统开源合规机制的颠覆性影响以及随后的补救性开源许可证的开发，要求组织审计和更新其知识产权政策，以最大限度地降低侵权风险。

云计算的出现及其对开源合规性的影响重新点燃了历史上专有软件和开源软件之间的斗争，并加强了开源社区内的传统分歧。专有软件与开源软件辩论的起源可以追溯到 1970 年代中期 IBM 的拆分，之后用户不再可能访问和修改代码。尽管用户自由通过拆分过程被移除，但程序员们继续寻找访问、修改和共享代码的方法，这著名地促使比尔·盖茨在微软的 Basic 泄露后写了他的“致业余爱好者的公开信”。

在 1970 年代后期和 1980 年代初期，开源运动分为两个不同的派别兴起，第一个派别由麻省理工学院人工智能实验室的前程序员理查德·斯托曼领导。斯托曼认为，访问、修改和再分发代码的能力是一项基本自由，这促使他开发了 GNU 项目，该项目在 GPL 下获得许可——这是一种限制性许可证，专门设计用于确保 GNU 代码在被纳入衍生作品时不会被变为专有。

大约在同一时间，伯克利计算机科学研究小组正在开发 BSD UNIX 系统。在 1990 年代后期，BSD UNIX 在 BSD 许可证下可用。虽然斯托曼的 GPL 被设计为一种旨在防止底层代码变为专有的限制性著作权许可证，但 BSD 被草拟为一种许可型许可证，它将允许用户将底层代码嵌入到专有产品中。

涵盖开源代码的许可证带有独特的条款，这些条款对代码的使用、修改和分发具有影响。如前所述，开源许可证分为两大类——许可型和限制型。许可型许可证，如 MIT 和 BSD 许可证，对代码的使用、修改和分发提供了最少的义务，使开发人员能够将开源代码纳入专有软件中，然后他们可以通过添加额外的许可条款来保护这些软件。

相比之下，限制性开源许可证，如 GPL，不允许受覆盖代码的用户在不同的许可条款下发布衍生作品。此外，这些限制性许可证要求分发修改后程序的用​​户将其源代码提供给下游用户，以维护著作权社区实现软件自由的目标。软件自由的概念是指所有下游用户访问、运行、修改和再分发包含受覆盖代码的软件的权利。限制性许可证的这一特性使得不可能将开源代码纳入专有产品中。没有办法避免这些严格的规则，并且不遵守这些义务可能会导致严重的后果，包括被迫通过发布资产的源代码或支付知识产权侵权赔偿金来合规。

在云环境之前，软件供应商通过软件分发向最终用户提供其产品。由于没有其他方法可以向用户提供软件，因此供应商不可能逃避限制性开源许可证中的分发条款。然而，随着云计算的引入，这种情况发生了变化。

限制性开源许可证，如 GPL，只有在底层开源代码是分发的一部分时才能发挥作用以维护软件自由。例如，GPLv3 规定：

如果您分发软件副本，您有某些责任：尊重他人自由的责任。如果您分发此类程序的副本，无论是免费的还是收费的，您都必须将您收到的相同自由传递给接收者。您必须确保他们也收到或可以获得源代码。

在云出现之前，此许可条款确保了任何时候将包含受覆盖代码的软件部署给第三方时，该分发都将受 GPL 条款约束，从而迫使分发者将其代码提供给用户。然而，基于云的 SaaS 解决方案的激增威胁到 GPL 模型的稳定，因为它创造了一个环境，在这个环境中，软件首次在不被分发的情况下提供给用户。

在包含 GPL 代码的软件通过网络服务提供的情况下，分发条款被绕过，提供商不必发布其源代码。请记住自由软件互惠触发器：“如果您分发此类程序的副本……您必须将您收到的相同自由传递给接收者。” 然而，由于软件在云中不分发——它只是作为服务提供给用户——提供商不必向前支付这些自由。相反，他们可以享受使用自由软件的好处，而无需被迫向其用户提供相同的好处。此漏洞使 SaaS 企业能够将 GPL 覆盖的代码嵌入到专有云产品中。实际上，这意味着，在这种无分发模型中，GPL 承担了许可型许可证的属性（想想 MIT、BSD）。

对于任何认为云使专有软件和开源软件的辩论变得毫无意义的人来说，请再想一想——这场战斗远未结束，它只是转移到了另一个前沿。不久之后，开源运动的著作权派系重新集结，并对基于云的 SaaS 模式对其维护软件自由的目标构成的威胁做出了回应。该运动开发和部署以应对新兴的基于云的 SaaS 环境带来的独特挑战的武器是 Affero GPLv3 (AGPLv3)，它涵盖了流行的应用程序，如 PHP-Fusion、Launchpad 和 SugarCRM。

与 GPL 依赖于分发行为来触发自由软件互惠条款不同，AGPLv3 包含以下条款，该条款专门针对软件在网络上使用但技术上未分发的情况而制定。该条款规定：

如果您修改程序，您的修改版本必须显着地为通过计算机网络远程与其交互的所有用户（如果您的版本支持这种交互）提供机会，通过从网络服务器免费提供对相应源代码的访问，通过一些标准的或惯用的方式来促进软件的复制，从而接收您的版本的相应源代码。

此许可条款将基于分发的互惠条款应用于基于云的软件产品，在这种产品中，用户从远程服务器运行程序。

AGPL 的起草是为了解决公共云创建的问题。其序言指出，虽然 GPL“允许制作修改版本并让公众在服务器上访问它，而无需向公众发布其源代码……AGPL 专门设计用于确保在这种情况下，修改后的源代码可供社区使用。” 但是，如果组织在内部使用 AGPL 代码会发生什么？远程网络交互条款规定：

如果您修改程序，您的修改版本必须显着地为通过计算机网络远程与其交互的所有用户提供机会，通过一些标准的惯用方式来促进软件的复制，从而接收您的版本的相应源代码。

在公共云和私有云环境中，似乎都适用相同的原则——任何用户都有权访问修改后的代码并创建自己的版本。在私有云场景中，这些自由将扩展到任何员工、承包商和其他使用服务器的各方。

不遵守开源许可证义务可能会导致严重的后果，包括被迫通过发布修改后的代码和支付赔偿金来合规。不合规的组织面临风险，因为包括美国、德国和法国在内的各个司法管辖区的法院都一致裁定开源许可证是可执行的，从而导致了开源诉讼和和解的激增。

较早的侵权诉讼之一巩固了开源软件的可执行性，该诉讼源于思科在 2003 年收购 Linksys。收购后不久，思科因在其路由器固件中使用 GPL 覆盖的代码而遭到侵权诉讼。事实证明，侵权芯片组是由 Broadcom 提供给 Linksys 的，而 Broadcom 又将开发外包给了第三方。作为各方之间达成的和解协议的一部分，思科被迫在其网站上提供侵权代码，任命一名开源合规官，并向自由软件基金会捐款。

BusyBox 还对一些公司发起了多次成功的侵权诉讼，这些公司合并了其代码并利用由此产生的资产违反了 GPL。其中第一起涉及在 Monsoon Multimedia, Inc. 提供的嵌入式系统中使用 BusyBox 代码。BusyBox 声称 Monsoon 在没有按照 GPL 向下游用户提供其修改后的代码的情况下使用了 BusyBox 代码。双方以未公开的金额达成和解，Monsoon 同意发布其代码并任命一名开源合规官。BusyBox 和 Verizon Communications 之间也达成了类似的和解协议。最近，BusyBox 对包括三星和百思买在内的 14 家电子产品供应商提起诉讼，指控被告分发包含 BusyBox 代码的设备，而没有向用户提供其修改后的代码。虽然其中一些被告选择和解，但在 Westinghouse 案中，纽约地区法院做出了有利于原告的判决。在该案中，法院裁定 Westinghouse 故意侵犯了 BusyBox 代码的版权，因此损害赔偿金增加了三倍。

开源侵权诉讼和由此产生的和解的激增巩固了开源软件的可执行性。由于与知识产权侵权诉讼相关的巨大经济和声誉损害，组织必须确保遵守开源许可证义务。尽管云环境为依赖开源软件的组织带来了新的不确定性，但仍有各种工具可以用来最大限度地降低不合规的风险。

鉴于 AGPLv3 施加的新义务，基于云的 SaaS 提供商必须清点其产品中嵌入的开源代码，并确保其知识产权政策符合涵盖所用代码的各种开源许可证施加的义务，这一点至关重要。有各种工具可用于帮助 SaaS 企业确保云中的开源合规性。例如，企业可以使用专门设计用于检测开源代码的工具扫描其软件，并提供每个组件随附的许可义务列表。此外，结构化的开源软件采用流程 (OSSAP) 可用于为组织定义可接受的知识产权许可政策，审计当前的软件组合和传入代码，并通过所有软件开发和采购阶段确保合规性。

开源许可证管理解决方案现在可以供云中的公司使用。由于这些解决方案托管在云环境中，因此它们消除了企业安装或更新代码扫描软件的需求。相反，公司可以注册服务提供商，并获得扫描其代码、识别开源并提供相关许可义务细目的软件的访问权限。此类开源许可证管理服务对于 SaaS 企业来说非常宝贵，尤其是在考虑到与云中的开源相关的不确定性时。除了确保组织理解并能够履行其开源许可证义务外，这些管理解决方案还使企业能够有效且高效地响应检测到的任何不合规情况。例如，通过了解软件的哪些组件以不合规的方式使用，SaaS 企业可以定位自己，用提供类似功能的代码替换侵权代码，或调整其政策以确保遵守义务。

新兴的基于云的 SaaS 模式提供了巨大的机遇，但也为组织带来了与知识产权侵权相关的新风险。各种开源许可证管理解决方案可用于帮助企业安全地过渡到云端。对于计划在云环境中导航的企业——以及那些已经完成迁移的企业——重要的是清点软件中包含的代码，并确定是否符合开源许可义务。请记住，为传统软件分发模型开发的知识产权政策将需要进行评估和更新，以满足与云环境相关的独特义务。

云图像 通过 Shutterstock.com。