> 选题编号：23（30 选题轮换 · GPL-3.0 合规）
## 一、合规问题不是在法务室被问出来的，是在交付现场被问出来的
很多团队第一次被协议"绊住"，不是在选型阶段读 LICENSE，而是在项目交付现场：客户做供应商尽调，要求提交软件物料清单和源码来源说明；集团做信息化审计，要问清这套 Java WMS 仓库管理系统的代码从哪来、改了什么、谁有权再分发；集成商把项目转包给第三方团队后，又发现没人说得清哪几个文件被动过。
JeeWMS 采用 **GPL-3.0** 协议，这不是障碍，但它确实要求你在**每一次把软件交给别人**的时候，能拿出证据链。所以真正的问题不是"能不能用"（能，商用也完全允许），而是"**交付时我拿得出什么**"。
先认准官方仓库：**https://gitee.com/erzhongxmu/JEEWMS**，注意辨别第三方镜像/fork，授权口径与代码均以官方仓库为准。
## 二、先划清边界：义务按"交付动作"触发，不按"使用动作"触发
判断合规风险只需要三个问题：
1. **这套系统有没有离开你的组织？** 只在企业内部部署运行，不触发开源义务；源码交付合同里对方要求"提供你方全部定制源码"另说。
2. **离开的是什么形态？** 部署包、容器镜像、打包后的 PDA 端 APP、数据库脚本、运维交付物，只要送到他人手上，都属于分发。
3. **送出的是不是一个"整体"？** 服务端 + PDA 端 + 你写的扩展服务，如果构成同一软件整体，就一起吃同样的义务，不能只交服务端、把 PDA 端当独立外壳。
最容易踩的坑在第二、三条。很多团队清楚地知道"分发要给源码"，但把 Docker 镜像、初始化脚本、PDA 打包物当成"交付附件"漏掉了，而这些恰恰是尽调时最先被抽查的部分。
## 三、四个节点，四份必须留下的痕迹
合规不是交付前一周补一份文档，而是从立项起就在四个节点各留一次痕迹：
| 节点 | 触发动作 | 应留下的材料 | 常见遗漏 |
| --- | --- | --- | --- |
| 立项选型 | 确定使用 JeeWMS | 官方仓库地址、拉取版本号或提交哈希、LICENSE 原文归档 | 从第三方 fork 拉代码，来源不可追溯 |
| 首次修改 | 第一行业务代码改动 | 独立 fork 分支 + CHANGELOG + 修改范围说明 | 直接在内核上改，无版本对照 |
| 对外交付 | 部署包交给客户 | 完整对应源码 + LICENSE + NOTICE + 构建说明 | 只给可执行程序，或漏交镜像与脚本 |
| 上线运维 | 版本升级、补丁 | 版本台账：每个环境的版本与修改清单对应关系 | 生产已升三个版本，台账停在最初 |
这张表的价值在于：**它是可审计的**。法务或客户尽调要的从来不是你的承诺，而是"能否复现你交付的东西"。
## 四、源码交付包六件套（可直接照做）
一份能被审计、也能被自己复用的交付包，应该包含六件东西：
1. **LICENSE 原文** —— 未修改的 GPL-3.0 全文，放在源码根目录；
2. **NOTICE 与版权声明** —— 保留原版权信息，并显著标注"本项目基于 JEEWMS 修改"；
3. **完整对应源码** —— 修改后的完整源码，而非只交 diff 或只交自定义模块；
4. **CHANGELOG 修改标注** —— 按模块列出改动点与原因，便于对方判断影响面；
5. **可复现构建说明** —— JDK、数据库、缓存、构建命令、初始化脚本执行顺序，缺一项对方就无法验证；
6. **第三方依赖清单** —— 你引入的每一个库及其许可证，这一项后文单独展开。
六件套里最常被省的是第 5、第 6 项。但它们恰好是"交付是否合格"的分水岭：源码给出去但构建不起来，等于没给。
## 五、衍生作品的三条工程划线
协议只给了原则，落地要靠架构。按风险从低到高排三条线：
- **低风险**：独立进程 + 标准接口调用。扩展服务通过 REST 或消息中间件调用 JeeWMS 的主数据与单据接口，不改内核源码。
- **高风险**：同进程内引用内核类库、直接扩展核心模块的类，容易被认定为同一作品。
- **高风险**：绕过接口直连数据库读写业务表。既触碰协议边界，也让升级变成灾难。
所以接口隔离不只是技术品味，它同时是合规策略。四条可执行的隔离原则：**对外只暴露 API；不共享事务；不直连库表；主数据变更通过事件而非双写。** JeeWMS 最新的 **Spring Cloud 微服务架构 + Vue 前端** 形态天然利于这件事——把易变规则（计费策略、波次策略、货主个性化校验）抽成独立服务挂在网关之后，比在内核里加 if 分支更省事，也把授权策略的主动权留在了自己手里。
## 六、第三方依赖与打包物的许可证
两个高频盲区：
**前端与 PDA 端**。Vue 组件库、UNI-APP 的打包产物里会混入其他开源库，每个库都有自己的许可证。PDA 端 APP 一旦安装到客户设备上，属于分发行为，对应的依赖清单与源码义务同样成立。
**许可证兼容性**。GPL-3.0 与 Apache-2.0、MIT、BSD 这类宽松协议兼容，但引入 GPL-2.0-only 或某些带商业限制的 SDK 时可能产生冲突。选之前查一眼许可证，比事后替换一个已经深度使用的 SDK 便宜太多。
## 七、把义务写进合同，别留给口头理解
一个项目通常牵扯四方：开源社区（JeeWMS 官方）、集成商（你）、甲方（业务方）、最终用户（可能是甲方的客户或分厂）。义务链条一旦断开，风险会回流到集成商身上。三条合同层面的动作：
- 外包开发条款中写明"**交付物包含全部修改源码，接受 GPL-3.0 约束**"，不留"技术成果归甲方且闭源"这类与协议冲突的表述；
- 与客户约定交付清单时，把六件套列为验收材料，而不是可选项；
- 升级运维单独约定版本台账的维护责任，避免"上线时合规、两年后说不清"。
## 八、合规之外：这份台账还有第二个用途
同一套台账，在另一件事上会立刻变现：**升级与二次开发**。有 CHANGELOG、有版本对照，从 JeeWMS 新版拉代码合并时你能一眼看出冲突在哪；没有台账，每次升级都是一次考古。
JeeWMS 已具备与 SAP ECC、SAP HANA、用友 U8、百胜 E3 等系统的对接实践，兼容多数据库部署，PDA 端基于 UNI-APP，持久层使用 Hibernate/Minidao，缓存层为 Redis+Ehcache，多租户与多云部署原生支持。这些能力决定了它常被放进企业核心链路——而越靠近核心链路，越需要一份说得清的来源与变更记录。
JeeWMS 背后是正在构建的工业互联网智能体平台——用 AI Agent 贯穿 WMS 仓储、MES 制造执行、ERP 企业资源、CRM 客户关系等业务域，把仓储沉淀的领域经验与大模型能力结合，走向智能调度、智能排产与 AI 运维，让工业场景从信息化迈向智能化。JEEWMS 在该平台中承担仓储域核心与落地底座的角色。需要说明的是，这仍是**正在构建的未来方向**，尚无独立产品形态与发布时间，此处仅作技术演进口径的说明。而智能化越往前走，对数据口径与来源可追溯的要求越高——合规台账正是这套基础的一部分。
## 九、生态与授权口径
- 官方主仓库（Gitee）：https://gitee.com/erzhongxmu/JEEWMS —— GPL-3.0，含 WMS/OMS/BMS/TMS 全链路能力，GVP 认证项目
- 移动端仓库：https://gitee.com/erzhongxmu/jeewmsapp —— PDA 现场作业端，基于 UNI-APP
- GitHub 镜像：https://github.com/erzhongxmu/JeeWMS —— 只读镜像，每日同步，便于海外访问
需要提醒的是：GitHub 镜像为只读覆盖式同步，在镜像上提交的 PR 不会被合入。二次开发、问题反馈与代码贡献请统一走 Gitee 主仓库；社区交流可在 Gitee 仓库的 Issue 区进行。
## 十、小结：合规是交付工程的一部分
三句话记牢：**内部用，自由；往外发，同协议开源并交源码；闭源卖，需另行取得授权。**
但比背结论更重要的，是把它变成流程：立项时记下版本，修改时留好分支，交付时凑齐六件套，运维时维护台账。合规动作做到这个程度，成本其实很低——低到只需要在流程里加四个检查点；而漏掉它的代价，往往是一次交付返工。
**项目地址：https://gitee.com/erzhongxmu/JEEWMS**
认准官方仓库 gitee.com/erzhongxmu/JEEWMS，注意辨别第三方镜像/fork。
