agpl许可证
The advent of open-source changed the entire software industry, for once and for ever. But the control on who can do what with open-sourced code, has been a challenge, and is still a challenge. That’s when open-source licenses came to the rescue. But always remember this: there’s no land without stone and no meat without bone. There are over 80 OSI approved licenses and the numbers have only increased, making it hard for open-source developers to choose licenses for their projects, with each license having its own benefits and drawbacks. The AGPL, short for the Affero General Public License is one of these licenses, more specifically a strong copyleft license, and is arguably one of the most misunderstood licenses.
开源的出现一次又一次地改变了整个软件行业。 但是,控制谁可以使用开源代码做什么,这一直是一个挑战,而且仍然是一个挑战。 到那时,开放源代码许可证得到了拯救。 但请始终牢记:没有石头的土地,没有骨头的肉。 OSI批准的许可证有80多个,而且数量只是在增加,这使得开源开发人员很难为其项目选择许可证,每个许可证各有其优缺点。 AGPL是Affero通用公共许可证的缩写,是其中的一种许可证,更确切地说是强效的Copyleft许可证,并且可以说是最被误解的许可证之一。
为什么还要另一个GPL? (Why another GPL?)
Wait, what? Another GPL? Umm, yes. The AGPL is almost identical to the GPL, except for this addition to Section 13:
等一下另一个GPL ? 嗯是的AGPL与GPL几乎相同,但第13节有以下补充:
Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. […]
尽管本许可协议有其他规定,但如果您修改本程序,则修改后的版本必须显着地为所有通过计算机网络与它进行远程交互的用户(如果您的版本支持这种交互)提供了机会,可以通过提供通过一些促进软件复制的标准或惯例方式,从网络服务器免费访问相应的源。 […]
This has one direct implication — if you let users access any AGPL licensed software over a network, then that is also a form of distribution. This is what the GPL had missed out. With the boom of the cloud era, SaaS has exploded, and instead of distributing software directly, developers and vendors started digitally delivery of software.
这有一个直接的含义-如果您让用户通过网络访问任何AGPL许可的软件,那么这也是一种分发形式。 这就是GPL所错过的。 随着云时代的繁荣, SaaS爆炸了,并且开发人员和供应商开始直接以数字方式交付软件,而不是直接分发软件。
Let’s take an example of a binary application (not a library) developed by Bob. For the sake of representation, let’s call it XBin, which can be used to, say, automatically allocate more resources whenever a web app runs out of them. (PS: This is an example)
让我们以Bob开发的二进制应用程序(不是库)为例。 为了表示方便,我们称其为XBin ,它可以用来在Web应用程序用完时自动分配更多资源。 (PS:这是一个例子)
Step 1: Bob uses the GPL
步骤1:Bob使用GPL
Bob decides to use the GPL. It’s great for him as all of his users send patches to him whenever they find a bug or want a feature to be added. Bob happily merges their code — and is happy! But one day he sees that a big cloud provider, ProviderX, is providing XBin as a part of its project management suite with more features. He’s unhappy about this fact, because he’d have liked ProviderX to have submitted these as patches to improve XBin. Now, Bob can’t do anything legally, because the GPL doesn’t cover network distribution!
Bob决定使用GPL。 这对他来说很棒,因为所有用户都在发现错误或想要添加功能时向他发送补丁程序。 鲍勃愉快地合并了他们的代码-很高兴! 但是有一天,他看到一家大型云提供商ProviderX将XBin作为其项目管理套件的一部分提供了更多功能。 他对这个事实不满意,因为他本来希望ProviderX提交这些补丁程序来改进XBin。 现在,鲍勃无法合法地做任何事情,因为GPL并不涵盖网络分发!
Step 2: Bob switches to the AGPL
步骤2:Bob切换到AGPL
After realizing the drawbacks of the GPL license, Bob switches to the AGPL from the next release. Now, whenever ProviderX makes any change and distributes it as a service to it’s users, it will have to submit the changes back to Bob. Now, it’s fair play! Since then, Bob coded happily ever after!
在意识到GPL许可证的缺点之后,Bob从下一个版本切换到了AGPL。 现在,每当ProviderX进行任何更改并将其作为服务分发给用户时,它都必须将更改提交回给Bob。 现在,这是公平竞争! 从那时起,鲍勃从此过着幸福的编码!
验收问题 (The acceptance problem)
However, the big cloud guys didn’t like this! Several companies have their own AGPL policies, like this and some guys have even voiced out against the adoption and use of the AGPL, calling it toxic. But AGPL adoption continues to grow among several SaaS providers, and DBaaS providers are among the most popular adopters. The point, that most people miss, is that, the AGPL is just a super-set of the GPL, which terms distribution to also be network distribution, and nothing more!
但是,大云家伙不喜欢这样! 有几家公司有自己的AGPL政策,像这样一些人甚至说出了对采纳和使用的AGPL的,称这是有毒的。 但是AGPL的采用在数个SaaS提供商中继续增长,并且DBaaS提供商是最受欢迎的采用者之一。 大多数人都想知道的一点是,AGPL只是GPL的超集,该术语将分发也称为网络分发,仅此而已!
Now let’s take a look at the YAYs and NAYs when using an AGPL licensed binary. I’ll take my project, TerrabaseDB as an example.
现在,让我们看看使用AGPL许可的二进制文件时的YAY和NAY 。 我将以我的项目TerrabaseDB为例。
Scenario 1: Using an unmodified AGPL binary
方案1:使用未修改的AGPL二进制文件
Bob is back again — but this time, he decides to build a web app while using TerrabaseDB, which is an AGPL licensed database, for storing data. His app lets people sign up and save their favorite books, and this data is stored in the AGPL licensed database.
鲍勃又回来了-但是这次,他决定使用TerrabaseDB(这是AGPL许可的数据库)来存储数据时,构建一个Web应用程序。 他的应用程序使人们可以注册并保存自己喜欢的书,并且这些数据存储在AGPL许可的数据库中。
Bob’s confusion: Do I have to open-source my app’s code?The answer: No! The AGPL has got nothing to with Bob’s app! Since Bob has not modified the database, and is merely using it in binary form, “as-is”, he doesn’t have to do anything other than improving his app!
鲍勃的困惑:我是否必须开源应用程序的代码? 答案:不! AGPL与Bob的应用程序无关! 由于Bob尚未修改数据库,而只是以二进制形式“按原样”使用数据库,因此除了改进自己的应用程序外,他无需执行任何其他操作!
Scenario 2: Using a modified AGPL binary
方案2:使用修改后的AGPL二进制文件
Bob now realizes that it would have been better if TerrabaseDB would have a query type X, it would have been more convenient for him. So he downloads the source code and modifies it. Now he has built, what would be called, a derivative work, but, he hasn’t distributed it directly.Bob’s confusion: Do I have to open-source my app’s code?The answer: No! He doesn’t even have to give back the changes he made to the database, since he is not letting users directly access the database. His app’s code — remains his own.
Bob现在意识到,如果TerrabaseDB具有查询类型X会更好,这对他来说将更加方便。 因此,他下载了源代码并进行了修改。 现在,他已经建立了所谓的派生作品,但是,他还没有直接分发它。 鲍勃的困惑:我是否必须开源应用程序的代码? 答案:不! 他甚至不必退还对数据库所做的更改,因为他不允许用户直接访问数据库。 他的应用代码仍然是他自己的。
Scenario 3: Letting users access a modified version of an AGPL Binary
方案3:让用户访问AGPL Binary的修改版本
Bob has modified TerrabaseDB to have query X. He now wants to let other users access it, for a fee. This is again, a derivative work.Bob’s confusion: Do I have to open-source the changes?The answer: Yes! What Bob has done is a derived work, which he has distributed. He will have to disclose the source code for the changes he made.
Bob修改了TerrabaseDB以使其具有查询X。 他现在想让其他用户付费使用。 这又是一个衍生作品。 鲍勃的困惑:我必须开源更改吗? 答案:是的! 鲍勃所做的是他分发的衍生作品。 他将必须披露所做更改的源代码。
Scenario 4: Using a modified version, in private
方案4:私下使用修改后的版本
People at Bob’s office like the modified version of TerrabaseDB, and they want to use it inside their workplace. Bob’s fellow workers have also added some authentication features to TerrabaseDB, to enable workplace users to authenticate themselves. But this code isn’t safe to be given back to the author of TerrabaseDB (I mean, that’s me!).Bob’s confusion: Do I have to disclose the changes?The answer: No! Since Bob is using it internally, within his organization, he is not distributing it to other people. Such copies of modified AGPL software, can be kept, without disclosing changes.
鲍勃办公室的人们喜欢TerrabaseDB的修改版,他们想在工作场所中使用它。 鲍勃的同工还向TerrabaseDB添加了一些身份验证功能,以使工作场所用户能够对自己进行身份验证。 但是将这段代码提供给TerrabaseDB的作者并不安全(我的意思是,就是我!)。 鲍勃的困惑:我是否必须披露更改? 答案:不! 由于Bob在组织内部内部使用它,因此他没有将其分发给其他人。 可以保留经过修改的AGPL软件的此类副本,而无需透露更改。
If you followed this example well enough — you can clearly see that the AGPL doesn’t really bother with your app, or service which uses the AGPL binary as a backend, but instead, cares about what you do with the the AGPL licensed binary.
如果您很好地遵循了此示例,则可以清楚地看到AGPL并没有真正打扰您的应用程序或使用AGPL二进制文件作为后端的服务,而是关心您使用AGPL许可的二进制文件的工作。
结论 (Conclusion)
To put it in one simple line — if you use an AGPL licensed binary “as-is”, without any modification, then you don’t have to think much — just work on your stuff man! But, if you make changes to the AGPL code, and distribute it — then you’ll have to submit the changes back to the original project, to remain legally correct. Now before you blow up the comment section — here’s one thing: this is not legal advice in any way! Feel free to correct me if I happen to have mislead you (and myself), somewhere.
简而言之-如果您使用AGPL许可的二进制文件“按原样”,而无需进行任何修改,那么您就不必花太多时间了-只需在您的随身物品上工作即可! 但是,如果您对AGPL代码进行了更改并分发了它-那么您必须将更改提交回原始项目,以保持法律上的正确性。 现在,在删除注释部分之前,这是一件事:这绝对不是法律建议! 如果我在某个地方误导了您(和我自己),请随时纠正我。
Interesting reads
有趣的读物
Lack of leadership in open source results in source-available licenses
If you like what you just read, consider giving a 👋🏻 and sharing this article! Also, do take a look at TerrabaseDB on GitHub!
如果您喜欢刚刚阅读的内容,请考虑给👋🏻并分享这篇文章! 另外,请查看GitHub上的TerrabaseDB !
翻译自: https://medium.com/swlh/understanding-the-agpl-the-most-misunderstood-license-86fd1fe91275
agpl许可证