Website Migration Notice: SafePoint is now operated by CyberServal.Learn more →
DiscussionSLA

[Suggestion] SafeLine 项目声称采用 GPL-3.0 许可证,但在实际发布中存在违反 GPL-3 许可证条款的情况

Published a month ago

# Github Issue

Published a month ago

profile_photo

lishiyucn

Updated a month ago

0

What would you like to be added or improved?

问题描述

SafeLine 项目声称采用 GPL-3.0 许可证,但在实际发布中存在违反 GPL-3 许可证条款的情况。具体表现为:

  1. 缺失源代码:二进制发行版中包含的部分功能在源代码仓库中不存在对应实现
  2. 专有组件依赖:核心功能依赖未开源的专有库(libfvm.so、libct)
  3. 不完整的"对应源代码":违反 GPL-3 第 1 条关于"对应源代码"(Corresponding Source)的定义

具体证据

1. Open API 端点缺失源代码

management/webserver/main.go 中注册了以下 Open API 端点:

1// Open API endpoints
2publicRouters.GET(api.OpenHealth, api.GetOpenHealth)
3publicRouters.POST(api.OpenTrack, api.PostOpenTrack)
4publicRouters.GET(api.OpenSystemAssets, api.GetOpenSystemAssets)
5publicRouters.GET(api.OpenSystemArch, api.GetOpenSystemArch)
6publicRouters.POST(api.OpenBehaviour, api.PostOpenBehaviour)
7publicRouters.GET(api.OpenAuthCSRF, api.GetOpenAuthCSRF)

但是,这些端点的实现文件 management/webserver/api/open.go 在官方 GitHub 仓库中不存在

2. 专有库依赖

按照项目文档编译源码发现:

webserver 需要 FVM C 库(libfvm.solibct)用于规则编译 - 这些是专有组件

这些库的源代码未在仓库中提供,导致:

  • 无法从源代码完整构建可工作的系统
  • 核心检测功能依赖闭源组件
  • 违反 GPL-3 对"对应源代码"的要求

3. 编译失败验证

尝试从源代码编译完整系统时,会遇到以下问题:

  • 缺少 api/open.go 导致编译错误
  • 即使手动补充缺失文件,运行时会因缺少 libfvm.so 而崩溃(Segmentation fault)
  • 无法生成与二进制发行版功能等同的可执行文件

GPL-3 许可证条款分析

违反条款

GPL-3 第 1 条 - "对应源代码"定义

"对应源代码"是指生成、安装和(对于可执行作品)运行目标代码所需的所有源代码,包括控制这些活动的脚本。

SafeLine 的二进制发行版包含的功能(Open API 端点、FVM 库)无法通过仓库中的源代码重现,违反了此条款。

GPL-3 第 6 条 - 传递非源代码形式的要求

当您以目标代码形式传递受保护作品时,您必须同时提供对应的源代码。

SafeLine 通过 Docker Hub 分发二进制镜像,但未提供完整的对应源代码。

影响

这种不合规行为导致:

  1. 用户权利受损:用户无法行使 GPL-3 赋予的修改和重新分发权利
  2. 社区贡献受阻:开发者无法基于完整源代码进行二次开发
  3. 许可证欺诈风险:声称 GPL-3 但实际为"开放核心"(Open Core)模式
  4. 法律风险:可能面临 GPL 执行组织(如 Software Freedom Conservancy)的法律行动

建议的补救措施

为恢复 GPL-3 合规性,建议采取以下措施之一:

方案 1:完整开源(推荐)

  • 在仓库中补充所有缺失的源代码文件(如 api/open.go
  • 开源 FVM 相关库(libfvm.so、libct)的源代码
  • 确保用户可以从源代码完整构建功能等同的系统

方案 2:许可证变更

如果无法开源所有组件,应:

  • 将许可证更改为更宽松的许可证(如 Apache 2.0 或专有许可证)
  • 明确标注哪些组件是专有的
  • 停止声称整个项目为 GPL-3

方案 3:架构重构

  • 将专有组件与 GPL-3 组件分离
  • 使用插件架构或 AGPL 例外条款
  • 确保 GPL-3 部分可独立构建和运行

时间线

  • 发现日期:2026-04-12
  • 验证方法
    1. 克隆官方仓库
    2. 检查 management/webserver/api/ 目录
    3. 尝试编译并运行
    4. 对比二进制发行版功能

参考资料

请求

请项目维护者:

  1. 确认此问题
  2. 提供补救时间表
  3. 说明是否有计划完整开源或变更许可证

如果此问题在合理时间内(建议 30 天)未得到解决,我们可能需要:

  • 在社区论坛公开讨论此合规性问题
  • 联系 Software Freedom Conservancy 或 Free Software Foundation
  • 考虑创建完全合规的社区分支

Why is it needed?

这种不合规行为导致:

  1. 用户权利受损:用户无法行使 GPL-3 赋予的修改和重新分发权利
  2. 社区贡献受阻:开发者无法基于完整源代码进行二次开发
  3. 许可证欺诈风险:声称 GPL-3 但实际为"开放核心"(Open Core)模式
  4. 法律风险:可能面临 GPL 执行组织(如 Software Freedom Conservancy)的法律行动
profile_photo

SenyFish

Updated a month ago

0

这都是国内企业玩剩下的