硬核观察 #499 马斯克的星链卫星两次导致中国空间站紧急规避
马斯克的星链卫星两次导致中国空间站紧急规避中国向联合国通报称：2021 年 7 月 1 日，星链-1095 卫星与中国空间站间出现近距离接近事件。它之前稳定运行在平均高度约 555 千米的轨道上一年有余，然后该卫星持续降轨机动至平均轨道高度 382 千米，近距离接近了中国空间站。2021 年 10 月 21 日，星链-2305 卫星处于连续轨道机动状态，与中国空间站发生近距离接近事件。中国空间站两次主动实施了紧急避碰措施。SpaceX 已发射 1900 多颗星链卫星，总计拟发射 4.2 万颗卫星。此外，天文学家们也认为星链严重影响了地面望远镜对宇宙的观测。老王点评：在这些卫星真正发挥作用，并合理利用太空资源之前，或许就是一堆太空垃圾，也有可能是太空武器。意大利法院认定开源软件许可证的可执行性12 月 13 日，意大利威尼斯法院在一起涉及 GPL 许可证的案件中，肯定了开源软件许可证的法律可执行性。在裁决中，一家软件供应商因未遵守开源许可的要求而败诉。该案涉及一个 GPL 许可的 WordPress 插件。据该软件的版权方称，它的两名前雇员重新分发了该软件，这在 GPL 下是允许的。但再分发没有包括对原始作品的确认，包括被告对软件的修改信息，也没有提到软件的版权所有者。法院裁决，除了命令被告在使再分发软件符合规定之前停止分发该软件，并按天处以罚款，同时要求他们在其网站对法院的裁决进行明显公示，以及支付超过 5000 欧元的诉讼费用。老王点评：越来越多的法律实践支持 GPL 等开源许可证的法律效力。研究发现 1200 多个能够拦截 2FA 的钓鱼工具包一个学术团队表示，它发现了 1200 多个部署在野外的 网络钓鱼工具包，能够拦截并允许网络犯罪分子绕过双因素认证（2FA）安全代码。在主要科技公司开始将 2FA 作为其用户的默认安全功能后，钓鱼网站发现由于他们无法绕过 2FA 程序，被盗的凭证变得毫无用处。因此，从 2017 年开始，这些网络犯罪分子开始采用新的工具，他们通过窃取用户的认证 cookie 来绕过 2FA，这些 cookie 是用户在 2FA 程序完成后登录账户时在浏览器中创建的。老王点评：果然是道高一尺魔高一丈。下面就看如何应对这些新的威胁了。
硬核观察 #430 软件自由保护协会起诉智能电视生产商 Vizio 违反 GPL
软件自由保护协会起诉智能电视生产商 Vizio 违反 GPL软件自由保护协会（SFC）宣布它已对 Vizio 公司 提起诉讼。Vizio 的 SmartCast 操作系统是基于 Linux 的。Linux 的源代码受 GPLv2 保护。除了 Linux 内核，SmartCast 中的其他受 GPL 和 LGPL 保护的代码包括 U-Boot、bash、gawk、tar、Glibc 和 FFmpeg 等等。Vizio 在 2018 年 8 月就被 SFC 告知，它因没有发布 SmartCast OS 的源代码而违反了 GPLv2。经过一年多的沟通努力，SFC 宣布，该公司不仅仍然拒绝遵守 GPL，而且从 2020 年 1 月起完全停止回应询问。以前，这些案件是为了维护开发者的权利，但 SFC 在这次诉讼中采取了一种新的策略。它是作为一个产品的购买者提出的，这个产品非法地包含了版权代码。这种做法使其成为第一个关注个人消费者作为第三方 GPL 受益人权利的法律案件。你作为购买者也是有权利访问这些源代码的。老王点评：你知道还有哪些无视 GPL 的智能电视生产商？83% 的勒索软件受害者支付了赎金在一项针对 300 名美国 IT 决策者的 新调查发现，64% 的人在过去 12 个月里曾是勒索软件攻击的受害者，而这些攻击受害者中有 83% 支付了赎金要求。在接受调查的人中，72% 的人看到网络安全预算因勒索软件威胁而增加，93% 的人正在分配特别预算来对抗勒索软件威胁。受访者表示，最容易受到勒索软件攻击的载体是电子邮件（53%），其次是应用程序（41%）和云（38%）。专家说，“像‘永远不要支付赎金’这样的天真声明忽略了现实的情况，并没有任何机会在实际改变什么。”老王点评：受害者只要评估支付的赎金低于损失就会支付，但是支付不一定能有结果。微软正式废弃通用 Windows 平台微软把以桌面为重点的 Windows App SDK 和 WinUI 3 作为 Windows 应用开发的未来。Windows App SDK 基本上采用了关键的 UWP 技术和像 WinUI 3 这样不会被向后移植到 UWP 的新技术。微软说，在未来 UWP 将只收到“错误、可靠性和安全修复”，而不是新功能，这表明它现在已经被废弃。现有的 UWP 应用开发者，当然可以继续使用 UWP。但是那些想要“最新的运行时、语言和平台功能”的人，包括 WinUI 3、WebView 2、.NET 5、与 Windows 10 1809 或更新版本的完全兼容，以及任何即将到来的新功能，得把他们的应用程序 迁移到 Windows App SDK 了。老王点评：看来由商业公司支持的软件开发框架方面，没有什么常青树。
硬核观察 #379 机械妖姬要到了 GPLv2 授权的源代码
机械妖姬要到了 GPLv2 授权的源代码前两天我们报道过，深圳一家公司面对外国开发者要求其按照 GPLv2 许可证提供源代码时，让对方到其深圳办公室去取，并表示公司人员只说中文。这似乎听起来是搪塞之辞。网名为“机械妖姬”的 YouTube 网红不信邪，于是和这名外国开发者达成协议，替她去线下索要这份源代码。这个消息在国内发酵之后，引来了许多关注。后继，机械妖姬又继续发布了进一步进展的视频。在视频中，机械妖姬说“因为我不能告诉他们我们不符合 GPL，我们中国人不是那样的。”经过良好沟通后，她拿到了这些源代码文件，并得到了外国开发者对双方的感谢。从这件事，我觉得需要给机械妖姬点赞，也给这家名为 Umidigi 的公司做了正确的事情点赞。另外，说一句，这段视频值得一看。IBM 和 SCO 达成 1425 万美元的和解2003 年，SCO 对 IBM 等 Linux 供应商提出一系列诉讼，指控由 IBM 等贡献与集成进入 Linux 核心的源代码中使用了它的 System V 源代码，违反了著作权。最近，早申请破产 SCO 的托管人与 IBM 于 8 月 26 日向特拉华州破产法庭递交了和解协议，来解决双方在犹他州诉讼案所有剩余索赔，IBM 向托管人支付 1425 万美元。托管人认为和解最符合破产方和债权人的最佳利益，它认为即使打赢官司但赔偿金额未必高于和解金额，而且也有可能 IBM 会赢得诉讼或在反诉中获胜。终于这块破胶布可以扯掉了。苹果商店允许在应用外支付并不会有太大影响之前我们报道过，苹果宣布和开发者达成诉讼和解，允许开发者在其 iOS 应用程序之外提供支付方式，从而免除通过苹果支付所付出的 30% 的“苹果税”。但如果真的想在应用内出售内容，仍然要使用苹果的支付方式，因此也要向苹果支付分成——这依然是许多开发者的痛点所在。如今，应用内购和订阅就是苹果商店的主要支柱，最大创收来源都是免费游戏、流媒体服务和基于订阅的应用，依赖于苹果支付来购买和订阅。看来之前是我天真了，苹果这样的公司怎么会放弃自己的主要利益呢。
Linux 操作系统诞生 30 周年1991 年 8 月 25 日，Linux 之父 Linus Torvalds 在 USENET comp.os.minix 上发布了一个帖子：“你最想在 MINIX 里见到什么？”，首次透露出自己正在开发一个免费、开源的操作系统，并且不使用任何一行 MINIX 的源代码。这个时间被许多爱好者视为 Linux 的真正诞生日期，而非第一个 Linux 内核 0.01 发布的 9 月 17 日，也不是第一个正式版 0.02 的 10 月 5 日。忽忽 30 年，Linux 已经不仅仅是改变了世界，而且已经成为了这个世界不可或缺的一部分。感谢 Linus Torvalds，感谢为之致力的一切贡献者！网红前往深圳公司寻求对方遵守 GPLv2 授权据 Solidot 报道，一位波兰开发者根据 GPLv2 许可证要求深圳的一家手机制造商 Umidigi 提供内核源代码。Umidigi F2 运行了一个修改版的 Linux 内核，根据 GPLv2 许可证要求，该公司在发行产品时需要向消费者提供源代码。但该公司 Ben 的回答是如果要获得可共享的源代码可以在工作时间到该公司深圳办公室里来拿，并表示办公室员工只会说普通话。生活在深圳的 Youtube 网红机械妖姬，与这位波兰开发者在 Twitter 上达成协议，代替对方到深圳办公室去拿源代码。结果被告知 Ben 离开了。就是需要有这样较真的人，虽然我之前不太喜欢这位机械妖姬。三星远程让在南非被盗的电视机变砖今年 7 月南非一些地区发生骚扰，三星公司在当地仓库中的电视机被盗。三星南非分公司宣布，它激活了所有被盗电视机的 TV Block 功能，如果电视机的系列号被监测出属于被盗产品，那么在联网时 TV Block 功能将会被激活，所有电视功能将被禁用。三星认为，这足以限制掠夺的动机，并减轻销售非法商品的市场的产生。电视屏蔽技术已经预装在所有的三星电视上，不会局限于南非市场。这一招比较厉害，互联网化之后的电视的新功能。
硬核观察 | Linus Torvalds 认为 GPL 是 Linux 成功的重要部分
Linus Torvalds 认为 GPL 是 Linux 成功的重要部分Linux 创始人 Linus Torvalds 接受邮件采访回顾了 Linux 的三十年。Torvalds 说开发 Linux 时他真的没有想得太远，更多是一种概念验证，向外展示下他过去几个月的工作成果，更好的理解他的新 PC 硬件。Linux 最初是作为替代品提供给负担不起昂贵的商业 UNIX 系统的人，因此它采用的许可证是不能商业使用。当有人想通过软盘在本地的 Unix 用户组分发 Linux 但想要至少收回软盘的费用后，他切换到了 GPL 许可证。随后基于软盘的发行版 SLS 和 Slackware 就诞生了。他相信选择 GPL 是 Linux 以及 Git 成功的一个重要部分。他认为 GPLv2 完美的平衡了“每个人在相同规则下的工作”。虽然不是每个开源软件都喜欢 GPL，但是如果没有 GPL ，或许不会有如今的 Linux 和整个开源世界。奇亚币占用超过 1EB 存储空间据报道，在过去的一个月时间里，分配给奇亚币（CHIA）的硬盘空间从 120PB 一直增加到 1143PB，也就是 1.14 EB，相当于 6 万多个 20TB 硬盘，奇亚币已经让硬件市场形成了一个新的领域。奇亚币是以硬盘空间和时间来作为资源，利用 CPU 或者显卡通过某种算法将硬盘空间写入数据，用户将数据存储在硬盘上一段时间，赢得奖励的机会和分配的空间成正比。简单来说的话就是程序在你硬盘上写满了彩票号码，服务器会不时随机抽奖，分配的硬盘空间越大，在线时间越长，中奖的可能性越大。这迫使挖奇亚币需要尽可能扩充存储空间容量和长时间运行，事实上除了耗损硬盘，内存的消耗也很大，整个系统各个模块加起来的耗电量也不低。比特币、以太坊等一直被批评空耗能源和处理能力而挖掘无用的加密货币，而奇亚币则把没被其它加密货币利用的存储能力也利用了。以至于计算机用户们哀叹显卡、CPU 之后，硬盘也买不到了。Opera 原生支持 IPFSOpera 宣布原生支持点对点协议 IPFS（星际文件系统）。在这之前，Brave 成为首个支持 IPFS 点对点协议的浏览器。IPFS 类似 BitTorrent，设计作为去中心化储存系统，允许用户在数百甚至数千个节点之间共享内容。IPFS 的理想非常好，但是可能与现实的兼容性有点问题。
2019 年 11 月初，数字天堂（北京）网络技术有限公司（下称：数字天堂）诉柚子（北京）科技有限公司、柚子（北京）移动技术有限公司（下称：两柚子）侵犯计算机软件著作权纠纷案，由北京高级人民法院二审作出终审判决。笔者曾密切关注该案，终审判决生效前，囿于关联代理关系的利益冲突，不便多谈。现将本案相关若干问题梳理成文，愿与各位探讨之。本案之所以受关注，是因为本次计算机软件著作权侵权案涉及开源软件和 GPL 许可证，本案的判决对未来开源软件诉讼实践有重要意义。本案一审法院对 GPL 相关条款作了阐述，二审法院回避了 GPL 问题。本文，笔者基于本案事实和法院判决做些思考，分享给大家讨论。本文将仅对涉及开源软件及 GPL 许可证的内容进行论述，其他法律问题不作探讨。案情简介为节省篇幅，以下对案情进行摘要和总结，详细案情可见一审链接和二审链接。经过一审和二审对事实的调查和确认，两柚子认可：数字天堂是 HBuilder 软件的著作权人；数字天堂拥有 HBuilder 软件中的代码输入法功能插件、真机运行功能插件、边改边看功能插件源代码著作权；两柚子的 APICloud 软件中对应插件源代码部分与涉案的三个插件具有同一性。基于此，针对本著作权侵权控诉，两柚子抗辩理由只有 GPL 开源许可协议这一个突破口。而二审中对涉案代码量、侵权产品数量的认定，以及基于此对赔偿额的认定，只是量的维度问题。开源许可证是法律文件一审法院虽未明确 GPL 许可证的法律效力，但在论述涉案三个插件是否受 GPL 协议限制时，默认了 GPL 许可证具有法律约束力。这一点虽然是意料之中，但毕竟开源理念和大部分开源协议来源于国外，且应用于开源社区特定人群，这一认定给未来涉及开源软件的诉讼消除了部分不确定性。为了强调协议内容，下文涉及 GPL 许可证的除特指许可证本身外，都以 GPL 协议指代。法院虽然默认了 GPL 协议具有约束力，即类似于协议或合同的法律效果，但并未进一步将 GPL 协议条款基于我国著作权法进行解释。社区内关于 GPL 协议的解释，特别是关于 GPL 传染性的解释是基于美国版权法，其能否为国内法院认可，依然存在不确定性。随着开源理念的深入以及开源软件在世界范围内的普及，本案作为中国 GPL 第一案，对未来开源软件相关的诉讼意义重大。稍有遗憾的是，两审法院并未就开源软件以及 GPL 协议的关键问题进行阐述。当然，也不可能期待 GPL 问题通过一次诉讼案件完全解决，未来还需要更多的法律、学术、技术等人士贡献智慧。关于一审认定的思考既然法院确认了 GPL 协议的法律约束力，那么对 GPL 协议的解释要么采取社区通说解释，要么基于我国著作权法作独立解释。否则很容易出现矛盾或模糊，以至于增加企业开源实践中的法律不确定性。关于 GPL 协议约束力范围（传染性），一审法院以涉案的三个插件可以独立运行，分别存放在三个独立的文件夹中且三个独立文件夹中无 GPL 许可证，据此认为涉案三个插件不属于 GPL 协议中所指应被开源的衍生产品或修改版本。GPL 许可证中有关的原文如下：The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".)——GPL 3.0To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work.A “covered work” means either the unmodified Program or a work based on the Program.——GPL 2.0结合 GPL 协议条款和 GNU 官网对于 GPL 传染性的解释，一审法院这一认定是值得商榷的，就像你不能认为总部在西城的 A 公司与其在昌平拥有独立办公场所的分公司 B 是完全独立的，这需要从 A 和 B 之间的财务、人事、业务等是否独立为基础判断。同理，GPL 模块 A 与模块 B 之间是否独立，绝对不能以A和B是否位于独立的文件夹中来判断，还是需要从 A 和 B 之间的功能关系、通信关系、调用关系、依赖关系等来判断。插件相对于主程序是否独立，需要看：插件的使命，是否为该主程序而存在；插件与主程序的交互方式，如管道、队列、函数调用； 交换消息的密切性 （ intimate communication ） ；是否有例外声明等。一审法院在确定赔偿额的时候又一次指出三个涉案插件是三个独立软件作品。一审法院从审判认定到赔偿衡量是一致的。这里，两柚子并没有就涉案三个插件的独立性进行抗辩，而这一点对 GPL 是否构成传染非常关键，在一审中被告代理律师对 GPL 许可证条款的理解也存在局限。关于二审认定的思考首先，二审中两柚子再次提出司法鉴定来否定涉案三个插件独立性，可能是准备利用GPL传染性中关于独立作品的认定来抗辩。不过，法院认为二审诉讼中再次提出第三次鉴定申请，有违司法程序公正和司法程序效率，即二审法院基于程序公正的角度考量不予准许。同时，二审法院认为两柚子提出的新的司法鉴定申请内容与本案待证事实之间无直接关联性，这一点是值得商榷的，因为 GPL 中作品是否独立直接影响作品是否受GPL约束，进而直接影响本案关于侵权的认定。二审法院的否决理由，直接回避了可能对 GPL 传染性问题的讨论。其次，二审法院认定数字天堂现有证据不足以证明涉案三个插件可以独立于 HBuilder 开发工具软件中的其他程序独立运行，但针对不独立的插件却没有进一步讨论这种不独立是否能够进行 GPL 开源抗辩。也就是说，一审法院基于作品的独立认定 GPL 抗辩无效，二审法院采取了一审对 GPL 抗辩的意见，但却否定了作品的独立性这一前提。是否为独立作品的认定直接决定作品是否属于 衍生作品 （ derivative work ） 或 修改作品 （ modified version ） ，进而直接影响是否受 GPL 约束。当然，我们可以这样解读二审法院对于作品独立的认定，即 GPL 许可证里所说的作品的独立性，和一审、二审法院判决赔偿额对插件独立的认定是不同维度/层次，这是说的通的。但仔细阅读一审判决可知，法院在否决 GPL 抗辩中和赔偿额判定中对独立的认定是一致的，二审认可了一审对 GPL 抗辩部分的认定，却否决了赔偿额中对独立作品的认定，本身前后有矛盾嫌疑。笔者认为，如果按照上述：GPL 传染性中独立性判定和对侵权作品数量中独立性判定是不同维度的独立性判定的假设，至少二审中需要重新认定 GPL 传染性的问题，从而将两个维度的独立性认定区分开来。关于两柚子诉求理由的思考两柚子在二审中再次申请司法鉴定：涉案三个插件是否可以脱离 Eclipse 主体软件在 Windows 环境中独立运行；将涉案三个插件源代码编译为插件以验证插件能否在 Eclipse 主体软件中独立运行；任意删除 Hbuilder 软件目录下的一个或多个以“org．eclipse”、“org．apache”、“com．aptana”为前缀的文件或目录 JAR 文件以验证涉案三个插件能否正常运行……关于这三个补充鉴定事项，首先，笔者认为两柚子或者其律师在开源上做足了工作，但其中依然存在问题。首先，插件独立于 Eclipse 主程序，并不一定需要插件可以脱离 Eclipse 主程序在 Windows 中独立运行。插件的独立性在于：插件有明确的功能，可用于特定的主程序，但不依赖于特定的主程序。最后，主程序脱离插件，应当且必须可以独立运行，并且不损失主程序本身的所有功能。再看诉讼本身基于以上认识，我们再回头看看案件本身。首先说明，因本案需要进行多处技术鉴定，笔者无法也没有精力一一取证，仅仅基于几个假设，再捋一下 GPL 相关的问题。笔者认为，关于本案 GPL 传染性的认定需要从 3 个方面来看：Eclipse 主程本身；基于 Eclipse 主程序的 GPL 插件；涉案插件与主程序，以及涉案插件与上述 GPL 插件的关系。为方便读者理解，引用数字天堂代理律所对一审结果评述的一张图。（1）从 Eclipse 主程序看APICloud 和 HBuilder 都是基于主程序 Eclipse 平台，包含第三方开源插件+各自自研插件组成的集成开发环境 IDE。首先，主程序 Eclipse 是采用 EPL（Eclipse Public License）许可证公开，EPL 与 GPL 不兼容。即便是 2017 年 8 月发布的 EPL-2.0 版本虽然添加了次级许可证选项，但其与 GPL 依然是不兼容的。因此，HBuilder 作为下游产品，其对 Eclipse 的包装分发不能变更 Eclipse 许可证。其次，针对插件来说，无非是拓展 Eclipse 某一特定的功能，任何非 Eclipse 本身的第三方插件，可以说对于 Eclipse 主程序来说都是非必须的。其第三方公司开发的 Eclipse 主程序的插件，按照 EPL 传染性的规定，一般不视为 EPL 的衍生作品，不受 EPL 约束。最后，需要强调的是 EPL 虽然是弱 Copyleft 许可证，但其依然是类似于 GPL 的具有“传染性”的许可证，其在给予用户更大使用方便的同时，对自身软件的 Copyleft 保护依然很强。因此，下游软件开发者在处理 EPL 软件和 GPL 软件时，需要认真对待它们的兼容性问题。（2）从 Aptana 插件看Aptana 在 2006 年推出时，以 EPL 1.0 发布，并于 2017 年 9 月 21 日修改为 GPL3.0 和 APL（Aptana Public License ）双许可。APL 不是开源/自由软件许可证，可以认为是商业许可，但对于非分发的内部使用是免费的。Aptana 作为主程序 Eclipse 的插件，由于 EPL 和 GPL 不兼容，Aptana 中的 GPL 插件要和以 EPL 许可的 Eclipse 主程序连接，必须在 GPL 许可证里作例外声明。毫无疑问，笔者在 Aptana 官网找到了例外声明，即关于独立作品的 GPL 传染性例外声明，以及聚合程序的 GPL 传染性例外声明。部分内容如下：GPL Section 7 Exception……which are conveyed to you by Appcelerator, Inc. and licensed under one or more of the licenses identified in the Excepted License List below (each an "Excepted License"), as long as:you obey the GPL in all respects for the Program and the modified version, except for Excepted Works which are identifiable sections of the modified version, which are not derived from the Program, and which can reasonably be considered independent and separate works in themselves,all Excepted Works which are identifiable sections of the modified version, which are not derived from the Program, and which can reasonably be considered independent and separate works in themselves,are distributed subject to the Excepted License under which they were originally licensed, andare not themselves modified from the form in which they are conveyed to you by Appcelerator, andthe object code or executable form of those sections are accompanied by the complete corresponding machine-readable source code for those sections, on the same medium as the corresponding object code or executable forms of those sections, and are licensed under the applicable Excepted License as the corresponding object code or executable forms of those sections, andany works which are aggregated with the Program, or with a modified version on a volume of a storage or distribution medium in accordance with the GPL, are aggregates (as defined in Section 5 of the GPL) which can reasonably be considered independent and separate works in themselves and which are not modified versions of either the Program, a modified version, or an Excepted Work.If the above conditions are not met, then the Program may only be copied, modified, distributed or used under the terms and conditions of the GPL or another valid licensing option from Appcelerator, Inc. Terms used but not defined in the foregoing paragraph have the meanings given in the GPL从以上 GPL 例外中可以看出，Aptana 只是部分限定了“衍生作品”解释，也就是运行采用 GPL 许可证的 Aptana 与像 Eclipse 这样独立的程序交互不会发生传染，仅此而已。而如果修改 Aptana，将其他程序并入 Aptana Studio，或者将 Aptana 与其他程序进行整合的作品依然受到 GPL 协议约束。简单的说，加入 GPL 例外的 GPL 程序依然是 GPL 程序，这一点必须强调。关于这一点，Aptana 官网还专门有问题解答：Can I add EPL'd plugins to Aptana Studio package and redistribute it?No. You can only redistribute the unmodified binary versions of the EPL'd plugins that are part of Aptana Studio when distributing any of the GPL'd code. Adding any files to Aptana Studio package creates a derivative work, and since all derivative works need to be made GPL'd, you will not be able to add EPL'd (or any other license) plugins without contacting us for a commercial license.What if I want to make changes to some of Aptana Studio's EPL'd plugins?You are free to make changes to any of Aptana Studio EPL'd code under the terms of the EPL. To get those redistributed as part of Aptana Studio, we encourage you to contribute those back to Aptana so that we may evaluate your changes for inclusion back into the product.Can I take unmodified Aptana Studio binaries and combine them with an Eclipse distribution?No. Combining our GPL'd licensed code with any other product requires that the entire product be GPL'd, and therefore you cannot include any Eclipse distribution.数字天堂认为，其 HBuilder 是包含 Eclipse 平台框架和众多插件的聚合体软件包，但其基于 Eclipse 开发且打包了 Aptana 中的 GPL 插件。从 GPL 协议对独立程序和聚合程序的规定来看，HBuilder 不被感染很难成立。一旦这种潜在传染可能性成立，数字天堂的 HBuilder 发行版就不满足合规性，其内部 EPL 和 GPL 软件不兼容。直白的说，就是整个发行版都可能受到 GPL 的约束。同时，这对于 Eclipse 是不可接受的，哪怕 EPL 是弱 Copyleft 许可证。这些问题，多是对 EPL 和 GPL 的 Copyleft 性质认识不到位导致。（3）涉案插件与主程序及 Aptana 插件的关系其实，以上两步分析一旦得出受 GPL 约束的结论，就不需要下面的分析了。为了完整，同时供未来类似案例参考，简单介绍。进一步分析 Aptana 与数字天堂的涉案三个插件之间的关系，若涉案三个插件与 Aptana 有调用、通信、依赖关系，那么涉案三个插件必然会被 GPL 传染，也即是受 GPL 约束。从以上三步的分析可见，在 GPL 传染性判断时，是否为独立作品是非常关键的。这也是我在前面法院判决部分要强调一审法院对独立的认定虽未必符合 GPL 本身解释，但至少前后一致。而二审法院对作品独立的认定甚至前后矛盾。当然，笔者没太多精力去调查技术细节，点到为止，有兴趣的读者可以进行深入研究。以上分析，是基于 Eclipse 作为中立主程序（即 Eclipse 主程序著作权人非诉讼参与人），GPL 插件与非 GPL 插件判定的情况，换一种场景以上判断完全或者大部分不成立。关于开源软件和 GPL 的问题还有很多需要注意的，限于篇幅不再进一步说明，对本案或对开源感兴趣的朋友可以找我单独讨论。 付钦伟，集慧智佳高级咨询师、专利代理人，擅长专利分析布局、FTO 调查与风险应对、专利信息应用、开源软件风险与合规指导。
GPL 合作承诺 GPL Cooperation Commitment 消除了开发者对许可证失效的顾虑，从而达到促进技术创新的目的。假如能免于顾虑，技术创新和发展将会让世界发生天翻地覆的改变。 GPL 合作承诺 GPL Cooperation Commitment 就这样应运而生，只为通过公平、一致、可预测的许可证来让科技创新无后顾之忧。去年，我曾经写过一篇文章，讨论了许可证对开源软件下游用户的影响。在进行研究的时候，我就发现许可证的约束力并不强，而且很多情况下是不可预测的。因此，我在文章中提出了一个能使开源许可证具有一致性和可预测性的潜在解决方案。但我只考虑到了诸如通过法律系统立法的“传统”方法。2017 年 11 月，RedHat、IBM、Google 和 Facebook 提出了这种我从未考虑过的非传统的解决方案：GPL 合作承诺。GPL 合作承诺规定了 GPL 公平一致执行的方式。我认为，GPL 合作承诺之所以有这么深刻的意义，有以下两个原因：一是许可证的公平性和一致性对于开源社区的发展来说至关重要，二是法律对不可预测性并不容忍。了解 GPL要了解 GPL 合作承诺，首先要了解什么是 GPL。GPL 是 GNU 通用许可证 GNU General Public License 的缩写，它是一个公共版权的开源许可证，这就意味着开源软件的分发者必须向下游用户公开源代码。GPL 还禁止对下游的使用作出限制，要求个人用户不得拒绝他人对开源软件的使用自由、研究自由、共享自由和改进自由。GPL 规定，只要下游用户满足了许可证的要求和条件，就可以使用该许可证。如果被许可人出现了不符合许可证的情况，则视为违规。按照第二版 GPL（GPLv2）的描述，许可证会在任何违规的情况下自动终止，这就导致了部分开发者对 GPL 有所抗拒。而在第三版 GPL（GPLv3）中则引入了“ 治愈条款 cure provision ”，这一条款规定，被许可人可以在 30 天内对违反 GPL 的行为进行改正，如果在这个缓冲期内改正完成，许可证就不会被终止。这一规定消除了许可证被无故终止的顾虑，从而让软件的开发者和用户专注于开发和创新。GPL 合作承诺做了什么GPL 合作承诺将 GPLv3 的治愈条款应用于使用 GPLv2 的软件上，让使用 GPLv2 许可证的开发者避免许可证无故终止的窘境，并与 GPLv3 许可证保持一致。很多软件开发者都希望正确合规地做好一件事情，但有时候却不了解具体的实施细节。因此，GPL 合作承诺的重要性就在于能够对软件开发者们做出一些引导，让他们避免因一些简单的错误导致许可证违规终止。Linux 基金会技术顾问委员会在 2017 年宣布，Linux 内核项目将会采用 GPLv3 的治愈条款。在 GPL 合作承诺的推动下，很多大型科技公司和个人开发者都做出了相同的承诺，会将该条款扩展应用于他们采用 GPLv2（或 LGPLv2.1）许可证的所有软件，而不仅仅是对 Linux 内核的贡献。GPL 合作承诺的广泛采用将会对开源社区产生非常积极的影响。如果更多的公司和个人开始采用 GPL 合作承诺，就能让大量正在使用 GPLv2 或 LGPLv2.1 许可证的软件以更公平和更可预测的形式履行许可证中的条款。截至 2018 年 11 月，包括 IBM、Google、亚马逊、微软、腾讯、英特尔、RedHat 在内的 40 余家行业巨头公司都已经签署了 GPL 合作承诺，以期为开源社区创立公平的标准以及提供可预测的执行力。GPL 合作承诺是开源社区齐心协力引领开源未来发展方向的一个成功例子。GPL 合作承诺能够让下游用户了解到开发者对他们的尊重，同时也表示了开发者使用了 GPLv2 许可证的代码是安全的。如果你想查阅更多信息，包括如何将自己的名字添加到 GPL 合作承诺中，可以访问 GPL 合作承诺的网站。via: https://opensource.com/article/18/11/gpl-cooperation-commitment作者：Brooke Driver 选题：lujun9972 译者：HankChow 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
本文由高级咨询师薛亮据自由软件基金会（FSF）的英文原文翻译而成，这篇常见问题解答澄清了在使用 GNU 许可证中遇到许多问题，对于企业和软件开发者在实际应用许可证和解决许可证问题时具有很强的实践指导意义。关于 GNU 项目、自由软件基金会（FSF）及其许可证的基本问题对于 GNU 许可证的一般了解在您的程序中使用 GNU 许可证依据GNU许可证分发程序在编写其他程序时采用依据 GNU 许可证发布的程序将作品与依据 GNU 许可证发布的代码相结合关于违反 GNU 许可证的问题7 关于违反 GNU 许可证的问题7.1 如果发现了可能违反 GPL 许可证的行为，我该怎么办？您应该进行报告。 首先，尽可能检查事实。然后告诉发行者或版权所有者涉及的具体 GPL 程序。如果是自由软件基金会，请写信给 mailto:license-violation@gnu.org。此外，程序的维护者可能是版权所有者，他可能会告诉您如何联系版权所有者，因此将其报告给维护者。7.2 谁有权力执行 GPL 许可证？（同 1.10）由于 GPL 是版权许可，软件的版权所有者将是有权执行 GPL 的人。如果您发现违反 GPL 的行为，您应该向遵循 GPL 的该软件的开发人员通报。他们是版权所有者，或与版权所有者有关。若要详细了解如何报告 GPL 违规，请参阅“如果发现了可能违反 GPL 许可证的行为，我该怎么办？”。7.3 我听说有人依据另一个许可证获得了 GPL 程序的副本。这可能吗？GNU GPL 不允许用户将其他许可证附加到程序。但是，程序的版权持有人可以依据几个不同的许可证并行发布。其中一个可能是 GNU GPL。对于您的副本中的许可证来说，假设由版权所有者放置，并且您合法地获得该副本，则是适用于您的副本的许可证。7.4 遵循 GPL 的程序的开发者是否受 GPL 的约束？开发者的行为是否会违反 GPL？严格来说，GPL 是开发者授予其他人使用、分发和更改程序的许可。开发者本身并不受其约束，所以无论开发者做什么，都不是 GPL 的“违规”。但是，如果开发者做某些违反 GPL 的行为，那么开发者一定会失去在社区的道德地位。7.5 我刚刚发现一家公司有一份 GPL 程序的副本，获取该副本需支付费用。他们会因为不能在互联网上提供副本而违反 GPL 吗？（同 4.12）不会，GPL 不要求任何人使用互联网进行分发。它也不要求任何人特意去再分发程序。而且（一个特殊情况之外），即使有人决定再分发该程序，GPL 也不会要求他必须特意向您或其他人分发副本。GPL 要求的是，如果他愿意，他必须有权将副本分发给你。一旦版权所有者将程序的副本分发给某人，如果某人认为合适，那么该人可以将程序再分发给您或任何其他人。7.6 我可以在如果客户不继续支付订阅费用就停止运行的设备上使用遵循 GPL 的软件吗？不可以。在这种情况下，继续支付费用的要求限制了用户运行程序的能力。 这是在 GPL 之上的额外要求，GPL 禁止这种行为。7.7 “纠正” （ cure ） 违反 GPL v3 的行为意味着什么？纠正违规行为意味着调整您的做法以符合许可证的要求。7.8 如果有人在笔记本电脑上安装遵循 GPL 的软件，然后将笔记本电脑借给朋友，而不提供软件的源代码，他们是否违反了 GPL？在我们调查这个问题的司法管辖区，这种借用不会被算作、 传递 （ convey ） 。笔记本电脑的所有者不会依据 GPL 承担任何义务。7.9 假设两家公司试图通过让一家公司发布已签约的软件，另一家公司发布仅运行第一家公司签约软件的用户产品，以此来规避提供安装信息的要求。这是否违反了 GPL v3？是的。如果双方通过一起工作来逃避 GPL 的要求，就可以追究它们的侵权行为。这是特别真实的情形，因为 传递 （ convey ） 的定义明确地包括会使某人对二次侵权负责的活动。译者介绍：薛亮，集慧智佳知识产权咨询公司高级咨询师，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。
在 GPL v3 许可证颁发 11 周年之际，让我们了解一下它对自由和开源软件的持久贡献。2017 年，我错过了为 GPL v3（GNU 通用公共许可协议的第三版）发布 10 周年撰写文章的机会。GPL v3 由 自由软件基金会 （ Free Software Foundation ） （FSF）于 2007 年 6 月 29 日正式发布，这一天在技术史上更为人熟知的事件是苹果公司推出了 iPhone 手机。一年之后的现在，我觉得应该对 GPL v3 做一些回顾。对于我来说，许多有关 GPL v3 的有趣内容可以追溯到 11 年之前，我作为积极参与者经历了当时的公共起草过程。2005 年，经过近十年热衷于自由软件的自我沉浸，但却几乎没有任何开源法律经验可言的我被 Eben Moglen 聘用，加入 软件自由法律中心 （ Software Freedom Law Center ） （SFLC）担任法律顾问。SFLC 当时是 FSF 的外部法律顾问，我的角色被设定为关注 GPL v3 起草过程的初期公共阶段。这个机会把我从以前的并不令我满意的一次职业转变中解救出来。 自由和开源软件 （ Free and Open Source Software ） （FOSS）的法律问题成为我的新专长，我发现这一点很有吸引力，令人满意，并且在智力上有所回报。我在 SFLC 的工作，特别是我在 GPL v3 方面勇闯火线的工作，成为了我的在职培训。GPL v3 必须被理解为早期 FOSS 时代的产物，其轮廓可能让今天的人难以想象。在 2006 年公共起草过程开始时，Linux 和开源已经不再是早年一些漫不经心的观察者所看到的几乎是同义词的情形了，但两者之间的联系仍然比现在更密切。Linux 已经对技术行业产生深远影响的反映是，每个人都认为 GPL v2 是主要的开源许可模式。我们看到了开源（和伪开源）商业模式如寒武纪式爆发的最终震荡。一个泡沫化商业炒作包围的开源（对我来说最令人难忘的典型代表是 开源商业会议 （ Open Source Business Conference ）与软件工程专业人士目前对开源开发的接受程度几乎没有相似之处。微软凭借其不断扩大的专利组合以及对 Linux 的竞争性对抗，在 FOSS 社区中普遍被视为一种现实存在的威胁，而 SCO 诉讼已经在 Linux 和 GPL 之间笼罩上了法律风险的阴云，并且没有完全消散。这种环境必然使得 GPL v3 的起草成为自由软件历史上前所未有的高风险事件。主要的技术公司和顶级律师事务所的律师争先恐后地对该许可协议施加影响，并确信 GPL v3 必将接管并彻底重塑开源业态及所有大量相关的商业投资。技术社区内存在类似的心态；这在 Linux 内核开发人员于 2006 年 9 月对 GPL v3 的强烈指责中所表达的恐惧里略见一斑。我们这些接近 FSF 的人知道的多一点，但我认为我们假定新的许可协议要么是压倒性的成功，要么是彻底的失败——“成功”意味着将现有的 GPL v2 项目生态系统升级为 GPL v3，尽管也许 Linux 内核会缺席（LCTT 译注：十年过去了，Linux 内核仍旧采用 GPL v2 许可证）。实际的结果是介于两者之间的东西。我对测量开源许可协议采用程度的尝试没有信心，近年来这种做法通常用于证明 左版 （ Copyleft ） 许可协议失去竞争优势。根据我自己的接近 Linux 和工作于 红帽 （ Red Hat ） 公司的明显有倾向性的经验，表明 GPL v3 作为自 2007 年以来推出项目的可选许可协议，享有适度的受欢迎程度。尽管 2007 年之前存在的大多数 GPL v2 项目以及它们在 2007 年以后的分支，仍然遵循旧许可协议。（GPL v3 的兄弟许可协议 LGPL v3 和 AGPL v3 从未获得过相当程度的普及）大多数现有的 GPL v2 项目（有一些明显的例外，如 Linux 内核和 Busybox）被许可为“GPL v2 或任何更高的版本”。技术界早就决定“GPL v2 或更高版本”是一个政治中立的许可协议选项，它包含了 GPL v2 和 GPL v3。这可以解释为什么 GPL v3 的采用推进得缓慢和有限，特别是在 Linux 社区中。在 GPL v3 起草过程中，一些人表达了对 Linux 生态系统“ 巴尔干化 （ balkanized ） ”的担忧，无论是因为用户必须了解两个不同的强大左版许可协议的开销，还是因为 GPL v2 / GPL v3 的不兼容。事实证明，这些担忧完全没有根据。在主流服务器和工作站 Linux 堆栈中，这两个许可协议已经和平共存了十年。这其中部分是因为这样的堆栈由强大的左版范畴的单独单元组成（参见我对容器设置中相关问题的讨论）。至于强左版范畴单元内部的不兼容性，在这里，“GPL v2 或更高版本”的普遍性被技术界视为干净利索地解决了理论问题。尽管名义上的“GPL v2 或更高版本”升级为 GPL v3 的情况几乎没有发生过。我已经说过，我们中间的一些 FOSS 许可协议极客已经提到了假定的左版衰退的问题。早在公共起草过程的开始阶段，GPL v3 已经在批评者那里形成了滥用，并且可以推断，有些人已经在特殊情况下的 GPL v3 不受欢迎与一般意义上的 GPL 或左版失宠之间建立了联系。我对它的看法有所不同：很大程度上是因为它的复杂性和 巴洛克 （ baroque ） 风格，GPL v3 失去了创建强大的可以广泛地吸引现代个人软件作者和企业许可人的左版许可协议的机会。我相信今天的个人开发者往往更喜欢简短、易懂、简约的许可证，最明显的例子就是 MIT 许可证。面临开源许可协议选项的一些公司决策者可能很自然地分享这种观点，而其他公司决策者可能认为 GPL v3 的某些部分风险太大（例如专利条款或反锁定要求）或与其商业模式不相容。具有讽刺意味的是，未能吸引这些群体的 GPL v3 的一部分特性是因为有意识地试图使许可协议吸引这些具备相同类型利益的群体。GPL v3 是如何变得如此巴洛克式的？正如我所说，GPL v3 是较早时期的产物，彼时 FOSS 许可协议被视为项目治理的主要工具。（现在我们倾向于将治理与其他类型的法律或准法律工具联系起来，例如组织非营利组织，围绕项目决策制定规则，行为准则和贡献者协议。）在其起草过程中，GPL v3 是对 FOSS 许可协议可以作为雄心勃勃的私人监管手段持乐观态度的最高点。对于 GPL v2 来说已经是这样了，但是 GPL v3 通过详细解决一些新的政策问题——软件专利、反规避法律、设备锁定等方式来解决问题。这必然会使 GPL v3 许可协议比 GPL v2 更长、更复杂，因为 FSF 和 SFLC 在第一份 GPL v3 基本原理文件中满怀抱歉地提到了这一点。但是，起草 GPL v3 过程中的其他一些因素无意中导致许可协议的复杂性增长。代表供应商和商业用户利益的律师从法律和商业角度提供了有用的改进建议，但这些通常采取让措辞简单的条款变成更冗长的形式，在明晰性方面可以说没有明确的改善。对技术社区反馈（通常是识别许可条款的漏洞）的回应也有类似的效果。GPL v3 起草人也因短期政治危机（2006 年有争议的微软/ Novell 交易）纠缠在一起，导致许可协议的专利部分永久性地增加了新的和不寻常的条件，这在 2007 年之后是毫无用处的, 除了使有良心的专利持有商更难遵守许可证。当然，GPL v3 中的一些复杂性仅仅是为了使合规更容易（特别是对于社区项目开发人员）或者编写 FSF 的解释实践。最后，人们可以对 GPL v3 中使用的语言风格提出质疑，其中大部分语言都具有传统软件许可法律的顽皮模仿或嘲弄；在许多情况下，一种更简单、直接的措辞形式是一种改进。GPL v3 的复杂性以及在许可协议起草中倾向于简练和简洁的趋势以及明智的许可政策目标，意味着 GPL v3 的实质性文本对后来的 FOSS 法律起草几乎没有直接影响。但是，正如我在 2012 年所惊奇和高兴地看到的那样，MPL 2.0 改编了 GPL v3 的两个部分：GPL v3 终止条款中的 30 天补救和 60 天休眠文本，并保证升级到更高版本许可协议的下游对上游许可人没有新的义务。GPL v3 补救文本已经产生了重大影响，特别是在过去一年中。随着 FSF 的支持， 软件自由保护组织 （ Software Freedom Conservancy ） 颁布了《 面向社区的 GPL 执行原则 （ Principles of Community-Oriented GPL Enforcement ） 》，该原则要求将 GPL v3 补救机会扩展到 GPL v2 违规行为，Linux 基金会技术顾问委员会发布了一份声明，得到了一百多个 Linux 内核开发人员支持，其中包含了 GPL v3 的补救文本。接下来是以红帽公司为首的一系列企业承诺，将 GPL v3 补救条款扩展到 GPL v2 和 LGPL v2.x 违规，这是一项建议个人开源开发者做出同样承诺的活动。红帽公司的一项声明宣布，从此以后其主导的 GPL v2 和 LGPL v2.x 项目将在项目存储库中直接使用承诺文本。我在最近的博客文章中讨论了这些发展。关注 GPL v3 的一个持久贡献是改变了对广泛使用的 FOSS 许可协议修订方式的期待。在没有社区评论的参与，也没有努力与主要利益相关者进行磋商的情况下，这些许可协议不能完全进行私下修改。MPL 2.0 以及最近的 EPL 2.0 的起草过程反映了这一新规范。作者简介：Richard Fontana 是红帽公司法律部门产品和技术团队的高级商业顾问。 他的大部分工作都集中在开源相关的法律问题上。译者简介：薛亮，集慧智佳知识产权咨询公司总监，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。
本文由高级咨询师薛亮据自由软件基金会（FSF）的英文原文翻译而成，这篇常见问题解答澄清了在使用 GNU 许可证中遇到许多问题，对于企业和软件开发者在实际应用许可证和解决许可证问题时具有很强的实践指导意义。关于 GNU 项目、自由软件基金会（FSF）及其许可证的基本问题对于 GNU 许可证的一般了解在您的程序中使用 GNU 许可证依据GNU许可证分发程序在编写其他程序时采用依据 GNU 许可证发布的程序将作品与依据 GNU 许可证发布的代码相结合关于违反 GNU 许可证的问题6 将作品与依据 GNU 许可证发布的代码相结合6.1 GPL v3 是否与 GPL v2 兼容？不兼容。许多要求已经从 GPL v2 变为 GPL v3，这意味 GPL v2 中的精确要求并不体现在 GPL v3 中，反之亦然。例如，GPL v3 的终止条件比 GPL v2 的终止条件更为宽泛，因此与 GPL v2 的终止条件不同。由于这些差异，两个许可证不兼容：如果您试图将依据 GPL v2 发布的代码与依据 GPL v3 发布的代码组合，则将违反 GPL v2 的第 6 部分。但是，如果代码依据 GPL “v2 或更高版本”发布，则与 GPL v3 兼容，因为 GPL v3 是其允许的选项之一。6.2 GPL v2 是否有提供安装信息的要求？GPL v3 明确要求再分发中包含完整的必要的“安装信息”。GPL v2 不使用该术语，但它需要再分发中包含用于控制可编译和安装可执行文件的脚本以及完整和相应的源代码。这涵盖了 GPL v3 中称为“安装信息”的部分内容，但不包括所有内容。因此，GPL v3 对安装信息的要求较强。6.3 各种 GNU 许可证之间如何相互兼容？各种 GNU 许可证彼此之间具有广泛的兼容性。下面是唯一的一种您不能将遵循两种 GNU 许可证的代码结合起来的情况：将遵循旧版本许可证的代码与遵循该许可证新版本的代码进行结合。以下是 GNU 许可证的各种结合的详细兼容性矩阵，以便为特定情况提供易于使用的参考。它假设有人依据其中一个许可证编写了一些软件，而您希望以某种方式将该软件的代码结合到您要发布的项目（您自己的原始作品或其他人的软件的修改版本）中。在表顶部的列中找到项目的许可证，并在左侧的一行中找到其他代码的许可证。它们交叉的单元格会告诉您这种结合是否被允许。当我们说“复制代码”时，我们的意思就是：您正在从一个源代码中获取一段代码（无论是否修改），并将其插入到自己的程序中，从而基于第一部分代码形成一个作品。当您编译或运行代码时，“使用库”意味着您不直接复制任何源代码，而是通过链接、导入或其他典型机制将源代码绑定在一起。矩阵中每个标明 GPL v3 的地方，其关于兼容性的声明也同样适用于 AGPL v3。兼容性矩阵 我希望依据以下许可证许可我的代码仅 GPL v2GPL v2 或更高版本GPL v3 或更高版本仅 LGPL v2.1LGPL v2.1 或更高版本LGPL v3 或更高版本我希望复制遵循右侧许可证的代码：仅 GPL v2可以可以 【2】不可以可以，结合作品只能遵循GPL v2 【7】可以，结合作品只能遵循GPL v2 【7】【2】不可以GPL v2 或更高版本可以 【1】可以可以可以，结合作品需遵循GPL v2或更高版本 【7】可以，结合作品需遵循GPL v2或更高版本 【7】可以，结合作品需遵循GPL v3 【8】GPL v3不可以可以，结合作品需遵循GPL v3 【3】可以可以，结合作品需遵循GPL v3 【7】可以，结合作品需遵循GPL v3 【7】可以，结合作品需遵循GPL v3 【8】仅 LGPL v2.1可以，需依据GPL v2传递复制后代码 【7】可以，需依据GPL v2或更高版本传递复制后代码 【7】可以，需依据GPL v3传递复制后代码 【7】可以可以 【6】可以，需依据GPL v3传递复制后代码 【7】【8】LGPL v2.1 或更高版本可以，需依据GPL v2传递复制后代码 【7】【1】可以，需依据GPL v2或更高版本传递复制后代码 【7】可以，需依据GPL v3传递复制后代码 【7】可以 【5】可以可以LGPL v3不可以可以，结合作品需遵循GPL v3 【8】【3】可以，结合作品需遵循GPL v3 【8】可以，结合作品需遵循GPL v3 【7】【8】可以，结合作品需遵循LGPL v3 【4】可以我希望使用遵循右侧许可证的库：仅 GPL v2可以可以 【2】不可以可以，结合作品只能遵循GPL v2 【7】可以，结合作品只能遵循GPL v2 【7】【2】不可以GPL v2 或更高版本可以 【1】可以可以可以，结合作品需遵循GPL v2或更高版本 【7】可以，结合作品需遵循GPL v2或更高版本 【7】可以，结合作品需遵循GPL v3 【8】GPL v3不可以可以，结合作品需遵循GPL v3 【3】可以可以，结合作品需遵循GPL v3 【7】可以，结合作品需遵循GPL v3 【7】可以，结合作品需遵循GPL v3 【8】仅LGPL v2.1可以可以可以可以可以可以LGPL v2.1 或更高版本可以可以可以可以可以可以LGPL v3不可以可以，结合作品需遵循GPL v3 【9】可以可以可以可以角注：在这种情况下，当结合代码时，您必须遵守 GPL v2 的条款。您不能适用更高版本的条款。在这种情况下，您可以依据 GPL v2 或更高版本发布您的项目（您的原始作品和/或您收到并修改的作品），请注意，您使用的其他代码仍然只能遵循 GPL v2。只要您的项目依赖于该代码，您将无法将项目的许可证升级到 GPL v3 或更高版本，整个作品（您的项目和其他代码的任意结合）只能依据 GPL v2 的条款传递。如果您有能力依据 GPL v2 或任何更高版本发布项目，您可以选择依据 GPL v3 或更高版本发布该项目，一旦您执行此操作，您就可以结合依据 GPL v3 发布的代码。如果您有能力依据 LGPL v2.1 或任何更高版本发布项目，您可以选择依据 LGPL v3 或更高版本发布该项目，一旦您这样做，您就可以结合依据 LGPL v3 发布的代码。在这种情况下结合代码时，您必须遵守 LGPL v2.1 的条款。您不能适用更高版本 LGPL 中的条款。如果这样做，只要项目包含仅依据 LGPL v2.1 发布的代码，您将无法将项目的许可证升级到 LGPL v3 或更高版本。LGPL v2.1 允许您将遵循自 GPL v2 之后任何版本 GPL 的代码进行重新许可。如果在这种情况下可以将遵循 LGPL 的代码切换为使用适当版本的 GPL（如表所示），则可以进行此种结合。LGPL v3 是 GPL v3 加上在这种情况下可以忽略的额外权限。由于 GPL v2 不允许与 LGPL v3 结合，因此在这种情况下，您必须依据 GPL v3 的条款传递项目，因为它允许此种结合。6.4 “聚合” （ aggregate ） 与其他类型的“修改版本”有什么区别？（同 2.25）“聚合”由多个单独的程序组成，分布在同一个 CD-ROM 或其他媒介中。GPL 允许您创建和分发聚合，即使其他软件的许可证不是自由许可证或与 GPL 不兼容。唯一的条件是，发布“聚合”所使用的许可证不能禁止用户去行使“聚合”中每个程序对应的许可证所赋予用户的权利。两个单独的程序还是一个程序有两个部分，区分的界限在哪里？这是一个法律问题，最终由法官决定。我们认为，适当的判断标准取决于通信机制（exec、管道、rpc、共享地址空间内的函数调用等）和通信的语义（哪些信息被互换）。如果模块们被包含在相同的可执行文件中，则它们肯定是被组合在一个程序中。如果模块们被设计为在共享地址空间中链接在一起运行，那么几乎肯定意味着它们组合成为一个程序。相比之下，管道、套接字和命令行参数是通常在两个独立程序之间使用的通信机制。所以当它们用于通信时，模块们通常是单独的程序。但是，如果通信的语义足够亲密，交换复杂的内部数据结构，那么也可以视为这两个部分合并成了一个更大的程序。6.5 我在使用 GPL 程序的源代码时是否具有 “合理使用” （ fair use ） 权限？（同 4.17）是的，您有。“合理使用”是在没有任何特别许可的情况下允许的使用。由于您不需要开发人员的许可来进行这种使用，无论开发人员在许可证或其他地方对此怎么说，您都可以执行此操作，无论该许可证是 GNU GPL 还是其他自由软件许可证。但是，请注意，没有全世界范围普适的合理使用原则；什么样的用途被认为“合理”因国而异。6.6 美国政府可否对遵循 GPL 的程序进行改进并发布？（同 3.14）可以。如果这些改进是由美国政府雇员在雇佣期间编写的，那么这些改进属于公有领域。不过，GNU GPL 仍然涵盖了整体的改进版本。在这种情况下没有问题。如果美国政府使用承包商来完成这项工作，那么改进本身可以被 GPL 覆盖。6.7 GPL 对于与其所覆盖的作品进行静态或动态链接的模块有不同的要求吗？没有。将 GPL 覆盖的作品静态或动态地链接到其他模块是基于 GPL 覆盖的作品构建结合作品。因此，GNU GPL 的条款和条件将覆盖整个结合作品。另请参阅：6.24 如果我在 GPL 软件中使用了与 GPL 不兼容的库，会出现什么法律问题？6.8 LGPL 对于与其所覆盖的作品进行静态或动态链接的模块有不同的要求吗？为了遵守 LGPL（任何现有版本：v2、v2.1 或 v3）：（1）如果您静态链接到 LGPL 库，您还必须以对象（不一定是源代码）格式提供应用程序，以便用户有机会修改库并重新链接应用程序。（2）如果您动态链接已经存在于用户计算机上的 LGPL 库，则不需要传递库的源代码。另一方面，如果您自己将可执行的 LGPL 库与您的应用程序一起传递，无论是静态还是动态链接，还必须以 LGPL 所提供的方式之一来传递库的源代码。6.9 如果库依据 GPL（而不是 LGPL）发布，这是否意味着使用它的任何软件必须遵循 GPL 或与 GPL 兼容的许可证？是的，因为程序实际上与库进行了链接。因此，GPL 的条款适用于整个结合作品。与库链接的软件模块可能遵循与GPL兼容的不同许可证，但整体作品必须遵循 GPL。另见：“2.23 许可证与 GPL 兼容是什么意思？”6.10 您有一个遵循 GPL 的程序，我想将它与我的代码进行链接，来构建一个专有程序。那么事实上，我链接到您的程序意味着我必须让我的程序遵循 GPL 许可证？不完全是。这意味着您必须依据与 GPL 兼容的许可证（更准确地说，与您链接的结合作品中所有其他代码所适用的一个或多个 GPL 版本相兼容）发布您的程序。然后，结合作品本身就可以遵循这些 GPL 版本。6.11 如果是这样的话，有没有机会依据 LGPL 获得您的程序许可？您可以这么要求，但绝大多数的作者都会坚定不移地说不。GPL 的想法是，如果要将我们的代码包含在程序中，您的程序也必须是自由软件。GPL 的意图是给您施加压力，让您以能够使其成为我们社区一部分的方式来发布您的程序。您始终拥有不使用我们代码的合法选择。6.12 我们构建专有软件的项目不能使用遵循 GPL 的某个 GNU 程序。您会为我们提供例外吗？ 这将意味着该程序拥有更多用户。对不起，我们没有这样的例外。这样做是不对的。最大化用户数量不是我们的目标。相反，我们正在努力为尽可能多的用户提供至关重要的自由。一般来说，专有软件项目是阻碍而不是实现软件自由的原因。我们偶尔提供许可证例外来协助一个依据 GPL 以外的许可证生产自由软件的项目。不过，我们必须看到一个很好的理由，即这个项目为什么会推动自由软件的发展。我们有时也会改变软件包的分发条款，这显然是为自由软件事业服务的正确方法；但是我们对此非常谨慎，所以您必须向我们展示非常有说服力的理由。6.13 如果一个编程语言解释器是依据 GPL 发布的，这是否意味着由它解释的程序必须遵循与 GPL 兼容的许可证？当解释器只是解释一种语言时，答案是否定的。被解释程序对于解释器来说只是数据；根据版权法，像GPL这样的自由软件许可证不能限制您使用解释器的数据。您可以使用任何数据（被解释程序），以任何您喜欢的方式运行它，并且没有任何要求规定您必须将数据授权给任何人。然而，当解释器被扩展以向 其他程序 （ facilities ） （通常但不一定是库）提供 “绑定” （ bindings ） 时，被解释程序通过这些绑定有效地与其使用的程序相关联。因此，如果这些程序是依据 GPL 发布的，则使用它们的被解释程序必须以与 GPL 兼容的方式发布。JNI（Java Native Interface）是这种绑定机制的一个例子；以这种方式访问​​的库与调用它们的 Java 程序动态链接。这些库也与解释器联系在一起。如果解释器与这些库静态链接，或者如果它被设计为与这些特定库动态链接，那么也需要以与 GPL 兼容的方式发布。另一个类似且非常常见的情况是为库提供解释器，它们能够自我解释。例如，Perl 带有许多 Perl 模块，Java 实现带有许多 Java 类。这些库和调用它们的程序总是动态链接在一起。结果是，如果您选择在程序中使用遵循 GPL 的 Perl 模块或 Java 类，则必须以与 GPL 兼容的方式发布该程序，无论结合后的 Perl 或 Java 程序所依之运行的 Perl 或 Java 解释器中使用什么样的许可证。6.14 如果编程语言解释器遵循与 GPL 不兼容的许可证，我可以在其上运行遵循 GPL 的程序吗？当解释器解释一种语言时，答案是肯定的。被解释程序对于解释器来说只是数据；GPL 不会限制您处理程序时所使用的工具。然而，当解释器被扩展以向 其他程序 （ facilities ） （通常但不一定是库）提供“绑定”时，被解释程序通过这些绑定有效地与其使用的程序相关联。JNI（Java Native Interface）是此种程序的一个例子；以这种方式访问​​的库与调用它们的 Java 程序动态链接。因此，如果这些程序是依据与 GPL 不兼容的许可证发布的，则情况就像以任何其他方式跟与 GPL 不兼容的库链接。这意味着：如果您正在编写代码并将其依据 GPL 发布，您可以声明一个 明确例外 （ explicit exception ） ，允许将其链接到与 GPL 不兼容的程序。如果您依据 GPL 编写并发布程序，并且专门设计了与这些程序配合使用的功能，人们可以将其作为 隐性例外 （ implicit exception ） ，允许它们与这些程序进行链接。但是，如果这只是你的打算的话，最好明确地这么说。您不能把别人遵循 GPL 的代码用于这种方式，或者添加这样的例外。只有该代码的版权所有者才能添加例外。6.15 如果我将一个模块添加到遵循 GPL 的程序中，我必须使用 GPL 作为我的模块的许可证吗？GPL 规定，整个结合后的程序必须依据 GPL 发布。所以你的模块必须可以依据 GPL 进行使用。但是，您可以提供使用您代码的额外授权。如果您愿意，您可以依据比 GPL 更为宽松但与 GPL 兼容的许可证发布模块。许可证列表页面提供了与 GPL 兼容许可证的部分列表。6.16 什么时候程序和插件会被认为是单一的结合程序？这取决于主程序如何调用其插件。如果主程序使用 fork 和 exec 来调用插件，并通过共享复杂的数据结构或来回传送复杂的数据结构来建立 密切通信 （ intimate communication ） ，可以使它们成为一个单一的结合程序。如果主程序使用简单的 fork 和 exec 来调用插件并且不建立它们之间的密切通信，插件被认为是一个单独的程序。如果主程序动态地链接插件，并且它们彼此进行函数调用并共享数据结构，我们相信它们形成了一个单一的结合程序，它必须被视为主程序和插件的扩展。如果主程序动态地链接插件，但是它们之间的通信仅限于使用某些选项调用插件的“main”功能，并等待它返回，这是一种 临界案例 （ borderline case ） 。使用共享内存与复杂数据结构进行通信几乎等同于动态链接。6.17 如果我写了一个用于遵循 GPL 程序的插件，那么对可用于分发我的插件的许可证有什么要求？请参阅 “6.16 什么时候程序和插件会被认为是单一的结合程序 ？”以确定插件和主程序是否被视为单个结合程序，以及何时将其视为单独的作品。如果主程序和插件是单个结合程序，则这意味着您必须依据 GPL 或与 GPL 兼容的自由软件许可证授权插件，并以符合 GPL 的方式将源代码进行分发。与其插件分开的主程序对插件没有要求。6.18 在为非自由程序编写插件时，可以应用 GPL 许可证吗？请参阅 “6.16 什么时候程序和插件会被认为是单一的结合程序？”以确定插件和主程序是否被视为单个结合程序，以及何时被视为单独的程序。如果它们组成单一的结合程序，这意味着遵循 GPL 的插件与非自由主程序的结合将违反 GPL。但是，您可以通过向插件的许可证添加例外声明来解决该法律问题，并允许将其与非自由主程序链接。另请参阅正在编写的使用非自由库的自由软件的问题。6.19 我可以发布一个旨在加载遵循 GPL 的插件的非自由程序吗？请参阅 “6.16 什么时候程序和插件会被认为是单一的结合程序？”以确定插件和主程序是否被视为单个结合程序，以及何时被视为单独的程序。如果它们组成单一的结合程序，则主程序必须依据 GPL 或与 GPL 兼容的自由软件许可证发布，并且当主程序为了与这些插件一起使用而被分发时，必须遵循 GPL 的条款。然而，如果它们是单独的作品，则插件的许可证对主程序没有要求。另请参阅正在编写的使用非自由库的自由软件的问题。6.20 我想将遵循 GPL 的软件纳入我的专有系统。我只依据 GPL 给予我的权限来使用该软件。我可以这样做吗？（同 5.6）您不能将遵循 GPL 的软件纳入专有系统。GPL 的目标是授予每个人复制、再分发、理解和修改程序的自由。如果您可以将遵循 GPL 的软件整合到非自由系统中，则可能会使遵循 GPL 的软件不再是自由软件。包含遵循 GPL 程序的系统是该 GPL 程序的扩展版本。GPL 规定，如果它最终发布的话，任何扩展版本的程序必须依据 GPL 发布。这有两个原因：确保获得软件的用户获得自己应该拥有的自由，并鼓励人们回馈他们所做的改进。但是，在许多情况下，您可以将遵循 GPL 的软件与专有系统一起分发。要有效地做到这一点，您必须确保自由和非自由程序之间的通信 保持一定距离 （ arms length ） ，而不是将它们有效地结合成一个程序。这种情况与“纳入”遵循 GPL 的软件之间的区别，是一部分实质和一部分形式的问题。实质上是这样的：如果两个程序结合起来，使它们成为一个程序的两个部分，那么您不能将它们视为两个单独的程序。所以整个作品必须遵循 GPL。如果这两个程序保持良好的分离，就像编译器和内核，或者像编辑器和shell一样，那么您可以将它们视为两个单独的程序，但是您必须恰当执行。这个问题只是一个形式问题：您如何描述您在做什么。为什么我们关心这个？因为我们想确保用户清楚地了解软件集合中遵循 GPL 的软件的自由状态。如果人们分发遵循 GPL 的软件，将其称为系统（用户已知其中一部分为专有软件）的“一部分”，用户可能不确定其对遵循GPL的软件所拥有的权利。但是如果他们知道他们收到的是一个自由程序加上另外一个程序，那么他们的权利就会很清楚。6.21 我想将遵循 GPL 的软件纳入我的专有系统。我是否可以通过在 GPL 覆盖的部分和专有部分之间，放置一个遵循与 GPL 兼容的宽松许可证（如 X11 许可证）的 “封装” （ wrapper ） 模块来实现？不可以，X11 许可证与 GPL 兼容，因此您可以向遵循 GPL 的程序添加一个模块，并让其遵循 X11 许可证。但是，如果要将它们整合到一个更大的程序中，那么这个整体将包含 GPL 覆盖的部分，所以它必须在 GNU GPL 下作为一个整体获得许可。专有模块 A 仅通过遵循 X11 许可证的模块 B 与遵循 GPL 的模块 C 通信，该事实在法律上是无关紧要的；重要的是模块 C 包含在整体作品中。6.22 我可以编写使用非自由库的自由软件吗？如果您这样做，您的程序将无法在一个自由的环境中完全使用。如果您的程序依赖于一个非自由库来做某件工作，那么在自由软件世界里就不能做这个工作。如果这依赖于一个非自由库来运行，它不能是自由操作系统（例如 GNU）的一部分；这完全成为了自由软件世界里的禁区。所以请考虑：你可以找到一种方法来完成这项工作，而不使用这个库吗？你可以为该库编写一个自由软件替代选择吗？如果程序已经使用非自由库编写，那么改变决定也许已经太晚了。您也可以按照目前状态来发布程序，而不是不发布。但是请在 README 文件中提到，对非自由库的需求是一个缺点，并建议更改程序以便在没有非自由库的情况下执行相同的工作。请建议任何想要在程序上进行大量进一步工作的人首先将其从依赖非自由库中解脱出来。请注意，将某些非自由库与遵循 GPL 的自由软件相结合也可能存在法律问题。有关更多信息，请参阅有关 GPL 软件与和其不兼容库的问题。6.23 我可以将遵循 GPL 的程序与专有系统库链接吗？每个版本的 GPL 相对于其 左版 （ copyleft ） 都有一个例外，通常称为系统库例外。如果您要使用的与 GPL 不兼容的库符合系统库的标准，则使用它们不需要做特别的工作；分发整个程序的源代码的要求不包括那些库，即使您分发包含它们的链接可执行文件。作为 “系统库” （ system library ） 的标准在不同版本的 GPL 之间有所不同。GPL v3 在第 1 节中明确定义“系统库”，将其从 “相应源代码” （ Corresponding Source ） 的定义中排除。GPL v2 在第 3 部分的末尾进行，处理这个问题略有不同。6.24 如果我在遵循 GPL 的软件中使用了与 GPL 不兼容的库，会出现什么法律问题？如果您希望程序与未被系统库例外所涵盖的库链接，则需要提供许可来执行此操作。以下是您可以使用的两个许可证通知示例；一个用于 GPL v3，另一个用于 GPL v2。在这两种情况下，您应该将此文本放在您授予此权限的每个文件中。只有该程序的版权持有人才能合法地按照这些条款发布其软件。如果您自己编写了整个程序，假设您的雇主或学校没有声明版权，您就是版权所有者，因此您可以授权该例外。但是，如果您想在代码中使用其他作者的其他遵循GPL的程序的一部分，那么您无法将例外授权给他们。您必须获得这些程序的版权所有者的批准。当其他人修改程序时，他们不需要为他们的代码设置同样的例外——是否这样做是他们自己的选择。如果您打算链接的库不是自由软件，请参阅使用非自由库编写自由软件部分。如果您使用 GPL v3，您可以通过在第 7 节下授予额外权限来实现此目标。以下许可证通知将会执行此操作。您必须使用适合您程序的文本替换括号中的所有文本。如果不是每个人都可以为您打算链接的库分发源代码，则应该删除大括号中的文本；否则，只需删除大括号。Copyright (C) [年份] [著作权人名称]本程序为自由软件；您可以根据自由软件基金会发布的 GNU GPL 许可证的条款再分发和/或修改它；无论是依据本许可证的版本3，或（根据您的选择）任何更高版本。本程序基于希望其有用的目标而分发，但不提供任何担保；甚至也没有适销性或适用于特定用途的默示担保。有关详细信息，请参阅 GNU GPL 许可证。您应该已经收到本程序以及 GNU GPL 许可证的副本；如果没有，请参阅 http://www.gnu.org/licenses。依据 GNU GPL v3 第7节的额外许可如果您通过将[与库的名称]（或库的修改版本）链接或结合来修改本程序，或任何被覆盖的作品，其中包含被[库许可证的名称]的条款所覆盖的部分，则该程序的许可人授予您额外许可来传递所产出的作品。{这种结合的非源代码形式的相应源代码应包括所使用的[库名称]部分的源代码以及被覆盖的作品的源代码。}如果您使用 GPL v2，您可以为许可证条款提供自己的例外。以下许可证通知将这样做。同样，您必须使用适合您程序的文本替换括号中的所有文本。如果不是每个人都可以为您打算链接的库分发源代码，则应该删除大括号中的文本；否则，只需删除大括号。Copyright (C) [年份] [著作权人名称]本程序为自由软件；您可以根据自由软件基金会发布的 GNU GPL 许可证的条款再分发和/或修改它；无论是依据许可证的 v2，或（根据您的选择）任何更高版本。本程序基于希望其有用的目标而分发，但不提供任何担保；甚至也没有适销性或适用于特定用途的默示担保。有关详细信息，请参阅 GNU GPL 许可证。您应该已经收到本程序以及 GNU GPL 许可证的副本；如果没有，请参阅 http://www.gnu.org/licenses。将[您的程序名称]与其他模块静态或动态链接是以[您的程序名称]为基础构建结合作品。因此，GNU GPL 许可证的条款和条件将覆盖整个结合作品。另外，作为一个特殊例外，[您的程序名称]的版权持有人可以让您将[您的程序名称]与依据 GNU LGPL 发布的自由程序或库以及依据[库的许可证名称]标准发布的[库名称]中包含的代码相结合（或具有相同许可证的此类代码的修改版本）。您可以按照[您的程序名称]所依据的 GNU GPL 的条款和其他有关代码的许可证复制和分发此系统{前提是当 GNU GPL 要求分发源代码时将其他代码的源代码包含在内}。注意，对[您的程序名称]做出修改版本的人没有义务为其修改版本授予此特殊例外；是否这样做是他们自己的选择。GNU GPL 许可证允许发布一个没有此例外的修改版本；该例外也使得发布一个带有该例外的修改版本成为可能。6.25 我正在使用 Microsoft Visual C ++（或 Visual Basic）编写 Windows 应用程序，我将依据 GPL 发布它。依据GPL，是否允许将我的程序与 Visual C ++（或 Visual Basic）运行时库动态链接？您可以将您的程序链接到这些库，并将编译后的程序分发给其他程序。执行此操作时，运行时库是 GPL v3 所定义的“系统库”。这意味着您不需要担心将库的源代码包含在程序的相应源代码中。GPL v2 在第 3 节中提供了类似的例外。您可能不会随同您的程序以编译后的 DLL 形式分发这些库。为了防止不道德的分发者试图将系统库例外作为漏洞进行利用，GPL 表示，只有库不与程序本身一起分发，库才能被认定为系统库。如果您随同您的程序分发 DLL，则它们将不再符合此例外的资格；那么遵守 GPL 的唯一方法就是提供它们的源代码，而您无法做到。可以编写只在 Windows 上运行的自由程序，但这不是一个好主意。这些程序将被 Windows “围困” （ trapped ） ，因此对自由软件世界的贡献为零。6.26 我想修改遵循 GPL 的程序，并将它们与 Money Guzzler Inc. 的可移植性库链接。我无法分发这些库的源代码，因此，任何想要更改这些版本的用户都必须单独获取这些库。为什么 GPL 不允许这样做？有两个原因。第一、一般性的原因。如果我们允许 A 公司制作一个专有文件，B 公司分发与该文件相关的遵循 GPL 的软件，其效果等同于将 GPL 撕开一个大洞。对于保持 GPL 软件各种修改和扩展的源代码来说，这如同一张署名空白纸。让所有用户能够访问源代码是我们的主要目标之一，所以这个结果绝对是我​​们想要避免的。更具体地说，根据我们对条款的理解，与 Money Guzzler 库链接的程序版本不会是真正的自由软件——它们不会附带完整的让用户能够更改和重新编译程序的源代码。6.27 如果模块 Q 的许可证具有与 GPL 不兼容的要求，但是只有当 Q 自身分发时，而不是在较大程序中包含 Q 时，该要求才适用，是否可以使得该许可证与 GPL 兼容？可以将 Q 与遵循 GPL 的程序结合使用吗？如果程序 P 依据 GPL 被发布，这意味着“任何和所有部分”都可以依据 GPL 进行使用。如果您集成了模块 Q，并依据 GPL 发布结合程序 P + Q，则表示可以依据 GPL 使用 P + Q 的任何部分。P + Q 的一部分是 Q，所以依据 GPL 发布 P + Q 意味着，Q 的任何部分可以依据 GPL 进行使用。换句话说，依据 GPL 获得 P + Q 的用户可以删除 P，所以 Q 仍然遵循 GPL。如果模块 Q 的许可证允许您授予该许可，则其与 GPL 兼容。否则，它不与 GPL 兼容。如果 Q 的许可证在不明确的条件下表示，您必须在自己再分发 Q 时做某些事情（与 GPL 不兼容），那么不允许您依据 GPL 分发Q。因此，您也不能依据 GPL 发布 P + Q。所以您不能将 P 与 Q 进行链接或结合。6.28 在面向对象的语言（如 Java）中，如果我在不修改的情况下使用遵循 GPL 的类，并对其进行子类化，GPL 会以什么方式影响较大的程序？子类化将会创建衍生作品。因此，当您创建遵循 GPL 的类的子类时，GPL 的条款会影响整个程序。6.29 分发一个意图链接到 Linux 内核的非自由驱动程序会违反 GPL 吗？Linux（GNU / Linux 操作系统中的内核）依据 GNU GPL v2 进行分发。分发一个意图链接 Linux 的非自由驱动程序违反 GPL 吗？是的，这是一种违规行为，因为这样做形成了更大的结合作品。用户期望把这些片段放在一起的事实并不会改变任何事情。在代码实体部分拥有版权的 Linux 的每个贡献者都可以执行 GPL，我们鼓励他们对那些分发非自由 Linux 驱动程序的人采取行动。6.30 如何允许在受控接口下将专有模块与我的 GPL 库链接起来？在声明该文件依据 GNU GPL 进行分发的文本末尾，将以下文本添加到软件包中每个文件的许可证通知中：将 ABC 与其他模块静态或动态链接是基于 ABC 创建结合作品。因此，GNU GPL 许可证的条款和条件将覆盖整个结合作品。作为一个特殊的例外，ABC 的版权所有者可以将 ABC 程序与自由软件程序或依据 GNU LGPL 发布的库以及通过 ABCDEF 界面与 ABC 通信的独立模块相结合。您可以根据 ABC 的 GNU GPL 条款和其他代码的许可证复制和分发此系统，前提是您在 GNU GPL 需要分发源代码时提供该代码的源代码，并且您没有修改 ABCDEF 界面。请注意，制作 ABC 修改版本的人没有义务为其修改版本授予此特殊例外；是否这样做是他们自己的选择。GNU GPL 许可证允许发布不含此例外的修改版本；此例外也使得发布一个带有该例外的修改版本成为可能。如果您修改了 ABCDEF 界面，此例外不适用于您修改的 ABC 版本，并且您必须在分发修改后的版本时删除此例外。此例外是依据 GNU GPL 许可证第3版（“GPL v3”）第7节的额外权限。此例外允许通过指定接口（“ABCDEF”）与遵循不同许可证的模块进行链接，同时确保用户仍然会按照 GPL 通常的方式接收源代码。只有该程序的版权持有者才能合法授权此例外。如果您自己编写了整个程序，假设您的雇主或学校没有声明版权，您就是版权所有者，因此您可以授权该例外。但是，如果您想在代码中使用其他作者的其他遵循 GPL 程序的一部分，那么您无法对他们的例外进行授权。您必须获得这些程序的版权所有者的批准。6.31 考虑这种情况：1）X 发布遵循 GPL 的项目的 V1 版本。2）基于对 V1 的修改和新代码开发，Y 对 V2 的改进做出贡献。3）X 想将 V2 转换为非 GPL 许可证。X 需要 Y 的许可吗？需要。Y 需要依据 GNU GPL 发布其版本，因为它基于 X 的版本 V1。没有任何要求规定 Y 为其代码适用任何其他许可。因此，X 必须获得 Y 的许可才能依据另一个许可证发布该代码。6.32 我已经编写了一个与许多不同组件链接的应用程序，它们具有不同的许可证。我对我的程序有什么许可要求感到很困惑。您能告诉我可以使用哪些许可证吗？为了回答这个问题，我们需要看一下你的程序使用的每个组件的列表，该组件的许可证和一个简短的（几句话应该足够）说明你的库如何使用该组件的描述。两个例子是：为了让我的软件工作，它必须链接到遵循 LGPL 的 FOO 库。我的软件进行系统调用（使用我建立的命令行）来运行 BAR 程序，该程序遵循 GPL，“具有允许与 QUUX 链接的特殊例外”。6.33 可以在依据与 GPL 不兼容的许可证进行许可的文档中使用遵循 GPL 的源代码片段吗？如果片段足够小，依据“合理使用”或类似的法律，您可以将它们纳入其中，那么可以。否则，不可以。译者介绍：薛亮，集慧智佳知识产权咨询公司高级咨询师，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。