主流开源软件授权协议详解
2013-04-25 14:14:11 
阿炯
开源运动同样有自己的游戏规则和道德准则，不遵行这些规则不但损害开源运动的健康发展，也会对违规者造成名誉和市场上的损失，更可能陷入法律纠纷和赔偿。
现今存在的开源协议很多，而经过Open Source Initiative组织通过批准的开源协议目前有58种。我们在常见的开源协议如BSD、GPL、LGPL、MIT等都是OSI批准的协议。如果要开源自己的代码，最好也是选择这些被批准的开源协议。
各种开源软件授权方式的选择
各种开源软件授权方式的介绍
首先介绍开源软件的共同的特点：源代码开放、免费修改、免费重新发布。
以BSD为代表的接近于公共域软件的授权。包括Xwindows、FreeBSD、apache、perl、python、ruby、zope 等。其中apache的授权叫APL，是一种比较典型的授权声明，下面对于近似公共域的授权以APL表示。这种授权的特点就是虽然保留版权，但不但免费修改、免费重新发布，而且允许商业使用，允许商业修改后不公布修改的软件代码。是对商业软件友好的授权方式。
以GPL为代表的自由软件，包括linux、gcc、KDE、gnome等。允许免费修改、免费重发布，但要求修改代码必须也遵守GPL。这种授权方式大大限制了从开源中牟利的手段，因此是对商业不友好的授权，对商业不友好的后果是不能使开源代码产生更广泛的效果、不能调动商业软件开发力量。但也要看到GPL对打破垄断的价值，打破垄断对所有的商业软件也是有利的。在GPL下面还有一种对商业更友好的方式就是LGPL，允许商业代码链接LGPL代码，这样商业软件在利用LGPL软件的同时能够很大程度上保留商业利益。gnome是LGPL的(不确定)，KDE是GPL的。因此在KDE上面实现商业软件比较困难，因此说KDE是开放不充分的。
以MPL为代表的商业公司的开源策略。包括mozilla、openoffice等。允许免费重发布、免费修改，但要求修改后的代码版权归软件的发起者，这样发起者和组织者具有更优越的地位。MPL一般也是同时遵守LGPL的。这是因为GPL比较严格，不会产生另一个商业的竞争者。MPL也是对商业友好的。并且用一些优惠来鼓励商业软件开源。
强开源约束授权
GPL(GNU General Public License)
我们很熟悉的Linux就是采用了GPL。GPL协议和BSD， Apache Licence等鼓励代码重用的许可很不一样。
GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。
这也就是为什么我们能用免费的各种linux，包括商业公司的linux和linux上各种各样的由个人，组织，以及商业软件公司开发的免费软件了。
GPL协议的主要内容是只要在一个软件中使用(“使用”指类库引用，修改后的代码或者衍生代码)GPL 协议的产品，则该软件产品必须也采用GPL协议，既必须也是开源和免费。
这就是所谓的”传染性”。
GPL协议的产品作为一个单独的产品使用没有任何问题，还可以享受免费的优势。
由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议，对于使用GPL协议的开源代码，商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。
其它细节如再发布的时候需要伴随GPL协议等和BSD/Apache等类似。
弱开源约束授权
MPL License(Mozilla Public License)
允许免费重发布、免费修改，但要求修改后的代码版权归软件的发起者。
这种授权维护了商业软件的利益，，它要求基于这种软件的修改无偿贡献版权给该软件。这样，围绕该软件的所有代码得版权都集中在发起开发人得手中。
但MPL是允许修改，无偿使用的。
MPL软件对链接没有要求。(要求假如你修改了一个基于MPL协议的源代码，则必须列入或公开你所做的修改，假如其他源代码不是基于MPL则不需要公开其源代码)
LGPL(GNU Lesser General Public License)
LGPL是GPL的一个为主要为类库使用设计的开源协议。和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。
LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。
但是如果修改LGPL协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。
因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以LGPL协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。
GPL/LGPL都保障原作者的知识产权，避免有人利用开源代码复制并开发类似的产品。
MIT(MIT)
MIT是和BSD一样宽范的许可协议，作者只想保留版权，而无任何其他了限制。也就是说，你必须在你的发行版里包含原许可协议的声明，无论你是以二进制发布的还是以源代码发布的。
无开源约束授权
BSD开源协议
BSD开源协议是一个给于使用者很大自由的协议。
基本上使用者可以”为所欲为”，可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。
但”为所欲为”的前提当你发布使用了BSD协议的代码，或者以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：
1、如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
2、如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
3、不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
BSD 代码鼓励代码共享，但需要尊重代码作者的著作权。
BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。
而很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。
Apache Licence
Apache Licence是著名的非盈利开源组织Apache采用的协议。
该协议和BSD类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布(作为开源或商业软件)。
需要满足的条件也和BSD类似：
1、需要给代码的用户一份Apache Licence
2、如果你修改了代码，需要再被修改的文件中说明。
3、在延伸的代码中(修改和有源代码衍生的代码中)需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。
4、如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。
你可以在Notice中增加自己的许可，但不可以表现为对Apache Licence构成更改。Apache Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。
其它开源约束授权
Creative Commons(CC)
您在自己的作品上使用知识共享许可协议，并不意味着放弃您的著作权，而是在特定的条件下将您的部分权利授予公共领域内的使用者。
哪些特定的条件呢？您可以在此处看到所有知识共享许可协议及其简单的介绍。
所有的许可协议都要求您以作者或者许可人的名义署名。您可以将以下的选项进行组合、搭配，由此将构成我们的六套核心知识共享许可协议。
1、是否允许他人对自己享有著作权的作品及演绎作品进行复制、发行、展览、表演、放映、广播或通过信息网络向公众传播，但在这些过程中对方必须保留您对原作品的署名。
2、是否允许他人对您享有著作权的作品及演绎作品进行复制、发行、展览、表演、放映、广播或通过信息网络向公众传播，但仅限于非商业性目的。
3、是否允许他人对您的作品原封不动地进行复制、发行、展览、表演、放映、广播或通过信息网络向公众传播，但不得进行演绎创作。
4、只有在他人对演绎作品使用与您的原作品相同的许可协议的情况下，您才允许他人发行其演绎作品。
关于GPL的一些话
如果开源软件的开发要借助社区的力量，那么最好是用GPL授权，因为这样可以防止商业软件抢走用户而导致的开源软件的使用者和开发者都不足。
当然，选择GPL或BSD授权还和人的价值观有关系，但以开发类型来选择授权方式是比较合理的。如果采用封闭开发，使用BSD也可以达到GPL的效果，而采用社区开发，BSD会对开发团队的成长不利。如果在没有商业化价值的领域，GPL完全没有必要。
MPL授权是商业软件想要借助社区的力量的产物。
LGPL对有商业化的友好性和GPL相比是大大提高了，在很多情况下对商业化都没有阻碍，可以说达到了50%的商业化的要求，但有时商业化需要对源代码的彻底修改，因此不能说LGPL百分之百满足商业化要求，LGPL是一个折衷的授权，如果社区开发的软件希望能在更大的范围内被使用，可以采用 LGPL。
“BSD满足了开发者的自由，GPL满足了使用者的自由”这句话对两种授权的出发点做了简单明确的回答。“对于开源项目来说，BSD是封闭开发的选择，GPL是社区开发的选择”(对于小的开源项目，封闭开发反而更有效率)是我理解的两种授权不同的适用范围。
版权与开源协议的那些事
4月26日是世界知识产权日，很多人或许会觉得这和软件开发没什么关系，但事实上，开源软件大多受到知识产权法中著作权法(Copyright，也称版权)的保护。开源软件虽说开放了源代码，但是用户在使用、修改、再发布时，必须要遵守软件中规定的开源协议(也称开源许可证/开源License)，否则可能构成侵权，惹上官司。
随着计算机软件的激增，其著作权保护愈发重要。同样在26日，《中华人民共和国著作权法修正案(草案)》提交十三届全国人大常委会第十七次会议审议。修正案中有多处直接涉及计算机软件的修正：如在第十条的出租权中明确包含计算机软件的原件或者复制件权利；修正后的第五章“著作权和与著作权有关的权利的保护”中，第四十八条处加入对计算机及其系统或者网络的完全性能进行测试条例。虽然修正案还未最终确定，但这也显现了加强软件法律保护的趋势。今天，我们就来谈谈计算机软件开发、使用中涉及的一些权利问题，以及这些问题的源头和当下的新争议。
Copyright 和 Copyleft：开源著作权和开源协议
提到 “Copyright”，大家可能还会想到自由软件之父 RMS 提出的“Copyleft”反版权思想。“Copyleft”最初是为反对商业软件而生，但它并不是放弃版权，“Copyleft”中的“Left”，不使用英语中“保留”的意思，而是指“Left(左)”，与“版权(Copyright)”中的“Right(右)”具有镜像的关系。
二者的区别可总结为：“Copyright”指软件的版权和其它一切权利归软件作者所私有，用户只有使用权，没有其它如复制、重新修改发布等权利。而“Copyleft”的特点是仅有版权归原作者所有，其他一切权利可以与任何人共享。
首先，计算机软件作者都可对自己的作品享有著作权“Copyright”。
著作权源于信息时代早期，最初指印刷出版之权，是印刷术发明催生起的复制(Copy)权(Right)。后来随着科学技术发展，种类渐增，逐渐开始保护文学作品作者权利、作者的表演权利等等。1994年，计算机程序被明文提出应该作为文学作品受到保护，1996年这一规定被世界知识产权组织在全球范围内推行。
注释：1994年4月15日，关贸总协定乌拉圭回合各缔约方在马拉签署了《与贸易有关的知识产权协议》(TRIPS)，其第十条规定：“计算机程序，无论是原始资料还是实物代码，应根据《伯尔尼公约》(1971)作为文学作品来保护。”
1996年12月20日，世界知识产权组织通过的《世界知识产权组织版权条约》(WTC)其第四条明确规定不论计算机程序表达方式或表达形式如何，均作为《伯尔尼公约》第二条意义上的文学作品受到保护。
这为国际件计算机软件版权保护提供了统一的标准和依据。
其次，开源软件作者在拥有著作权的同时，还可以自由决定如何与别人分享自己的作品，这便是“Copyleft”所提倡的理念，也是受开源许协议所保障的权利。
“Copyleft”通常被译作“著佐权”，即通过许可证的形式，补足、辅佐著作权(Copyright)不足的版权授权，相当于一种权利与义务的契约。RMS 1983年9月创建 GNU 项目，1984年发表《GNU 宣言》，抨击封闭源码行为，也创造了“Copyleft”一词。
“Copyleft”思想脱胎于 RMS 的知识产权观——他认为知识产权是一种社会赋权，权利人应该被允许通过契约的方式，自由转让软件权利，如复制、修改、再发布的权利。所以 RMS 提出：自由软件在承认著作权的基础上，可以通过许可协议，与公众共享作品的其它权利。
1989年，RMS 与一群律师起草了世界上第一个开源软件协议——GNU 通用公共协议证书(GNU General Public License, GNU GPL )。证书的序言体现了“Copyleft”的思想。
一是承认软件的著作权；二是提供许可协议，来获得复制、发布、修改的法律许可。用户可以获得权利人通过许可证放弃的权利，但也必须遵守许可证的规定才能行使，如果不遵守开源软件规定，便是侵犯了开源软件著作权，其著作权人就有权要求对方停止相关行为及其他。
至此，“Copyleft”一词有了实际载体。而这也是现在开源许可协议既可以保护开源软件作者著作权，又可以为开发者提供修改、再发布权利的法律思想源头和基础。
开源软件及协议的发展
基于“Copyleft”思想的 GPL 现在是使用最为广泛的许可证之一。
这个许可证在开放源代码的前提下，几乎可以说是“最大程度”地限制了使用者——它不仅要求用户再修改的软件要开源，而且如果用户将 GPL 许可证下的软件添加入专有软件，那么新组合的软件也应当全部适用于 GPL 许可证，也就是说，组合里所有的软件都必须开源。
因此，GPL 被称作是带有“传染性”的许可证。越来越多的开源软件支持者认为，我们应该向更加宽松的许可协议靠近，不应该在许可协议上做过多限制。
但 RMS 认为，GPL 才是真正保护了所有使用者的自由。因为 GPL 协议可以规范使用开源软件的用户继续开源，从而维护源码开放使用的自由。
RMS 是自由软件运动的领导者之一，被称为“自由软件之父”。在组织人力起草 GPL 协议之外，他最为人们津津乐道的成就还有创建 GNU 项目以及成立 FSF 自由软件基金会。现在我们常说的 Linux 其实是指 Linux 内核加上 GNU 套件，即 GNU/Linux，这是全世界尤其是超级计算机中使用率最高的底层操作系统。RMS 曾向媒体要求，在采访他的时候，要用“GNU/Linux”称呼操作系统，而非 Linux。
RMS 执着于解放软件，一直致力推动软件和世界自由，这让外人觉得他脾气执拗古怪。也有人问他，参与自由软件运动多年，到底收获了什么。他说，“我比较感兴趣的是，世界得到了什么。我对我的人生很骄傲，因为我人生的一半，都在为自由奋斗，抵制人们做不自由的事，虽然我们还没达到胜利的目标。”
这个“胜利的目标”，在很多开发者看来，是不切实际的。1998年，Eric Raymond 发表《大教堂与集市》一书，为开源奠定文化理论基础。Raymond 以及他的追随者认为，RMS 和 FSF 在推动自由软件的时候，受意识形态影响太深，与现实脱节。而为了自由软件尽可能大范围地取得成功，应该侧重提供源代码的实用价值，而不是过多的讲究共享和道德哲学。
很快，Raymond 邀请了十几个自由软件社区著名成员开会(当然，不包括 RMS)，讨论决定用“开源软件”来代替“自由软件”。1998年，Raymond 和 Bruce Perens 成立了开源促进会——OSIA，这个组织后来主导了开源运动，并定义了开源软件，其中也对许可协议做了一定规范：
OSD：自由再发布；以源代码的形式再发布；派生作品，即使用同款开源软件协议，不同协议之间也可以兼容；作者源代码的完整性，自己修改的程序用不同的版本号与原始的做区分，软件用户有权知道作者是谁；个人或团体不受歧视；开源软件程序可以被使用在任何领域再发布许可协议，新增软件不得添加新的条款；许可证不得只用于特定产品；许可证不得限制其他软件；许可协议必须是技术中立的。
随着开源运动的扩大，以及开源软件定义的明晰，许可协议对开源软件的促进、保护作用愈发凸显，其种类也在不断增加。《大教堂与集市》的译者卫剑钒在近日发布的一篇文章中，形象道出许可证的机制和作用：
我允许你们XXX，我许可你们XXXX，你们可以XXXX，但是，你们必须XXXX，如果你们XXXX了，你们就必须XXXX，对了，对于XXXX这些情况，我可不负责。你要同意，就用，不同意就别用。如果你用了，但违反了许可证的要求，我可能会告你啊！
国内近期有一起计算机软件著作权诉讼案，涉及开源软件和许可协议。2019年12月，北京高级人民法院对被告柚子(北京)科技有限公司、柚子(北京)移动技术有限公司、与原告数字天堂(北京)网络技术有限公司侵犯计算机软件著作权纠纷做出终审判决。
起因是两被告公司的 APICloud 软件复制及修改了原告数字天堂公司 HBuilder 软件中的三个插件，这些插件采用了 GPL 协议。如前文所述，按照 GPL 的规定，只要使用了 GPL 下的软件，就必须全部开源，但 APICloud 并没有全部开源，于是引发诉讼。
最终，法院认定，柚子科技公司、柚子移动公司的 APICloud 软件复制及修改了数字天堂公司 HBuilder 软件中的三个插件，侵犯了著作权人数字天堂公司对软件作品享有的复制权和修改权等权利，判令被告停止侵权并赔偿71万元。此案是中国 GPL 诉讼第一案，其判决被认为对开源软件诉讼实践有重要意义，这对之后类似案件的审判有较高参考价值，对国内开发者使用开源软件也有指导意义。
国际上在实际判例中承认开源许可协议的法律效力来得更早。2008年，美国联邦巡回上诉法院首次在判决中主张了开源许可证的著作权协议。原告Bob Jacobsen 采用 Artistic 许可证，发布了自己的开源软件。被告 Matthew Katzer 使用了该软件，但是却未履行许可证中规定的著作权声明义务。最终，被告被认定违反 Artistic 许可证的行为是侵犯了原告的著作权。
声明作者的著作权，基本可以称作是开源许可证的“入门级”协议，在此基础上，许可证还规定了使用者是否可以将其拿去商用、是否可以打着原作者的名义营销等等。此前，有人将较为流行的几种许可证做了一个划分：
上图中的几个许可证仅是目前较为流行的，在这之外，通过 OSI 认证的许可证还有近百个。一项调查显示，许可证逐渐被认为是开发人员在决定使用某个开源项目时最需要考虑的事项，因为没有开发人员愿意在不知道接下来将如何发展的情况下，开始使用新的软件包。
许可证种类和规定的多样性导致软件合规变得复杂，不过目前已经有一些工具可以初步降低这一门槛，比如 Linux 基金会推出的许可证使用规范工具 ACT、Gitee 的许可证引导功能。
一些争议
在软件开发过程中，围绕软件法律保护产生了多种争议。
一方面，许可证应该规定哪些权利义务、应该走向宽松还是限制被广为讨论。另一方面，人们是否应该为软件的设计思想申请专利也引发了开发者之间的对立。
许可证种类渐增的当下，人们愈发渴望更加宽松的开发环境、和更简洁的协议。大量软件从限制性许可证转到宽松许可证。Blackduck 数据显示，从 2009 年到 2015 年的六年间，宽松型 MIT 许可证的份额上升了15.7%，Apache 的份额上升了12.4%；而 GPL v2 和 v3 的份额则下降了21.4%。GitHub 2015年发布的许可证使用情况报告显示，MIT 协议使用率最高，两年前的一项研究也得出了同样的结论。
然而，追求宽松又带来新的问题。
MIT 是现在使用最广泛，又最为宽松的许可证。开发者只要保留原作者的版权和许可，便可以随意使用，包括出售源码。这时，原开发者就可能会面临“别人都能拿着我的软件出去售卖，我徒留版权有何用”的窘境，此刻大概只有用“自由与分享”的理想做注解了。而如果想避免这种状况，开发者可以更换更为严格的许可协议，或者不开源。
此外，近年还出现开源公司被云厂商“寄生”的情况，云厂商直接将开源厂商的开源能力作为云环境下的商业服务，而不回馈开源社区，挤压开源厂商业务，致使其陷入生存困境。这迫使许多开源软件又从宽松型许可证转向更严格的协议，甚至直接闭源。
更有甚者，认为开源软件应该脱离现有的著作权法，拥有一部属于自己的《开源法》：以著作权法为主的知识产权法是后工业时代和前信息时代的产物，它赋予人们对其创造出来的信息—电影、软件等作品、发明等技术方案、产品设计—进行垄断的财产权。但软件存在的意义应该是作为解决实际问题的工具，真正核心的特点是工具性、功能性，而非表面上的作品性。这时就不再适用著作权法，而是应该新建《开源法》。
实际上，除了著作权和许可证，还有一部分软件，尤其商用软件可以同时受到专利法的保护。我国法律规定，计算机软件专利保护期限为从申请日起算20年。著作权保护期为作者有生之年加死亡后50年；法人及其它组织的作品，其法律规定的相关著作权的保护期为50年。
区别于著作权对软件本身的保护，专利权保护计算机软件体现在保护软件的设计思想。比如，一个软件构思，可以通过不同的编程语言来实现。著作权保护的是已经写出来的整套编程，而专利权则保护编程语言背后的构思。所以，一个软件可以同时享有著作权和专利权，开源软件也可以在开源之前，先为软件设计思路申请专利。
一些开源协议允许开源软件享有专利权，如 Mulan PSL v2第2条规定：每个“贡献者”根据“本许可证”授予您永久性的、全球性的、免费的、非独占的、不可撤销的(根据本条规定撤销除外)专利许可，供您制造、委托制造、使用、许诺销售、销售、进口其“贡献”或以其他方式转移其“贡献”……Apache 2.0等开源协议也有类似的规定，而诸如 MIT 的一些协议，并未涉及专利问题，其是否存在默示的专利限制，还有待解答。
为软件申请专利的流程更为复杂，但是其法律约更多，对软件开发和共享造成更大阻力，因此催生了反软件专利的运动。反软件专利的支持者认为，软件创新也不需要外界强力来推动，即不需要专利法去刺激创新。这也引出了以上争议背后的焦点问题——究竟什么样的知识产权保护，才能最大程度推动整个计算机软件世界的创新与发展，而不是仅仅关注当下，或者某个体的既得利益？
AGPL之困
开源界的几乎都知道 GPL 的。1983年，自由软件之父 RMS(Richard Mattew Stallman)发起著名的 “GNU 计划”，某种意义上可以视为开源的开始。在 RMS 的哲学中，知识产权是一种社会赋权，权利人应该被允许通过契约的方式，自由转让软件权利，如复制、修改、再发布的权利。即 “Copyleft” 。为了支撑这一概念的落地，1989年 RMS 与一群律师起草了世界上第一个开源软件协议 —— GNU 通用公共协议证书(GNU General Public License，也就是 GPL)，到现在 GPL 依旧是开源世界最流行的开源许可证之一。
总的来说，从相对于“版权(Copyright)”的“Copyleft”，到整个自由软件运动，RMS 的初衷就是——反对专有软件。这也为之后开源与其他势力的冲突埋下了伏笔。Web 和云计算崛起之后，对开源业界带来的冲击从而引发的一系列摩擦就是一个例证。
面对新模式的侵袭，开源世界并没有坐以待毙，AGPL(GNU Affero General Public License)就是为此诞生的。在 AGPL 更严苛的限制条件下，各厂商也的确开始忌惮。但事与愿违，AGPL 并没有被多数开源公司视为有效途径，甚至开始走向边缘化。甚至连 GNU 官方也表示，AGPL 并没有解决“SaaS 替代品(SaaSS，Service as a Software Substitute)”的问题。
诞生在上个世纪的 GPL 没有想到的是，软件的分发模式会在21世纪发生巨大的变化。GPL 主要是针对以微软为代表的传统软件分发商业模式，其约束生效的前提是“发布”软件，也就是说，必须通过互联网或光盘 release 软件，才会受到 GPL 的限制(也不算真的限制，就是需要明示地附上相关源代码，且你分发的软件也必须是 GPL 的)。随着以 Google 为代表的网络服务提供者(Application Service Provider)出现，这一条款就不再适用了。因为他们不分发软件！Google 的商业模式是为客户提供网络服务，不分发就不需要开源他的私有解决方案，基本就等于不受约束。
大家将 GPL 的这个漏洞称之为 Web Service Loopwhole。同理，SaaS(Software as a Service，软件即服务)也是一样。SaaS 在云上提供软件服务，也是走了不“分发”的漏洞。云计算公司可以不向社区共享更改，让他们获得了某种优势。比如亚马逊的 Aurora MySQL 就是基于 MySQL 。
于是，一些自由软件理念者开始推动修改 GPL 授权条款的内容。
2002年，在自由软件基金会 (Free Software Foundation, FSF) 的同意下，Affero 公司基于 GPLv2 发布了 AGPL 的最初版本。随着 GPLv3 在2007年发行，AGPL 也重新在 GPLv3 的基础上，更新了 AGPLv3。现行的 AGPL指的就是这一版本。
AGPL 可以说是对 GPL 的一次“查漏补缺”。AGPL 继承了 GPL 所有条款，并在此基础上增加了一条：如果其许可下的软件与用户通过网络进行交互，那么就需要提供源代码给用户，所有的修改也同样要提供给用户。本质上说，AGPL 就是针对基于 web 的应用程序的。在一开始，Google 等网络服务公司是其主要的观察对象，然后随着云计算崛起，亚马逊等云厂商又成为了新的对象，用于确保对开放源代码 SaaS 应用代码的修改会反馈给自由软件社区。
如果你认为自由软件不能赚钱，那就错了。
Open Core 模式就是一种开源商业模式。简单说来，就是开源一个免费的社区版，而对商业版本闭源收费。在 Open Core 模式下，AGPL 完全可行。比如说你开发了一套商城，如果以 GPL 开源，竞争对手就可以直接拿走程序提供 SaaS 服务；而在 AGPL 下，部署了相关程序但是不想开源的，就需要购买商业版权。
2018年11月，因为不想让云提供商白白获利， Neo4j 正式走向 Open Core 模式，宣布从 Neo4j 3.5版本开始，企业版仅在商业许可下提供，不再在 Github 上提供源代码，而 Neo4j 社区版将在 AGPLv3 下继续开源。
AGPL 的效力是显而易见的，但是依旧遭到了“背叛”。同样是在2018年，Redis Labs 将 Redis 模块的许可证从 AGPL 更改为 Apache v2.0 ，并附带 Commons Clause 。其中，Commons Clause 不是开源协议，明令禁止商业：“许可证授予的权利不包括、并且不授予您销售软件的权利。”
Commons Clause 并不是孤例。几乎是在同一时期， MariaDB 公司创建 BSL，这是本质上介于闭源和 Open Core 开源模式的“中间模式”，BSL 中指定级别以下的使用总是完全自由的，超过指定级别的使用需要有商业授权，并且 BSL 保证在某个时间点会变成“真的”开源，这时所有对项目的使用行为都是自由的。 MongoDB 创建 SSPL，比 AGPL 更过分的是，如果你将产品作为服务提供给他人，SSPL 要求公开发布任何修改以及管理层的源代码。
其中，BSL 和 SSPL 都不是开源协议，都没有通过 OSI (Open Source Intiative)的认证。
从开源维度上来讲，放着 AGPL 一个根正苗红的被 OSI 认可的开源许可证不用，这些开源公司为什么要另起炉灶去创建一些不被开源世界所认可的“非开源许可证”呢，难道是 AGPL 不好使？
与其说 AGPL 不好使了，不如说在商业世界里的竞争都是“不讲武德”的。完全从商业角度来看 AGPL 就是完全另一码事了。
首先，AGPL 并不受商业公司待见。
显而易见，AGPL 等强 Copyleft 许可证是带有传染性的，倾向于保守的商业公司天然对 AGPL 存有疑虑，毕竟不谨慎采用 AGPL 就会为公司带来技术外泄的风险。比如，苹果就不允许 GPL /AGPL 授权的软件出现在应用商店，而谷歌更是以禁止 AGPL 闻名，MongoDB 之前使用 AGPL 也被美国三大云厂商亚马逊、微软和谷歌排除在其云服务之外。
因为 GPL 一旦授权就无法撤销，而 AGPL 更糟，用户只是使用软件就会触发授权。许多拥有 AGPL 项目的公司都会被大企业要求转而采用更宽松的许可证，因为使用 AGPL 违反了他们公司的政策。有律师表示，不少企业对 GPL/AGPL 有恐惧心理，担心传染自研代码。
其次，大企业抢蛋糕，管你什么开不开源。
或许是基于对 AGPL 的抗拒心态，又或许是商业世界利益至上，大企业在抢占“蛋糕”时，吃相往往不好看。
文档数据库市场巨大，但因为 MongoDB 采取 AGPL 授权模式，其他云厂商巨头一直没办法直接使用开源的 MongoDB，但是他们还是想了办法进入这个市场。微软首先推出 DocumentDB这个产品，采用兼容 MongoDB 的 API 的方式来实现对 MongoDB 的支持。这个产品后来升级成为 CosmosDB，支持除了 MongoDB 以外的其他一系列开源接口。亚马逊也紧跟其后，推出了 DocumentDB 服务。
有评论认为，从 MongoDB 推出 SSPL 便知道 AGPL 效果不佳。云服务在众多以 SaaS 模式进行开源商业化的初创公司面前成为了一把双刃剑：客户把数据和计算交给开源公司，而开源公司的服务质量(包括性能、可扩展性和可用性)又取决于云服务商(AWS、阿里或微软等)同时其代码还暴露在公开环境中。那么无论从规模经济还是服务质量来看，后者在基础设施层上天然具有一定优势。
从而，一种不平等产生了：基于 IT 巨头的地位，开源创业公司很难有反抗之力；与此同时，开源越来越离不开商业运作。
在亚马逊用分叉(fork)的方式对付 Elasticsearch 时，他们甚至还发文怒斥 Elasticsearch 的这种行为，称其为“假开源”。另一个例子是 Docker，虽然 Docker 几乎已成为当今容器技术的事实标准，但在更高层次的容器编排生态，谷歌推出的 Kubernetes 占了绝对主导。Docker 实际上并没有从其中获得多少好处。
最后，违反 AGPL 的成本不高，而且维权也很难。
AGPL 作为一个被 OSI 认证的开源协议，肯定是具有法律效力的。但你有没有发现企业却很少通过法律诉讼维权？
因为如果弊大于利或者胜负难料，执法成本过高，那么对 AGPL 侵权采取法律行动是没有意义的。
一方面，很多 AGPL 侵权者未必能提供多少令人感兴趣的代码，很可能侵权者的代码很烂，要求对方根据许可证要求披露代码反而是增加自己维护代码的负担。而且，绝大多数 AGPL 侵犯者通常也无法拿出多少钱来进行赔偿。另一方面，如果你想告一家大公司，那么一起案件的诉讼费就是一笔巨款，况且对方有着强大的经济实力作为后盾，诉讼将会非常长，比如针对 VMware 的侵权诉讼拖了5年之久，还是以原告放弃上诉收场。
此外，AGPL 的侵权行为往往是跨国的，而跨国起诉的难度则更大。因此，对于 AGPL 违约，大家更多的是从道德层面谴责 —— 享受开源成果，是应该给社区回馈的。
自由理想崩塌了吗？
这是一个异端观点，是我们过分担忧授权了。尤其认为我们并不需要互惠许可证，不需要像 GPL 之类的许可证，去惩罚拿了开源代码却做闭源开发的人。
2009年，《大教堂与集市》的作者、开源界领袖式的人物 Eric S. Raymond 在长岛 Linux 用户组聚会上宣称，鉴于开源运动与众不同的运作方式，GPL 许可证已经不再是必要的了。
这撕开了开源世界的一个真相：自由软件与开源软件之间存在裂缝。
AGPL 虽然是开源许可证，但它更重要的身份是：自由软件许可证。AGPL 的焦点是从软件绝对必须 100% 自由的角度出发的，它更符合早期开源项目建立的核心 —— 注重开放性和软件自由性。但随后开发形式被更新了，开源项目的内核也发生了改变。对现在的开源项目来说，自由什么的可能不太重要，开源是为了完成命令，又或者只是为了开放某个软件的一个组件。
从这一维度来说，让 AGPL “失效”的，并不是商业的“围剿”，而可能是理想的崩塌。
其实，AGPL 在商业上，并非完全不可绕过。在 AGPL 的规则中，被要求开源出来的仅仅是修改部分； AGPL 也有很多例外条款，比如以聚合体发布可以闭源。同时，AGPL 也允许做封装，还可以通过标准接口调用，或者使用动态链接把程序的模块相互划分开来，形成独立的文件，以区分代码。很多公司是可以绕过，比如 Google GMS 就可以不开源。
时至今日，依旧有开源公司选择成为 AGPL 的拥趸。
2021年4月，Grafana Labs 公司宣布旗下核心开源项目(Grafana、Grafana Loki 和 Grafana Tempo)的许可证将从 Apache License 2.0 变更为 AGPLv3。Grafana Labs 公司认为这是一种更公平的方式，并且有助于建立更强大的社区。
Grafana Labs CEO Raj Dutt 表示，自己也知道 AGPL 对自家产品的“保护”不能达到像其他许可证(例如SSPL)那种程度，但他认为这已经实现了一定的平衡，这种平衡是 Grafana Labs 公司一直以来的探索 —— 如何在开源和社区的“价值创造”以及商业化策略的“价值获取”之间取得平衡。开源一直以来都是 Grafana Labs 的内核，他相信采用 AGPLv3 可以让社区和用户继续拥有一直以来享有的自由。
2021年6月，ThingsPanel 变更开源授权协议为 AGPLv3。ThingsPanel 表示，Grafana、Loki和Tempo 改用 AGPLv3 许可证的新闻给了其一个新的启示，去进一步平衡商业与开源，以更好地推动 ThingPanel 项目的开展。最大化的开源是 ThingPanel 的最佳选项。
事实上，AGPLv3 协议已经存在并运行了长达 14 年，维基百科还专门有一份列出了哪些开源项目是采用了 AGPLv3 开源协议的列表。
尽管 Redis Labs 将 Redis 模块从 AGPL 迁移到将 Apache 2.0 与 Commons Clause 相结合的许可证，但是 Redis 作者 antirez 是这样表态的：“对于我将开发的Redis模块，比如Disque，我会选择AGPL。我们生活在云时代，所以使用新许可证会强制其他SaaS公司重新提交回他们的改进。”
对自由坚守，还是对商业妥协，或许这才是问题的核心。
现今存在的开源协议很多，而经过Open Source Initiative组织通过批准的开源协议目前有58种。我们在常见的开源协议如BSD、GPL、LGPL、MIT等都是OSI批准的协议。如果要开源自己的代码，最好也是选择这些被批准的开源协议。
各种开源软件授权方式的选择
各种开源软件授权方式的介绍
首先介绍开源软件的共同的特点：源代码开放、免费修改、免费重新发布。
以BSD为代表的接近于公共域软件的授权。包括Xwindows、FreeBSD、apache、perl、python、ruby、zope 等。其中apache的授权叫APL，是一种比较典型的授权声明，下面对于近似公共域的授权以APL表示。这种授权的特点就是虽然保留版权，但不但免费修改、免费重新发布，而且允许商业使用，允许商业修改后不公布修改的软件代码。是对商业软件友好的授权方式。
以GPL为代表的自由软件，包括linux、gcc、KDE、gnome等。允许免费修改、免费重发布，但要求修改代码必须也遵守GPL。这种授权方式大大限制了从开源中牟利的手段，因此是对商业不友好的授权，对商业不友好的后果是不能使开源代码产生更广泛的效果、不能调动商业软件开发力量。但也要看到GPL对打破垄断的价值，打破垄断对所有的商业软件也是有利的。在GPL下面还有一种对商业更友好的方式就是LGPL，允许商业代码链接LGPL代码，这样商业软件在利用LGPL软件的同时能够很大程度上保留商业利益。gnome是LGPL的(不确定)，KDE是GPL的。因此在KDE上面实现商业软件比较困难，因此说KDE是开放不充分的。
以MPL为代表的商业公司的开源策略。包括mozilla、openoffice等。允许免费重发布、免费修改，但要求修改后的代码版权归软件的发起者，这样发起者和组织者具有更优越的地位。MPL一般也是同时遵守LGPL的。这是因为GPL比较严格，不会产生另一个商业的竞争者。MPL也是对商业友好的。并且用一些优惠来鼓励商业软件开源。
强开源约束授权
GPL(GNU General Public License)
我们很熟悉的Linux就是采用了GPL。GPL协议和BSD， Apache Licence等鼓励代码重用的许可很不一样。
GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。
这也就是为什么我们能用免费的各种linux，包括商业公司的linux和linux上各种各样的由个人，组织，以及商业软件公司开发的免费软件了。
GPL协议的主要内容是只要在一个软件中使用(“使用”指类库引用，修改后的代码或者衍生代码)GPL 协议的产品，则该软件产品必须也采用GPL协议，既必须也是开源和免费。
这就是所谓的”传染性”。
GPL协议的产品作为一个单独的产品使用没有任何问题，还可以享受免费的优势。
由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议，对于使用GPL协议的开源代码，商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。
其它细节如再发布的时候需要伴随GPL协议等和BSD/Apache等类似。
弱开源约束授权
MPL License(Mozilla Public License)
允许免费重发布、免费修改，但要求修改后的代码版权归软件的发起者。
这种授权维护了商业软件的利益，，它要求基于这种软件的修改无偿贡献版权给该软件。这样，围绕该软件的所有代码得版权都集中在发起开发人得手中。
但MPL是允许修改，无偿使用的。
MPL软件对链接没有要求。(要求假如你修改了一个基于MPL协议的源代码，则必须列入或公开你所做的修改，假如其他源代码不是基于MPL则不需要公开其源代码)
LGPL(GNU Lesser General Public License)
LGPL是GPL的一个为主要为类库使用设计的开源协议。和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。
LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。
但是如果修改LGPL协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。
因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以LGPL协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。
GPL/LGPL都保障原作者的知识产权，避免有人利用开源代码复制并开发类似的产品。
MIT(MIT)
MIT是和BSD一样宽范的许可协议，作者只想保留版权，而无任何其他了限制。也就是说，你必须在你的发行版里包含原许可协议的声明，无论你是以二进制发布的还是以源代码发布的。
无开源约束授权
BSD开源协议
BSD开源协议是一个给于使用者很大自由的协议。
基本上使用者可以”为所欲为”，可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。
但”为所欲为”的前提当你发布使用了BSD协议的代码，或者以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：
1、如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
2、如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
3、不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
BSD 代码鼓励代码共享，但需要尊重代码作者的著作权。
BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。
而很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。
Apache Licence
Apache Licence是著名的非盈利开源组织Apache采用的协议。
该协议和BSD类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布(作为开源或商业软件)。
需要满足的条件也和BSD类似：
1、需要给代码的用户一份Apache Licence
2、如果你修改了代码，需要再被修改的文件中说明。
3、在延伸的代码中(修改和有源代码衍生的代码中)需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。
4、如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。
你可以在Notice中增加自己的许可，但不可以表现为对Apache Licence构成更改。Apache Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。
其它开源约束授权
Creative Commons(CC)
您在自己的作品上使用知识共享许可协议，并不意味着放弃您的著作权，而是在特定的条件下将您的部分权利授予公共领域内的使用者。
哪些特定的条件呢？您可以在此处看到所有知识共享许可协议及其简单的介绍。
所有的许可协议都要求您以作者或者许可人的名义署名。您可以将以下的选项进行组合、搭配，由此将构成我们的六套核心知识共享许可协议。
1、是否允许他人对自己享有著作权的作品及演绎作品进行复制、发行、展览、表演、放映、广播或通过信息网络向公众传播，但在这些过程中对方必须保留您对原作品的署名。
2、是否允许他人对您享有著作权的作品及演绎作品进行复制、发行、展览、表演、放映、广播或通过信息网络向公众传播，但仅限于非商业性目的。
3、是否允许他人对您的作品原封不动地进行复制、发行、展览、表演、放映、广播或通过信息网络向公众传播，但不得进行演绎创作。
4、只有在他人对演绎作品使用与您的原作品相同的许可协议的情况下，您才允许他人发行其演绎作品。
关于GPL的一些话
如果开源软件的开发要借助社区的力量，那么最好是用GPL授权，因为这样可以防止商业软件抢走用户而导致的开源软件的使用者和开发者都不足。
当然，选择GPL或BSD授权还和人的价值观有关系，但以开发类型来选择授权方式是比较合理的。如果采用封闭开发，使用BSD也可以达到GPL的效果，而采用社区开发，BSD会对开发团队的成长不利。如果在没有商业化价值的领域，GPL完全没有必要。
MPL授权是商业软件想要借助社区的力量的产物。
LGPL对有商业化的友好性和GPL相比是大大提高了，在很多情况下对商业化都没有阻碍，可以说达到了50%的商业化的要求，但有时商业化需要对源代码的彻底修改，因此不能说LGPL百分之百满足商业化要求，LGPL是一个折衷的授权，如果社区开发的软件希望能在更大的范围内被使用，可以采用 LGPL。
“BSD满足了开发者的自由，GPL满足了使用者的自由”这句话对两种授权的出发点做了简单明确的回答。“对于开源项目来说，BSD是封闭开发的选择，GPL是社区开发的选择”(对于小的开源项目，封闭开发反而更有效率)是我理解的两种授权不同的适用范围。
版权与开源协议的那些事
4月26日是世界知识产权日，很多人或许会觉得这和软件开发没什么关系，但事实上，开源软件大多受到知识产权法中著作权法(Copyright，也称版权)的保护。开源软件虽说开放了源代码，但是用户在使用、修改、再发布时，必须要遵守软件中规定的开源协议(也称开源许可证/开源License)，否则可能构成侵权，惹上官司。
随着计算机软件的激增，其著作权保护愈发重要。同样在26日，《中华人民共和国著作权法修正案(草案)》提交十三届全国人大常委会第十七次会议审议。修正案中有多处直接涉及计算机软件的修正：如在第十条的出租权中明确包含计算机软件的原件或者复制件权利；修正后的第五章“著作权和与著作权有关的权利的保护”中，第四十八条处加入对计算机及其系统或者网络的完全性能进行测试条例。虽然修正案还未最终确定，但这也显现了加强软件法律保护的趋势。今天，我们就来谈谈计算机软件开发、使用中涉及的一些权利问题，以及这些问题的源头和当下的新争议。
Copyright 和 Copyleft：开源著作权和开源协议
提到 “Copyright”，大家可能还会想到自由软件之父 RMS 提出的“Copyleft”反版权思想。“Copyleft”最初是为反对商业软件而生，但它并不是放弃版权，“Copyleft”中的“Left”，不使用英语中“保留”的意思，而是指“Left(左)”，与“版权(Copyright)”中的“Right(右)”具有镜像的关系。
二者的区别可总结为：“Copyright”指软件的版权和其它一切权利归软件作者所私有，用户只有使用权，没有其它如复制、重新修改发布等权利。而“Copyleft”的特点是仅有版权归原作者所有，其他一切权利可以与任何人共享。
首先，计算机软件作者都可对自己的作品享有著作权“Copyright”。
著作权源于信息时代早期，最初指印刷出版之权，是印刷术发明催生起的复制(Copy)权(Right)。后来随着科学技术发展，种类渐增，逐渐开始保护文学作品作者权利、作者的表演权利等等。1994年，计算机程序被明文提出应该作为文学作品受到保护，1996年这一规定被世界知识产权组织在全球范围内推行。
注释：1994年4月15日，关贸总协定乌拉圭回合各缔约方在马拉签署了《与贸易有关的知识产权协议》(TRIPS)，其第十条规定：“计算机程序，无论是原始资料还是实物代码，应根据《伯尔尼公约》(1971)作为文学作品来保护。”
1996年12月20日，世界知识产权组织通过的《世界知识产权组织版权条约》(WTC)其第四条明确规定不论计算机程序表达方式或表达形式如何，均作为《伯尔尼公约》第二条意义上的文学作品受到保护。
这为国际件计算机软件版权保护提供了统一的标准和依据。
其次，开源软件作者在拥有著作权的同时，还可以自由决定如何与别人分享自己的作品，这便是“Copyleft”所提倡的理念，也是受开源许协议所保障的权利。
“Copyleft”通常被译作“著佐权”，即通过许可证的形式，补足、辅佐著作权(Copyright)不足的版权授权，相当于一种权利与义务的契约。RMS 1983年9月创建 GNU 项目，1984年发表《GNU 宣言》，抨击封闭源码行为，也创造了“Copyleft”一词。
“Copyleft”思想脱胎于 RMS 的知识产权观——他认为知识产权是一种社会赋权，权利人应该被允许通过契约的方式，自由转让软件权利，如复制、修改、再发布的权利。所以 RMS 提出：自由软件在承认著作权的基础上，可以通过许可协议，与公众共享作品的其它权利。
1989年，RMS 与一群律师起草了世界上第一个开源软件协议——GNU 通用公共协议证书(GNU General Public License, GNU GPL )。证书的序言体现了“Copyleft”的思想。
一是承认软件的著作权；二是提供许可协议，来获得复制、发布、修改的法律许可。用户可以获得权利人通过许可证放弃的权利，但也必须遵守许可证的规定才能行使，如果不遵守开源软件规定，便是侵犯了开源软件著作权，其著作权人就有权要求对方停止相关行为及其他。
至此，“Copyleft”一词有了实际载体。而这也是现在开源许可协议既可以保护开源软件作者著作权，又可以为开发者提供修改、再发布权利的法律思想源头和基础。
开源软件及协议的发展
基于“Copyleft”思想的 GPL 现在是使用最为广泛的许可证之一。
这个许可证在开放源代码的前提下，几乎可以说是“最大程度”地限制了使用者——它不仅要求用户再修改的软件要开源，而且如果用户将 GPL 许可证下的软件添加入专有软件，那么新组合的软件也应当全部适用于 GPL 许可证，也就是说，组合里所有的软件都必须开源。
因此，GPL 被称作是带有“传染性”的许可证。越来越多的开源软件支持者认为，我们应该向更加宽松的许可协议靠近，不应该在许可协议上做过多限制。
但 RMS 认为，GPL 才是真正保护了所有使用者的自由。因为 GPL 协议可以规范使用开源软件的用户继续开源，从而维护源码开放使用的自由。
RMS 是自由软件运动的领导者之一，被称为“自由软件之父”。在组织人力起草 GPL 协议之外，他最为人们津津乐道的成就还有创建 GNU 项目以及成立 FSF 自由软件基金会。现在我们常说的 Linux 其实是指 Linux 内核加上 GNU 套件，即 GNU/Linux，这是全世界尤其是超级计算机中使用率最高的底层操作系统。RMS 曾向媒体要求，在采访他的时候，要用“GNU/Linux”称呼操作系统，而非 Linux。
RMS 执着于解放软件，一直致力推动软件和世界自由，这让外人觉得他脾气执拗古怪。也有人问他，参与自由软件运动多年，到底收获了什么。他说，“我比较感兴趣的是，世界得到了什么。我对我的人生很骄傲，因为我人生的一半，都在为自由奋斗，抵制人们做不自由的事，虽然我们还没达到胜利的目标。”
这个“胜利的目标”，在很多开发者看来，是不切实际的。1998年，Eric Raymond 发表《大教堂与集市》一书，为开源奠定文化理论基础。Raymond 以及他的追随者认为，RMS 和 FSF 在推动自由软件的时候，受意识形态影响太深，与现实脱节。而为了自由软件尽可能大范围地取得成功，应该侧重提供源代码的实用价值，而不是过多的讲究共享和道德哲学。
很快，Raymond 邀请了十几个自由软件社区著名成员开会(当然，不包括 RMS)，讨论决定用“开源软件”来代替“自由软件”。1998年，Raymond 和 Bruce Perens 成立了开源促进会——OSIA，这个组织后来主导了开源运动，并定义了开源软件，其中也对许可协议做了一定规范：
OSD：自由再发布；以源代码的形式再发布；派生作品，即使用同款开源软件协议，不同协议之间也可以兼容；作者源代码的完整性，自己修改的程序用不同的版本号与原始的做区分，软件用户有权知道作者是谁；个人或团体不受歧视；开源软件程序可以被使用在任何领域再发布许可协议，新增软件不得添加新的条款；许可证不得只用于特定产品；许可证不得限制其他软件；许可协议必须是技术中立的。
随着开源运动的扩大，以及开源软件定义的明晰，许可协议对开源软件的促进、保护作用愈发凸显，其种类也在不断增加。《大教堂与集市》的译者卫剑钒在近日发布的一篇文章中，形象道出许可证的机制和作用：
我允许你们XXX，我许可你们XXXX，你们可以XXXX，但是，你们必须XXXX，如果你们XXXX了，你们就必须XXXX，对了，对于XXXX这些情况，我可不负责。你要同意，就用，不同意就别用。如果你用了，但违反了许可证的要求，我可能会告你啊！
国内近期有一起计算机软件著作权诉讼案，涉及开源软件和许可协议。2019年12月，北京高级人民法院对被告柚子(北京)科技有限公司、柚子(北京)移动技术有限公司、与原告数字天堂(北京)网络技术有限公司侵犯计算机软件著作权纠纷做出终审判决。
起因是两被告公司的 APICloud 软件复制及修改了原告数字天堂公司 HBuilder 软件中的三个插件，这些插件采用了 GPL 协议。如前文所述，按照 GPL 的规定，只要使用了 GPL 下的软件，就必须全部开源，但 APICloud 并没有全部开源，于是引发诉讼。
最终，法院认定，柚子科技公司、柚子移动公司的 APICloud 软件复制及修改了数字天堂公司 HBuilder 软件中的三个插件，侵犯了著作权人数字天堂公司对软件作品享有的复制权和修改权等权利，判令被告停止侵权并赔偿71万元。此案是中国 GPL 诉讼第一案，其判决被认为对开源软件诉讼实践有重要意义，这对之后类似案件的审判有较高参考价值，对国内开发者使用开源软件也有指导意义。
国际上在实际判例中承认开源许可协议的法律效力来得更早。2008年，美国联邦巡回上诉法院首次在判决中主张了开源许可证的著作权协议。原告Bob Jacobsen 采用 Artistic 许可证，发布了自己的开源软件。被告 Matthew Katzer 使用了该软件，但是却未履行许可证中规定的著作权声明义务。最终，被告被认定违反 Artistic 许可证的行为是侵犯了原告的著作权。
声明作者的著作权，基本可以称作是开源许可证的“入门级”协议，在此基础上，许可证还规定了使用者是否可以将其拿去商用、是否可以打着原作者的名义营销等等。此前，有人将较为流行的几种许可证做了一个划分：
上图中的几个许可证仅是目前较为流行的，在这之外，通过 OSI 认证的许可证还有近百个。一项调查显示，许可证逐渐被认为是开发人员在决定使用某个开源项目时最需要考虑的事项，因为没有开发人员愿意在不知道接下来将如何发展的情况下，开始使用新的软件包。
许可证种类和规定的多样性导致软件合规变得复杂，不过目前已经有一些工具可以初步降低这一门槛，比如 Linux 基金会推出的许可证使用规范工具 ACT、Gitee 的许可证引导功能。
一些争议
在软件开发过程中，围绕软件法律保护产生了多种争议。
一方面，许可证应该规定哪些权利义务、应该走向宽松还是限制被广为讨论。另一方面，人们是否应该为软件的设计思想申请专利也引发了开发者之间的对立。
许可证种类渐增的当下，人们愈发渴望更加宽松的开发环境、和更简洁的协议。大量软件从限制性许可证转到宽松许可证。Blackduck 数据显示，从 2009 年到 2015 年的六年间，宽松型 MIT 许可证的份额上升了15.7%，Apache 的份额上升了12.4%；而 GPL v2 和 v3 的份额则下降了21.4%。GitHub 2015年发布的许可证使用情况报告显示，MIT 协议使用率最高，两年前的一项研究也得出了同样的结论。
然而，追求宽松又带来新的问题。
MIT 是现在使用最广泛，又最为宽松的许可证。开发者只要保留原作者的版权和许可，便可以随意使用，包括出售源码。这时，原开发者就可能会面临“别人都能拿着我的软件出去售卖，我徒留版权有何用”的窘境，此刻大概只有用“自由与分享”的理想做注解了。而如果想避免这种状况，开发者可以更换更为严格的许可协议，或者不开源。
此外，近年还出现开源公司被云厂商“寄生”的情况，云厂商直接将开源厂商的开源能力作为云环境下的商业服务，而不回馈开源社区，挤压开源厂商业务，致使其陷入生存困境。这迫使许多开源软件又从宽松型许可证转向更严格的协议，甚至直接闭源。
更有甚者，认为开源软件应该脱离现有的著作权法，拥有一部属于自己的《开源法》：以著作权法为主的知识产权法是后工业时代和前信息时代的产物，它赋予人们对其创造出来的信息—电影、软件等作品、发明等技术方案、产品设计—进行垄断的财产权。但软件存在的意义应该是作为解决实际问题的工具，真正核心的特点是工具性、功能性，而非表面上的作品性。这时就不再适用著作权法，而是应该新建《开源法》。
实际上，除了著作权和许可证，还有一部分软件，尤其商用软件可以同时受到专利法的保护。我国法律规定，计算机软件专利保护期限为从申请日起算20年。著作权保护期为作者有生之年加死亡后50年；法人及其它组织的作品，其法律规定的相关著作权的保护期为50年。
区别于著作权对软件本身的保护，专利权保护计算机软件体现在保护软件的设计思想。比如，一个软件构思，可以通过不同的编程语言来实现。著作权保护的是已经写出来的整套编程，而专利权则保护编程语言背后的构思。所以，一个软件可以同时享有著作权和专利权，开源软件也可以在开源之前，先为软件设计思路申请专利。
一些开源协议允许开源软件享有专利权，如 Mulan PSL v2第2条规定：每个“贡献者”根据“本许可证”授予您永久性的、全球性的、免费的、非独占的、不可撤销的(根据本条规定撤销除外)专利许可，供您制造、委托制造、使用、许诺销售、销售、进口其“贡献”或以其他方式转移其“贡献”……Apache 2.0等开源协议也有类似的规定，而诸如 MIT 的一些协议，并未涉及专利问题，其是否存在默示的专利限制，还有待解答。
为软件申请专利的流程更为复杂，但是其法律约更多，对软件开发和共享造成更大阻力，因此催生了反软件专利的运动。反软件专利的支持者认为，软件创新也不需要外界强力来推动，即不需要专利法去刺激创新。这也引出了以上争议背后的焦点问题——究竟什么样的知识产权保护，才能最大程度推动整个计算机软件世界的创新与发展，而不是仅仅关注当下，或者某个体的既得利益？
AGPL之困
开源界的几乎都知道 GPL 的。1983年，自由软件之父 RMS(Richard Mattew Stallman)发起著名的 “GNU 计划”，某种意义上可以视为开源的开始。在 RMS 的哲学中，知识产权是一种社会赋权，权利人应该被允许通过契约的方式，自由转让软件权利，如复制、修改、再发布的权利。即 “Copyleft” 。为了支撑这一概念的落地，1989年 RMS 与一群律师起草了世界上第一个开源软件协议 —— GNU 通用公共协议证书(GNU General Public License，也就是 GPL)，到现在 GPL 依旧是开源世界最流行的开源许可证之一。
总的来说，从相对于“版权(Copyright)”的“Copyleft”，到整个自由软件运动，RMS 的初衷就是——反对专有软件。这也为之后开源与其他势力的冲突埋下了伏笔。Web 和云计算崛起之后，对开源业界带来的冲击从而引发的一系列摩擦就是一个例证。
面对新模式的侵袭，开源世界并没有坐以待毙，AGPL(GNU Affero General Public License)就是为此诞生的。在 AGPL 更严苛的限制条件下，各厂商也的确开始忌惮。但事与愿违，AGPL 并没有被多数开源公司视为有效途径，甚至开始走向边缘化。甚至连 GNU 官方也表示，AGPL 并没有解决“SaaS 替代品(SaaSS，Service as a Software Substitute)”的问题。
诞生在上个世纪的 GPL 没有想到的是，软件的分发模式会在21世纪发生巨大的变化。GPL 主要是针对以微软为代表的传统软件分发商业模式，其约束生效的前提是“发布”软件，也就是说，必须通过互联网或光盘 release 软件，才会受到 GPL 的限制(也不算真的限制，就是需要明示地附上相关源代码，且你分发的软件也必须是 GPL 的)。随着以 Google 为代表的网络服务提供者(Application Service Provider)出现，这一条款就不再适用了。因为他们不分发软件！Google 的商业模式是为客户提供网络服务，不分发就不需要开源他的私有解决方案，基本就等于不受约束。
大家将 GPL 的这个漏洞称之为 Web Service Loopwhole。同理，SaaS(Software as a Service，软件即服务)也是一样。SaaS 在云上提供软件服务，也是走了不“分发”的漏洞。云计算公司可以不向社区共享更改，让他们获得了某种优势。比如亚马逊的 Aurora MySQL 就是基于 MySQL 。
于是，一些自由软件理念者开始推动修改 GPL 授权条款的内容。
2002年，在自由软件基金会 (Free Software Foundation, FSF) 的同意下，Affero 公司基于 GPLv2 发布了 AGPL 的最初版本。随着 GPLv3 在2007年发行，AGPL 也重新在 GPLv3 的基础上，更新了 AGPLv3。现行的 AGPL指的就是这一版本。
AGPL 可以说是对 GPL 的一次“查漏补缺”。AGPL 继承了 GPL 所有条款，并在此基础上增加了一条：如果其许可下的软件与用户通过网络进行交互，那么就需要提供源代码给用户，所有的修改也同样要提供给用户。本质上说，AGPL 就是针对基于 web 的应用程序的。在一开始，Google 等网络服务公司是其主要的观察对象，然后随着云计算崛起，亚马逊等云厂商又成为了新的对象，用于确保对开放源代码 SaaS 应用代码的修改会反馈给自由软件社区。
如果你认为自由软件不能赚钱，那就错了。
Open Core 模式就是一种开源商业模式。简单说来，就是开源一个免费的社区版，而对商业版本闭源收费。在 Open Core 模式下，AGPL 完全可行。比如说你开发了一套商城，如果以 GPL 开源，竞争对手就可以直接拿走程序提供 SaaS 服务；而在 AGPL 下，部署了相关程序但是不想开源的，就需要购买商业版权。
2018年11月，因为不想让云提供商白白获利， Neo4j 正式走向 Open Core 模式，宣布从 Neo4j 3.5版本开始，企业版仅在商业许可下提供，不再在 Github 上提供源代码，而 Neo4j 社区版将在 AGPLv3 下继续开源。
AGPL 的效力是显而易见的，但是依旧遭到了“背叛”。同样是在2018年，Redis Labs 将 Redis 模块的许可证从 AGPL 更改为 Apache v2.0 ，并附带 Commons Clause 。其中，Commons Clause 不是开源协议，明令禁止商业：“许可证授予的权利不包括、并且不授予您销售软件的权利。”
Commons Clause 并不是孤例。几乎是在同一时期， MariaDB 公司创建 BSL，这是本质上介于闭源和 Open Core 开源模式的“中间模式”，BSL 中指定级别以下的使用总是完全自由的，超过指定级别的使用需要有商业授权，并且 BSL 保证在某个时间点会变成“真的”开源，这时所有对项目的使用行为都是自由的。 MongoDB 创建 SSPL，比 AGPL 更过分的是，如果你将产品作为服务提供给他人，SSPL 要求公开发布任何修改以及管理层的源代码。
其中，BSL 和 SSPL 都不是开源协议，都没有通过 OSI (Open Source Intiative)的认证。
从开源维度上来讲，放着 AGPL 一个根正苗红的被 OSI 认可的开源许可证不用，这些开源公司为什么要另起炉灶去创建一些不被开源世界所认可的“非开源许可证”呢，难道是 AGPL 不好使？
与其说 AGPL 不好使了，不如说在商业世界里的竞争都是“不讲武德”的。完全从商业角度来看 AGPL 就是完全另一码事了。
首先，AGPL 并不受商业公司待见。
显而易见，AGPL 等强 Copyleft 许可证是带有传染性的，倾向于保守的商业公司天然对 AGPL 存有疑虑，毕竟不谨慎采用 AGPL 就会为公司带来技术外泄的风险。比如，苹果就不允许 GPL /AGPL 授权的软件出现在应用商店，而谷歌更是以禁止 AGPL 闻名，MongoDB 之前使用 AGPL 也被美国三大云厂商亚马逊、微软和谷歌排除在其云服务之外。
因为 GPL 一旦授权就无法撤销，而 AGPL 更糟，用户只是使用软件就会触发授权。许多拥有 AGPL 项目的公司都会被大企业要求转而采用更宽松的许可证，因为使用 AGPL 违反了他们公司的政策。有律师表示，不少企业对 GPL/AGPL 有恐惧心理，担心传染自研代码。
其次，大企业抢蛋糕，管你什么开不开源。
或许是基于对 AGPL 的抗拒心态，又或许是商业世界利益至上，大企业在抢占“蛋糕”时，吃相往往不好看。
文档数据库市场巨大，但因为 MongoDB 采取 AGPL 授权模式，其他云厂商巨头一直没办法直接使用开源的 MongoDB，但是他们还是想了办法进入这个市场。微软首先推出 DocumentDB这个产品，采用兼容 MongoDB 的 API 的方式来实现对 MongoDB 的支持。这个产品后来升级成为 CosmosDB，支持除了 MongoDB 以外的其他一系列开源接口。亚马逊也紧跟其后，推出了 DocumentDB 服务。
有评论认为，从 MongoDB 推出 SSPL 便知道 AGPL 效果不佳。云服务在众多以 SaaS 模式进行开源商业化的初创公司面前成为了一把双刃剑：客户把数据和计算交给开源公司，而开源公司的服务质量(包括性能、可扩展性和可用性)又取决于云服务商(AWS、阿里或微软等)同时其代码还暴露在公开环境中。那么无论从规模经济还是服务质量来看，后者在基础设施层上天然具有一定优势。
从而，一种不平等产生了：基于 IT 巨头的地位，开源创业公司很难有反抗之力；与此同时，开源越来越离不开商业运作。
在亚马逊用分叉(fork)的方式对付 Elasticsearch 时，他们甚至还发文怒斥 Elasticsearch 的这种行为，称其为“假开源”。另一个例子是 Docker，虽然 Docker 几乎已成为当今容器技术的事实标准，但在更高层次的容器编排生态，谷歌推出的 Kubernetes 占了绝对主导。Docker 实际上并没有从其中获得多少好处。
最后，违反 AGPL 的成本不高，而且维权也很难。
AGPL 作为一个被 OSI 认证的开源协议，肯定是具有法律效力的。但你有没有发现企业却很少通过法律诉讼维权？
因为如果弊大于利或者胜负难料，执法成本过高，那么对 AGPL 侵权采取法律行动是没有意义的。
一方面，很多 AGPL 侵权者未必能提供多少令人感兴趣的代码，很可能侵权者的代码很烂，要求对方根据许可证要求披露代码反而是增加自己维护代码的负担。而且，绝大多数 AGPL 侵犯者通常也无法拿出多少钱来进行赔偿。另一方面，如果你想告一家大公司，那么一起案件的诉讼费就是一笔巨款，况且对方有着强大的经济实力作为后盾，诉讼将会非常长，比如针对 VMware 的侵权诉讼拖了5年之久，还是以原告放弃上诉收场。
此外，AGPL 的侵权行为往往是跨国的，而跨国起诉的难度则更大。因此，对于 AGPL 违约，大家更多的是从道德层面谴责 —— 享受开源成果，是应该给社区回馈的。
自由理想崩塌了吗？
这是一个异端观点，是我们过分担忧授权了。尤其认为我们并不需要互惠许可证，不需要像 GPL 之类的许可证，去惩罚拿了开源代码却做闭源开发的人。
2009年，《大教堂与集市》的作者、开源界领袖式的人物 Eric S. Raymond 在长岛 Linux 用户组聚会上宣称，鉴于开源运动与众不同的运作方式，GPL 许可证已经不再是必要的了。
这撕开了开源世界的一个真相：自由软件与开源软件之间存在裂缝。
AGPL 虽然是开源许可证，但它更重要的身份是：自由软件许可证。AGPL 的焦点是从软件绝对必须 100% 自由的角度出发的，它更符合早期开源项目建立的核心 —— 注重开放性和软件自由性。但随后开发形式被更新了，开源项目的内核也发生了改变。对现在的开源项目来说，自由什么的可能不太重要，开源是为了完成命令，又或者只是为了开放某个软件的一个组件。
从这一维度来说，让 AGPL “失效”的，并不是商业的“围剿”，而可能是理想的崩塌。
其实，AGPL 在商业上，并非完全不可绕过。在 AGPL 的规则中，被要求开源出来的仅仅是修改部分； AGPL 也有很多例外条款，比如以聚合体发布可以闭源。同时，AGPL 也允许做封装，还可以通过标准接口调用，或者使用动态链接把程序的模块相互划分开来，形成独立的文件，以区分代码。很多公司是可以绕过，比如 Google GMS 就可以不开源。
时至今日，依旧有开源公司选择成为 AGPL 的拥趸。
2021年4月，Grafana Labs 公司宣布旗下核心开源项目(Grafana、Grafana Loki 和 Grafana Tempo)的许可证将从 Apache License 2.0 变更为 AGPLv3。Grafana Labs 公司认为这是一种更公平的方式，并且有助于建立更强大的社区。
Grafana Labs CEO Raj Dutt 表示，自己也知道 AGPL 对自家产品的“保护”不能达到像其他许可证(例如SSPL)那种程度，但他认为这已经实现了一定的平衡，这种平衡是 Grafana Labs 公司一直以来的探索 —— 如何在开源和社区的“价值创造”以及商业化策略的“价值获取”之间取得平衡。开源一直以来都是 Grafana Labs 的内核，他相信采用 AGPLv3 可以让社区和用户继续拥有一直以来享有的自由。
2021年6月，ThingsPanel 变更开源授权协议为 AGPLv3。ThingsPanel 表示，Grafana、Loki和Tempo 改用 AGPLv3 许可证的新闻给了其一个新的启示，去进一步平衡商业与开源，以更好地推动 ThingPanel 项目的开展。最大化的开源是 ThingPanel 的最佳选项。
事实上，AGPLv3 协议已经存在并运行了长达 14 年，维基百科还专门有一份列出了哪些开源项目是采用了 AGPLv3 开源协议的列表。
尽管 Redis Labs 将 Redis 模块从 AGPL 迁移到将 Apache 2.0 与 Commons Clause 相结合的许可证，但是 Redis 作者 antirez 是这样表态的：“对于我将开发的Redis模块，比如Disque，我会选择AGPL。我们生活在云时代，所以使用新许可证会强制其他SaaS公司重新提交回他们的改进。”
对自由坚守，还是对商业妥协，或许这才是问题的核心。