我们都知道,AGPL 是有“传染性”的许可证。简单来说,如果你使用了 AGPL 许可的软件,你的软件也必须采用 AGPL 许可证,这就是大家普遍担心的问题所在。 接下来让我们看看,AGPL或者SSPL是如何传染的。AGPL 或者 SSPL 的特点既然提到了 AGPL 和 SSPL 的传染性,让我们深入了解一下这两种协议的特点,以及它们对开发者和企业的影响。 因此,如果你的应用同时使用了 Apache 2.0 和 AGPL 许可证的库,由于 AGPL 是更严格的许可证,你的应用可能会被要求遵守 AGPL 的开源要求。 关键点:AGPL:如果你使用 AGPL 许可的代码提供网络服务,哪怕你没有修改或嵌入代码,也必须公开该服务使用的 AGPL 代码的源代码。 AGPL 和 SSPL 的细微区别尽管 AGPL 和 SSPL 都属于传染性许可证,它们在传染性范围和适用场景上有所不同:AGPL:要求你在通过网络提供服务时,公开应用中所使用的 AGPL 许可代码的源代码
目录 一、AGPL3.0开源协议简介 二、为什么需要闭源授权费 三、Fastbee的开源策略 四、长远发展规划 五、取得授权者将得到更多权益 六、常见问题 6.1 减少授权费用的技巧? 6.4 个人开发者 七、总结 一、AGPL3.0开源协议简介 AGPL3.0是基于GPL3.0进行的扩展,目的是强化“网络服务使用”条款。 AGPL3.0的“网络服务使用”条款规定,如果你使用一份AGPL3.0许可协议的代码部署到服务器上,提供公共网络服务访问,并向公众使用,则你必须公开其源代码。 这样,AGPL3.0保证了代码的开源性,更能适应现代服务产业的需求。 MzMedia 使用的 AGPL3.0 开源协议的开源框架,如果你的产品是打算开源的,使用 AGPL3.0 时无须购买授权。但如果你的产品不打算开源的(就是源代码不对外开放),就需要购买闭源授权。
http://ewen0930.github.io/2016/11/open-source-licenses/ 几种开源协议的比较(BSD,Apache,GPL,LGPL,AGPL,MIT) – 整理 GPL/LGPL都保障原作者的知识产权,避免有人利用开源代码复制并开发类似的产品 AGPL 协议(Affero General Public License) GPL(2.x ~ 3.x) 协议还有一个非常大的 随着以Google为代表的软件作为服务的互联网公司的兴起,它们的“不分发软件,为客户提供网络服务”的商业模式就不受GPL协议的约束 AGPL则增加了对此做法的约束: AGPL = GPL + 一条限制 一条限制:如果使用AGPL许可的软件与用户通过网络进行交互,也需要提供源代码给用户,所有的修改也要给用户。 MPL第二版与Apache许可证以及GPL第二版或更新、LGPL2.1版或更新,及AGPL第三版或更新兼容。而1.1版因为有“一些复杂的限制”造成与GPL的不兼容(从而阻止升级到MPL 2.0)。
核子可乐 近日,Grafana Labs 宣布旗下核心开源项目许可证的重大变更: Grafana、Grafana Loki 和 Grafana Tempo 从 Apache License 2.0 转为 AGPL 但根据 AGPL 的许可,如果用户决定修改项目代码以供某方使用,则必须同时共享新的源代码(通过发行版或经由网络共享)。 ? 根据维基百科解释,AGPL v3 全称是 GNU Affero 通用公共许可协议,是一个广泛被使用的自由软件许可协议,最初由 Affero,Inc 撰写。此许可协议最新版本为“第 3 版(v3)”。 而 AGPL 是改自 GNU 通用公共许可协议,并加入额外条款。
基于AGPL-3.0协议的AI驱动开源知识库,凭借轻量化部署、全链路智能能力与高扩展性,在技术文档管理、企业知识沉淀、跨端协同等场景中展现出独特的技术价值。 在协议与开源设计上,系统采用AGPL-3.0协议,这一设计既保障了开源社区的协作性,也对商业使用提出了明确约束——修改后的代码需以相同协议开源,通过网络提供服务时也需公开代码,这一特性使其更适合企业内部使用或开源生态下的二次开发 (4)AGPL-3.0协议需重点关注,规避合规风险在商业场景使用时,需严格遵守AGPL-3.0协议的要求:若仅在企业内部使用,无需公开修改后的代码;若通过网络向外部用户提供服务,则必须将修改后的代码以相同协议开源
于是 2007 年,AGPL v3 出来了,专门堵这个漏洞。 AGPL 的核心要求 AGPL 的核心就一句话:通过网络提供服务,也算分发,也得开源。 GPL 只在你分发软件的时候要求开源,AGPL 是你提供服务就要求开源。 AGPL 的传染性 跟 GPL 一样,AGPL 也有传染性。而且更强。 这些项目为什么要用 AGPL? 案例一:某公司用 AGPL 组件做内部工具 有个公司,运维团队用了一个 AGPL 的监控组件,部署在内网。后来法务审核,发现这个组件是 AGPL 的。 内部工具要不要开源? 案例二:云厂商和 AGPL AWS、Google Cloud 这些大厂,对 AGPL 很谨慎。一般禁止在云服务中使用 AGPL 的代码。 为什么?因为一旦用了,可能就得把整个服务栈开源。
被告认为,对 Neo4j 瑞典软件许可证有一个合理的解释,即允许被许可人,如 GFI 或被告,删除 Commons 条款,并根据标准化的 AGPL 许可证重新发布软件。反方动议在 27-30 页。 在这起诉讼中,ONgDB 不是“自由和开放源码”,因为 PureThink 从 AGPL 中删除了 Commons 条款。想想这个问题。请看第 23 页开始的“虚假声明”部分。 他们希望看到法院认定 Neo4j 的发布不是开源的,因为他们在 AGPL 中加入了 Commons 条款。 他们得到的是一个法院说,从 AGPL 中拿走 Commons 条款使得关于开源的说法成为虚假的说法。 这里真正的标题是“联邦法院认为 AGPL 加上共享条款是开放源码”吗?见鬼,不是。法院的语言并没有对“开源”在全球范围内的含义做出任何决定。它只是回顾了这起诉讼中各方所接受的事实框架。
此前,MongoDB 采用 GNU AGPLv3 (AGPL),该许可协议要求任何想要修改且将 MongoDB 作为公共服务运行的公司都必须将他们的软件开源,或需要从 MongoDB 获得商业许可。 服务器端公共许可(SSPL)以 AGPL 为核心,但澄清了以服务形式提供开源软件的条件。 服务器端公共许可(SSPL)保留了原 AGPL 协议下对开源社区一致的自由权利:软件的自由使用、审查、修改以及重新发布代码。 从AGPL 到服务器端公共许可(SSPL)协议的更改,不影响已经购买 MongoDB 商业许可的客户。
此前,MongoDB 采用 GNU AGPLv3 (AGPL),该许可协议要求任何想要修改且将 MongoDB 作为公共服务运行的公司都必须将他们的软件开源,或需要从 MongoDB 获得商业许可。 服务器端公共许可(SSPL)以 AGPL 为核心,但澄清了以服务形式提供开源软件的条件。 服务器端公共许可(SSPL)保留了原 AGPL 协议下对开源社区一致的自由权利:软件的自由使用、审查、修改以及重新发布代码。 从AGPL 到服务器端公共许可(SSPL)协议的更改,不影响已经购买 MongoDB 商业许可的客户。
Affero GNU 通用公共许可证(AGPL) a. 背景与历史 Affero GNU 通用公共许可证(AGPL)是 GPL 的扩展版本,专为网络应用设计。 AGPL 增加了一项关键条款,要求在网络上提供服务的应用必须公开其源代码。 b. 核心条款 Copyleft 条款:AGPL 保持了 GPL 的 Copyleft 条款,要求所有衍生作品以相同的许可证发布。 网络分发:AGPL 规定,任何通过网络分发的应用必须公开其源代码,确保用户可以访问和修改代码。 专利授权:AGPL 也包含了专利授权条款,保护用户免受专利诉讼。 c. 优势与挑战 优势:AGPL 确保了代码在云环境中的自由性,防止了代码被专有化。 挑战:AGPL 的严格要求可能会限制一些企业对开源代码的使用,尤其是在商业 SaaS 应用中。 9.
AGPL,使用传染(使用了,无论怎么使用都传染)。如果自己软件本身是服务类软件,又想保持软件自由,用这个。 企业内部的项目中引用了使用AGPL许可的软件,需要公开源代码么? - 坚果囊地鼠的回答 - 知乎 注:本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。
协议说明1、Affero GPL (AGPL) 如果云服务(即 SAAS)用到的代码是该许可证,那么云服务的代码也必须开源。 2、AGPL 是 GPL 的扩展,包括对与软件交互的用户的附加要求 通过网络软件。 这些用户还必须共享他们的源代码和他们对软件所做的任何更改。 这意味着如果您使用 AGPL 许可的程序并在您的服务器上运行它并通过网络将其提供给其他人,您还必须 这些用户可用的源代码。 这在 GPL 下不是必需的。 简而言之,AGPL 是比 GPL 更严格的许可,因为它要求用户在通过网络使用软件时共享他们的源代码。 这个是官方修改开源协议(从 AGPL 到 SSPL,基于修改协议前的最后一个稳定版本4.0.3),存在较大争议,开放源代码促进会 OSI 甚至认为 SSPL 就不是开源许可协议。
新开源许可证遵循 OSI 批准的两个许可证之一:AGPL 和 Apache 2.0 许可。 以前闭源项目将在 2019 年 9 月至 2020 年 1 月期间变更为 AGPL 许可模式。 Cloudera 的改变: 昨天,Cloudera 首席产品官 Arun Murthy 和产品和事业部总经理 Charles Zedlewski 联合发文,宣布计划全部产品更改为 AGPL 和 Apache 2.我们所有的开源许可证都将遵循两个OSI批准的许可证之一:Apache许可证第2版或GNU Affero通用公共许可证第3版(“AGPL”)。 从2019年9月到2020年1月,我们将为以前闭源组件建立新的开源项目,并开始执行AGPL许可。
前言 今天大姚给大家分享一款基于 .NET8 + Vue 开源、免费(AGPL-3.0开源协议)、跨平台的企业级在线考试系统:XBLMS。 项目介绍 XBLMS是一款基于 .NET8 + Vue 开源、免费(AGPL-3.0开源协议)、跨平台的企业级在线考试系统,系统支持多种数据库系统,包括人大金仓、达梦、OceanBase、MySql、SqlServer
以AGPL-3.0协议开源的AI知识库系统,依托富文本编辑、多源内容导入、第三方集成与AI增强能力,可快速搭建产品手册、技术文档、FAQ与博客等知识载体,兼顾部署灵活性与数据可控性。 开源协议与合规边界开源项目采用AGPL-3.0开源协议,核心规则如下:• 可自由使用、修改、分发软件;• 修改版本需以相同协议开源;• 以网络服务形式提供时,需公开对应修改代码;• 企业内部非对外服务场景 核心优势• 开源可控:AGPL-3.0协议清晰,内部部署无版权风险,可按需二次开发;• 上手成本低:部署流程简洁,编辑体验接近主流文档工具,学习成本低;• 导入能力强:多源导入大幅降低冷启动门槛,适配存量系统迁移 优先私有化部署,保障敏感知识安全;• 先迁移高频文档,再逐步扩展,避免一次性全量导入导致维护困难;• 对接内部大模型,降低API依赖与数据外泄风险;• 配合IM机器人使用,提升使用率与员工接受度;• 严格遵循AGPL 其富文本、多源导入、第三方集成能力解决传统文档管理痛点,AI能力提升检索与创作效率,AGPL-3.0协议为商业化与内部使用提供明确合规路径。
还有个是AGPL,它可以说是专门针对云服务提供商制定的,一般来说,我们修改了开源软件并且再次分发出来的时候才会受许可证的限制,如果是我们自己内部使用则不受限制。 但是AGPL则要求即使是自己使用开源软件,但如果用来提供云服务,那么我们的云服务的代码也必须全部免费开源。所以云服务提供商要慎重选择AGPL许可的软件,避免不必要的麻烦。 常用的开源许可证介绍完了。 我们来总结一下,首先从版权的角度来说,所有许可证都要求附上许可证和版权声明,其次,除了MIT和BSD,其他许可证都要求我们写代码要有注释,最后GPL/LGPL/AGPL具备开源传染性,不允许闭源,MIT 最后,我把各许可证的风险做了分级,AGPL,GPL风险最高, 使用这些许可证的开源软件要特别小心,要注意不要违反Copyleft开源传染性的规定。
Affero通用公共许可证(Affero General Public License, AGPL) 优点 类似于GPL。 局限性 增加了对通过网络提供软件服务的使用方式的监管。 # 一个简单的 AGPL 许可证代码示例 print("Hello, AGPL!") 可能对代码的再分发附带限制 保留版权、许可证声明 MPL 修改后的代码必须以MPL发布 修改的代码部分必须开源 EPL 衍生作品也必须采用EPL 修改后的代码也必须开源 LGPL 修改的库代码必须开源 修改的库代码必须开源 AGPL
一、定位:开源知识库的核心价值与使用边界开源知识库系统基于大模型能力构建,以AGPL-3.0协议开源,定位清晰——面向技术团队、产品部门与运维场景,打造轻量化、可扩展、可私有化的知识管理,核心承载多形态内容的托管 ,为技术落地与场景适配奠定基础:• 架构原则:前后端分离、容器化部署、模型可插拔,兼顾开箱即用与二次扩展;• 能力原则:以“基础管理+AI赋能+多端集成”为核心,覆盖知识全生命周期;• 合规原则:基于AGPL (五)合规要求:开源协议与使用边界基于AGPL-3.0协议,开源知识库明确合规要求:可自由使用、修改、分发源码;修改版本需以相同协议开源;网络服务形式提供时,服务端代码需开源;商业使用需遵守Copyleft (三)二次开发:合规前提下的扩展升级二次开发建议:前端扩展自定义字段与审批流,后端增强权限与加密功能;严格遵循AGPL-3.0协议,修改版本需开源,做好合规管理。
前言 今天大姚给大家分享一款基于 .NET8 + Vue 开源、免费(AGPL-3.0开源协议)、跨平台的企业级在线考试系统:XBLMS。 项目介绍 XBLMS是一款基于 .NET8 + Vue 开源、免费(AGPL-3.0开源协议)、跨平台的企业级在线考试系统,系统支持多种数据库系统,包括人大金仓、达梦、OceanBase、MySql、SqlServer
时隔一年,Redis 重新开源 Redis 方面表示,自 Redis 8 开始将把 GNU Affero 通用公共许可证(AGPL)作为 Redis 的附加许可选项,且正在转向由开源代码倡议(OSI) 以为为声明原文: 五个月前,我重新加入 Redis 并很快跟同事们讨论起是否该改用 AGPL 许可证。我发现公司内部早就在关注这个问题,不少人都觉得 AGPl 比 SSPl 更好。 我一直在努力为 AGPL 这派的支持者争取更多空间。我个人感觉社区其实并没有真正接受 SSPL。OSI 开源代码倡议不会接受它,软件社区也不会把 SSPL 视为开放许可证。 今天我高兴地看到 Redis 再次回归开源阵营,并且遵循 AGPL v3 许可证。 作为一个真正自由 / 开源软件的贡献者,我感觉自己被背叛了——如果他们当时改用 AGPL,从道德角度来说,我完全可以接受这种调整(顺便一提)。