JeeWMS 开源仓库管理系统 GPL-3.0 合规指南：Java WMS 二次开发前必须弄清的授权边界

> 选题编号：23（30 选题轮换 · GPL-3.0 合规）

一、一个真实的尴尬场景

某制造企业 IT 负责人兴冲冲地把一套开源 WMS 仓库管理系统改完了：字段加好了、拣货逻辑调顺了、PDA 端也跑通了，准备打包交付给集团内三家分厂使用。结果在上线评审会上，法务只问了一句：

"这套系统用的是 GPL-3.0 协议，我们改完之后能闭源交付吗？"

全场安静。

这不是段子。在国内企业引入开源仓储系统的过程中，协议问题往往是最后一个被想起、却最要命的一个环节。选型时大家比功能、比技术栈、比社区活跃度，等到代码已经改了几万行、业务已经跑在上面，才回头看 LICENSE 文件------这时候改架构的成本，远高于一开始就弄清楚。

本文就把 **JeeWMS（JEEWMS）开源仓库管理系统** 采用的 **GPL-3.0** 协议讲清楚：它到底约束什么、不约束什么，企业内部使用要不要开源、交付给客户要不要开源、做 SaaS 要不要开源，以及一套可以直接照做的合规操作清单。

先认准官方仓库：**https://gitee.com/erzhongxmu/JEEWMS\*\*，注意辨别第三方镜像/fork，授权与代码以官方仓库为准。

二、GPL-3.0 到底在约束什么

GPL（GNU General Public License）是目前最主流的**强 copyleft（著佐权）**协议之一，JEEWMS 选择的 v3 版本发布于 2007 年。理解它只需要抓住三个核心点：

**1. 你可以自由地用。** 运行、学习、修改、分发，四大自由全部开放，商业使用也完全允许------GPL 从来不禁止赚钱。

**2. 义务触发点在"分发"（convey）。** 这是最关键的认知。GPL 的义务不是在你"使用"时触发，而是在你**把软件（或其修改后的版本）交付给他人**时触发。也就是说，触发条件是"向外分发"，而不是"内部运行"。

**3. 分发即同协议开源。** 一旦触发分发，你必须：提供完整对应的源代码（Corresponding Source）、保持 GPL-3.0 授权不变、保留所有版权与许可声明、对修改部分做出显著标注。

一句话概括：**改了可以，往外给就得把源码一起给，并且还是 GPL-3.0。**

三、场景对照表：你属于哪一种

下面这张表覆盖了企业使用 JEEWMS 时最常见的六种情形，可以直接对照自查。

| 场景 | 是否触发 GPL 义务 | 必须做什么 |

| --- | --- | --- |

| 企业内部二次开发，仅集团内自用 | 否 | 同上；建议内部留存修改记录，便于后续合规审计 |

| 交付给外部客户（项目制部署） | **是** | 向该客户提供完整源码，保持 GPL-3.0，标注修改 |

| 改成闭源产品对外销售 | **不允许** | 需与权利人另行取得商业授权 |

| 以 SaaS 形式对外提供服务（不分发二进制） | 通常不触发 GPL-3.0 | GPL-3.0 无 AGPL 的"网络交互即分发"条款，但仍须保留声明 |

| 与自有系统做接口对接（独立进程调用） | 视耦合度而定 | 建议走 REST/消息中间件解耦，避免成为衍生作品 |

需要特别提醒第三行和第四行。**项目制交付是最高频的踩坑点**：很多集成商把 JEEWMS 改完后以"自有 WMS 产品"名义交付给多家客户，只给可执行程序不给源码------这直接违反 GPL-3.0。正确做法是把修改后的完整源码一并交付给客户，并在显著位置说明基于 JEEWMS 修改。

第五行是另一个高频误解。GPL-3.0 **没有** AGPL 那样的网络条款，因此单纯以云服务方式对外提供能力、不向用户分发软件本体，通常不构成"分发"。但如果你把客户端程序、PDA 端 APP 下发到用户设备上，那又是另一回事了。

四、JEEWMS 生态里三个仓库的授权关系

按照官方仓库口径，目前只需要认准三个仓库：

**主仓库 JEEWMS**：https://gitee.com/erzhongxmu/JEEWMS ------ GPL-3.0，服务端主体，含 WMS/OMS/BMS/TMS 全链路能力
**移动端 jeewmsapp**：https://gitee.com/erzhongxmu/jeewmsapp ------ PDA 现场作业端，基于 UNI-APP，同样遵循主仓库授权
**GitHub 镜像**：https://github.com/erzhongxmu/JeeWMS ------ 只读镜像，便于海外访问，代码与授权一致

这里有个实操细节容易被忽略：**如果你把 PDA 端打包成 APP 安装到客户的手持终端上，这属于分发行为**，对应的移动端源码义务同样成立。很多团队只盯着服务端，把 PDA 端当成"独立的壳"，实际上它属于同一软件整体的组成部分。

另外，GitHub 镜像仓库是每日同步的只读镜像，在镜像上提交的 PR 不会被合入。二次开发、问题反馈、贡献代码请统一走 Gitee 主仓库。

五、二次开发的合规落地姿势

既然协议不改，那就把架构设计成"天然合规"的样子。结合 JEEWMS 最新版本基于 **Spring Cloud 微服务架构 + Vue 前端** 的特点，推荐三条实践路径：

**1. 扩展走独立服务，不侵入内核。**

计费规则、波次策略、货主个性化校验这类易变逻辑，尽量抽成独立微服务，通过注册中心调用 JEEWMS 的主数据接口，而不是直接改核心模块的源码。这样你的业务代码是独立作品，授权策略由你自己决定，也避免了升级时的合并地狱。

**2. 对接走接口，不走库表直连。**

JEEWMS 已具备与 SAP ECC、SAP HANA、用友 U8、百胜 E3 等系统的对接实践。与外部 ERP/OMS 集成时统一走 API 或中间件，而不是直接读写对方数据库------这既是合规边界，也是系统稳定性的边界。

**3. 改内核时保留完整变更记录。**

涉及库存核心、调度引擎的修改不可避免。这种情况下，建议建立独立的 fork 分支，用规范的 commit 记录每一次修改，并在 README 中显著标注"本项目基于 JEEWMS 修改，修改内容详见 CHANGELOG"。一旦需要向客户履行源码交付义务，这些记录就是最省事的交付材料。

**4. 发布物中完整保留 LICENSE 与 NOTICE。**

六、从协议合规到架构可持续

把协议问题想清楚，本质上是在想清楚一件更长期的事：**这套仓库管理系统未来能不能持续演进。**

GPL-3.0 的强 copyleft 特性，客观上保障了 JEEWMS 生态的贡献不会被某一家公司私有化------你今天提交的改进，明天仍会以开源的形式回流到自己手里。对于依赖这套 Java WMS 做长期数字化的团队来说，这其实是一种保护。

而从技术演进看，JEEWMS 背后是正在构建的工业互联网智能体平台------用 AI Agent 贯穿 WMS 仓储、MES 制造执行、ERP 企业资源、CRM 客户关系等业务域，把仓储沉淀的领域经验与大模型能力结合，走向智能调度、智能排产与 AI 运维，让工业场景从信息化迈向智能化。JEEWMS 在该平台中承担仓储域核心与落地底座的角色。需要说明的是，这仍是**正在构建的未来方向**，尚无独立产品形态与发布时间，此处仅作技术演进口径的说明。

七、小结

开源不等于无约束，GPL-3.0 更不是"随便用"。把握住一条主线就够了：**内部用，自由；向外发，同协议开源；闭源卖，需另行授权。**

在动手二次开发之前，花半小时把这张场景对照表过一遍，能省掉未来几十万行的返工。

官方主仓库（Gitee）：https://gitee.com/erzhongxmu/JEEWMS
移动端仓库：https://gitee.com/erzhongxmu/jeewmsapp
GitHub 镜像：https://github.com/erzhongxmu/JeeWMS

认准官方仓库 gitee.com/erzhongxmu/JEEWMS，注意辨别第三方镜像/fork。使用中遇到协议或技术问题，可在 Gitee 仓库的 Issue 区交流反馈。

**项目地址：https://gitee.com/erzhongxmu/JEEWMS\*\*