GitHub因FFmpeg版权申诉下架瑞芯微MPP代码库

申诉方指出瑞芯微未能满足:复用代码必须保留与LGPL兼容的许可协议,并完整保留原始版权声明与署名信息。

GitHub在收到FFmpeg开发者发出的DMCA通知后,关闭了瑞芯微维护的Linux MPP代码库,该通知指控其违反LGPL许可协议。

GitHub已应FFmpeg项目贡献者的DMCA下架请求,关闭了瑞芯微维护的Linux多媒体代码库。

投诉焦点不仅在于代码复用,更在于瑞芯微决定将FFmpeg衍生代码重新授权为不兼容许可,此举被指违反GNU较少通用公共许可证(LGPL)。

元素周期表

根据提交文件,瑞芯微的媒体处理平台(MPP)代码库包含多个直接源自FFmpeg libavcodec代码库的源文件。虽然LGPL允许复用FFmpeg代码,但需满足严格条件。首要条件是:复用代码必须保留与LGPL兼容的许可协议,并完整保留原始版权声明与署名信息。

申诉方指出瑞芯微未能满足这些要求。相反,被复制的代码被重新分发至Apache许可证下,而该许可证在此情境下与LGPL存在冲突。

此外,DMCA通知进一步指控瑞芯微删除了原始版权头信息和作者信息,实质上将代码据为己有。

申诉文件列举了AV1、H.265和VP9解码器的实现案例,指出通过相同的结构、注释甚至注释掉的调用(仍保留原始FFmpeg函数名称)可明确追溯代码来源。

据报道,瑞芯微早在近两年前就已获知许可问题,并多次承诺将解决此事。然而该公司始终未采取纠正措施,最终导致正式DMCA请求的提交。正如预料的那样,事态发展如期而至

投诉提交后,GitHub已禁用该仓库的公开访问权限。截至本文撰写时,该仓库仍处于不可用状态,且未公开任何反通知声明。

瑞芯微是一家中国半导体供应商,其系统级芯片平台广泛应用于单板计算机、安卓设备、媒体播放器及嵌入式Linux系统。其MPP框架旨在为瑞芯微硬件提供现代编解码器的硬件加速视频编解码功能。

元素周期表抱枕

共有{183}精彩评论

  1. 该仓库在一年半前就将FFmpeg代码整合到其项目中,同时宣称其代码采用Apache 2.0许可证[1]

    此举违反了LGPL协议,该协议要求必须动态链接库文件。他们直接将FFmpeg代码复制粘贴到自己的仓库中。

    [1] https://x.com/HermanChen1982/status/1761230920563233137

    1. 问题不在于此。LGPL并不要求动态链接,仅要求任何分发的成果物必须能够与LGPL代码的衍生版本配合使用。在Apache 2.0许可下分发可构建的源代码同样符合要求。

      此处的症结并非技术性违反LGPL,而是Rockchip并不拥有FFMPEG的著作权,因此根本无权将其发布在LGPL之外的任何许可证下。他们本应将修改后的FFMPEG代码放入分叉项目,明确标注LGPL许可文件,并链接至该项目。

      1. “以Apache 2.0许可证分发可构建源代码同样符合要求”

        “不拥有FFMPEG的版权,且根本无权在LGPL之外的任何许可证下发布”
        这两者如何自洽?

        1. 您可在单次下载中同时分发自身Apache许可代码与LGPL许可的FFmpeg

        2. 前提是他们将自身代码以Apache 2.0许可分发,且该代码可与LGPL许可的FFmpeg代码构建兼容,无需将FFmpeg本身重新授权为Apache许可

      2. 发送提醒时是否存在其他/更优的应对方案?

        我认为该中国公司的开发者似乎立即承认了署名权。

        如今开源社区失去了IloveRockchip的开源代码,而FFmpeg除获得单个文件的署名(尽管方式笨拙,但Rockchip开发者确实公开承认了)外,实际未获任何实质收益,反而损害了声誉并失去商业分支(及潜在合作伙伴)。

        1. 当合作伙伴如此轻视你——无视你授予的许可,被质问时更选择漠视——你该如何维系合作?

        2. 他们早有充分警告却无视许可条款,你到底在纠结什么?

              1. 那么我们该等待他们如何回应这些问题?采取什么措施?基于什么理由?

                我们耗费时间梳理了所有IRC聊天记录、推特讨论串、SoC制造商的态度等。

                一个本可十分钟解决的问题,竟拖延一年半才被追责,其中必有隐情。

                  1. 显然是决策失误与风险收益评估失当。若涉及核心代码且采用GPL许可,(技术层面)解决难度极高。

                    但此处涉及的FFmpeg采用LGPL许可,且仅涉及单个文件,修复工作量更小。

                    1. 没错,Rockchip似乎搞砸了。但根据GitHub的DCMA通知:

                      https://github.com/github/dmca/blob/master/2025/12/2025-12-1

                      > …相关违规仓库维护者早在近两年前([private])就已收到问题通知,却未采取任何解决措施。更糟的是,他们最后的评论([private])表明根本无意解决。

                      看来举报者已给予他们大量时间修复问题,当他们意识到问题永远不会被解决时,才采取了恰当的后续行动。

            1. 这简直是胡扯。FFmpeg开发者完全有权立即发送DMCA删除通知,无需事先客气相求。

              这正是大公司对付小企业的手段,所以我们对大公司毫无欠债可言。

              他们给了瑞芯微一年半的整改期。自首次收到通知起,瑞芯微就有责任解决问题,FFmpeg开发者没有义务在对方履行法律义务时全程陪同指导。

              1. 没错。这就像在漏洞披露前拖延90天,然后抱怨“你们本可提前联系我们争取时间,现在只剩90天了”。典型的精神操控入门课。这90天恰恰给了那些坐拥资源却坐拥零日漏洞(如Cellebrite)的家伙免费试用的机会。

            2. 截止日期和提醒?他们不是老师,Rockchip也不是学生——受害者才是受害者,Rockchip才是过错方。别再用字面意义上的“责怪受害者”来指责他们的应对方式了。

              1. 明确声明:Rockchip负全责,100%。任何盗用我代码且拒绝署名的企业,我都将提起诉讼(当然还会启动DMCA程序)。

                若对方拒绝整改,你立即诉诸[DMCA/法律诉讼]实属合理,但若在沉默两年后(且仅限于此种情况,毕竟他们可能在推特/X平台外发表过言论)突然采取行动,就显得有些奇怪了。

                1. 或许该少花点时间监管他人行为准则,尤其当你对沟通内容或存在性进行肆意揣测时

                  1. 这是呼吁开发者坦诚说明幕后情况,诸多暗示如“我猜是否…?”“事态升级可能源于何事?”“为何未公开提醒?背后发生了什么?”等等,这些问题刻意保持开放性。

                    1. 哦。用粗鲁的语气暗示开发者(在你看来)基于你对他们行动的猜测犯了错误,绝不是促使他们阐述法律策略的有效方式。

                      况且这种行为本身就很无礼,这已足够成为不这么做的理由。

                2. 成年人的世界里,违法者不会得到任何警告。

        3. 你最初的评论结尾写着…

          > – Rockchip的代码消失 > – FFmpeg一无所获 > – 社区失去所有现有改进 > – Rockchip从伙伴变成对手

          这些纯属臆测,想必是你删文的原因。

          他们的代码并未消失(除非管理方式彻底错误),FFmpeg向营利性侵权行为发出警告,社区得以看清Rockchip在开源合作中的无知行径,最后… 若瑞芯微竟敢成为其牟利所依赖的顶级开源项目之敌,那他妈的瑞芯微就该滚蛋。他们不过是屡次被警告却拒不整改的许可证侵犯者罢了。

          1. 原帖作者删除了那句话,我认为不该被举报屏蔽,因此我为其担保。我理解很多人不同意该观点,可能会投反对票,但这与举报性质不同。(我已提前投赞成票以防万一)

            他提供了中国视角的见解,我认为值得大家阅读。(并非表示我认同其任何观点)

            1. 你说得对,FFmpeg开发者们也完全正确,我完全理解这一点。

              事实上我赞同这种向大公司施压、强力维护开发者权益的做法。

              我认为更早采取行动本可带来积极效果,但沉默一年后突然“投下炸弹”且未提前提醒(至今仍不确定是否如此),这种做法确实难以预测,因此我想提出这个问题

              1. 根本不存在沉默期。社区多人持续在现已关闭的Github仓库公开问题中敦促Rockchip解决此事,甚至提出过潜在DMCA申诉的可能性。

                他们唯一的回应是:“我们忙于处理其他上千款芯片,此事将无限期推迟”。

                荒谬至极。

        4. 我们不会蒙受任何损失。若社区足够强大,总会有人发布修复问题的分支版本。

        5. 若必须追着他们要求停止违法行为,说明对方本就是对抗者。最简单的合规方式就是遵守许可协议,如此各方皆赢。

      3. “此外,仅将非基于本程序的其他作品与本程序(或基于本程序的作品)在存储介质或分发介质上进行聚合,并不使该其他作品纳入本许可范围。”

        只要LGPL完整保留,这些作品就应作为聚合体受到保护。

        1. 争议焦点在于ffmpeg代码被“复制粘贴”时既未署名也未保留许可证(如LGPLv2 LICENSE文件)。显然我无法核实——既无代码克隆副本,仓库又因DMCA执法被封锁。但至少Github/微软似乎认同存在侵权行为。

          1. 微软/GitHub无权干预DMCA申诉的执行。

            1. 呃…该仓库已被GitHub直接下架:https://github.com/rockchip-linux/mpp

              不明白你在此想表达什么。根据法规,DMCA下架执行完全由在线服务提供商负责。这是他们获得侵权内容托管责任豁免的机制。

              1. 没错,但微软/GitHub不会对申诉的有效性作出任何判定。

                一旦提交了有效的(从流程角度看)申诉,服务商必须将申诉内容下架10天。此后,反申诉和法庭程序将进入往返流程。

    2. LGPL允许复制粘贴代码,但若在删除许可声明和代码片段归属信息的情况下进行此操作则不被允许。

      1. 仅当你粘贴LGPL部分的代码所处的项目采用兼容许可证时才允许,而Apache许可证不兼容。

        在保留不兼容许可证的前提下合规的最简方式是将LGPL部分封装为动态库,虽有其他方法,但此法最为常见。

      2. 复制粘贴或其他数字复制手段无关紧要——问题在于未经授权删除原有许可并实质上“重新授权”的行为,无论代码包含机制如何。

      3. 此表述准确,本应如此措辞。我不该提及动态链接,你说的没错,这无关紧要。

        谢谢!

    3. LGPL并未强制要求动态链接,其核心要求是允许重新组装新版本库。对于静态链接的应用程序,这可能意味着分发对象文件,但该许可仍允许此操作。

    4. 此说法根本错误。LGPL的诞生正是源于静态链接场景——此时GPL许可代码会被包含在分发的二进制文件中。

      GPL是否影响动态链接仍是开放性问题(FSF有其立场,但从未得到司法裁决)。

      有人可能认为:若将GPL动态库与非GPL代码捆绑发布,则构成集合体,GPL将感染整体。但若发布运行于Debian、Redhat等系统上的非GPL二进制文件,且使用这些系统自带的GPL库时,情况则更为复杂。

    5. 他们等待了一年半之久,却从未忘记此事

      1. 对方获得了整整1.5年的缓冲期。自由软件社区理应以同等标准对待商业实体。

        说真的,若我们抄袭其代码构成侵权,距离收到DMCA侵权通知会拖延多少小时?

        自由软件在许可执行上本该专制。毕竟只要遵守简单规则,使用和改编本就是免费的。我也认为安卓手机制造商应全面公开源代码,若进口时发现侵权行为应予以没收。

        但目睹自由软件开发者总说“我们友善些”。以牙还牙才是迄今最优的博弈策略。是时候付诸实践了。

        1. 据我所知,GPL在法庭上缺乏大量先例支撑。若在重大诉讼中孤注一掷却败诉,该判例将长期束缚GPL,甚至可能削弱所有copyleft许可证效力。

          更明智的做法是施加温和压力,建立违规者采取补救措施的记录。这样当你最终诉诸法庭时,就能列出一份明确遵守条款的个人及企业名单——因为他们认为条款足够清晰,这将为你的主张增添分量。

          此言出自一位GPL强硬派之口。

          1. 这在多个司法管辖区确实有先例。天啊,SFC刚刚在美国通过执行GPL条款胜诉Vizio,此前在法国和德国也有过胜诉案例。

          2. 大多数许可协议、最终用户许可协议、合同等在法庭上都缺乏先例支撑。没有理由认为GPL一旦遭遇足够狡猾的律师就会崩溃。

          3. 据我所知已有足够判例(虽受司法管辖区影响,但仅需一例即可),但各方对许可范围的解读存在分歧。例如若主张驱动开发者必须开源固件二进制文件或其通过内核适配层加载的专有驱动,你将面临艰难诉讼且很可能败诉。

    6. 当两个不同许可的库需要混合使用时会怎样?

      1. 若你拥有其中一个库,混合LGPL代码并发布,最终产物完全受LGPL约束。

        若你无权拥有该库且无法合法将其部分内容重新授权为LGPL,则不得发布混合产物。

        能合并他人代码并不等于法律允许你这么做。

        1. 此说法有误;你只需同时遵守所有适用许可即可。这可能可行也可能不可行,但实践中相当常见。

          1. > 能够合并他人代码并不等于法律允许你这样做。
            > 这种操作可能可行也可能不可行

            我不确定你的意思,这与你回复的评论内容不同。

        2. 完全取决于你“混合”的程度,以及该具体作品的特殊情况。

          合理使用原则不会因GPL作者的特定世界观而被抛弃。

          其次,源代码中存在大量无法受版权保护的组件——若无法获得版权保护,自然也无法适用GPL协议。这些组件可由任何人随时自由复制。

      2. 首先需确认许可证是否兼容。若兼容,只要同时满足两份许可证条款即可。

        若不兼容,则不可混合使用,必须另寻替代方案或自行开发功能。

      3. 部分许可证(如LGPL)对此有特殊条款,部分则直接禁止。

        在ffmpeg的具体案例中,允许从采用不兼容许可证的项目中动态链接它。

      4. 应将它们存放在不同目录下,并为每个目录配置相应的许可证。可在顶级目录放置LICENSE文件说明情况。

      5. 这取决于具体许可证条款。

        Copyleft许可证旨在防止代码混合,因其通常与混合使用存在冲突。

        更宽松的许可证通常允许混合使用。这正是允许在专有代码库中包含宽松许可证代码的原因。

        关于链接行为,“弱Copyleft”许可证允许链接但禁止“混合”代码——这正是LGPL的核心要义。

    7. 我喜欢FFmpeg,但厌恶这种“那又怎样”的辩论,尤其当FFmpeg在此事上显然占据道德制高点时…不过听着,FFmpeg作为产品本身也存在大量许可违规问题。什么专利问题,什么“不洁手原则”。我担心Reddit会对试图探讨全局的人投反对票,因为缺乏细致分析的结果总是变成:“好吧,真正的赢家是谷歌和苹果。”

      1. 除Apache许可证外,多数主流许可证都不涵盖专利。若你指的是专有许可证,我对此并不了解,但相关条款确实模糊不清。若想提出有力论据,或许该比“什么什么”更具体些。

        1. GNU v3系列许可证同样涵盖软件专利,FFmpeg的部分代码也采用该许可证(不过被下架的复制代码应属LGPLv2.1+许可范畴)。

        1. 他们并未违反许可协议,否则早就被诉讼潮淹没消失了。

        2. 微软、苹果和谷歌付费购买的编解码器许可证。FFmpeg认为仅终端用户需要编解码器许可证,这不仅是他们的主张,更与微软、苹果和谷歌的立场相悖。虽然现状确实如此,但LGPL违规同样是普遍现象。由此可见FFmpeg大肆宣扬许可证问题实属不明智。

      2. 算法的独立实现与软件许可属于不同维度,因此“不洁之手”的论点在此站不住脚。

        专利 ≠ 版权

      3. > 我厌恶玩弄“那又怎样”的辩论手法[…],但…

        …然而你仍旧这么做了,既未深入说明也未提供任何证据证明(你所声称的)侵权行为存在。

        若你的指控有实质依据,请提供细节和证据,这样才能形成建设性讨论,而非徒增噪音。

    8. 整合兼容代码且采用不同许可完全合理,各组成部分可使用不同许可协议,而整体作品则遵循另一套条款。

      坦白说我实在不明白FFmpeg在此抗议什么——如果ILoveRockchip在兼容许可下编写代码(Apache 2.0相对于FFmpeg采用的LGPLv2+即属此类),这似乎完全合规。

      相关代码库现已不复存在。问题在于ILoveRockchip是否声称其代码实为FFmpeg所写?若属实则性质恶劣,这与许可条款或兼容性无关,纯属剽窃行为。

        1. 感谢提供链接;遗憾的是所有指向该仓库的链接均无法查看具体发生的情况。

          致那些投反对票的人:好奇原因何在?由于GitHub隐藏了多数链接,导致相关讨论变得相当棘手。

          1. 或许是因为如果ffmpeg团队声称有正当理由,且已等待一年半要求遵守协议,我们更倾向于相信他们,而非那些未经许可擅自重新授权代码的人。

          2. 我没投反对票。但有人这么做,大概是因为你听起来像在为ILoveRockchip的行为辩护——要么是1)不明白他们做了什么,要么是2)不了解事实真相。人们对滥用自由软件的行为向来很敏感。

    1. 存档对讨论线程帮助不大。但他们确实这么说过吗?从评论看他们只表示“正在处理,但目前忙于XYZ项目”,之后数月毫无进展。

      存档无法加载剩余3项内容。

      1. 是的存档确实无法加载,但我持续关注该讨论串。最近几个月内确实有人提及此事,这引发了后续讨论并促使ffmpeg采取行动。

      2. 纯属个人推测:

        他们从未真正着手处理,以为问题会自行消失。或许某位初级/资深开发者尝试过,提交了项目计划却无疾而终。

  2. 我好奇这将如何应对AI生成代码却无源代码或署名的情况。毕竟大型语言模型并非凭空杜撰,其内容源自原始素材。

    1. 最佳情况是彻底摧毁软件专利的概念,以及整个丑陋的版权囤积产业。认为永久性租金寻租是版权和专利法律概念的自然延伸和预期结果,这种想法实在荒谬。

      1. 我无法想象这会如何影响父母。

        版权和专利是完全独立的概念。

        “永久性”固然是问题所在,但“寻租”恰恰是版权与专利制度诞生的根本初衷。

        1. 不——这些制度存在的意义在于为创作与发现提供资金支持;授予临时垄断权正是实现该目标的机制。

          这听起来或许迂腐,但切勿将手段与目的混为一谈:

          > 为促进科学与实用艺术的进步,通过在限定时间内保障作者和发明者对其著作与发现的专有权;

          https://constitution.congress.gov/browse/article-1/section-8

          1. 真希望我能获得防御性保护,抵御那些数以百万计的劣质软件制造商。但世上根本不存在这种保护。

            你知道吗?Facebook持有自动完成功能的专利。雅虎曾拥有该专利,而Facebook将其收购,将其作为私有核武器,与其他持有核武器级专利的公司形成相互确保毁灭的战略格局。

            当然,明知故犯的专利侵权处罚更为严厉,因此企业极不愿让员工意识到每次自动补全都可能构成专利侵权——这将带来额外的法律风险。

    2. 当大型语言模型(LLM)以人类行为会被认定侵权的方式侵犯版权时,我认为无人质疑应采取何种措施。

      关于LLM的核心争议在于:人类可合法的行为若由其执行是否合法?其次才是技术层面能否有效监管的问题。

    3. 人类创造的一切也源于原始素材。

      无论哪种情况,真正的(法律)问题在于实际抄袭的程度有多大,以及抄袭痕迹是否明显。

      1. 我基本同意你的观点,但人类直接抄袭受版权保护的作品就是违法。大型语言模型似乎也该遵循相同标准——除非它们比人类更无需遵守法律。

        而且判断大型语言模型是否抄袭极其困难,因为法庭上无法质问它,它自己可能也说不清。

        1. 据我观察,(美国)法院似乎区分两种情况:完全由机器自动生成的内容(无任何人工提示),以及人类明确指示其生成特定内容的情况。(当然我明白计算机的所有操作都需要某种预先指令。)

          但版权问题的症结在于作品的传播环节——在法律意义上可能涉及衍生或改造的作品传播,通常仍需人类以某种形式参与操作。因此我认为,即便生成内容本身由大型语言模型产出,人类传播者仍需为潜在侵权行为承担责任。

          但法律判定终究会回归我先前提到的核心标准:单纯考察“抄袭程度与相似度”,而这取决于每起案件中法官的主观裁量。

      2. 此说不成立。那是哲学怀疑论,早已被彻底驳斥。

    4. > 不知AI生成代码时若无源代码或署名会如何判定?

      现行规则已明确:任何AI生成的内容均无法获得任何形式的保护(英国对特定类型创作有例外)。

      例如若AI模仿ffmpeg代码,则ffmpeg拥有优先权。

    5. 大型语言模型不会原封不动地吐出训练数据中的代码片段。

      1. 你依然能轻而易举地从Copilot获取整段代码,甚至包含原始作者姓名(只需用doxygen标签提示即可)。

      2. ChatGPT给我的代码附带如此具体的注释,让我找到了六年前的原始GitHub仓库。

        1. 这事多久以前的?

          这丝毫不影响你的说法——我只是知道他们肯定在追查这事,就像生死攸关似的。

      3. 确实如此,而且微软(可能还有其他公司)早期就设置了检查机制试图掩盖。

        1. 26面骰子能复现整段源代码。界限究竟在哪里?

          1. 这可是个多太字节级别的骰子,完全不随机,而且绝对复制了相关源代码。

            1. 骰子容量绝非数太字节。若按平均令牌词汇量估算,更合理的面数应在3.2万至5万之间。

              本质上取决于编码方式。抛硬币就能生成任意短度的UTF-8编码字符串。

              1. 面数与内部数据毫无关联。它并非随机生成,有时会以明显非偶然的方式重复内容。

                1. 当然是随机且基于概率——令牌本质上是从预测概率分布中抽取的。若你认为偶然性等同于均匀概率,必须明确说明。

                  任意短序列的重建可由几乎任何随机过程实现,且重建长度与目标序列输出分布的相似度成正比——这根本不该有争议。

                  我的观点是:序列匹配长度与分布相似度均可量化。你打算如何划定界限?

                  1. > 当然,这是随机且偶然的——令牌确实是从预测概率分布中抽取的。

                    非随机分布中随机抽取不会产生随机结果。

                    而且你根本不必用随机性来选取令牌。

                    > 若你指偶然性=均匀概率,必须明确说明。

                    别纠缠不休。这并非讨论均匀分布与其他通用分布的区别,而是针对每个令牌进行精密计算——其目的正是使下个令牌具有合理性,同时排除绝大多数令牌。

                    > 我的观点是:序列长度匹配与分布相似度均可量化。你打算如何划定界限?

                    任何合理的界限都有来自多种模型的跨越案例。可复现的极长片段。因为许多模型在训练过程中对特定代码片段进行了过拟合,本质上导致它们被死记硬背。

                    1. > 可复现的极长片段

                      没错,极短片段同样可以复现。假设“//”是任意短的片段,它能匹配某些源代码。这显然成立。我可以在硬币上刻“//”,抛硬币时一半概率会显示“//”。我们不妨将其视为下限。

                      我甚至不否认存在上限。完整复现整个代码库显然构成匹配。

                      因此必然存在一条分界线,区分过短与过长的段落。

                      问题在于:你凭什么标准划分1个令牌的复现与1000个令牌的复现?5个?10个?20个?50个?这种划分有何依据?纯粹基于“合理性”吗?

                    2. 你为何如此执着于让我给出具体数字?

                      存在极其冗长的范例,显然属于记忆式生成。

                      比如若模型在训练时接触了全世界所有代码(唯独缺该特定范例),它生成该代码片段的概率不足十亿分之一亿分之一。但该片段被反复输入训练,最终被当作标准惯用语完整记忆下来。

                      这样的门槛够清晰了吗?

                      我不知道确切界限在哪,但它肯定在这个大范围之内,而有些例子已经完全超出这个范围了。

                      我不在乎具体边界在哪里。

                    3. 老兄,这算不上善意。

                    4. 听起来你其实很在意具体位置?

                    5. 我在乎的是它是否大致符合我详细说明的范围。具体落在范围哪个位置我不在乎。

                      你给出了夸张的上限——“整个仓库”这个极端值毫无歧义。

                      我也给出了夸张的上限,同样极端到毫无歧义。而且我的例子是真实发生的事件,严重到构成明显违规。

                      或许类比能说明问题:沙粒堆积成丘的临界点本可模糊界定。但当我们记录到公斤级沙堆呈锥形堆积的实例时,便无需再精确划定阈值——直接认定沙丘真实存在即可。同理,大型语言模型通过完整记忆而非偶然性或通用编程知识重构代码的事件,同样真实存在。

                      你是唯一暗示真实抄袭事件只是统计幻觉(如同随机骰子)的人。通常争论焦点在于:此类事件的发生频率与影响程度、责任归属以及应对措施。

                    6. 重申核心争议:原论断是“LLM不会逐字复现训练数据中的代码片段”。显然我们对此均持反对意见。

                      你执意将讨论引向上限问题,而我试图说明的是——带有“//”标记的硬币会复现代码片段。再次强调。我认为这点上我们其实并无分歧。我始终未能从你那里得到的是两者之间的本质区别。

                      我试图找到一把剪刀,将你的观点提炼成一条一致的规则,但每次都被驳回,仿佛我在强行辩论。如果你的体系缺乏一致性,直接说出来就好。

                    7. 我确立了一条一致规则:若大型语言模型达到我设定的阈值,则必然构成版权侵权;若未达阈值则需进一步调查。

                      现有证据表明某些模型已突破阈值,这已解答了问题。

                      你举的例子都属于“需进一步调查”范畴,不影响结论。

                      我们都认同单个令牌本身无碍,但达到某个数量就过量了。

                      那你为何反复追问此事,仿佛这会让我的论点自相矛盾?我们观点完全一致啊!

                      我们无需知道精确的临界值,也无需计算其变化规律。我们只需找出超过阈值的违规者。

                      不如你告诉我你希望我说什么?是想让我承认系统存在矛盾吗?它并不矛盾。存在答案不明确的区域,意味着系统无法解答所有问题,但它本就不必解答所有问题。

                      若你指责我滥用“感觉”破坏体系,我反驳:我给出的概率明确具体且极其罕见,其依据程度绝不比你建议的整个仓库更依赖“感觉”。

                      > 我始终未能从你那里得到两者之间的显著区别。

                      你指的是“//”和我说过的阈值之间的区别吗?

                      两者最显著的区别在于:一种因篇幅过短而不构成版权侵权,另一种则因篇幅冗长且内容具体而绝对构成侵权(当来源是受版权保护且未经许可复制的现有文件时)。你还想要什么?

                      正如1粒沙子绝对不算沙堆,1公斤沙子绝对是沙堆。

                      若问我对2个、3个或20个令牌的看法,我的回答是:我不在乎,这无关紧要,也*别假装这与大语言模型是否构成版权侵权(“逐字剽窃大段内容”)有关。

  3. LGPL允许将整个ffmpeg编译为so或lib文件,随后可从该库动态链接至闭源代码。这正是LGPL与GPL的核心差异。

    但若在构建ffmpeg.so时进行修改或添加内容,则需遵循GPL许可。

    显然他们将ffmpeg的部分文件与自有专有代码混合编译成了整体。这正是问题所在。

    1. 版权法依据实质性相似性和依赖性定义衍生作品,而非基于链接等技术机制。链接等技术手段并非版权概念范畴。

      动态链接是符合LGPL的必要条件,但并非充分条件。动态链接本身并不能自动使组合作品免于被认定为衍生作品。

      1. > 动态链接是LGPL合规的条件

        并非如此。该条款要求允许用户对LGPL覆盖的软件部分进行修改并使用。动态链接仅是实现此目的的便捷方式,而非必要条件。

  4. 法律似乎已名存实亡。太多案例表明,有人公然违法却无人能制止。并非人人都有数万乃至数十万美元聘请律师。待你攒够钱时,才发现这个体系根本腐败透顶——即便聘请律师且法律上占理,你也不再相信它能伸张正义。

    法律的存在本质上是压迫工具。这恰如拥枪派的论调:“只有好人遵守枪支法,所以坏人才有枪。”

    守法的好人都处处受损,违法的坏人却处处得利。坦白说,现阶段法律的制定权早已掌握在他们手中。

    1. 我最近与加拿大某政府部门打交道时,发现一名任职二十年的职员连最基础的阅读理解能力测试都未能通过。随后在隐私专员办公室(OPC)处理的多起案件中,该机构竟在基本问题上彻底失职。

      安大略省的租户法同样饱受诟病,被指纵容不良租客行为。但细读法规会发现:房东需经历数月延迟程序,租客却仅需两天通知——这才是现实图景。

      更甚者,某房东公然撒谎并承认造假,其谎言竟在明知虚假的情况下影响裁决结果。上诉文件提及裁决者的自由裁量权。

      不知这种状况还能维持多久才崩溃,但想必时日无多。

      1. 无能本是禁忌话题,但它不该如此。

        我认为对他人做出价值判断完全合理,若能提供证据支撑,就应公开发表并让其职位承担相应后果。

    2. 我不得不将其视为帝国衰落的征兆。更多人意识到你所言(尤其是最后两段)的真相只是时间问题,届时整个体系必将分崩离析。

    3. 所以现在正义一方运用法律手段……至少暂时……取得了胜利……你的观点是什么?

      1. 这种现象随处可见。具体到这个案例,耗时整整两年才解决。当然,如今FFmpeg因与人工智能炒作挂钩而获得更多媒体曝光,终于得到“公平”的法律对待…我可不觉得这是胜利。这种事我见多了,整个西方世界都是如此。

        记得罗温·艾金森(英国演员)几年前就对此现象发过言,此后再无下文,但这种感受却日益强烈…没有曝光度,没有资金,没有法律代理。与此同时,我们却被洗脑说自己享有特权。

        1. > 在此案例中,耗时两年的事实。而如今FFmpeg因与AI炒作挂钩获得更多媒体曝光,终于得到“公平”的法律对待…这算什么胜利?

          耗时两年是因为FFmpeg拖延两年才向Github发送DMCA通知,并非司法系统延误。你似乎混淆了不同无关的问题。

    1. 你提到的案例似乎并未误导许可条款,即若你使用该代码创建衍生作品,理应按LGPL协议分享对代码的修改内容。

    2. 这是因为只要遵守许可条款,LGPL代码可被整合到任何项目中。

      Rockchip是硬件平台,代码运行的具体硬件在此无关紧要。

      1. 既然Rockchip仓库中实际代码的链接已被DMCA下架,有人分叉过代码吗?这样我们才能独立判断。

        1. 难道Hacker News社区的说明性评论还不够充分吗?

          1. 若仓库仍可访问,我唯一要确认的就是LGPL部分是否被修改或静态链接。既然无法验证,基于许可协议的解释就合理。

  5. 好极了,支持!捐款渠道在哪里?

    1. 冲突点何在?是说中国缺乏版权观念,还是不重视法治?

      1. 不,他们有这些概念。只是未普遍执行,或者说执行时带着“些许灵活性” 🙂

        FFmpeg能对Rockchip的“强推”施加多少“牵制”,尚待观察。

    2. 虽非中共拥趸,但GH平台普遍存在用户不理解不尊重许可协议的问题——常将他人代码据为己有,有时是无心之失,更多则是蓄意为之。

  6. 若能生活在“知识产权”和“版权”这类愚蠢概念已被世人嘲笑出局的世上该多好。可惜我们身处现实,这道德与法律的荒原,恰似遍地垃圾的公园。

    1. 这主要得感谢比尔·盖茨。代码即数学,任何坚持相反观点者,其道德或智力——或两者兼具——都值得怀疑。

  7. 有人贴个存档链接吗?我看不懂这个

      1. 绕过禁令访问网站真的比直接访问更好吗?道德上有什么区别?

        如果所有人都主动抵制该网站,它一夜之间就会失去意义。其他任何行为都只是默许其继续存在。别自欺欺人。

        1. 问题在于查看回复需要账号,而非访问网站本身存在道德争议(尽管后者也可能成立)。

            1. 二者并非互斥。有时内容发布在人们不愿支持的网站上,此时复制内容并查看/分享副本更为可取。

    1. 也许我不够聪明,没法理解这些华丽辞藻,但这意思是说:只要我花几年写些代码,只要你的销售和营销比我强,你就能为私利抄袭我的代码而不必补偿我?

      我不认为瑞芯微从ffmoeg代码中学到了什么。他们根本就是直接抄袭,连署名都没有。

      1. 我认为你们双方都有道理。但楼主或许该考虑更宏观的层面。有点像“快速行动,打破常规”那种理念——当价值足够高时,某些界限本就该模糊。我并非认同这种道德立场,但过于僵化地恪守规则确实存在某种僵化弊端。这确实是个微妙的平衡点。

      2. > 若我耗费数年编写代码,你理应能为个人需求复制使用

        若代码已公开发布,确实存在合理论据支持他人自由使用:若开发者能(或已)通过代码获利,便不会选择公开。若未能获利或尝试失败,或许让所有人参与尝试反而更符合社会利益?

        1. 我甚至不喜欢GPL许可证,但除金钱外还有其他交换形式。

          许可证规定了使用条件。可以认为,无视许可证就等于未支付规定代价。

        2. 没错,但我们真正推动的是什么激励机制?

          若唯一赚钱或避免被窃取的方式是封闭保护主义,进步何在?

          现代世界如此依赖开源。难道真要让所有公司连同他们的母亲都从零重建世界,只为避免被坑?在这种世界里,iPhone之类的产品还能存在吗?

    2. > LGPL是特定历史时刻的产物:欧洲法律主义与美国企业妥协的结合体

      虽然我认同帖子主旨,但这个具体论点毫无道理。

      LGPL和GPL是100%的美国产物。它们最初源自美国学术界,明确目标是出于意识形态目的强迫(美国)版权体系就范。

      这与欧洲法律体系毫无关联。

    3. 将此问题重新定义为中国与西方之争显得牵强且怪异

    4. 所以进步永远是好的,不管你未经同意剥削了多少人的劳动成果?你有辆好车,我就能直接拿来自己用?代码有什么不同?奴隶制也行吗?

      更有趣的问题是:如何创造繁荣而不牺牲他人——让所有贡献者按其贡献比例获利。

    5. 资本主义固然有弊端,但它比所有已知制度更擅长高效配置资源以提升生产力。换言之,这是我们所知最高效的制度。

      无法为投资者创造效用的投资终将萎缩。无论“投资”是金钱还是才华,此理皆然。

      你所主张的“允许人们无视创作者定价的体系更高效”的观点,已被历史反复证伪。

    6. 当然,中国企业通过申请微小改进专利,将开源项目拒之门外的做法是个例外。

    7. 软件许可不过是产权的另一种形式,而产权正是社会用来激励文明行为的手段。

      1. > 软件许可不过是产权的另一种形式

        这可是相当重大的论断,却缺乏充分依据。

        将版权等同于动产或土地所有权的论调本质上是宣传攻势。

      2. 若你是最后的幸存者,谁还在乎文明礼仪?

        再说——“文明”这个词。我们本就是受自利驱动的动物。在此语境下文明究竟意味着什么?

        1. > 我们本就是受自利驱动的动物。在此语境下文明究竟意味着什么?

          正是这种自利性促成了人类合作。人类进化出协作、建立社会纽带和友谊的能力,因为长远来看这能提升生存率和福祉。文明正是这种生存工具箱的一部分。它并非对自利的否定,而是自利性本身的一部分。

          1. 谢谢,这正是我想表达的观点……尽管个体可能自私邪恶,但合作本身存在激励机制。

    8. > 这里存在超越FFmpeg的更深层模式

      核心在于窃取行为。

      这并非复杂概念,亦非西方观念。

    9. 这完美概括了我对软件许可的看法。

      我始终觉得荒谬至极。要么公开代码并接受他人使用,且没有任何可执行的限制;要么干脆别公开。道理就是这么简单。

      其余全是愤世嫉俗的老家伙们自我膨胀的产物。

      1. > 我一直觉得这简直荒谬至极。要么你公开发布代码,就该接受他人使用且无法强制限制;要么干脆别发布。道理就是这么简单。

        倘若这种模式能推广至所有领域——电影、书籍、电视、音乐乃至一切文化产品——我定会赞同。但现实并非如此。若允许人们自由混编过去五十年的文化遗产,其创造力将不可估量。如今我们却仍困守于七十年前的陈旧内容。

        软件领域的进步潜力或许同样巨大,但问题根源与文化作品如出一辙。于是我们陷入金钱至上的桎梏——维护所谓“知识产权™”的法律体系,本身就需要金钱支撑。即便现行制度糟糕透顶,我也不怪罪ffmpeg遵循规则行事。

        1. 或者至少要求使用我代码的人也遵循相同原则。但既然现实并非如此,copyleft许可证(特别是GPL而非LGPL)至少能在有限范围内强制实现这种要求。

        2. 代码既非文化亦非艺术,我不明白为何要将它们相提并论。

          1. 我渴望更多优质代码,也渴求更高品质的文化。二者都面临着同一道核心障碍——版权问题,这正是本文、我的评论及你观点的症结所在。我不明白为何代码能享有版权豁免,文化却不能。

    10. 精彩评论,感谢分享。

      > 衰落的文明痴迷于规则,崛起的文明痴迷于成果。

      这句话我曾在截然不同的语境下听过。能否透露你引用的出处?你如何得知?

  8. 开源软件始终是个骗局,其目的在于向大型语言模型输送海量代码,同时扼杀程序员的生计,使其无法实现作品变现。况且没人关心许可证,大家都在肆无忌惮地窃取触手可及的一切。

    1. 所以开源软件糟糕,商业软件也糟糕?那还能做什么——出门去摸摸草坪吗?

    2. 开源软件兴起的时间,比大型语言模型成为模糊概念还要早几十年。

  9. 中文是盗版编程,设备公司用ffmpeg有利有弊

  10. 是时候创建去中心化的区块链版GitHub(GitCoin?)了,让每次提交都成为链上交易。这样就永远无法被下架。

    1. Git本身已有区块链;下一步需将仓库对象副本同步至其他服务器。(但我不确定区块链是否包含Git标签——我认为可能不包含,但对此了解有限),不过它确实包含对象。Fossil则将标签与文件、提交等数据一并纳入区块链。

    2. 我的意思是,种子下载本质上是去中心化的,从技术层面无法被彻底取缔。但完全有可能让参与者在法律层面付出代价——正如海盗湾、Megaupload的遭遇,或是围绕个人种子用户形成的整套“停止并终止”函产业所示。

      故意违反版权法能让你走得很远,但涉及巨额利益,所以一旦引起错误的关注——通常是因为太成功了——你就会挨揍。

      1. 我的意思是,种子下载是去中心化的,从技术上讲无法被取缔。

        封锁种子流量其实相当简单。

    3. 即便仅是指向分布式文件存储的链接,成本也极其惊人

      1. Github存储约19PB数据,在Filecoin上每年需花费约2万美元。当前Filecoin供大于求,因其正处于投机驱动阶段。

      2. 不会有组织维护它。你只需购买价值100美元的GitCoin,就能获得10000次提交权限,大致如此。

    4. 没错,用区块链技术欺骗GPL许可证。

      这构想足够反乌托邦了,确实。

      若能加入些多余的大型语言模型元素,我们就能更接近“折磨枢纽”的领域。继续努力吧。

      1. 噢,不如这样:开发者无法手动编写提交信息,必须强制让大型语言模型根据上次提交后的差异自动生成。而该模型需在区块链上分布式运行,导致速度极其缓慢,还得用类似“gas”的代币支付,从而产生巨额交易手续费。

        这是我能想到最技术宅脑洞的点子了。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

你也许感兴趣的: