V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
liyafe1997
V2EX  ›  开源软件

似乎 GPL 有法律上的漏洞能“限制”源码和 Binary 被公开,传播和使用

  •  1
     
  •   liyafe1997 · 2024-05-29 18:25:05 +08:00 · 1760 次点击
    这是一个创建于 385 天前的主题,其中的信息可能已经有所发展或是发生改变。

    设想一个场景,你开一家公司,通过销售二次开发/魔改 GPL 产品来盈利,比如 Linux ,MySQL 等等。你不希望你的产品及源码被客户二次分发,也不希望你的产品被“非授权”使用。但是根据 GPL 协议,你必须向得到了 Binary 的客户提供源码,同时根据 GPL 协议,你的客户有权二次分发和传播 Binary 和源码。

    但 GPL 管不了 GPL 以外的其它协议/合同,因此在向客户提供产品之间,完全可以签订另一个协议:虽然根据 GPL 协议你有权二次分发 binary 和源码,你可以这么做,但是一旦你行使这项 GPL 权利,我们的所有合作就此终止,以后不再提供产品和更新及其源码,并且不退款,并且不再合作,说白就是撕破脸。

    这样使得客户“不敢”去公开/二次分发你的源码以及 binary ,或者说能开,但只能开一次。然后实际上你就能光明正大的“销售”GPL 产品了,并且这份源码(包括产品 binary 本身)并不会真正的被公开,实际上一直处于私密状态,尽管你的客户能够得到它。对于其它人而言,也必须要向你付费才能得到及使用产品。

    如果你的产品或源码还是被流传出去了,未向你付费的人使用泄露出去的版本法理上应该也不算盗版,没有法律上的风险,因为根据 GPL 协议他有权使用。但是假设你的公司影响力足够大,比如是某些国际大厂,产品涵盖很多领域,跟客户在不同领域均有合作,那么假如在其它领域(非 GPL )的产品和客户的协议有一项条款:如果未与本公司签订协议/付费而使用 XX 系列产品,公司将有权终止所有合作关系。说白就是你能用,你也有权用,在这方面没法追究你,但是就跟你撕破脸了,咱家别的东西你以后都别想买了。

    这些条款对个人用户没啥意义,但对于企业尤其是大企业,还是会考虑其中的“风险”的。其实这也基本符合现在很多大厂产品的营销策略:对个人用户“免费”(不管是放任盗版,还是像最近 VMware workstation 那样直接宣布对个人免费),对商用收费。

    不知各位有什么看法?不知道红帽在“闭源”Linux 后是不是/有没有用类似的策略来限制自家源码以及 RHEL 兼容产物(类似之前的 CentOS )的传播?

    12 条回复    2024-06-01 13:43:41 +08:00
    xou130
        1
    xou130  
       2024-05-29 20:34:26 +08:00
    商业上来看,如果不是 redhat 这个生态一开始利用 cent 绑架的太多,乙方和甲方提这种要求,甲方一开始就会想如果遇到难解决的问题需要乙方花费一定成本,乙方可以假证甲方泄露代码,不就可以随时单方面终止合同,如果这个软件又提供的是公司业务的核心部分,那风险可以说是巨大。可能有极少数有合规需求和甲方签这种条款,就算是 redhat ,本来 cent 加 red 生态已经火焰很高了,现在正好给了由头让大家换各种其他系统,比如 UOS ,openeuler 。gpl 能运行正是这种双向的“君子协议”,乙方的源码甲方可以任意提供给第三方,无论是审查还是什么目的,甲方没事也不会拿源码整个一样的去卖,毕竟还有专利还有下游客户。说到底,卖软件这种模式已经是上个版本了,这个版本是卖服务,当地主做收费站。买来用的软件,哪怕是工业软件,国产替代也是轰轰烈烈,少一家的软件无非就是业务不稳一点点,慢慢生态起来了都一样。
    shoa
        2
    shoa  
       2024-05-29 20:38:44 +08:00
    GPLv2 第 6 条:
    “You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.”

    GPLv3 第 10 条:
    “You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License.”

    补充协议是与 GPL 矛盾的
    liyafe1997
        3
    liyafe1997  
    OP
       2024-05-29 21:18:44 +08:00
    @shoa 不知道这个“restrictions/限制”在法律上的定义/边界在什么地方。
    就像上面我说的,我并没有限制你的行为 A ,也不会就你行为 A 本身去追究你(毕竟没有这个权限,行为 A 本身是合法的)
    但是可以通过另外的条款/合同/协议,如果有行为 A ,那么就 xxxxxx 。
    不知道这算不算一种“限制”
    liyafe1997
        4
    liyafe1997  
    OP
       2024-05-29 21:20:02 +08:00
    @xou130 这个是商业生态的现实,不过我这里想讨论的是纯法律本身层面的问题
    liyafe1997
        5
    liyafe1997  
    OP
       2024-05-29 21:27:28 +08:00
    @shoa 甚至这个“限制”可以更为软性,不一定非要终止合同/撕破脸,比如“将服务方式从每月提供功能更新版本调整为每 2 年接受一次仅安全更新”
    agagega
        6
    agagega  
       2024-05-30 00:22:40 +08:00 via iPhone
    理论上如果一家公司内部 fork 了 gpl 软件使用,员工作为拥有二进制的人有权获得源码,但因为受到公司规定的制约,不能随意向外泄露二进制。

    企业用户的场外因素本来也很难界定,所以也不能说违背了 gpl 的理念吧。
    baobao1270
        7
    baobao1270  
       2024-05-30 09:30:27 +08:00
    这种可通过商业策略限制,比如改成订阅制
    janus77
        8
    janus77  
       2024-05-30 10:13:20 +08:00
    你这个不就是实质上的限制吗,这跟“如果你偷东西,我就抓你”有什么区别吗
    NXzCH8fP20468ML5
        9
    NXzCH8fP20468ML5  
       2024-05-30 14:57:54 +08:00 via Android
    可以的,红帽就是这么干的。
    你订阅 redhat ,我就给源码给你。但你一旦共享出去,咱们合同立刻取消。
    实际上 redhat 不是带头这样干的,高通 MTK 博通英飞凌等等都有类似协议。

    gpl 只需要遵守二进制的
    NXzCH8fP20468ML5
        10
    NXzCH8fP20468ML5  
       2024-05-30 14:58:54 +08:00 via Android
    gpl 规则是获得二进制的人,也能获得源码。
    因此只要限制二进制的获得合同就行。
    liyafe1997
        11
    liyafe1997  
    OP
       2024-06-01 03:47:55 +08:00
    @xxfye 但问题是,GPL 规定不管是源码还是二进制,拿到的人有二次分发的权利
    NXzCH8fP20468ML5
        12
    NXzCH8fP20468ML5  
       2024-06-01 13:43:41 +08:00 via Android
    @liyafe1997 对呀,客户当然有权利可以分发,但是红帽就终止合同,停止你获得后续的二进制和源码的机会。这个并没有限制你已经到手的源码和二进制的分发权利。因此不违背 gpl 协议。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5151 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 08:00 · PVG 16:00 · LAX 01:00 · JFK 04:00
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.