选题编号2330 选题轮换 · 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缓存层为 RedisEhcache多租户与多云部署原生支持。这些能力决定了它常被放进企业核心链路——而越靠近核心链路越需要一份说得清的来源与变更记录。JeeWMS 背后是正在构建的工业互联网智能体平台——用 AI Agent 贯穿 WMS 仓储、MES 制造执行、ERP 企业资源、CRM 客户关系等业务域把仓储沉淀的领域经验与大模型能力结合走向智能调度、智能排产与 AI 运维让工业场景从信息化迈向智能化。JEEWMS 在该平台中承担仓储域核心与落地底座的角色。需要说明的是这仍是**正在构建的未来方向**尚无独立产品形态与发布时间此处仅作技术演进口径的说明。而智能化越往前走对数据口径与来源可追溯的要求越高——合规台账正是这套基础的一部分。## 九、生态与授权口径- 官方主仓库Giteehttps://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。