因网络时代与云端应用而生的AGPL-3.0授权条款

​ 此篇文章转载自：因應網路時代與雲端應用而生的 AGPL-3.0 授權條款

如你所见，原文为繁体，我将其转为简体并将“网路”替换为“网络”，方便阅读。并未修改原文其他内容

---

    GNU Affero General Public License 3.0 (AGPL-3.0) 是自由软体基金会于2007 年11 月19 日所发布的一份自由开源软体授权条款*（注一）*。这份授权条款与GPL-3.0 为孪生条款，因为这两份条款仅在第13 条有所不同，其余的规定则一模一样。但这第13 条的不同差异处，就让AGPL-3.0 与GPL-3.0 的拘束特性有着很大的分别，这也让许多提供网络服务的公司对于这份条款避之唯恐不及。但AGPL-3.0 在使用上真的如此令人恐惧？其中的条款内容究竟如何？在利用自由开源软体元件的同时，又应该以什么样的态度与立场来面对AGPL-3.0？本文将会针对这些问题一一说明。

​ 如本文一开始所述，AGPL-3.0 与GPL-3.0 仅第13 条的内容不同，而AGPL-3.0 这一条的内容若是用白话来解释，大意是：若透过网络连结的服务方式，让使用者可以利用AGPL-3.0 衍生程式的服务，即便这位使用者并没有真的取得或拥有AGPL-3.0 衍生程式的程式码，此时网络服务的提供者，仍然要让这位使用者可以取得这个AGPL-3.0 衍生程式的源码。这样的网络服务提供者在早期一般简称为ASP (Application Service Provider)，对照到现在通行的用词，这些ASP 业者就是提供SaaS (Software as a Service) 的业者，像Google Search、Google Map、Gmail等都属于这样的网络服务，Google 的各项服务可说就是ASP 服务型态的典型。从撰写理由来看，AGPL 之所以特别规定ASP 业者必须提供程式源码给网络使用者，是因为在还没有AGPL 这样的授权条款之前，许多ASP 业者利用GPL 授权元件来架构网络应用程式，而依照GPL 的规定，这些应用程式因为并没有被散布到ASP 业者以外之处，也就是网络服务的使用者并没有取得这些应用程式，仅透过网络来利用程式的功能，所以网络使用者并没有权利依GPL 授权条款，向ASP 业者索取这些应用程式里GPL 元件的程式源码（注二）。一些自由开源软体理念者认为，这样的现象是因为GPL 规定有漏洞所造成，因此推动修改GPL 授权条款的内容。在自由软体基金会(Free Software Foundation, FSF) 的同意下，透过在GPL-2.0 第2 条第1 项的后面加上第d) 款，AGPL-1.0 就这样诞生了。因此虽然GPL-2.0 与AGPL-1.0 这两份条款的版本差一个号次，但其实也可以算是内容近乎完全一致的孪生条款（注三）。

​ 其后，自由软体基金会在草拟GPL-3.0 的同时，也草拟、制订出了最新一版的AGPL-3.0，从此GPL-3.0 与AGPL-3.0 的内容与版本号次开始一致。而在一版与三版中间，有一个仅具象征性意义的过渡版本AGPL-2.0，其中简短的内容主要是表达：若一个程式采用AGPL-1.0 及其后版本授权的话，程式使用者可以根据AGPL-2.0 的规定，自由决定是否要采用AGPL-3.0 来授权这个程式（注四）。

​ 从历史背景可以了解到，AGPL 这一个系列授权条款共有三个版本，这三个版本都是在GPL 的基础上，着力处理ASP 业者的利用行为，因此AGPL 具有GPL 的所有特性，这其中当然也蕴含了实践四大自由的理念（注五），以及对于衍生程式的授权拘束性在内。不过由于文章篇幅有限，本文仅针对最新版的AGPL-3.0 加以介绍，同时将焦点集中在第13 条，其余与GPL-3.0 相同的内容，还请读者另行参考GPL 相关的文章。

​ 依据AGPL-3.0 第13 条的规定，若是程式被修改并产生衍生程式的话，任何与这个衍生程式透过电脑网络来互动的网络使用者，都必须要有机会可以透过网络来近用( access) 这个AGPL-3.0 衍生程式的程式源码，也就是说，将衍生程式放置到网络上，供网络使用者利用之人，有义务要提供衍生程式使用者取得程式源码的机会。以AGPL-3.0 授权的SatusNet 微网志为例（注六），若甲公司下载StatusNet 的程式源码，修改之后重新命名为CrossChat，并将CrossChat 上线，依此衍生程式提供网络使用者微网志服务，此时甲公司就必须遵守AGPL-3.0 的规则，让CrossChat 使用者可以透过网络取得CrossChat 的程式源码。因此可以知道，启动AGPL-3.0 第13 条规定的关键在于「修改」与「网络服务」，若甲公司并没有修改StatusNet，而是整包拿来、改换名称与logo ，之后让其他元件透过此AGPL-3.0 原始程式的互动介面(Application programming interface, API)，直接上线提供服务的话，此时甲就没有提供AGPL-3.0 原始程式源码的义务（注七）。

在这样的基本规定之上，还有几点必须要注意：

1. 由于AGPL-3.0 衍生程式是透过网络与服务使用者互动，最简便提供程式源码的方式，就是利用网络传输来进行提供，所以AGPL-3.0 规定网络服务提供者必须将衍生程式的程式源码储放在网络伺服器上，然后提供服务使用者近用这些储放设备的管道，让其可以因此取得程式源码(... providing access to the Corresponding Source from a network server....)；
2. 为了避免服务提供者利用过于复杂或者困难的技术，来阻碍使用者下载程式源码，间接影响程式源码的自由散布，因此AGPL-3.0 规定网络服务提供者必须利用标准或一般常见的方式，来帮助、便利使用者下载程式源码(... through some standard or customary means of facilitating copying of software....)；
3. 由于网络服务提供者本身已经是透过网络来提供服务，额外提供程式源码的成本几乎等同于零，所以AGPL-3.0 规定透过网络传输来提供程式源码的行为必须是免费的。
   
   接续上述的例子，来进一步说明：甲公司可以在CrossChat 的网站上，单独开立上一个名为"Source Code" 的页面，在该页面中说明CrossChat 的授权方式，同时提供下载程式源码的连结，如此就可以满足AGPL-3.0 要求免费提供衍生程式源码的基本义务规定。当然，甲公司也可以采用其他方式，例如服务使用者在完成CrossChat 的注册程序之后，会收到一封注册完成通知信，甲公司可以在通知信中附上CrossChat 原始码的下载网址，让使用者透过直接点选连结就可以下载到原始码。总之，透过近用网络伺服器的管道来便利使用者取得原始码，在技术上与方法上都可以有许多的变化，只要符合上述AGPL-3.0 规定与取得便利的基本精神，就是可行的方式。

▲ 图1：identi.ca 是利用StatusNet 所架设的微网志网站，这个网站透过"Source" 独立页面说明网站系统源码的来源、授权条款，与下载程式源码的管道。

​ AGPL-3.0 与GPL-3.0 一样，都是为了实践四大自由而制定的授权条款，也因此这两份条款对于衍生程式都具有较严谨的授权拘束性（注八），这样的特性如果发挥到极致，会让AGPL-3.0 与GPL-3.0 这两份孪生条款彼此排斥，所以为了让AGPL-3.0 元件与GPL-3.0 元件可以结合并存在同一个程式当中，两份条款分别在其第13 条的地方一同设立了例外规定：那就是，各自的授权条款仅拘束原本各自的元件，而不会扩及拘束到另一方的授权元件，也就是AGPL-3.0 授权的元件，维持AGPL-3.0 的授权，而GPL-3.0 授权的元件，一样维持GPL-3.0 授权，彼此的授权状态互不干扰，然而，当整体衍生程式成为网络服务程式的话，GPL-3.0 授权的元件，则必须一并适用AGPL- 3.0 第13 条的进阶规定，也就是说，此时GPL-3.0 元件的程式源码也必须一并提供给使用者，以不弱化AGPL-3.0 设定网络服务就要启 程式源码提供义务的规定。如此一来，两份条款彼此有了例外并存的依据，亦可以增进元件的结合与应用，同时也维持了AGPL-3.0 规范ASP 业者必须提供程式源码的初衷。

​ 而对于开源界来说，正因为AGPL-3.0 着眼于网络使用方面的规则，特别针对网络服务行为规定有提供程式源码的义务，所以一些自由开源专案反而特别偏好采用AGPL-3.0 来授权，如此未来专案程式被网络服务提供者透过网络加以应用的时候，就可以要求服务提供者必须提供衍生程式的程式源码。这样的专案除了前述的StatusNet 之外，企业资源管理系统OpenERP、人际关系管理系统SugarCRM、图形资料库系统Neo4j，以及软体专案开发管理平台Launchpad 等著名的自由开源软体专案（注九），都是采用AGPL-3.0 来授权。

​ 在经过上述的简要介绍之后，让我们重新审视本文一开始罗列的诸多疑问：AGPL-3.0 在使用上真的如此令人恐惧？一般使用者与商业使用者，又该以什么样的态度与立场来面对AGPL-3.0？

​ 其实，从应用面来看，AGPL-3.0 的授权拘束性并非会被无限制扩张的，只要使用者能谨守不直接修改原程式这个重要判断准则，因为AGPL-3.0 的规则，并非要所有运用AGPL-3.0 程式进行网络服务的专案，都必须将自己撰写的所有程式源码提供出来，其要求程式源码的范围，还是强调在原程式已被修改的部份，以及该部份与直接对应元件结合成为衍生作品时的程式源码。不过，不可讳言的是，也因为AGPL-3.0 这样的义务规定，间接扩张了AGPL-3.0 授权拘束性的影响力，一些无法或不愿意将程式源码提供出来，或对此规则有疑虑的公司，理所当然便会采取避用AGPL-3.0 授权元件的策略，以保守其网络应用程式在技术方法上的隐密性。然而在这样的情况下，部份AGPL-3.0 授权的专案，也已开始套用过往在GPL 授权专案上常见的双重授权商业模式（注十）：这些专案一方面透过AGPL-3.0 释出程式源码，获得与社群开发者协同开发与除错的优势，另外一方面也提供封闭源码的商业授权条款，让想要另外客制化应用、却又无法提供所有衍生程式源码的公司与个人，有另外一个选择的管道。前述的OpenERP 与SugarCRM，便皆是采用此种双重授权策略的范例专案。所以客观来说，AGPL-3.0 基于GPL-3.0 发展的授权拘束性，虽然确有扩张，但却并不是无法控管。许多网络传闻，单单一句话说「使用AGPL-3.0 授权元件进行网络服务，便得提供自身系统的所有程式源码。」那也是太简略而不清楚明了的误解。只要使用端有正确的使用观念，对于AGPL-3.0 元件的应用，能遵守其授权拘束性开启的分际，或是事先询求权利人的另外授权，那么是毋需过度担心与恐惧的。

注一：AGPL-3.0授权条款全文请见：https://www.gnu.org/licenses/agpl-3.0.html。

注二：关于ASP业者利用自由开源软体的相关讨论，请见：葛冬梅，ASP与自由／开放源码软体的散布条款，https://www.openfoundry.org/tw/legal-column-list/494- asp-。

注三：AGPL-1.0内容请见：https://www.affero.org/oagpl.html。在前言之前，有一小段文字，清楚说明AGPL-1.0是修改自GPL-2.0。　

注四：AGPL-2.0的内容请见：https://www.affero.org/agpl2.html。

注五：关于四大自由的内容以及与GPL条款的关系，请参见：葛冬梅，让人既爱又头痛的GNU GPL，https://www.openfoundry.org/tw/legal-column-list/525。

注六：精确来说，StatusNet是采用「AGPL-3.0及其后版本」来授权。StatusNet官网：https://status.net/；StatusNet开发专案网页：https://gitorious.org/projects/statusnet。

注七：不过甲公司仍然可以自行提供StatuNet 的程式源码，这样的作法可以协助自由开源软体的散布，进而促进开发软体专案的名声，并与开发社群建立良好关系，促进整体自由开源软体生态的正向循环。

注八：关于GPL授权拘束性的说明与相关议题，请参见：林诚夏，GPL条款对于衍生程式的判定标准与其授权拘束性的扩散范围（上），https://www.openfoundry.org/ tw/legal-column-list/8446；林诚夏，GPL条款对于衍生程式的判定标准与其授权拘束性的扩散范围（下），https://www.openfoundry.org/tw/legal-column-list /8447。

注九：此段所提到的软体进一步资讯如下：OpenERP网站，https://www.openerp.com/；SugarCRM网站，https://www.sugarcrm.com/；Neo4j ，https://neo4j. org/；Launchpad为Canonical公司所开发，该公司即为Ubuntu作业系统背后的支持公司，Canonical开发了Launchpad用于自由开源软体的开发与管理，同时也在Launchpad上面持续维护与开发Launchpad，https:/ /launchpad.net/launchpad-project。

注十：关于自由开源软体双重授权策略的应用，请参考：林诚夏，自由软体的商业应用模式（下）－双重授权篇，https://www.openfoundry.org/tw/legal-column- list/1056。