林纳斯·托瓦兹:Linux内核版权许可仅涵盖软件,不延伸至硬件

Vizio在电视中使用Linux却未按要求公开源代码,这显然不合规。

GPLv2 确认声明…

大家可能注意到我通常不在此发帖,但这里提供一份近期法院裁决的PDF文件。由于我平时不维护任何网络存在,也不愿将PDF文件发布到内核邮件列表等平台,这似乎是我分享该文件最便捷的方式。

我之所以想讨论此事,是因为该判决基本验证了我长久以来的观点:GPLv2的核心在于保障源代码的可获取性,而非控制其运行硬件的访问权限。

本案本身是两家劣迹斑斑的企业——Vizio与SFC——的纠葛。双方在法庭上都表现得极其恶劣,原因各不相同。

Vizio在电视中使用Linux却未按要求公开源代码,这显然不合规。

元素周期表

而软件自由保护协会竟试图论证许可证强制要求公开安装密钥等信息——尽管事实并非如此,这恰恰是内核坚持采用GPLv2的根本原因。相关人士对此心知肚明,却在法庭上公然违背事实。

最终结果:双方行为皆有不当。但至少Vizio已修正其行为,尽管显然需要这场诉讼才促成改变。而SFC则不然。

恳请SFC停止利用内核进行虚妄的法律辩论——你们企图将GPLv2的适用范围无限扩张,这只会让你们显得像一群无能的混蛋。

本案中唯一表现出专业素养的是法官,其在裁决中指出:

原告主张“机器可读”及“用于控制编译和安装的脚本”等表述支持其在特别质询第4项中的主张:被告应“交付文件,使普通技术人员能够将源代码编译为可执行程序并安装至同一设备,且在不造成不当困难的前提下保留原始程序的所有功能”。

协议条款措辞明确无误,并未规定本动议所涉义务。

整体解读协议可知,其要求Vizio提供的源代码须以可供原告或其他第三方便捷获取并修改的形式呈现。尽管源代码定义包含“用于控制编译和安装的脚本”,但这并不意味着Vizio必须允许用户将修改后的软件(或任何形式的软件)重新安装回其智能电视,且该安装方式需保留原始程序的所有功能并确保智能电视持续正常运行。在协议语境下,争议条款的实质要求是:Vizio必须以允许原告或其他方获取并修订源代码的方式提供源代码,以便将其用于其他应用程序。

换言之,Vizio必须确保用户具备复制、变更/修改及分发源代码的能力,包括在符合协议《前言》及《条款与条件》的前提下将代码用于其他自由软件。但协议条款中没有任何内容要求Vizio允许修改后的源代码重新安装在其设备上,同时确保设备在源代码修改后仍能正常运行。若此为协议本意,协议本可轻易修改为:必须允许用户修改并重新安装修改后的软件至使用该程序的产品,同时确保产品持续运行。此类条款的缺失具有决定性意义,无依据认定此类条款在此隐含存在。因此,本动议予以批准。

换言之,这明确表明:是的,你必须提供源代码;但不,GPLv2绝不会以任何形式强制你开放硬件。

我的意图——以及GPLv2的意图——都很明确:内核版权许可仅涵盖软件,不延伸至其运行的硬件。正如内核版权许可也不延伸至在其上运行的用户空间程序。

元素周期表抱枕

本文由 TecHug 分享,英文原文及文中图片来自 Linus - kernel copyright licence covers software, does not extend to hardware

共有{91}精彩评论

  1. @torvalds 感谢分享,Linus,很欣赏你对这个话题的见解

  2. @torvalds
    听到你的消息总是令人欣喜,莱纳斯。

    不过必须说:

    我本期待圣诞祝福——而非提醒某些人到了2025年仍不懂GPLv2。

    简而言之(个人观点):

    GPLv2的核心是确保源代码可获取。

    它并非强制厂商开放硬件或提供安装密钥。

    你必须能够:

    – 复制
    – 修改
    – 重新分发代码

    包括在其他设备上使用。

    你无权将修改后的软件重新安装在原始设备上并期待其继续运行。

    开源软件并非强制要求开放硬件的后门条款。

    若此为初衷,许可证本应明文规定。

    但它没有。

  3. @torvalds 这难道不意味着您无法行使自由1:“研究程序运作方式的自由,以及按您所需修改程序以实现计算目标的自由(自由1)”?若仅能阅读软件却无权实践任何修改,从软件自由角度提出质疑似乎合情合理。还是说我遗漏了讨论要点?

  4. @torvalds 好吧,我与他们结盟的意图就此破灭——感谢分享这些宝贵信息

  5. @pkal @torvalds 许可证的意图必须转化为具体可执行的条款。GPLv2 完全缺乏这点,所以根本无从执行。就是这么简单。

  6. @torvalds 这些道理我们都明白,但这也让协议变得毫无用处——既然我们无法自行从源代码重新编译安装,就无法保证或确认交付的源代码确实是硬件中运行的版本。

  7. @pkal @torvalds 据我理解,Linus的立场是:软件自由不能凌驾于硬件制造商对设备功能的设定之上。既然你通过GPLv2获得了软件访问权,自然可以自行制造硬件来运行该软件。
    我尚未形成明确观点,但这与林纳斯公开表态的立场一致。

  8. @xerz @torvalds 我认同,对我们这类人而言这恰恰是许可证的缺陷,但这并非我的核心观点:我更希望了解林纳斯对自由1原则的整体立场。

  9. @torvalds

    我明白这并非您制定Linux内核社会契约的初衷,但有个有趣的思考浮现:

    二进制文件属于衍生作品,因此继承了GPL授予的所有权利。

    拒绝用户对软件二进制文件的写入权限,是否构成对修改该衍生作品权利的限制?

    据我所知,法院裁决仅涉及源代码。

    我未发现明显反驳此逻辑的论据,但本人既非律师亦非专家。

  10. @torvalds

    当然你可以复制后修改副本,但这不等同于修改原始文件。

    通常情况下,我也不会被授予“修改原始副本”的权利。你不会授予我修改你检出的Linux内核副本的权利(这太荒谬了),仅限于我自己的副本。

  11. @torvalds

    但购买预装软件的硬件时,那便属于*我的副本*。该副本通过硬件购买以物理位的形式分发给我。

    我必须被允许修改下载的tar包或购买的USB驱动器中受GPL许可的数据,那么为何不允许我修改通过电视内部闪存芯片分发的GPL许可数据?

    我实在难以在此区分两者差异,但重申:我并非法律专家。

  12. @torvalds @woody

    “换言之,这明确表明:是的,你必须提供源代码;但不,GPLv2绝不会强制你开放硬件设计。”

    完全正确。若GPLv2要求如此,那么你就不能在(真正的)ROM上使用GPLv2代码。传统意义上的ROM是无法定义的——这正是其存在的目的。无论人们是否喜欢,有些场景下ROM确实有其合理性。若硬件必须可修改,那么该许可证下禁止使用只读硬件。

  13. @Atemu @torvalds

    > 我实在难以在此区分,但重申:我并非法律专家。

    谢天谢地。

    不,这份“副本”并非通过闪存芯片分发给你的。你购买了电视机,因此根据GPL许可条款及法官的明确解释,你有权获取源代码。二进制文件绝非“衍生作品”。

  14. @pkal @torvalds 现实情况是,存在约1000种合法规避许可的方式(不仅限于GPL),包括不实际共享源代码或限制他人使用权限。

    说到这个,Linux内核是个企业项目,内核开发者会站在哪边(个人开发者还是企业)显而易见。当然,采用GPLv3也改变不了现状,反而可能让情况更糟。

  15. @RealGene @torvalds

    我希望你不要无端对我进行人身攻击,我也不会继续与你这类人互动。

    但我想向所有人说明:根据版权法,编译成二进制文件的源代码属于衍生作品。

    GPL也明确规定:

    “您可在遵守上述第1、2条条款的前提下,以目标代码或可执行形式复制和分发本程序(…),但须同时(…)”

    (第1条:分发;第2条:修改)

  16. @torvalds 说实话我完全不知道您会使用社交媒体。不过这是条好信息,感谢分享

  17. @pkal @torvalds 你确实有权修改并使用修改后的版本。但你无权在原始版本所在的设备上运行修改版,仅可在其他设备上自由运行。

  18. Neal Gompa (ニール・ゴンパ)说道:

    @kees @torvalds 是的,我从未见过SFC声称其强制要求开放硬件。相反,他们认为人们根本误解了TiVo的行为,这导致了如今混乱的GNU v3许可证问题。

  19. @kbruen @torvalds @pkal 可编程硬件只是执行软件指令。

    据我所知,GPLv2存在漏洞被硬件厂商利用,导致用户获得无用代码,而专有软件却能操控设备及交互数据实施恶意操作。

    Linux包含硬件依赖与非依赖代码。依赖代码缺乏可移植性,除非能将修改后的二进制文件编译并加载至相同设备型号,否则修改毫无意义。

  20. @torvalds 嗯,试一试总没错 ¯⁠⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯

  21. @torvalds 我认同你的分析。关于采用GPLv2作为内核许可证基础的论点我也赞同。SFC试图超越你设定的权限范围,但他们所求是否合理,与所选许可证的许可范围本就是两回事。我尤其厌恶律师们通过层层递进的论证来推导“X蕴含非X”的伎俩——这无异于试图“证明”2的平方根等于2。

  22. @torvalds 我始终坚信copyleft优于版权。但必须承认,两种模式都存在严重缺陷。

    托瓦兹,顺便说一句,我出于诸多原因不信任Vizio。这又成了不购买他们产品的另一个理由。

  23. @torvalds FSF制定了GPL协议,我们不同意你在此处的解读。据我所知,Vizio在其电视中分发了GNU Bash和GNU GlibC,这同样涉及LGPL协议。我本不愿理会你的帖子,但你拥有扩音器效应,可能误导大众。

  24. @pkal @torvalds 我必须反对这种观点。

    软件能否正常运行,有时甚至完全无法运行,并非硬件制造商的法律责任。若真如此,我们大可起诉任天堂——毕竟他们既未支持也未协助在任天堂64上运行现代版Ubuntu系统。

    许多公司恶意滥用这种逻辑推论,但若因此禁止自由软件在任何法律机构使用,将彻底削弱其吸引力。

  25. @tragivictoria @pkal @torvalds 我确实认同Linux已高度商业化,但GPL2的条款本身并无不合理之处,捍卫其本质界限无可厚非——即便这恰恰利好企业。

  26. @torvalds 节日快乐!单篇floss.social帖子容不下你文中所有谬误的讨论。

    这场诉讼主要并非针对Linux——电视机中仅有26个copyleft项目中的一个;存在GPLv2与LGPLv2.1双重许可的二进制文件; Vizio的源代码在多项条款上仍不符合规范。你可能没认真读过我们的实际表述?

    众多Linux开发者对此事关注且观点各异,不妨花时间与他们或我交流?或许会很有趣!

  27. @torvalds 你如何验证他们提供了GPLv2许可要求的所有内容(例如3a条款:“完整的对应机器可读源代码”或3b条款:“完整的对应源代码机器可读副本”)?

    有人可能辩称他们提供了“功能上等效”但与硬件运行版本不同的内容…

    我们只能“信任”他们却无法验证。

  28. @neil 尼尔你好,我很好奇能否对此采取行动?我不确定有哪些法律手段能阻止公司隐瞒GPL许可软件,想听听你的看法

    很乐意私下讨论此事,但想先在这里提及你,看看你对此有何看法

    谢谢!

  29. @torvalds

    我理解并认同你对GPLv2的观点。当然,我同意公司应该能够盈利。

    但话说回来,制造商允许解锁引导程序究竟会损失多少收入?多数现代安卓手机支持官方解锁,但实际操作的用户(发烧友)寥寥无几,绝大多数人根本不会碰这个功能。

    “Tivo化”问题本质上属于立法范畴(如维修权法案),通过修改许可证解决效果有限。

    [](https://linuxrocks. online/system/media_attachments/files/115/778/691/884/482/990/original/dff45908b7822c7a.jpg “奇幻可爱蜜蜂灵梦风魔”)

  30. @torvalds 圣诞快乐,新年快乐

  31. @Logical_Error

    虽然存在少数(但数量有限)的执法案例,Harald Welte 多年来运营着 gpl-violations.org 项目。

    维护开源许可的幕后工作相当繁重,但诉讼仍属罕见。诉讼往往耗资巨大且进展缓慢。

  32. @torvalds

    “奥兰治郡”??🤭

  33. @torvalds 感谢您。即便您很少发帖,每次发声都令人倍感珍视。

  34. @torvalds 实在遗憾。用户理应拥有修改设备运行软件的权利。

  35. patrislav ♾️ #RIPNatenom说道:

    @pkal 这种“自由1”也可理解为“维修权”,不仅关乎自由更涉及可持续性。GPLv2诞生于物联网设备和加密启动ROM尚未普及的时代,遗憾的是它未能涵盖这些领域。

    @torvalds

  36. @ozamidas @pkal @torvalds 病毒式许可证与法律实际运作完全脱节。在欧盟,GPL已被彻底瓦解。

  37. @karen @torvalds 从什么时候起“趣味性”成了软件许可讨论的必备要素?法官明确指出“协议的平实措辞并不支持所谓义务”。这似乎对你而言并非“趣味阅读”,但无论人们/社区“感受”如何,事实已足够清晰…

  38. @kbruen @torvalds @pkal
    关键误解在于:一旦他们将硬件售予你,它就不再属于他们,而是你自己的硬件。

  39. @torvalds 使用GPLv2许可的软件是否意味着*任何人*都能起诉你?

    按理说,若有人违反许可条款,应由软件所有者提起诉讼。虽然这权限可能被授权,但我怀疑SFC并未获得此类权力。

  40. @ghul 我不认同“若真有此意图,许可协议本应明文规定,但并未如此”的说法。这可能源于GPLv2发布时的疏漏——当时未预见到会出现用户无法修改的软件与硬件绑定的情况。从其他文献来看意图相当明确,仅凭GPLv3正是针对此类硬件问题而制定的事实就足以说明。

    主张许可证使用者无意/不在意此事则是另一回事。

  41. @pkal

    我理解这个论点,但认为它在法律和历史层面都站不住脚。

    GPLv2的“疏漏”只有在文本存在歧义时才具有意义。

    法院已明确认定文本不存在歧义。

    在许可协议中,意图由书面条款和双方共识定义——
    而非事后预期或道德偏好。

    GPLv3明确针对封闭硬件而制定的事实,恰恰有力证明GPLv2未涵盖此类情形。

    若当初意图已然存在,GPLv3便无需新增条款。

    有人主张后期需要更强保障是合理之论——
    但这与宣称GPLv2原已包含此要求是截然不同的主张。

    简言之:
    目标演进催生新许可,而非旧版许可的重新诠释。

    许可条款不会因时代变迁而追溯性新增义务。

  42. – GPLv2未涵盖硬件或许是疏忽
    – GPLv3专门解决此问题表明了覆盖硬件的意图
    – Linux继续使用GPLv2并非疏忽,而是内核开发者明确表明不主张硬件访问权限的信号
    @ghul @pkal

  43. 关于第三点:即使内核开发者有意转向GPLv3,Linux也无法轻易实现,因为所有相关方需达成共识,而部分作者因已故无法同意。其贡献需先行替换。

    @osma @ghul @pkal

  44. @wonka @osma @ghul @pkalGPLv2明确允许任何后续版本,而删除该条款实属额外限制且存疑。不过此问题需由法院裁决,对Linux而言这种情况几乎不可能发生。

    但更关键的是社会契约问题。Linux是在GPLv2框架下构建并获得贡献的。修改条款等同于对现有贡献者关上大门。在我看来,这正是Linus在GPLv3推出时强调的核心要点。

  45. @wonka @osma @ghul我从未思考过:若贡献者离世,其继承人是否有权同意将贡献内容重新授权为GPLv3?

  46. @pkal @wonka @osma @ghul 只要没有合同等限制性协议,你始终可以重新授权自己拥有的代码。但你不能移除现有的GPLv2版本。例如Linux内核中就有大量供应商代码采用GPL许可,FreeBSD采用BSD许可,而Windows则采用专有许可。

  47. @kbruen 这正是我的担忧——软件自由终究关乎用户而非制造商😕。我显然无力生产讨论中的硬件类型,使得自由变得愈发抽象。我内心部分认为,这种看似务实的态度源于Linux基金会的资助,但缺乏足够依据将这种直觉转化为论断…

  48. @pkal @kbruen 早在Linux基金会成立之前,Linus就坚持认为TiVo没问题,不过那时候确实无关紧要。他当时也错了,但毕竟是他的项目,选择权在他😄

  49. @Logical_Error @neil 我认为很快会有许多新机遇。软件质量与可追溯性法规、欧盟相关条例等将创造机遇——迫使开发者继续吞下苦果,同时让他们在政府安全法规的监管下声名狼藉。
    当供应商憎恶你时,质量与可维护性便难以实现,这些法规将淘汰大量问题产品(虽非尽是,但多为中国垃圾货)。

  50. @torvalds

    GPL始终是政府法规的临时补丁。显然还有诸多违规现象亟待修正,且必须强制修正。GPL的局限性并不能否定这一事实。

    将电视制造商的设备在售出后仍视为其财产是错误的。应由法规而非GPL强制要求所有商品售出后所有权归属的转移。理所当然。

    或许终有一天政府不会如此落后于时代。可惜,今天还不行。

  51. @etchedpixels 能否在https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt中指出该问题?(或https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/LICENSES/preferred/GPL-2.0)

    我只在第9节看到“后续版本”的表述,且“任何后续版本”的适用性附带了重大条件限制。https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/COPYING明确声明“仅限GNU通用公共许可证第2版”。

    @osma @ghul @pkal

  52. @wonka @osma @ghul @pkal若遵循作者实际发布的许可协议,内核中大量代码过去和现在都采用V2或更高版本。同样,系统调用例外条款也从未获得第三方认可。我认为这根本不是问题,因为初衷很明确,人们有数十年的时间提出异议却始终未见。

  53. @bastelwombat @pkal @torvalds 这听起来像是种相当无用的“自由”,似乎与GPL的初衷背道而驰。GPL的诞生不正是源于封闭源代码的打印机吗?

  54. @karen 他具体指的是关于GPLv2的某些主张,这些主张是否被曲解了?

  55. @leeloo @torvalds @pkal 是的,但在制造过程中,这是他们的硬件。因此根据林纳斯的观点,制造商不应被迫在生产过程中预留空间供用户安装自编译的Linux系统。

  56. AUSTRALOPITHECUS 🇺🇦🇨🇿说道:

    @zl2tod @iank @torvalds >> 我本不该认真对待你的帖子,更不会回应,但你手握扩音器可能误导众人。

    这很奇怪,对吧?这位先生刚承认自己是个混蛋,这篇推文里根本没有留出辩论的余地

  57. @leeloo @kbruen @torvalds @pkal

    正因如此,我们早在1999年就停止销售软件,转而采用租赁模式。(此外,当时引入的加密狗存在千禧年漏洞,必须在系统上线前收回用户手中的设备。)

  58. @namedbird @torvalds

    据我理解(作为IANA律师,更别说美国律师了):
    – 普通用户乔·六罐啤酒要求获取$Modified_GPLd_SW的源代码副本;
    – $GPL_violator拒绝配合。
    – 乔·六罐啤酒现在有权投诉并提起诉讼。

  59. @torvalds 关键在于逻辑本就颠倒。我们真正需要的是更多#OpenFirmware以及#OpenHardware

    归根结底这是市场先例的问题。消费者理应有权获取所购硬件中所有固件的源代码。

    这完全是另一个问题。涉及各种许可和分发问题的复杂丛林,与Linux无关。

    正因如此,#CoreBoot 才成为如此卓越的项目,同样值得大力支持。

  60. @trashheap 软件自由基金会(SFC)的所谓“论点”纯属垃圾,向来如此。关于许可证的问题根本不存在争议,多年来我已多次明确表态。SFC对此心知肚明。

    因此当他们在法庭上曲解GPLv2条款时,绝非在执行GPLv2。他们试图推进的议程从一开始就站不住脚,且公然违背实际版权持有者的意愿。

    SFC纯属垃圾组织。

    若他们真想“保护”某个项目,就该保护主动寻求保护的项目——而非明知对方拒绝此类保护的项目。

    因为他们干的纯粹就是敲诈勒索,简单明了。

  61. @iank 在发表如此荒谬的言论前,你最好先让自由软件基金会董事会审核——因为你错了。

    @torvalds 同样有误,但原因不同,比如他根本没读懂SFC的实际声明。

  62. @wonka @osma @ghul @pkal 摆脱圣诞白利酒影响后重读此文,我明白你的意思了——是的,我认为你在这点上说得对。

  63. 让开启硬件访问权限的法律撬棍成为现实:硬件制造商向终端消费者出售而非租赁产品。若他们剥夺新所有者在图灵完备通用处理设备上安装任何操作指令的核心财产权,则应动用具体财产法而非知识产权法作为正确工具。

  64. @ghul @pkal 据我所记,GPL v2大约是1988年?
    那时ROM芯片、游戏卡带等二进制代码早已普及。“内置软件控制硬件”的问题早在此前就存在,而GPL从一开始就刻意回避了这一领域。
    1988年我在工业用8088单板计算机上,还得用螺丝刀拆卸两个ROM芯片安装高度专有的软件更新。

  65. @WellsiteGeo GPLv2发布于1991年,v1版则在1989年问世。其基础源自1985年的GNU Emacs通用公共许可证(GNU其他部分也采用类似条款)。

    GPL(任何版本)与ROM始终高度兼容。TiVo事件性质不同,而@torvalds惯于忽视这一事实(正如本讨论串中他完全无视SFC的陈述)。

    @ghul @pkal

  66. @torvalds 该许可确实明确不涵盖硬件,但同样明确的是其意图在于允许修改设备行为(FSF在LGPL中费尽心思描述如何在无需访问完整源代码的情况下保留此能力即为明证),而非仅限于研究代码及在其他平台运行修改版本。

  67. @amszmidt 你为何认为我在忽视或曲解SFC的声明?因为我对他们多年来的表态实在再熟悉不过。

    你认为加州高等法院法官也误读了SFC的声明吗?因为那位法官同样认定其论点毫无现实依据:

    协议的明确措辞并不支持所谓义务

    (此处“所谓义务”指SFC关于设备可重新安装功能的无端主张)。

    我认为你根本没读过判决书,可能只看了SFC关于“持续正常运行”这个完全无关紧要问题的胡扯——这正是Vizio拒绝发布密钥的所谓“理由”。

    换言之:我会读判例。高等法院法官会读判例。我认为需要学习如何读判例。对于SFC在法庭上——以及其博客上——的言论,你最好持保留态度。

    我理解有人青睐GPLv3许可,希望Linux内核采用该许可。但事实并非如此,过去没有,将来也不会。

    面对现实吧,别沉溺于毫无根据的幻想。

  68. Feike 🇪🇺🇳🇱 🚫👑说道:

    @torvalds 嗯,这是你——以及所有贡献者共同的项目

  69. 这不正是GPLv3的核心初衷吗?内核却始终未采纳。为防“Tivio化”

  70. @torvalds 没想到Fediverse还能发布PDF文件。

  71. @amszmidt @WellsiteGeo @torvalds @pkal

    GPLv2始终对ROM友好。

    后来的争议并非关于固件的存在性,
    而是硬件是否必须接受修改后的固件。

    这个问题直到GPLv3才得到解答。

  72. @torvalds 当人们谈论“GPLv2的初衷”时,往往不明确指的是GNU组织制定时的初衷,还是您选择该协议时的初衷。双方基本处于各说各话的局面。

    我认为在法庭上提出任何论点都无可厚非,民事法庭本就为此而设。法院支持你的观点固然可喜,这样内核就不必重新授权。但即便法院支持SFC也并非世界末日——毕竟GNU制定GPL时显然不愿存在此漏洞,众多采用GPL的开发者同样不希望自家软件受此漏洞影响(希望他们现已改用GPLv3)。

  73. 彼得鲁斯·希拉里乌斯说道:

    @torvalds @trashheap 又一个曾经清醒的人彻底失控了。随你便吧。让他们自便。或许该直白点说句“滚蛋吧你们这些想复用旧硬件的蠢货”,让你的倒退立场昭然若揭。

  74. @cyberia @torvalds 真是遗憾。我支持“修改权”和“维修权”,但坦白说GPLv2并未涉及设备本身,仅针对软件。若设备运行需依赖密钥等要素,GPLv2并未授权其运行权限。

    这不仅关乎我们对许可证的期望(尽管托瓦兹有权阐明其意图),更关乎许可证的实际条款。法官指出:

    若此为协议初衷,协议本可轻易修改为:用户必须被允许修改并重新安装修改后的软件至使用该程序的产品上,同时确保产品功能持续正常。

    GPLv2对安装脚本的表述存在模糊性,法官指出正因这种模糊性,该条款并不涵盖设备上的重新安装行为。若需涵盖,则“协议”(即GPLv2许可)应明确作出规定。

  75. @rostedt @torvalds 是的,我的意思是,我试图跳出技术细节的局限,思考问题的核心在于赋予用户对自有设备进行修改的自由。

  76. @torvalds 我再补充一点——若硬件必须开源,那他们就该全程采用FPGA芯片而非ROM。这并非反对开源硬件,只是表明我同样认同法官的裁决。

    依我之见,GPL v2与GPL v3都必须并存。这将为制造商和软件开发者提供更多开源许可选择,从而决定是否采用开源硬件。话虽如此,容我再抛个观点——若改装者想在自己的Vizio电视上安装定制软件,无论许可条款如何他都会这么做,所以SFC抱怨的问题本质上本就无法控制。

  77. @ghul @torvalds

    我始终持此观点。开源代码与硬件开放性是两个完全不同的议题,若涉及硬件所有权,则需另行解决。

发表回复

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

你也许感兴趣的: