讨论：我的胰岛素泵控制器使用Linux内核，它也违反了GPL协议
我决定联系Insulet索要内核源代码，毕竟该系统采用GPLv2许可协议，他们有义务提供
我只是想在这里发泄一下，或许说出来能带来些改变。
我是1型糖尿病患者，依赖胰岛素维生。自2021年起，我开始使用Insulet公司的OmniPod Dash胰岛素泵——纯粹因为厌倦了打针。它通过名为“PDM”的设备进行控制，我手头有几台备用机（因某些设备故障不得不更换，还有因电池召回更换的设备等等）。大约两年前我开始研究旧手机的定制ROM开发，于是决定拆解其中一台备用Dash PDM，结果发现——
它运行的是Android系统。而Android基于Linux内核。通过执行uname -r命令，我发现其内核版本竟是3.18.19——如此古老的版本用于医疗设备着实令人惊讶。但无论如何，我决定联系Insulet索要内核源代码，毕竟该系统采用GPLv2许可协议，他们有义务提供。多次邮件尝试均未获回复。该PDM硬件实为贴牌的中国手机Nuu A1+，于是转而联系Nuu公司寻求帮助。对方仅回复简短一句：“感谢联系NUU支持团队。很抱歉，目前我们无法提供该信息。” 我再次回复强调其法定义务，重申GPLv2许可条款，却收到回复：“再次告知，目前无法向您提供。我可联系工程师，但需等到下周中旬才能获得回复。”我表示理解，一周后收到邮件：“很遗憾，仍无法提供。” 此事距今近两年，尽管多次尝试，我始终未能从Nuu或Insulet获得任何进一步回复。
这种行为实在令人作呕。违反GPL本身已属恶劣，更何况是涉及医疗设备？这可是我与数千人生命赖以维系的设备！这种行径绝对不可原谅。只需30秒就能打包内核源代码生成.tar.gz文件，上传至服务器发送给我，但Insulet及其ODM厂商Nuu却以某种理由断然拒绝。设备还运行着已终止支持8年的3.18内核，搭载终止支持7年的Android Marshmallow系统，并通过蓝牙与胰岛素泵本体通信——整台设备堪称巨型安全漏洞，而拒绝共享内核源代码的行为更令人疑窦重重。Insulet究竟为何视核源为禁忌，不惜一切代价也拒绝公开？
另有一事虽与核源无关，但该设备完全缺乏AVB或任何分区验证机制。在缺失八年安全补丁的糟糕基础上，任何人只要拿到PDM设备、一条MicroUSB线和mtkclient工具，就能随意刷写任意程序。我在另一个子版块展示过PDM的root过程，一家市值210亿美元的公司竟无法在设备中部署连50美元手机都具备的安全措施，实在荒谬至极。
恳请有能力者协助揭露Insulet违反GPL的行为。距我首次联系已近两年，至今仍未取得进展，这种状况令人作呕。说实话，我已束手无策。
编辑：许多人认为我运气不佳，因为ODM厂商是（Nuu）公司，但我并不认同这种说法。我认为Insulet同样掌握内核源代码——他们对软件进行了大量修改，且在约2022年的硬件升级中（我掌握足够PDM设备可证实），某项改动导致原始Nuu A1+的boot.img无法在PDM上运行，这表明Insulet实施了某种引导程序和内核修改。Insulet是美国公司。
> 我随后决定联系Insulet获取其内核源代码，由于采用GPLv2许可协议，他们有义务提供源代码。
从技术角度而言，此说法并不准确。这虽是对常见情况的过度简化，但实际流程通常应为：
1. GPL要求公司向用户发送源代码的书面提供函。
2. 用户凭此要约向公司索取源代码。
3. 若用户未收到源代码，可因公司未履行承诺(即提供源代码的要约)而起诉。此举并非违反GPL，而是直接违反合同——此处合同指明示的源代码提供要约，而非GPL协议本身。
需注意：若用户最初未收到书面源代码要约，则上述流程完全失效。此情形下用户无权要求源代码，因其从未获得源代码要约。
然而，版权持有者可立即以违反GPL为由起诉该公司，因为该公司未向用户发送书面源代码提供通知。无论该公司是否实际向用户发送源代码，其最初未向用户发送书面提供通知的行为本身即构成GPL违规。
(本人非法律专业人士)
此为悬而未决的法律问题，希望Conservancy诉Vizio案能带来转机——该案中Conservancy主张消费者有权通过强制执行GPL获取源代码。
几天前这篇帖子在HN被淹没了，实在可惜：
https://social.kernel.org/notice/B1aR6QFuzksLVSyBZQ
林纳斯怒斥SFC裁决有误，并强调内核采用的GPLv2许可绝非强制要求开源硬件。GPLv2的核心精神在于推动软件改进回馈社区。
这引出了关键问题：此人获取(推测为)内核源代码后将如何处置？强迫将改进成果回馈内核？而这些改进很可能根本不存在。尝试在医疗设备上运行可能致命的定制软件？可能性极高。
法官在Vizio案中的裁决表明：即便此人获得源代码，也无权修改/重装系统并要求其继续作为胰岛素泵运行。
这简直荒谬至极——好比购买飞机票后，竟认为自己有权索取机载娱乐系统Linux的源代码。
许多人正在破解胰岛素泵，其技术水平已领先商业产品光年之遥。若想探索极具趣味性的领域，不妨用谷歌搜索“人工胰腺破解”。
一个值得关注的链接：
https://www.drugtopics.com/view/hacking-diabetes-the-diy-bio…
我更相信这些系统黑客的动力远超制造商——他们绝不敢搞砸，这就像驾驶自己亲手组装的飞机。
> 这相当于驾驶自己组装的飞机
绝妙的比喻——毕竟这种行为会致人死亡。我个人绝不会将代码推送到他人的胰岛素泵(或宣传代码适用于胰岛素泵)，因为若因我的漏洞导致他人丧生，我将永生难赎。
我知道确实有人因此丧生(通用航空事故)。但胰岛素泵制造商的员工并非都怀有同等使命感，我反而预期他们做得更差而非更好。
据我所知，闭环系统从业者从未因工作失误致死，他们通过严格同行评审确保安全标准。在这种情境下，我宁可把生命托付给开源项目，也绝不选择闭源方案。至少开源能让我评估代码质量——嵌入式领域的代码水平可谓天差地别，既有令人惊叹的杰作，也不乏令人咋舌的糟粕。
> 我预计他们会做得更糟，而非更好。
正因如此才存在诸多系统与流程(有时被称为繁文缛节)，旨在防范不良后果，而非将薄弱环节寄托于单个人的能力！
世上违反规程、钻空子的动机远比无能的开源黑客多得多。
任何亲力亲为的行为都存在风险。有人因焊接用除油剂清洗的零件丧生，有人死于驾驶、潜水、跳伞、蹦极……
宣传代码在我看来就像炫耀极限运动。我认为这无可厚非，一份完善的免责声明足以消除任何负罪感。
据我所知，尚未有任何死亡案例被归因于开源人工胰腺系统。与此同时，已有数起死亡案例被归因于闭源血糖监测仪。
并非归因于。FDA的措辞使用的是“与…相关”，其因果关联性要弱得多。
凭我三十年糖尿病患者的亲身经历，我可以向你保证：每天——以最不可思议的方式——我都险些“丧命”。无论是使用指尖采血检测、传感器、胰岛素笔注射，还是胰岛素泵管理。我们的生命始终在“不足”“过量”与“严重过量”间微妙平衡——那种“这次真要命丧黄泉”的平衡。
出于个人选择我使用商业CGM(若能“触摸它”，我定会确信自己会因愚蠢而丧命)，但看到“相关联”这类表述实在令人愤怒。监管机构在对开源世界(过去十年该领域革命的源泉)进行如此微妙的暗示前，应当睁开眼睛看看当前传感器质量的真实状况及其引发的实际问题。
感谢。
愿你坚强。我曾有位商业伙伴与你相似，每次他迟到十分钟我就焦虑不安，若超过一小时，我便会致电他家人确认安危。
然而确实有人在为这些设备推送代码。每一台设备都如此。
所以核心问题在于——这些自建泵的开源开发者，与那些受雇于公司的随机程序员相比，究竟投入更多还是更少？后者所在的公司显然连许可细节都搞不清楚，且怀揣盈利动机。
更鲁莽吗？或许吧。但至少他们的动机是正确的。
所以自制飞机比商业航班更安全，因为动机一致？明白了。
你身为某大型飞机制造商(非波音)的工程师，利用业余时间与同事们共同推进一项业余项目——为老式小型私人飞机添加现代安全装置。尽管该机型仍持有政府认证，你却认为其存在安全隐患，而你投身这个领域正是为了拯救生命。
你的“原型机”是原始制造商生产的飞机，未进行物理改造，仅通过软件补丁利用飞机原有传感器数据，防止计算机在强风条件下出现混乱——这种混乱已导致两起致命坠机事故。
现在你需要乘机出行，可选飞机要么是曾发生过致命事故的机型，要么是你改装过的同款飞机，而今天风势正劲。你会选择哪架飞机？
这个比喻太贴切了。尤其与那两架飞机的遭遇形成绝妙对照。
绝对不会选我自己写的未经测试代码！
开玩笑吧？你有多少次在不完全理解的代码库里无意间引入了漏洞？这根本是软件工程的基本门槛。
> 绝对不是我自己写的未经测试的代码！
没人说它未经测试。
> 你有多少次在不完全理解代码库的情况下，无意中引入了错误？这基本是软件工程的入门门槛。
这同样适用于公司雇来做这件事的人，现在我们又回到了“更有动力做好这件事的人，正是出了问题会丧命的人”这个论点。
我实在无法判断你是否真的认为：某个在地下室写代码的普通人，能与拥有API文档、设计规范、实际测试硬件、众多深谙项目风险的资深工程师团队、以及层层监管验证机制的公司相提并论。
但若你当真如此认为——哇哦。这倒真让人看清了Hacker News用户群体的本质。今后我将更谨慎选择回复对象。
> 我实在不明白你是否当真认为，某个在地下室写代码的普通人，能与拥有API文档、设计规范
你的意思是缺乏这些资源很危险？那安全关键设备厂商就该强制公开所有资料才行。
> 实际测试硬件
普通人为何无法购买测试硬件？若属实应解决问题而非借口。
> 参与项目并深谙风险的众多工程师的专业知识
他们难道没有网络访问权限？若已离职，这可能是获取信息的唯一途径。
字面意思就是链接的页面上正在发生的事。
> 更别提他们还要遵守各种法规和验证流程。
法规是为了防止他人伤害你。你不需要政府激励来保护自己免受自我伤害，你天生就具备这种自我保护机制。
怎么测试的？凭100%的“单元测试”覆盖率？我当然能理解网络上的随机人士可能充满干劲且确实有才华参与这类项目。但他们没有商业实体的预算和资源，没有同等的尽职调查要求，也不承担同等的法律责任。若我使用未经修改的商用设备，设备故障或缺陷导致伤害时责任在厂商。但若我在医疗设备上安装网络软件导致故障伤害，责任全在我。
作为可能改装自身医疗设备的人，我如此强调，只因资本主义对“垃圾化”的追求和对利润的极致渲染已让我彻底幻灭。普通网民根本无法对这类系统进行可靠测试，这需要数百至数千个测试案例的严苛验证。他们最多只能分享自己和少数自愿尝试者的成功方案——这种模式既无法规模化，安全性也绝不高于企业解决方案。
为何人们总认为随机公司的产品自动优于“DIY”制品？
我完全理解，出于责任归属和资源优势，人们会期待公司产品“安全可靠”。但关键在于：当你的屁股真要坐上去时，我敢打赌你会比某个随机公司的随机工程师谨慎得多。至于大公司的资源分配，通常更多倾向于营销、法律(包括游说阻挠“维修权”立法)等领域以最大化收益，而非真正投入到质量提升上。
我曾在两家从事“关键任务系统”的大公司工作过，天啊！我能告诉你不少关于他们产品安全隐患的故事，以及他们投入多少资金在“推卸责任”上，而非让产品更优质/更安全。
我以为已经解释清楚了，但还是用更通俗的语言说明吧。医疗软件不仅要解决特定用户的难题，还必须适用于多数寻求特定病症治疗的群体。某个CPAP用户通过调整设置适应自身生活方式的效果，并不能推广到所有CPAP用户身上。提供通用解决方案的企业承受着远超随机GitHub仓库的监管压力。企业若因产品致人死亡可能面临诉讼，但若因你在胰岛素泵里安装网上找到的随机脚本导致家人死亡，想让法庭判企业赔偿？祝你好运。
这和企业是否关心民众毫无关系。这完全关乎责任法则与受害者如何获得赔偿。这完全关乎安装随机网络脚本的实际风险，与必须跨越监管障碍的企业之间的差异。并非说企业永远正确——它们也常犯错。但它们是在监管监督下犯错，而你却要我相信没有监管的随机网络用户能做出更优秀的产品？简直荒谬。
我在其他评论里解释过，但容我再为你剖析：
所谓的“责任”、‘审查’、“监管”只会催生“自保措施”、官僚作风、繁文缛节和成本增加，几乎没有任何真正提升质量或安全的实质举措。我在一家关键任务系统公司工作，他们根本不在乎安全，只关心能否全身而退，或避免在赔偿死者家属时损失太多钱。
> 但祝你好运——当你把网上随便找的脚本装进胰岛素泵后，想说服法庭赔偿你家人损失？
更别提要起诉制药公司了。顺便说，你提到了CPAP话题。或许你闲暇时可以读读这个案例[1]，因为那是场轰动性丑闻，他们最终付出了代价。但90%的情况下他们不会赔偿。即便像这个案例，扣除法律成本后分摊给所有受害者，也算不上真正的补偿(剧透警告：这种情况永远不可能发生！)。
请注意：本案中他们明明知晓问题却无动于衷。责任追究和监督机制形同虚设。
[1] https://www.drugwatch.com/philips-cpap/lawsuits/
> 但他们不具备商业实体的预算和资源。
每个人都站在巨人的肩膀上。你不可能一个月内从石器工具跨越到喷气发动机，但你完全能在同一时间内修复其中一个的漏洞。
> 他们无需承担相同的尽职调查要求，也不必承担同等的责任。
这些机制旨在缓解委托他人创造依赖性产品时产生的激励错配问题。但最理想的状态是让激励机制从一开始就保持一致。
需注意这些措施仅是最低标准而非上限。企业只需履行最低义务，你可自由超越这些要求。
> 若我使用未经修改的商用设备，当设备故障或缺陷导致伤害时，责任在企业。若我在医疗设备上安装随机网络软件导致故障伤害，责任在我。
若社区版本修复了可能致命的漏洞，而你坚持使用商业版本导致死亡，你完全可以起诉他们谋杀——当然，前提是你还没死。
> 普通网民根本无法对这类系统进行可靠程度的测试。
基本上所有网民都参与其中，这群人自然包含所有为企业工作的测试人员。难道他们下班回家就会忘记工作技能？当他们或家人拿到其他公司的设备时，难道不会希望它正常运作？
驾驶自己组装的飞机，可能比乘坐同型号但由企业用最低价劳动力组装的飞机更安全——后者还会逼你签署二十页律师撰写的免责声明。
数十年的数据证明这种说法站不住脚。自制飞机的事故率远高于工厂制造的飞机。
你真要把业余爱好者的技术水平，和专业工程师在公司装配线上经质量控制的设计相提并论？
凭什么认为业余爱好者制造的实验性飞机更安全？
为何你认为一个对某事充满热忱、愿意投入所有闲暇时间的人，会比仅为谋生而工作的人技艺更差？
抱歉。比起某个接受过基本指导后就被放任自流的人，我更愿意选择由充满热忱者打造的产品。
在此语境(通用航空领域)下，我们并非将空客/波音与车库改装机相提并论。我们比较的是：某小型企业制造双座机，而你拥有机库及十名持证飞机机械师全程协助。
你为何认为诉诸情感的论点具有逻辑性？诚然他们未直接引用，但即便假设其成立，事故率的实证研究才是推导结论的逻辑基础。你个人偏好、情感反应及预期结果皆无意义。
你还在偷换概念。对方明确指涉的是资质模糊或不明的业余爱好者群体；而你却将讨论限定在拥有认证技师的小型企业等范畴。两者显然不属同一类别，使你的论点完全脱离主题。在责任归属讨论上也存在矛盾——小型企业及其技师(无论由谁操作)都需承担责任，而“随机仓库”则不然。
请参阅我后续评论(“同类模型”)。医疗设备软件开发与自制软件(甚至更糟的情况)的相似度，远高于航空工程领域。
你写得好像对医疗设备代码库经验丰富似的，我敢打赌你根本没接触过。有本事证明我错了。
你不可能真心相信这种观点，否则根本无法在社会上立足。
既能相信又能正常生活。
我们不自制飞机并非因为质量更差，而是耗时太久。我可没两万小时去钻研飞机原理再自己动手。
倘若能将知识直接植入脑中，再配上物质制造器，我想确实会——人人都会造飞机。或许更安全些，我也不确定。
关键在于，这些想法并非相互排斥。你可以同时相信两者，并在内心与现实中达成调和。
我不是原帖作者，但那只是讽刺，并非字面意思。
另外，自制飞机绝对更糟糕——即便你拥有专家级知识。任何复杂设计都如此。飞机设计、材料采购、制造加工、装配测试和质量控制都需要不同技能，但真正关键的是经验。
商用飞机之所以如此安全，是因为投入了大量精力调查和理解事故根源，更投入了更多精力实施设计改进和机组培训。
不，不是讽刺。你不可能一边认为自己比所有人都优秀，一边认为其他人都不称职，还能正常融入社会。
若真如此，你很可能患有未确诊的精神疾病。
>你不可能一边认为自己比所有人都优秀，一边认为其他人都是无能之辈，还能在社会上正常生活。
欢迎来到HN。
这篇帖子让我如梦初醒。今后得更谨慎选择回应对象。
这让我想起当年发现这里竟有大批自由意志主义者，他们竟认为驾照制度是压迫。
症结在于系统在奖励无能。那些按技术工资计酬、细致检查确保万无一失的机械师，在会计的电子表格里却成了醒目的红色问题，最终被优化淘汰。
系统可通过流程可重复性、冗余设计等方式弥补缺陷——这正是民航比通用航空更安全的原因，也解释了我为何特意强调“同型号飞机”的限定条件：若你放弃自组实验级套件飞机，转而委托责任限制公司雇佣最低工资工人按说明操作。我猜这种模式违反联邦航空局规定，但这恰恰印证了我的观点。
再举医疗系统为例：医生本是高智商群体，却因诊疗时间被切割成十分钟碎片，加之整个体系围绕责任推诿运转，导致大量聪明正直的人最终因系统性失灵而沦为严重失能者。我更希望能信任医生给出的任何诊断，而非被迫自行研究并争取权益来推动诊疗进程。但现行体系根本不按这个逻辑运转。
关于体系激励机制，我完全认同你的观点。我对资本主义的厌恶程度丝毫不亚于你！
但我依然相信身边的机构能保障我的安全。当然这取决于居住地——若我仍在巴西生活，感受必然不同。
上次看医生已是三年前的事。五分钟诊断完毕，十分钟完成治疗并开具处方。体验极佳，令人称心。
听起来你对生活的诸多领域都存在信任危机，或许该重新审视自己的认知框架。或者干脆搬去能让你安心的地方。
很高兴你至今经历顺利！不过“五分钟诊断”听起来根本不像处理复杂病症。
我确实一直在尝试从体系中获得良好结果，即给予信任，但情况总是一再受挫。当问题在于我深入探究细节时，反复发现所谓专业人士如何彻底忽略关键问题，这真能说是“信任问题”吗？
最新例子：我需要一台新洗碗机。按理说，我只需读几篇评测，花上千美元，问题就该解决了，对吧？再猜一次——首台送货的机器，因运输时猛烈撞击导致塑料框架变形，在金属内胆上压出凹痕(折痕)。第二台送货的机器，洗涤电机发出刺耳噪音。我联系保修服务，想着只要他们更换整个泵组件就行。结果维修人员连基本工作都不愿做！“这很正常无需维修，这是好型号，您该留着。”第三次尝试时洗涤电机声响稍缓但故障依旧。第三批送货员甚至没带走旧机(尽管我坚持要求他们更换，他们却说“有人会晚些来处理”)。我本想直接付钱解决问题，结果却被留下两台噪音洗碗机和一堆麻烦事。(该继续按换货按钮吗？还是直接订购新泵组自己修理，毕竟有额外洗碗机补偿？干脆放弃这个品牌重新考虑购买决策？)
当然，我完全可以降低标准，放弃较真，不再在意细节。那个凹陷的浴缸十年后大概也不会漏水，只要只在夜间使用，嘈杂的电机其实也没什么大不了，就算几年后需要更换电机，也只需200美元的维修费。但花了一千美元后，拒绝接受这种“尽力而为”的服务，真的该归咎于“我”的问题吗？这更像是经济层面的问题——只是我恰好具备专业知识，能察觉设备应有的运作状态，并有勇气据理力争罢了。
(尽管我庆幸眼前这件令我恼火的事是家电故障，而非再度陷入医疗体系的泥潭)
我的观点基于这样一个事实：个人组装的飞机与波音等厂商生产的整机是完全不同的机型。我确实认同，如果真存在737套件机，其安全性必然低于生产线上的成品机。
即便如此，我仍会更信任塞斯纳飞机，而非任何由单人制造或改装的飞机。
我认为比奇飞机公司的“丰收者”值得特别提及。相信参与制造的每位技师都是专家！
这个类比的最大问题在于混淆了三个关键要素：
– 通用航空本身就更危险，这是事实。无论你自己组装飞机还是购买成品(希望是新机，若二手则需保养得当)都改变不了这个本质
– 通用航空飞行员经验普遍不及民航机组，但民航飞行员担任通用航空飞行员时的表现往往更差。原因很简单：正是流程规范保障了商业航空(基本)安全。
– 通用航空事故常导致飞行员丧生，因为机上往往只有他们一人。
– 通用航空器与大型飞机同样会发生故障，这点并无特殊性。但它们缺乏大型飞机具备的关键要素：冗余性。这种冗余体现在电子系统、机械部件设计乃至人员配置中。
– 由操作者自行设计制造的通用航空器被归为实验机类是有原因的：未经测试的机型比获得认证的机型更易发生故障。商用飞机的设计流程与业余爱好者采用的设计流程相比简直微不足道——我们特意用“爱好者”一词来区分两者。
– 最后，尽管这个类比很有趣，但我的本意仅从利益相关角度出发：通用航空爱好者仍会竭尽全力确保自身安全。而波音高管只关心利润，安全不过是次要考量。根据我对比航空电子设备内部构造及其运行软件与医疗设备内部构造及运行软件的经验，我敢打赌：黑客圈对这些设备的故障模式了解程度，远超制造商本身。
无菌环境下的洁净室制造是关键差异点，但这仅适用于硬件领域——而医疗行业对此已驾轻就熟。电子行业整体技术水平本就较低，其软件知识往往极其匮乏，更不必说相关软件的质量保证流程了。
企业程序员在工作中未必会突然长出额外的质量脑。
看看Bede BD-5这类飞机，它夺走了多少业余建造者的性命。仅首飞阶段的死亡率就高达10%。
附注：飞机可不是在洁净室里组装的。
坦白说，你根本一窍不通，整个过程中几乎每件事都搞错了。
波音航班上的乘客本该得到更合理的动机解释。
结果他们遭遇了麦道式的对待。
事实证明，动机的重要性远超你的想象。
https://news.ycombinator.com/item?id=46398414
> 我相信这些系统的黑客比制造商更有动力确保系统安全
我认为恰恰相反。黑客仅需承担自身生命风险，而企业则要为众多生命负责且面临诉讼。黑客当然不愿丧命，但他们愿意承担风险。
公司搞砸这件事的绝对最坏情况，就是被起诉且对方胜诉，或者被迫和解。你得赔点钱，发个公开道歉之类的。如果情况真的糟糕透顶，公司可能倒闭。但你很可能依然比普通人富裕得多，而且责任分散得足够广，没人会受到刑事判决——毕竟这本来就不是现实的选择。
个人搞砸此事的基本最坏情况是丧命。
>搞黑客的人只冒自己性命的风险
是啊，仅是自己的性命——你知道的，对他们而言这东西既不值钱也不值得珍惜，可企业财务状况可不一样！
没错，但被起诉基本是风险最低的活动了。好吧，说得有点夸张：你不会坐牢，而且如果你有钱，即使变穷了也比大多数人过得好。从纯粹的绝对主义角度看，当老板基本上永远比当雇员风险小。
> 搞这个黑客的人只冒自己的生命风险。
只要不危及他人，这完全是他们的权利。
许多其他回复都提到类似观点：“当然人们更有动力避免失误，毕竟他们更在乎自己的性命，不像企业那么在意被起诉”。没错，这在普遍情况下成立，但：
– 有人尝试穿翼装穿越狭窄障碍物却失手
– 有人自制飞机直升机试飞丧生
– 有人打造深潜器探访泰坦尼克号，呃，成功率并非百分之百
– 有人制造蒸汽火箭机车丧生
“毕竟是他们自己的命，不会搞砸”这种说法根本无法解释上述行为。
我认为在家自制医疗设备固件的行为，更接近于冒险家式的“给我攥着啤酒”式举动，而非寻常之举。
这些都与普通糖尿病闭环系统黑客无关。你把追求刺激的人和努力生存的人混为一谈了。
他们同样是过度自信(包括自以为比他人更懂行)最终犯错的人。
我认为这与普通糖尿病闭环系统黑客的处境大相径庭。
请拿出证据证明医疗设备公司里为“老板”效力的嵌入式程序员，比闭环设备黑客更优秀更有动力。
你竟将一群伪装成死亡狂热者的家伙，与那些极度渴望改善生活质量且极其谨慎行事的人相提并论？事实上若你深入了解，会发现他们对细节的疯狂关注和极其严谨的流程，完全不逊于我所见过的工业标准，甚至可能更胜一筹。
本帖讨论让我想起当年人们嘲笑那个和伙伴们自制操作系统的芬兰少年。毕竟没人会把生意、财产甚至生命托付给开源项目。
我查证过，这里是Hacker News而非BSA论坛。
我认为“既然是自己的生命，自然比’官方机构’更谨慎”这种论调站不住脚。
现实中不乏“明知故犯”的案例：许多人无视专业医疗建议“自主决策”，最终酿成悲剧。这些人绝非寻求刺激的冒险者。
即便在HN的其他讨论中，你也能看到从“我不信任设备，坚持每日指尖检测”到“我信任直觉和设备，不再做指尖检测”的各种观点，这说明黑客群体的立场存在相当大的差异。
我绝非否认有人能成功破解设备，甚至做得比制药/医疗公司更好。
只是我不认同所有执着破解者必然优于这些公司——毕竟他们赌的是性命。现实中太多人因自以为掌握命运而酿成悲剧。
好吧，这次证据摆在眼前：这套方案确实可行。他们已解决大部分技术难题，甚至可能全部攻克。制造商们气急败坏，因为他们眼中的“实验对象”——那些被剥夺自主权的普通人——竟能反过来展示技术实力。毕竟，当一群普通却技艺精湛的人都能做到时，他们为天价产品辩护的理由几乎荡然无存。
我以观察这些公司为生，平均每两周就研究一家。我审阅他们的代码库，采访他们的工程师。其中并无神奇秘诀。真正理解工程本质、不把产品视为牟利途中微不足道障碍的公司实属罕见。医疗器械公司在这方面普遍不例外(尽管我确实知道一家例外)。
但好吧，你觉得这些公司雇员的价值就比那些身处险境的工人更高。恕我不敢苟同。
> 但好吧，你认为这些公司雇员的价值就比那些身处险境的人更高。
这并非我的论点。
我的观点是：身处险境本身并不能使某人更具价值。
确实如此，但此处的言论暗示他们更差劲且不可信任。我对此持反对意见。他们至少同样优秀，甚至可能更胜一筹。
> GPLv2的初衷在于将软件改进成果回馈社区。
或许最终法院会判定许可条款的字面含义仅限于Vizio案法官所述义务。而林纳斯完全有资格权威阐释当初同意将内核置于GPL许可时的初衷。
但我认为许可条款本身——尤其是冗长的序言——以及促成GNU项目和自由软件基金会诞生的动因， 他们为起草/发布该许可证所开展的倡导活动类型，以及此后的一切行动，都表明GPL的精神与SFC针对限制设备所有者自由使用权的厂商所采取的行动完全一致。
为何荒谬？若许可证明文规定你有权获取已分发的软件源代码，那么获取源代码的权利即已确立。无论你计划如何使用该代码都无关紧要。
关键在于许可证本身并未直接赋予你获取源代码的权利。唯有单独的书面承诺才能赋予你该权利。若未收到此类承诺，你便无权索取。但此时公司已毫无疑问地违反了GPL协议，可立即对其提起诉讼。关键在于：你无需事先向公司索要源代码！缺乏书面承诺本身就是明确的违规行为。
> 但此时该公司已毫无疑问地违反了GPL，可立即对其提起诉讼。
您至此的论述完全正确。需处方的医疗设备必须通过专业供应商获取，如同药房销售硬件设备。此类器械因误用可能导致危险，故不直接面向终端用户销售，持续气道正压通气(CPAP)设备亦在其中。
理论上，书面许可通知只需发送给设备供应商即可——而供应商几乎普遍对源代码毫无兴趣。当设备转售给用户时，无需附带源代码许可通知。
若此逻辑成立，任何转售安卓手机的行为都可能引发法律责任。试想普通eBay卖家忘记在满是指纹的二手手机上附带开源软件声明的情形。
> 若此论成立，任何转售安卓手机者都可能面临法律追责。
这纯属诉诸嘲笑的谬误。若此类谬误成立，我反驳如下：
若此论不成立，则任何公司只需通过经销商等中间商渠道销售产品，便可肆意违反GPL协议。
此乃诉诸法律的论点：版权用尽原则(亦称首次销售原则)规定，设备首次售出(即售予分销商)时版权即告用尽，分销商无权控制或阻止后续销售。
GPL可能无法实现其初衷，既非法律论证，亦不足为奇。
这是否意味着所有最终用户许可协议都因软件通过零售商销售而无效？即便非零售渠道，用户也能轻易获取二手副本？
据我理解，EULA基于合同法，通过点击式协议要求用户在使用前同意条款，而非版权法。除非在版权法层面，它能阻止你创建衍生作品——前提是该衍生作品不要求用户在使用前同意点击式协议。
这怎么解决问题？爱丽丝买下软件，点击“同意”使其运行，然后转卖给从未同意协议的鲍勃。
在法律术语的深处，爱丽丝已同意不进行此类转让，即“不可转让许可”条款。
这不正是违反首次销售原则的部分吗？
我认为通常的论点是：你并不拥有数字商品，你拥有的是使用许可，而该许可直接存在于你与原创者(或其经销商)之间。你无权转售该许可。
不，如果该行为本身违法——因为爱丽丝签署了禁止此类销售的合同——则另当别论。
GPL明确允许销售行为，此处操作完全合法。
> 不，如果该行为本身违法——因为爱丽丝签署了禁止此类销售的合同——则另当别论。
违约的正是这份合同本身，不是吗？倘若获取副本需签署放弃合同权利的协议，首次销售原则还有何意义？更何况，州级合同法如何能凌驾于联邦首次销售原则之上？
“衍生作品”的漏洞似乎也很脆弱。通常让对方同意某项条款的方式是：对方需要从许可中获得相应权利，而不同意就无法获得该权利。但若许可本身未授予对方必需的权利，那么“在无需同意附加条款的情况下，仍可合法使用已拥有副本”的默认状态，恰恰是你试图钻空子突破的困境——这岂非对方利用漏洞的根源？一旦出现疏漏，你又将如何自处？
假设爱丽丝是个三岁孩童。她拥有副本，按下按钮后便获得了运行副本——尽管她尚无缔约能力。随后鲍勃从她手中购得副本。又或者爱丽丝持有副本而卡罗尔按下按钮，此时卡罗尔可能面临诉讼，但她也可能身处异国他乡。无论哪种情况，爱丽丝都获得了从未承诺不出售的运行副本。此时你或许想辩称“这属于欺诈”，但这种欺诈程度并不比你此前诱使对方同意的行为更低。
同样地，GPL协议本质上也是契约——至少至今无人证明其非契约性质，而SFC将竭力证明其契约效力。
当然，姑且不论它是否成立，假设它是，那么合同双方应为制造商与版权持有者。该合同允许制造商向分销商分发软件，而无需分销商同意条款或成为合同方。分销商随后可销售预装该软件的设备，无需获取许可或成为合同方——因为版权已耗尽(首次销售原则)。
最终用户许可协议通过强制点击式协议使终端用户成为合同方来规避此限制。而GPL通常不存在约束分销商的点击式协议，且GPL本身不要求创建或维护此类协议，因此即使原始软件附带此类协议，制造商也可自由移除。
这就像我购买二手书后，未经原作者或出版商同意就复印并销售该书的情况吗？
这类似于买卖二手书时未获得著作权人授权就传播其受版权保护的作品——这种行为本应获得授权。
若仅持有单本且不复制，这种模式难以规模化。我敢说这在商业上不可行。
全球二手书店和图书馆都让这种模式运转良好
它们通常会批量购入书籍。
分销协议通常不同于销售。分销商作为制造商的代理人，此类交易尚未计入销售额。多数保修仅限首任所有者且不可转让。你认为这与保修条款如何兼容？难道意味着我在Costco买的洗碗机没有保修？正是基于分销商作为代理人的原则，制造商才能与你签订合同。
> 首次销售原则规定：设备首次售出(即售予分销商)时，版权即告耗尽。
版权在向分销商售出复制品时并未消失。某方(很可能是制造商)仍对版权持有者负有法律义务。
版权赋予的权利与GPL许可证不同——后者并非基于版权法，而是基于合同法(正如其名称所示——许可证)。
物品的销售并不转移这些许可(但这些许可对卖方仍然有效——销售小工具的制造商必须遵守GPL条款。若该小工具的最终用户需要源代码，则必须直接向制造商索取，而非通过任何中间商渠道)。
关于分销商所购副本的后续分发权限，该权利确实会消失。
> 当设备转让或转售给您时，无需附带提供源代码。
此说法错误。转让方必须履行以下义务之一：传递其接收的许可要约(仅限非商业性再分发的GPLv2第3(c)款)，或直接提供源代码(GPLv2第3(a)款)。
据我对美国法律的理解，首次销售原则意味着第3条((a)和(c)项均不适用)，版权已耗尽，中间方无需任何许可即可转售设备。即便主张GPL属于契约而非单纯许可，中间持有者也从未被要求成为契约方。即使因某种原因他们同意了契约——且该契约在完全缺乏对价的情况下仍具约束力——法院似乎也不太可能解释条款3适用，因为根据首次销售原则，转售设备不构成版权法意义上的“分发”。
我的安卓手机确实附带了明确的书面源代码获取条款，位于设置>关于>法律声明中。
> 理论上，该书面条款只需提供给设备供应商即可。
GPL明确规定了接收方，并未提及供应商。
你先前已撰写过精彩的顶层评论，深入剖析了“提供”与“交付”的差异，引发诸多讨论。我只想强调：无论法官最终如何裁定条款含义，要求软件许可条款得到适用与执行绝非“荒谬”之举。
这是需要处方的医疗设备，无法直接购买。他们也不向你分发软件。你必须通过医疗设备供应商，在保险支付部分或全部费用后才能获得设备。
同理，你不可能从垃圾堆里捡到飞机娱乐系统，然后打电话给公司索要源代码。
形式并不重要。GPL代码的编译二进制文件正在被分发。接收该二进制文件者有权获得GPL部分的可用形式源代码：
此处GPL的效力仅限于内核边界。用户空间是独立的，除非其中也链接了GPL代码。若开发者对链接边界疏于管理，责任自负。
你仅聚焦软件许可条款的片段，却未理解这些许可及交易背后的合同法与版权法环境，这已偏离正轨。
若你向法院提交的诉状仅围绕“GPL代码的编译二进制文件正在分发”这一主题展开——你将一无所获。
我恳请你学习如何识别相关方、何时形成何种合同、版权豁免的最低限度标准，以及代码中不受版权保护的部分。
该目标代码的接收方是医疗设备供应商，而非最终用户。
设备经处方验证后转交予您，且不附带源代码提供要约。
换言之，涉及认证医疗设备时，请始终视您为第二任所有者。
据我所知，即便在垃圾堆捡到安卓手机，您也无权索要源代码——因购买交易中从未收到源代码提供要约。您知道那些新电子产品开箱时随手丢弃的“开源软件声明”小纸条吗？
> 购买交易
被许可方必须向用户(更准确地说，向任何第三方)提供代码。该条款并未规定用户必须购买产品才能成为合法使用者。
> 换言之，涉及认证医疗设备时，请默认所有情况下的用户均为第二手持有者。
按此逻辑，任何公司只需先将设备售予签约经销商——该经销商承诺转售时_不_提供源代码——便能实质规避GPL限制。
据我理解，如果我在代码中使用GPL许可，并将代码分发给他人，而该人又转发给其他人…GPL许可依然有效。我不明白为何使用GPL软件的硬件设备会例外。
您是否不同意这种逻辑？您将GPL代码刻录在DVD上分发给我。我将该DVD转赠他人。由于我未复制源代码，故不涉及版权问题。但若我复制DVD并将ISO文件通过邮件发送给他人，则构成分发行为，此时版权条款即产生效力。
GPL约束所有分发GPL许可作品的实体，包括转售商。无论是否复制，分发行为本身即构成许可约束。
并非如此。未经同意者不受其约束。未同意者可能构成版权侵权并承担赔偿责任，但断言其约束所有分发者实属谬误。
他们是在无权分发的情况下进行分发。唯一允许其分发的依据是同意以特定方式执行许可/合同。若未履行该协议，则无权分发。来源方声称否则亦不能改变此事实。
许可随副本转移，正是许可赋予副本合法性。
若许可未随副本转移，则副本即属无许可状态，构成版权侵权。许可载明限制条款与授权权利，任何违背均导致许可失效。
你根本不懂自己在说什么，别再妄加揣测。
那么当我通过亚马逊购买含GPL代码的产品时，亚马逊就拥有获取源代码的权利？那家医疗供应商的收入，正是来自终端用户支付的医疗保险。
> 这家伙拿到(推测是)内核源代码后要做什么？逼中国人把改进成果回馈给内核？
正如Reddit原帖所言，Insulet是美国公司。
>这引出了关键问题：此人拿到(推测是)内核源代码后会做什么？
这并非问题所在，但答案是：对比掌管此人生命的软件与原始版本的差异，检查是否植入了后门、游离指针等漏洞。
强烈反对！若他们分发代码，同样要承担GPL源代码的责任！
这简直荒谬至极——好比购买飞机后就要求获取其使用的GPL源代码。
> 林纳斯怒斥
林纳斯针对的根本不是保守协会的实际主张，而是个稻草人论点。详见https://sfconservancy.org/news/2025/dec/24/vizio-msa-irrelev…。
> 这引出了关键问题：此人打算如何处置(推测中的)内核源代码？
https://openaps.org/
若你体内植入了心脏起搏器，是否认为自己有权修改和更新其运行软件？另外，你觉得这主意可行吗？
> 若你体内植入了起搏器，是否认为自己有权修改和更新其运行软件？
当然有。人们体内植入医疗设备后，竟被剥夺了解设备运作细节的权利，这种做法令人发指。
> 另外，你认为这在某种程度上是个好主意吗？
在极少数情况下，是的。具体原因可参考凯伦·桑德勒关于植入式起搏器及其缺陷的演讲。
虽然不是当事人，但我赞同。你完全忽略了人们有权了解自己体内装置的工作原理。
你的解读意味着他人必须为你的任性买单，尽管法律条文另有规定。
我认为这种立场荒谬至极，恕我必须直言不讳。
第一个问题显然是肯定的。谁能剥夺你操作自己心脏的权利？当然这通常不是明智之举。
>> 尝试在他医疗设备上运行可能致命的定制软件？极有可能
这句话令人痛心。这不仅是严厉的指控，更是反维修权运动的核心论点。我认为这种论调极其虚伪且别有用心，尤其(如同罗斯曼先生)对此深恶痛绝。
或许主要动机是：a) 好奇心作祟，b) 纯粹为验证他们是否遵守许可协议而寻求刺激。
> 林纳斯发飙了
每周二都上演，根本不算新闻。
尝试在他医疗设备上运行定制软件，很可能危及他的生命？可能性极大。
原厂软件也未必安全：https://sfconservancy.org/blog/2025/dec/23/seven-abbott-free…
此处的论点是：若存在要约，根据标准合同法他们本就应履行义务。
若仔细阅读我的论述，你会发现我从未主张相反观点。第三方是否具备起诉GPL侵权的资格与我的论点无关，且这些论点均非“悬而未决的问题”。
> GPL要求公司向用户提供源代码的书面要约
需注意这仅是分发GPL代码二进制文件者可选的三种方案之一。该方案虽最常见，且仅适用于非商业分发，但他们采用此方案的可能性极高。
另一种方案是随二进制文件附带源代码。
这将导致一种有趣的可能性：有人可能获得二进制文件却无人有义务提供源代码。据我所知此类情况尚未实际发生，但似乎迟早会出现。
假设X公司决定打造通用硬件平台供其他企业采购用于产品开发。该平台本质上是集成WiFi、蓝牙、双USB接口、多个以太网口及GPIO接口的小型单板计算机，并预装了移植至该硬件的Linux系统。
当X公司发货时，系统会随附一张预装Linux发行版的SD卡，其中包含其定制内核。系统默认从第一个SD卡槽启动，随后运行定制登录系统：该系统会检测第二个SD卡槽，若存在卡则挂载该卡，在根目录搜索名为application.exe的可执行文件，并以root权限运行。X公司随设备附赠小型U盘，内含SD卡中所有内容的源代码副本。
其设计理念是：当Y公司需要制造WiFi接入点或空气质量监测器等设备时，可向X公司采购这些主板，将其装入外壳并配置所需外设(如空气质量传感器)，编写应用程序软件后写入SD卡，再将该SD卡插入第二个插槽。
假设Y公司向X采购1000套系统，组装成1000台接入点设备进行销售。
若某客户要求Y提供GPL组件的源代码，Y是否必须提供？
我认为无需提供。Y并未复制或衍生作品，仅是接收X提供的实体副本，未经修改地转交客户。这完全符合美国版权法中的首次销售原则，以及其他司法管辖区的类似规则。
若客户向X索要副本呢？
X确实制作了副本和衍生作品并进行了分发。但X通过在发给Y的每块电路板中附带含源代码的U盘，已满足GPL要求。
你的意思是，在一般情况下，若你向他人发出书面要约后又拒绝履行，就构成违约？
这听起来不太合理。
书面要约不等同于合同。
书面要约是许可协议的组成部分，回应要约时提供源代码同样是协议要求。这些条款构成同一份协议。
仅凭书面要约本身通常在多数(甚至绝大多数？)司法管辖区不具备直接可执行性，其原理类似零售商无需承担错误标价责任(至少在英国，标价仅构成“招标邀请”， 而非合同或其他承诺)，除非其他法律法规(如反诱饵式营销规则)或避免舆论法庭争议的考量产生效力。
但在此情形下，书面要约及其响应均构成已达成共识的更广泛许可协议的一部分。
> 这与零售商无需承担错误标价责任的原理相同(至少在英国，标示价格属于“要约邀请”，而非合同或其他承诺)
这什么鬼？在我们这儿，价格标签就是一种公开合同，卖方需预先承诺。卖方忘了更换标签？那不是买家的问题。
既然钱还没交到对方手里，你随时可以在柜台前决定不买。至少在我去过的国家，这不具法律约束力。
这依然属于诱骗销售
只有故意为之才构成欺诈。若发现问题后立即更正错误价格，则(法律上)无妨。若错误价格持续展示，或刻意标出以吸引顾客，则属于诱骗销售。
另一种典型的诱饵式欺诈是宣传根本不存在的商品，企图诱使顾客转而购买更昂贵(或价值较低)的商品。
我认为并非如此；我记得GPL许可文本中并未明确将书面要约与GPL本身建立关联。
根据第4条[1]规定：
第6条亦有类似条款。
[1] https://www.gnu.org/licenses/old-licenses/lgpl-2.1.html
该条款(及第6d节类似条款)并非指书面提供源代码。书面提供源代码的义务实际规定于第6c款。
啊…谢谢
> c) 随作品附带一份有效期至少三年的书面要约，承诺向同一用户提供上述第6a款规定的材料，收费不得超过执行此分发的成本。
那么根据本帖迄今阐述的法律理论，任何人都无法起诉他人，且不存在提供源代码的义务。版权方无法起诉，因为许可条款已履行(提供了要约)；最终用户也无法起诉，因为该要约无需实际履行。
或者，与其推演理论依据来论证其不可行性，不如“直接”起诉对方，看看法官是否认同。
要约与承诺是合同成立的要素。没有要约就不可能存在合同。
若你接受某人的要约，且该要约满足有效合同的其他条件——恭喜你，此刻已形成合同关系。任何一方违反约定即构成违约。
> 书面要约不等同于合同。
要约是合同成立的先决条件和组成部分
客户支付金钱购买产品及随附源代码，这是交易组成部分。不履行交易部分即构成违约。
我认为他们只是说明GPL本质上不涵盖消费者/分销商的(不)协议，仅涉及版权问题。尽管GPL精神倡导用户优先，但仍需在版权法框架内实现。即便许多人混淆了精神目标与法律协议，它并未赋予“用户”任何特殊法律权力。
不履行书面承诺本身并不违法，违法的是违反许可协议传播受版权保护的材料。
因此GPL本质是许可方与被许可方的契约。若代码及许可协议未向用户共享，则用户并非契约主体，而是受益方。
提供源代码的行为，似乎是通过选择加入机制将源代码与目标代码分离传递的一种方式，而非通过法律手段制造用户-被许可方合同的伎俩。
尽管该提供行为可能确立许可方-用户义务，但合规分发仍会附带许可协议，从而将用户转化为许可方，并以递归方式形成许可方-许可方关系。
不知是否有律师专攻此领域？这听起来既酷炫又非常规，却与合同法存在某种契合性。
本人非法律从业者
这并非他们的本意。
货架上陈列着三台胰岛素泵：一台附带五年保修，一台廉价无保修，还有一台附带书面要约——允许你在未来三年内随时免费获取源代码(并根据GPL条款制作衍生作品)。
权衡利弊后，你选择了第三款。致函公司索要GPL源代码，对方却拒绝了。这已构成违约。
Linux采用的GPLv2许可证并未禁止该胰岛素泵在用户尝试安装未经制造商签名的“衍生作品”时自动锁死。
对于可能危及生命的设备，这种设计不仅可行，更是审慎之举。
此论或许成立，但与你回复的帖子无关。
争议焦点在于是否应向你提供源代码。
也许严格来说不算“违约”，要约也未必构成合同。但若你违背自己提出的要约，必然要承担某种责任。否则所有要约都将失去意义，变得毫无价值。
> 你必然要承担某种责任。否则所有要约都将失去意义，变得毫无价值。
在民法(合同法即属此范畴)中，无需承担“刑事责任”即可承担民事责任。“有罪”是刑法概念，并非合同可执行的必要条件。
通常情况下(存在例外)，单纯的要约**不具备强制执行力，亦不会形成合同。合同成立需具备其他要素——双方达成合意，且对方为接受要约采取相应行动——此时合同才具有可强制执行性。
我认为在多数情况下，未履行要约并不构成任何过错。
要约具有法律约束力，当他人基于该要约采取行动时，你可能需承担损害赔偿责任。
但这并不强制你履行原始要约。
此类要约与任何投标书具有同等法律效力。当然合同纠纷可能出现任何结果。
具体损害赔偿指什么？
三年期限的书面要约仅是一种许可分发方式。若从未发出要约，则不受该条款保护，必须通过其他方式履行义务且不享有三年缓冲期。
没错。我未涵盖这些情况是因为几乎无人会这么做。
我指的是，企业遵守GPL最简单、最廉价的方式就是随软件附带源代码。将其压缩存放在某个目录里即可。公司随后便可置之不理，无需担心有人联系他们抱怨源代码和GPL问题。但没有公司这么做。
另一种简单方法是：企业在用户下载程序的同一位置提供源代码下载链接。若用户错过下载机会，那是用户自身的问题。此举同样能让企业免于GPL相关顾虑。但同样没有公司这样做。
(GPL为个人及非营利组织提供了第三种途径，此处不作讨论。)
若撇开额外步骤不谈，根据GPL条款企业终究有义务提供源代码，此说法似乎并无不妥。
本人非法律专业人士，但理解如下：
书面要约中的对价是什么？口头承诺无法在法庭上强制执行。合同要具备可执行性，必须存在对等交换，而非单方面承诺。
https://www.law.cornell.edu/wex/consideration
对价存在替代方案。若想深入研究，可搜索“信赖损害”和“承诺禁反言”。
在美国或许如此。但在德国，终端用户似乎可直接起诉索要源代码。
或许吧。谁能起诉谁不能起诉与我的观点无关。但我严重怀疑有人能因源代码提起诉讼。有人可能因损害赔偿起诉，公司可能通过提供源代码达成和解。但据我理解，除非公司主动选择此举而非支付赔偿，否则任何公司都不能被起诉并被迫交出源代码。
我不清楚德国相较美国的情况，但上述说法有误。在美国，强制特定行为的诉讼绝对可行(且极为常见)。参见：推定信托、强制禁令、禁止性禁令、特定履行、撤销权、令状。
不过在美国，你很可能拿不到源代码。若对方坚决拒绝披露，最终结果通常是处以罚款并禁止继续分发。
重申：这或许是美国的做法。在德国，似乎可以为任何应得权益提起诉讼，而不仅限于金钱赔偿。
> 这并非GPL违规，而是直接违反合同
但GPL本身就是合同
我认为你指的区别在于GPL许可方与被许可方之间的合同关系，而非被许可方与用户之间的关系。
(本人非法律从业者)
> 但GPL本身就是合同
根据其创立者的原始理念并非如此，但观点存在巨大分歧。不过这与核心问题无关：真正未被履行的是一份独立于GPL的书面要约，而非GPL本身。若你未收到此类书面要约，GPL本身并不能保证你拥有获取源代码的权利。
> 若您未收到此类书面要约，GPL本身并不保证您有权获取源代码
错误。根据GPL提供源代码的要求主要受《GNU通用公共许可证v2》第3条和《GNU通用公共许可证v3》第1条约束。GPL的核心宗旨正是确保软件使用者能够获取该软件的源代码。
GPL 2第3条规定：公司必须在提供产品时同时向用户交付源代码(此时用户已持有源代码)，或向用户提供书面源代码获取要约。需注意：若选择第二种方案，公司本身并不受GPL约束必须提供源代码。此时仅书面承诺才构成公司提供源代码的义务；仅书面承诺赋予用户获取源代码的权利，而非GPL本身。
务必阅读置顶评论——自称曾任职该公司的网友提供了内部信息。
据我所见，当硬件开发被视为成本中心并外包给不同供应商和团队时，此类情况相当普遍。这些供应商和团队人员流动频繁，当初参与项目的人员极少会通过合同或直接雇佣形式继续与公司保持关联。
一线支持人员缺乏处理此类请求的能力。运气好的话，邮件会在内部被推诿，项目经理们玩起“烫手山芋”游戏直至此事被遗忘。若通过公司法务渠道或许能有所进展，但更可能的情况是律师们权衡你引发实际法律纠纷的概率后，决定置之不理。
曾在某家GPL纠纷频发公司任职时，我首要建立的规则是：每次发布都必须存档备份GPL压缩包。我们培训支持人员转发请求的流程，并亲自处理这些事务。十次中有七次，对方会因误以为GPL赋予其获取我们全部源代码的权利而愤怒——当发现tarball中仅含GPL许可代码时便大失所望。这让我真切体会到此类请求中存在的荒谬之处(当然不包括Reddit帖子中这种礼貌且知情的请求)，这也可能是支持人员不愿处理这类请求的另一原因。
> 十次中有七次，对方会因误以为GPL授权赋予其获取全部源代码的权利而愤怒，当发现tar包中仅含GPL代码时便大失所望。
若非GPL代码直接链接或紧密交互于任何GPL代码，这些用户的要求本就合理。
理查德·斯托曼关于链接的观点是错误的。
据我所知，理查德·斯托曼关于链接的观点源自自由软件基金会的律师团队。这些律师依据美国版权法，就何为“衍生作品”向基金会提供过法律建议。
若欲反驳FSF律师的观点，请提供更详尽且最好附有引证的论据(而非单纯断言)。
FSF持有观点但无判例依据——任何其他观点同样有效，因法院从未裁定动态链接是否构成衍生作品。
你必须基于现有法规和相关案例构建自己的观点。
Google LLC诉Oracle America案(593 U.S. 1 (2021))并非支持FSF的判例。
链接行为(无论动态与否)是否构成衍生作品，取决于整合程度、相似性及创造性表达等要素。
我认为FSF在公开声明中表现出不合理的自信——现行法律规定每项潜在侵权行为都需个案裁决。请自行查阅《美国法典》第17编第101条，并与FSF/斯托曼的观点进行对照。
程序链接行为的法律后果存在太多细微差别，唯一能说的就是“视具体情况而定”。
>谷歌诉甲骨文案(Google LLC v. Oracle America, Inc., 593 U.S. 1 (2021))
该判例不适用于GPL许可代码的链接行为。谷歌仅复制了应用程序接口，随后提供了自主编写的代码。
若你链接GPL库，即等同包含其版权代码——即便GNU使用的API并非源自该库，而是来自POSIX等标准。
除非真正提起诉讼，否则一切皆是猜测，而你错失的每一次机会都将永远消失
我建议参考Oracle诉Rimini案，其中第九巡回上诉法院在复杂且尚未解决的案件中明确裁定：为与受版权保护的程序互操作而构建的系统，并不构成该程序的衍生作品。(https://cdn.ca9.uscourts.gov/datastore/opinions/2024/12/16/2…)
他们援引了一个关联性较弱但知名度更高的案例(https://en.wikipedia.org/wiki/Lewis_Galoob_Toys,_Inc._v._Nin…。出于某种原因，链接末尾需要手动添加句点)，该案涉及NES作弊卡带是否构成版权侵权。若直接链接并兼容某程序的作品被视为该程序的衍生作品，那么Game Genie终究是违法的。在我看来这并不合理，考虑到自由软件基金会对主机限制的普遍立场(https://www.fsf.org/bulletin/2025/winter/new-nintendo-drm-ba…)，我认为他们应该会认同这种观点。
> (https://en.wikipedia.org/wiki/Lewis_Galoob_Toys,_Inc._v._Nin…。, 不知为何链接末尾必须手动添加句点)
在某些网站上，可通过对末尾字符进行百分比编码(即百分号后跟两个十六进制数字表示ASCII字符)来规避此类链接化错误：
https://en.wikipedia.org/wiki/Lewis_Galoob_Toys,_Inc._v._Nin…
我认为这两种情况都不适用于FSF和GNU对库链接的态度；因为这两种情况都不涉及创建组合衍生作品。
如果我制作一个人工智能驱动的显示屏，你可将平装书放入其中获得更佳阅读体验，你的平装书依然存在其中且可随时取出。我的显示屏或许离不开书籍才能运作，但它并未与书籍发生任何合并或修改。
Galoob对FSF而言是灾难性的，因为它允许存在仅为增强其他程序而存在的程序。
这完全不符合动态链接绝对主义者的世界观。
呃，称FSF为动态链接绝对主义者似乎有失公允。他们之所以关注这些，是因为把自己逼入了死胡同。他们想阻止人们为copyleft程序编写专有封装层，但又不愿采用过于严苛的许可证——这种许可证会禁止专有程序与copyleft程序交互。而自由0意味着他们无法明确禁止copyleft程序用于特定用途。
虽非内核本身，但LGPL库确实存在相关豁免条款。若你曾听过RMS的演讲，便知他极度注重细节且深谙其中微妙之处。
解决之道始终是联系对方法务部门，最好通过律师渠道。工程师和支持人员不会冒着丢掉饭碗的风险，对涉及公司资产的法律决策妄加置喙。
自由软件基金会若能发布索赔函模板，明确阐述许可执行及损害赔偿追索的法律依据与判例先例，将极大助力此事。
这并非公司资产。
但评估该主张的正是公司法务部门。因为这是法律主张。许可证并非魔法咒语，而是社会契约，非管理层员工不愿因做出管理层决策而惹上麻烦。
这要具体分析。公司仍可拥有其编写的代码版权，即使采用GPL许可。该资产在公司出售等情况下会转移，因此确实属于公司财产。
GPL仅授予使用和分发的权利，不授予所有权。代码不会因此突然进入公共领域。
支持人员甚至工程师无权做出此类决定。这属于法务部门的职权范畴，即便对你而言显而易见。
这理应是最高赞的回答。
确实存在初创公司，其负责人对此并不了解，而开发者因自认最了解问题本质而贸然行动。
但这显然属于法律范畴。
我同意一线客服甚至工程师可能并非合适人选，但负责任的做法难道不该是将请求转交至负责部门或人员吗？
当然，经常收到此类请求的公司会培训客服人员识别特定关键词，比如“许可证”或“GDPR”，这类请求必须转接处理。若缺乏相关培训，就难以理解为何“采用GPLv2许可证”比上一位客户的论点更具说服力——那位客户坚称设备保修条款要求你们立即放下所有工作，修复他报告的轻微界面错误。
衍生作品归创作者所有。具体可操作范围取决于版权条款细节，但基本原则成立。
软件许可违规讨论总让我火冒三丈。
拜托，为了自由软件基金会奉为神圣的一切——若真认为对方违法，直接提起诉讼不就得了？陈述诉求，让法庭裁决。
几百美元的诉讼费？对于医疗设备而言？这笔交易划算得很。
楼主几乎不可能是Linux内核的版权持有者。若是真持有者，他们早该表明身份了。
当前正验证一个理论：提起诉讼无需具备著作权人身份https://sfconservancy.org/copyleft-compliance/vizio.html
那他们凭什么在缺乏诉讼资格的情况下试图执行版权/合同法？
更让我恼火的是，居然有人发博客声称他人版权遭到侵犯。
咦，他们没这么做。是你自己说他们应该这么做。
那他们发邮件的依据是什么？若非基于版权/合同法的法律立场？
编辑：我的意思是这不过是众多烦人角色之一，他们会发邮件指控各种法律违规，自己却根本不懂所提主张的任何依据。
依据？你是指理由吗？
他们想要Linux内核源代码。
不，他指的是依据而非理由。两者有区别，我真心想听听你的解释。
当然明白区别，正因如此才寻求澄清。
我对“依据”概念的理解与发送邮件的情境不符，而“理由”是我能找到最贴切的替代词。
“依据”涉及规则或权威。当询问“X的依据是什么？”时，其假设是存在超越行为者动机的门槛需要满足——需要更多理由而非单纯意愿。这显然不适用于发送邮件的情境。此刻我完全可以发邮件问你最爱吃哪种鱼，或邀你下棋——无需任何依据，只需动机即可。
这番话其实是在委婉表达对方毫无依据却提出要求。
但听起来我们达成共识了：对方确实缺乏提出要求的正当依据。
或许解释得不够严谨，但它不仅涵盖了“没有依据”，更强调了“无需依据”，同时突出了这种在无需依据时索要依据的荒谬请求。
若仅以“没有依据”回应，就如同被问“你是否停止殴打妻子”时回答“是”或“否”。
我们讨论的难道不是行使/主张合法权利吗？
你有理由提出主张，与你有法律依据支持主张是两回事。
我们讨论的是Reddit用户Lost-Entrepreneur439向公司邮件索要代码的事。
这种行为完全可行。无需提及GPL、开源、强制执行或要求等术语，只需简单询问“我正在尝试实现X功能，能否查看Y代码？”。我在工作中经常收发此类邮件。
他们提到GPL是为提高获取代码的成功率。医疗设备公司的客服人员可能对软件许可、Linux或GPL一无所知。若公司有“向索取者发送GPL代码”的政策，而Lost-Entrepreneur439直接索要Linux内核，客服人员可能不知该政策适用，直接拒绝。若你在邮件中主动提及GPL，对方更有可能在内部知识库中搜索“GPL”关键词，从而看到“GPL请求请转发至jeff@ourcompany.com”之类的指引。
GPL协议并非由“迷失企业家439”与该公司签订，因此用“强制执行/行使法律权利”来描述当前情况并不准确。这种情况仅在Linux内核版权持有者介入时才会发生。
编辑：虽然这似乎更多是语义问题。比如法官命令某公司支付你一笔钱，而你说“把钱给austhrow743”——这样说我是否有权获得这笔钱？还是说你拥有的是“我获得该款项的权利”？如果有人想把“Linux内核版权持有者有权要求代码使用者向任何索取者分享代码”表述为“任何索取者都有权获得该代码”，我其实并不反对。
我只是认为请求与主张存在本质区别。提出请求无需认定自己具有法律权利，甚至不必认为获得可能性很高。而Abigail似乎将邮件往来的请求视为等同于法院传票。
现在回到我的核心疑问：为何如此行事？他们索要Linux源代码，公司拒绝提供，为何下一步是发博客而非起诉？这可是医疗设备——重要到值得为此投入资金。
他们却发布博客指控公司违反GPL许可，声称对方触犯法律。
我恳请任何遭遇类似情况的人证明这一点。他们发送邮件的理由是认为自己依法有权获取源代码。*请拿出证据*！这根本不花钱！
在哪个星球上打官司才要几百美元？
405美元
https://www.caed.uscourts.gov/caednew/index.cfm/attorney-inf…
这纯属幻想。好吧，如果目的是浪费时间并输掉官司，那几百美元确实能让你体验这种滋味。但在现实世界里，绝无可能。单次证词陈述的费用就可能达到这个数字的数倍。
当然你可以持不同意见。我猜你从未打过官司，也从未卷入过非小额索赔法庭之外的实质性法律纠纷。你大概连像样的生意都没做过。任何经营者都不会认为诉讼费只需几百美元。
正如我所说，现实世界截然不同。我认识的人在看似简单的案件中耗尽五万多美元(其中一人还自辩)，最终发现只是蜻蜓点水般触及表面才选择放弃。其中一位最终破产，不得不出售房产填补损失，迁居低成本州勉强维生。悲剧。顺带一提，他们并未败诉，只是在耗费数万美元后，面临继续诉讼将陷入更糟境地的抉择，最终只能放弃。
在我年轻气盛时(像多数自以为是的年轻人那样愚蠢)，曾执意追讨某公司拖欠的十万美元合同咨询费。该公司在数年间已支付我逾百万美元，这笔款项绝非小数目。
管理层更迭后，他们干脆决定拖欠供应商款项。这是除裁员外最简易的财务改善手段。巧合的是，新任CEO夫妇恰好经营着一家律师事务所。
于是我聘请了律师(这种事绝不可能花400美元自己搞定)。耗费1.1万美元后，我终于明白力量天平已然倾斜。我或许能赢，但代价可能高达7.5万美元。
然而另一重现实随之袭来：追讨欠款。没错，追讨本身可能耗费更多金钱，甚至引发新一轮诉讼。更别提整个过程将耗费数年光阴。更别提对方极可能申请破产，让我亲身体验用自己的判断当粗糙的厕纸擦屁股的滋味。
事实上，他们确实在18个月后对其他追讨欠款的供应商故技重施。耗时一年将所有资产转移至新公司，待原公司资产清零后便申请破产，怂恿所有债权人把判决书(若有的话)塞回自己口袋。
我反而庆幸只损失了1.2万美元就学到重要教训：法律途径仅适用于对抗实力相当的对手。世事皆有例外，但现实世界通常如此运作。
仍不信？若你是寻求投资的创业者，不妨试试这个： 在会谈中告诉他们：你根本不担心诉讼，因为405美元就能解决问题。千万别眨眼，否则你会错过他们火速逃离会议室的精彩画面。真的。
我亲眼见过，哪怕是应对小混混的诉讼，律师费也绝不会低于几千美元。
这可能暴露我的身份，但我即将仅凭GPT5.x和Claude，外加些诉讼费，就赢下一场针对大学的联邦歧视诉讼。我虽非蠢材却也算不上天才，当年解决Advent of Code 2025的题目时，代码写得一团乱麻才勉强过关。
在我国，公民享有普通法赋予的权利，可自行执行法律且无需支付律师费。在美国，我认为这是法定权利。
虽然我被判承担诉讼费用的风险高于0%，但若仅以微弱差距败诉，我无需支付任何费用。
就是这个。此类诉讼的立案费就是为此准备的。法律并未规定必须聘请律师撰写诉状。
编辑：
法院处理合同法纠纷是家常便饭。这属于他们的日常业务范畴，没什么特别之处。
编辑2：
楼下那位，请提供出处依据
如果败诉被法院判赔对方律师费，费用也是这样计算的吗？
那就用CCB(消费者信贷局)吧？
编辑：我有点生气，明明有这么多工具能解决GPL侵权的争论，却没人愿意使用。
供非美国人/非法律人士参考：
> 版权申诉委员会(CCB)可解决经济价值相对较低的版权纠纷，为联邦法院提供高效且成本较低的替代方案。
https://ccb.gov/
感谢提醒，我本应主动说明并更礼貌地回应。
>似乎没人愿意使用这些工具。
本质上，任何了解情况的人都清楚尝试后的结果往往如何。
若唯一使用的GPL组件是Linux内核，你大概率无权获取任何值得关注的源代码。已确立的法律原则表明：使用内核不会对运行于同一设备的用户空间软件产生GPL义务。此处最可能的配置是完全未定制的内核搭配开源用户空间程序——后者承担所有核心功能。
那么他们提供源代码应该轻而易举。
所谓轻而易举是指他们无需付出任何成本——因为内核极可能未作修改，即便有修改也毫无价值且不涉及商业机密。
但大型企业的官僚体系却让此事变得复杂——该请求需穿越重重审批流程，他们(正确地)判断拒绝随机请求更有利可图。
我确信若你真的起诉他们，他们会立即配合，因为届时支付工程师打包源代码树并发送给你的成本，反而低于聘请律师的费用。
但他们的分析确实正确：没人会浪费时间金钱去起诉获取本可从官方渠道直接下载的标准内核。这也正是此类投诉显得愚蠢的原因——他们既未索求有价值的东西，也未利用GPL推动软件自由(通过开放珍贵代码)，只是在浪费自己和他人的时间索要本可直接下载的东西。
> 因为内核很可能没有改动
这是毫无根据的假设。根据我的经验，只要涉及最微小的定制硬件，就必然需要进行局部调整。
> 他们既未索取有价值的东西，也未通过GPL解放珍贵代码来推进软件自由，只是在浪费自己和他人的时间——索要那些本可直接下载的内容。
很遗憾，这家靠使用受版权保护软件牟取暴利的公司竟要“浪费”200美元在官僚手续、印刷和邮寄上。但这是他们所用软件的许可条款，理应遵守。
> 这纯属无端臆断。据我经验，只要存在最微小的定制硬件，就必然需要进行局部调整。
你有多确定这些微调会构成衍生作品？基于你的经验。
我无法确定任何事。而且这无关紧要。即便只是微调，许可协议依然有效。
不，许可证并不成立！合理使用独立于GPL许可证而存在。
使用GPL软件不会剥夺你依法享有的权利。尽管愤怒的FSF律师们想让你相信——我完全可以按自己选择的方式使用任何GPL软件，并对他们提出的每项指控都援引合理使用作为积极抗辩。
胜败取决于具体使用情境——恕我直言，一个逗号根本站不住脚。
编辑补充：单个逗号在“微不足道原则”的简易判决中必败无疑。你提出的法律理论实在荒谬，不该传播这种观点。
编辑2：野兽男孩乐队曾因三音符采样在简易判决中以“微不足道”为由胜诉。关键不在于这三音符是否属于GPL范畴，而在于法律如何裁定。
若使用GPL适配层(如NVIDIA驱动及其他多数驱动)，此条款同样不适用于驱动模块，因此我不理解作者为何认为存在侵权。
让我猜猜。Omnipod吧。他们还搞过几次恶劣的召回。这辈子都不会把健康托付给他们那套垃圾软硬件组合。向本帖里那位曾供职于此的网友致歉，但希望你现在就职于更优秀的企业。
无需猜测，链接帖文第二行就写明了公司名称。
我的观点是：他们本可以省略提及。胰岛素泵制造商数量有限，标题所指对象显然只有一家。
若他们直接从代码库构建内核，只需指出正确的https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin…链接就足够了…
既然该公司自行构建系统，并非从第三方获取二进制文件转手给用户，且用途属于商业性质，则不符合GPLv2第3(c)条的任一条件——而该条款要求同时满足两项条件才能行使相关权利。
算了。整套系统早已被逆向工程破解。查查Loop、Trio或OpenAPS就知道了。像Insulet这样的糖尿病设备公司对设备被破解的态度向来很宽松。这事其实没多大不了。眼下我们需要的是协助逆向Omnipod 5。
我知道有几个人在研究Omnipod 5的逆向工程。目前最关键的问题是：当PDM/Omnipod 5应用登录Insulet账户时，会通过API获取存储在钥匙串中的私钥(并使用SSL绑定防止中间人窃取私钥)。配对时设备会交换公钥，并通过设备私钥+胰岛素泵公钥生成派生密钥，但目前尚未获取私钥副本以推进破解进程。
是否有渠道追踪进展？我参加过Nightscout会议并咨询过相关情况，但无人知晓可关注的团队，也无人了解该项目的最新动态。
我未发现公开的进展追踪小组，仅在Loop Zulip频道偶遇几位研究者，大家每隔数月有空时才会交流进展。
正想问同样的问题。另外，Omnipod应用是否不使用安卓认证机制，而是直接存储从Omnipod服务器获取的私钥？
它似乎在与Insulet服务器通信时使用Play Integrity API——该API会在设备绑定用户账户后向PDM/应用提供私钥。但由于Pod无法联网，据我所知它无法验证Play Integrity签名，因此转而检查PDM/应用提交的证书是否来自其信任的证书链。
不过并非全部。我正在研究Minimed胰岛素泵的逆向工程(仅限读取血糖数据，不涉及泵控制功能)，目前尚未攻克，至少780G型号仍未解决。但期待未来能实现，或许我也能贡献力量。
我并非美敦力员工。但这种情况极不可能发生。问题不仅在于逆向工程——在最初的美敦力“破解”/逆向工程尝试(即催生原始openAPS系统的项目)之后，FDA已针对胰岛素泵发布了新的网络安全防护指南。
如今所有新型设备中，手机/泵或血糖传感器/泵之间的通信均采用加密传输。
> 像Insulet这样的糖尿病公司对设备被破解问题一直相当松懈
这绝对不是事实，现在更不可能了。
事实确是如此。Insulet和Dexcom这类公司本可对所有涉及逆向工程的开源项目提起诉讼。Dexcom的血糖共享API多年前就被逆向破解，但该公司从未尝试更新系统或阻止非官方API的使用。我只是想说明这些企业根本不在乎。
> 当前所有新型设备中，手机/胰岛素泵或血糖传感器/胰岛素泵之间的通信均已加密。
请问您从何处获得此信息？此处“新型”具体指哪些设备？
此人指的是这份指导文件：https://www.fda.gov/medical-devices/digital-health-center-ex…
我作为医疗设备开发者，正在研究这个具体问题(血糖控制)
谢谢！
所以有人能告诉我——作为非胰岛素依赖型患者——为什么胰岛素泵需要(由？)手机(此处指Nuu手机)来控制？
难道不能以更低成本获得蓝牙控制器吗？非得说“直接用现成硬件——恰好就是整部手机——因为从中国买才5美元”？
这种做法无论产地如何，都让人感觉是在明目张胆窃取数据。
安全性问题…PDM设备完全封闭，无法安装应用，不连接WiFi，所有设置不可更改。关键在于，从技术层面看，PDM完全可能通过注射致命剂量胰岛素直接致人死亡。
有趣的是，同公司新款Omnipod 5现在支持普通手机控制，但仅限美国地区。
直到最近，若想推出可由其他设备(如手机)控制的胰岛素泵，厂商必须配套提供专属“控制器”——即便99.9%的用户已拥有手机。
因此，这款伴侣设备实则是Insulet不得不推出的产物。持续葡萄糖监测仪(CGM)领域也存在类似现象——Dexcom G7虽标榜“控制器”功能，实际仍需搭配手机使用，但厂商仍会额外销售小型伴侣设备。
这其实是监管层面的特殊要求：从FDA角度看，必须提供不含手机的完整独立系统才能获准上市。不过现在似乎不再强制要求配套设备，允许用户自备手机操作的方案已获认可。
所以本质上是这样？
“我们计划让用户通过手机连接并主要使用设备。FDA要求配备主设备/备用设备。既然设备本就由手机控制，那就去找个兼容的手机吧。成本得低廉，反正也没人会真正使用它”
这样解释更合理些。我原以为开发过程是同时设计两款设备，而非先开发一款再确定另一款。
感谢你的见解！
这也是出于安全考虑…在美国以外地区，普通手机仍无法连接Omnipod。
关键在于进食时需告知胰岛素泵，以便及时补充胰岛素。通过应用程序操作肯定比单独的控制器设备便捷得多。
胰岛素泵需与血糖监测仪配对使用。随时检测血糖水平确保稳定，及时修正异常值，这功能肯定很实用。
版权保护效果取决于执行力度。
看来这家公司早明白执法根本形同虚设。
记得博世洗碗机送货时，我无意翻阅说明书，发现他们承诺提供机器嵌入式系统的GPL开源代码。当时心想“这倒有意思，我试试看”，便发邮件至指定地址。结果收到自动回复邮件，大意是：“不行。您非授权人员，我们不认得您的邮箱，不知您何人，恕不奉陪。”
唉，大公司就是这么回事。嘴上应付法律要求，实际却设置重重障碍，让人望而却步——光是尝试突破这些障碍就得耗费大量时间金钱。
我对自己之前的评论感到困惑。博世究竟是如何处理此事的？我重新核查后发现，那封拒绝邮件确实来自他们的邮件服务器，属于典型的“访问被拒”类型邮件——我最初误以为是“您无权访问”的提示，因此感到恼火，但实际上我记错了邮件的真实含义。仔细审视后发现，该邮件并无深意，仅仅表明收件地址(记录在案：oss-request@bshg.com)不存在。这固然不妙，但远不及我上述描述的严重程度。特此向博世致歉(记录在案)。
这与理解知识产权运作机制或调整方案有何关联？无论何种相关性，都绝不会涉及安卓系统运行的Linux内核修改。这不属于内核采用的GPL许可范畴。能否解释这场争议的价值何在？难道仅仅是理论上的法律辩论——即他们是否该公开构建内核的特定源代码树(即便他们真构建过)？
很遗憾您尚未获得回复。我虽非法律专业人士，但问题核心似乎在于：
这涉及以下争议点：(1) GPL是否构成合同；(2) 非签约方能否强制执行GPL；(3) 合理使用原则如何适用；(4) 通过施压/舆论迫使企业公开源代码的手段是否正当？(5) 若实际权利方(Linux内核)提起诉讼，实际诉讼主体应是谁？(首次销售原则可能适用)
看到HACKER新闻里充斥着这样的评论，我震惊不已：
“你搞什么源代码？！别管它！别碰，不安全！大型制药公司比你清楚自己在做什么！”
真的吗？！真的吗？！
我不是说要疯狂修改软件——显然这可能致命。但这种“非巨头药企绝对做不好任何事，看代码绝对会自杀”的论调，实在…不知该怎么形容…太低级了。
这地方虽叫黑客新闻，但老兄，这里许多人离我心目中的黑客形象差得远呢…
“自主权很危险，请剥夺我(以及所有人)伤害自己的自主权！”这种论调不知怎的到处都很流行。人们渴望责任归咎的出口。
出于好奇，向FSF请愿处理这类事务是否有既定流程？
他们如何筛选并决定介入哪些案件？
简而言之：不是FSF而是SFC；请发邮件至compliance@sfconservancy.org
主流法律理论认为，GPL只能由版权持有方强制执行。SFC起诉Vizio的战略意图在于建立改变这一现状的先例——确立终端用户作为GPL项下的“第三方受益人”，使他人也能强制执行GPL；但目前仅版权持有者具备执行权。
因此自由软件基金会仅能在版权已转让给该基金会的项目(即大部分GNU项目)遭遇侵权时介入。若发现GNU项目侵权，处理流程为“发送邮件至license-violation@gnu.org”。克雷格和克日什托夫在筛选举报并决定追诉对象时采用何种流程，本人并不清楚。
许多Linux内核贡献者(以及SFC成员项目如OpenWrt、Git、Qemu)已将其版权转让给SFC或指定SFC为其法定代表人(同样适用于SFC成员项目)，因此SFC可以处理此类事务。同样，您可通过邮件compliance@sfconservancy.org向他们举报侵权行为(详见https://sfconservancy.org/copyleft-compliance/help.html)。
目前SFC掌握的侵权案例远超其处理能力，因此他们会战略性地追查影响重大的案例。具体决策标准我不清楚，但可以肯定的是医疗设备是他们特别关注的领域——执行董事Karen Sandler植入了除颤器，政策研究员Bradley Kühn使用着血糖监测仪，可见其关联性。
> 布拉德利·库恩的
上周我第一次见到这个拼写。
他改名了吗？还是原本就姓库恩，但因美国人难以发音变音符而采用库恩拼写？
他确实改过名字。
https://fedi.copyleft.org/@bkuhn/115461658201124515
多么高明的幌子啊——竟用“请想想孩子们HHHH黑客们！”的论调来打击“维修权”。
你不会下载整辆汽车吧？你不会破解自己的胰岛素泵吧？
认清现实吧：若是GPL许可且易受干扰的产品，责任完全在制造商身上，这是最快且无伤大雅的证明方式。若是GPL许可且经用户修改的产品，滚蛋。
> 这实在令人作呕。违反GPL本身已够恶劣，竟发生在医疗设备上？这可是维系我与数千人性命的设备啊？
真正令人作呕的是不尊重设备制造商——若没有他们，这些设备根本不存在，届时成千上万人将承受痛苦甚至死亡。
想对中国公司执行GPL许可？祝你好运
看来Insulet才是主要责任方，而Nuu(中国公司)只是硬件制造商
关税政策在此正可发挥实际作用
未必如此
可以对单一企业征收关税
或者直接禁止商品销售，何必让美国纳税人替那家企业的罪行买单？
对进口违禁品的企业，常规处理是边境查扣销毁货物，并可酌情对进口商处以巨额罚款。这已是既定流程。
> 进口非法产品
这些产品的“非法”之处何在？
> 对进口商处以巨额罚款
罚款真的能收缴吗？
> 这已是既定流程
该流程是否曾用于处理/civil/软件的GPL侵权？
[已删除]
你为何得出这种结论？难道不明显是Hacker News的用户群体本就偏爱旧版Reddit吗？
我们中有些人就是喜欢旧版，所以从地址栏复制链接时会直接跳转到旧版。
不