Automatisch 双许可证模型解析:AGPL-3.0 社区版与 Enterprise 版的文件级区分机制

发布时间:2026/9/15 9:54:24
Automatisch 双许可证模型解析:AGPL-3.0 社区版与 Enterprise 版的文件级区分机制 Automatisch 双许可证模型解析AGPL-3.0 社区版与 Enterprise 版的文件级区分机制【免费下载链接】automatischThe open source Zapier alternative. Build workflow automation without spending time and money.项目地址: https://gitcode.com/GitHub_Trending/au/automatischAutomatisch 是一款开源的工作流自动化平台官方定位为 open source Zapier alternative它通过一个单仓库同时承载社区版Community EditionCE与企业版Enterprise EditionEE的全部代码。本文基于仓库内的 许可证文档结合源码、许可文本与文件布局深入解析 Automatisch 的双许可证模型、.ee.文件命名约定的判别规则以及企业许可证在运行时的实际校验机制帮助你准确判断每一份代码的许可归属并合规地进行自托管部署与二次开发。双许可证模型总览一份仓库两套许可Automatisch 的许可结构非常清晰分为两层版本适用许可证适用对象Automatisch Community Edition社区版AGPL-3.0仓库中所有不包含.ee.的文件Automatisch Enterprise Edition企业版Enterprise License仓库中所有文件名包含.ee.的文件LICENSE 文件在仓库根目录以一句话明确了这一规则LICENSE.agpl (AGPL-3.0)applies to all files in this repository, except for files that contain .ee. in their name which are covered byLICENSE.enterprise.也就是说Automatisch 没有采用社区版与商业版各自独立的仓库的传统做法而是维护单一仓库、用文件名标记许可边界。官方在 许可证文档 中给出的理由是单仓库更便于开发协作We maintain a single repository to make development easier。AGPL-3.0面向网络服务场景的 Copyleft 协议LICENSE.agpl 收录的是 GNU Affero General Public License Version 32007 年 11 月 19 日发布它是一份 copyleft著佐权自由软件许可证其关键特点在许可证序言Preamble中有明确表述自由软件承诺保证用户分享与修改软件的自由允许分发副本甚至可以收费、获取源代码、修改软件或在新的自由程序中使用其片段针对网络服务设计的条款普通 GPL 允许把修改后的版本部署在服务器上而不公开源代码而 AGPL 专门弥补了这一漏洞——运营网络服务器并向公众提供修改版服务的运营商必须向该服务器的用户提供修改版的源代码。对于像 Automatisch 这样典型的服务器端软件 Web 界面形态AGPL 意味着如果你在自托管时修改了社区版代码并对外提供服务需要将修改后的源代码开放给服务用户。这是选择 AGPL-3.0 作为社区版许可的核心考量。Enterprise License按用户席位授权的商业许可LICENSE.enterprise 是一份面向 AB Software GmbH版权声明为 Copyright (c) 2023-present AB Software GmbH商业客户的授权协议核心条款包括生产环境使用需付费授权软件及相关文档仅在你的 Automatisch Enterprise 许可覆盖正确数量的用户席位user seats时才可用于生产环境允许修改与补丁发布在上述前提下你可以自由修改软件并发布补丁Automatisch 及其许可方保留对这些修改与补丁的所有权利、所有权和利益开发与测试免费不要求订阅的情况下你可以出于开发和测试目的复制与修改软件但不授予其他任何权利明确禁止的行为未经授权不得复制、合并、发布、分发、再许可或出售软件免责声明软件按 AS IS 提供不附带任何明示或暗示的保证作者与版权持有人不对任何损害承担责任。从这些条款可以看出Enterprise 许可的商业边界与用户席位数量直接挂钩与社区版免费开源的定位形成互补。.ee.文件命名约定许可归属的唯一判别标准双许可证模型落到工程实践上就是一套简单而机械的文件命名规则所有文件名中包含.ee.的文件属于 Enterprise License其余所有文件属于 AGPL-3.0。这一规则在仓库中得到了非常一致的贯彻。例如在 packages/backend/src 与 packages/web/src 中随处可见后端packages/backend/src/helpers/license.ee.js、packages/backend/src/serializers/saml-auth-provider.ee.js、packages/backend/src/models/subscription.ee.js、packages/backend/src/workers/delete-user.ee.js、packages/backend/src/apps/forms/actions/index.ee.js等前端packages/web/src/components/SsoProviders/index.ee.jsx、packages/web/src/components/UpgradeFreeTrial/index.ee.jsx、packages/web/src/components/SubscriptionCancelledAlert/index.ee.jsx、packages/web/src/components/AdminGuard/index.ee.jsx等。粗略统计仓库 packages 目录下包含.ee.的文件数量达到数百个量级约 460涵盖了订阅计费、SSO/SAML、角色权限、模板、Agent、MCP 服务器、表单等企业级功能模块。从命名规律可以推断凡涉及商业订阅、单点登录、多租户管理、席位/权限控制等高价值能力几乎都落在.ee.企业版一侧。这种约定带来的直接好处是贡献者与审查者一眼即可判断文件许可降低混用风险工具的 glob 匹配如**/*.ee.js可以精确圈定企业版代码范围便于做许可审计仓库的package.json如 packages/backend/package.json、packages/web/package.json、packages/docs/package.json统一将license字段声明为See LICENSE file把许可细节指向根目录的三份许可证文件避免重复冗余。源码级验证企业许可证在运行时如何生效双许可证不只是文档层面的声明企业版功能的启用与否在源码中有完整的运行时校验链路。1. 许可证密钥从环境变量注入后端配置在 packages/backend/src/config/app.js 中读取环境变量licenseKey: process.env.LICENSE_KEY,即通过设置LICENSE_KEY环境变量即可为部署实例注入企业许可证密钥例如在 docker-compose 或部署平台的环境变量区配置。2. 许可证校验与 24 小时缓存企业许可证的核验逻辑实现在 packages/backend/src/helpers/license.ee.js注意该文件本身即.ee.文件属于 Enterprise License 覆盖范围请求地址为https://license.automatisch.io/api/v1/licenses/verify通过axios向该接口POST { licenseKey }完成在线校验校验成功后结果通过memoryCache缓存24 小时CACHE_DURATION 1000 * 60 * 60 * 24避免频繁的网络请求若未配置licenseKey或校验请求失败getLicense()返回falsehasValidLicense()随之返回false。const getLicense async () { const licenseKey appConfig.licenseKey; if (!licenseKey) { return false; } const url AUTOMATISCH_LICENSE_VERIFY_URL; const cachedResponse memoryCache.get(url); if (cachedResponse) { return cachedResponse; } else { try { const { data } await axios.post(url, { licenseKey }); memoryCache.put(url, data, CACHE_DURATION); return data; } catch (error) { return false; } } };3. 企业能力路由的中断保护校验结果被 packages/backend/src/helpers/check-is-enterprise.js 封装为 Express 中间件当hasValidLicense()通过时放行请求否则直接返回404结束响应——即企业版 API 对无许可实例表现为不存在从行为上保护了商业功能边界import { hasValidLicense } from /helpers/license.ee.js; export const checkIsEnterprise async (request, response, next) { if (await hasValidLicense()) { next(); } else { return response.status(404).end(); } };从这套调用链app.js配置读取 →license.ee.js在线核验与缓存 →check-is-enterprise.js中间件拦截可以看出是否持有有效 Enterprise 许可证直接决定企业版 API 是否可用与 LICENSE.enterprise 中按用户席位授权的商业约定形成了代码与法务的一致闭环。实操指南如何识别、部署与合规使用判别文件许可归属在克隆仓库、阅读源码或准备二次开发时只需一条规则查看文件路径若文件名含目录名层级中出现.ee.如models/subscription.ee.js、helpers/license.ee.js则该文件受 Enterprise License 约束其余所有文件含根目录 LICENSE、README.md、docs 文档等默认受 AGPL-3.0 约束。举例packages/backend/src/serializers/admin/api-token.ee.js属于企业版而packages/backend/src/serializers/user.js属于社区版两者处于同一目录、服务于同一功能域却分别受不同许可管辖——这是单仓库双许可证模型最典型的形态。自托管与二次开发的合规要点社区版自托管仅使用非.ee.文件、不修改源码对外提供服务时AGPL 允许自由使用若修改了社区版代码并部署为对外可访问的网络服务需要注意 AGPL 要求向服务用户提供修改版源代码企业版功能如需在生产环境使用.ee.文件对应的功能SSO、订阅管理、席位/角色体系等需要获得与用户席位数量匹配的 Automatisch Enterprise 订阅并通过LICENSE_KEY环境变量激活未激活时企业版 API 会以 404 形式对前端隐藏详见上文check-is-enterprise.js逻辑开发与测试按照 LICENSE.enterprise 的条款出于开发、测试目的复制和修改企业版代码无需订阅但此类修改的权益仍归 Automatisch 及其许可方所有且不得用于生产分发发布补丁持有有效订阅时允许修改企业版软件并发布补丁但所有修改与补丁的所有权归属于 Automatisch。许可证文件速查表文件内容适用对象LICENSE一句话指明双许可的判别规则.ee.命名约定全仓库LICENSE.agplGNU AGPL v3 全文非.ee.文件LICENSE.enterpriseAutomatisch Enterprise LicenseAB Software GmbH2023-present所有.ee.文件结语Automatisch 以单仓库 .ee.文件名约定实现了社区版与商业版代码的优雅共存法律层面AGPL-3.0 保障了社区版的自由与开放Enterprise License 则按用户席位保护商业价值工程层面运行时通过LICENSE_KEY→license.ee.js在线校验 →check-is-enterprise.js中间件这一链路将许可状态落地为可观测的系统行为。无论是评估自托管方案、计划二次开发还是审计代码许可合规性只要把握住看文件名是否含.ee.这一核心规则再结合本文梳理的校验机制就能准确、合规地使用 Automatisch 的全部能力。【免费下载链接】automatischThe open source Zapier alternative. Build workflow automation without spending time and money.项目地址: https://gitcode.com/GitHub_Trending/au/automatisch创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考