这是一个创建于 1826 天前的主题，其中的信息可能已经有所发展或是发生改变。
预写一个非 GNU 的程序，谓之张三，需要使用某 GNU 程序库，王五。
另写一个程序，李四。李四直接调用王五，李四为 GNU 协议。李四通过管道、套接字等方式提供 API，此 API 内的指令语法、数据格式均与王五无关，且均为一般性文法或结构，诸如：read, write, set, get, 常用文件字节流，不包含王五独有特征的 JSON 、XML 等等
而后张三与李四通信，在舍弃一部分性能和功能后，是否可以通过此方法让张三采用非 GNU 兼容的协议？/p>
 | 1 ixiaohei 2020-10-12 10:37:13 +08:00 没看懂你说的；调用 gnu 程序不存在 gnu 传染行啊，除非你修改 gnu 程序源码才存在传染性 |
 | 2 InkStone 2020-10-12 10:39:33 +08:00 你可以看一下 Android 是如何通过 HAL 层阻断开源协议的 |
 | 5 renmu123 2020-10-12 10:46:45 +08:00 via Android 不改源代码的话不会传染 |
 | 6 ungrown OP 全文手滑，是 GPL 不是 GNU 全文手滑，是 GPL 不是 GNU 全文手滑，是 GPL 不是 GNU 好在大家都能看懂…… |
| 7 ungrown OP @stoneabc #4 @renmu123 #5 https://zh.wikipedia.org/wiki/GNU%E9%80%9A%E7%94%A8%E5%85%AC%E5%85%B1%E8%AE%B8%E5%8F%AF%E8%AF%81#%E9%8F%88%E6%8E%A5%E5%92%8C%E6%B4%BE%E7%94%9F%E4%BD%9C%E5%93%81 链接和派生作品 争议：非 GPL 软件是否可以合法地链接或动态地链接到 GPL 库 据 FSF 称，“GPL 不要求您发布修改版本，或其任何部分，您可以自由地进行修改和留作私人使用，而无需发布。”然而若是向公众发布 GPL 许可的实体，则有链接的问题：换言之，“使用 GPL 库的专利程序是否违反了 GPL ？” 这个关键的争议的重点是“非 GPL 软件是否可以合法地链接或动态地链接到 GPL 库”。这个问题有不同的看法。GPL 清楚地表明，GPL 下的所有派生作品代码都必须属于 GPL 。关于使用 GPL 库和将 GPL 软件捆绑到更大的包中（可能通过静态链接混合成二进制文件），会出现歧义。这最终不是 GPL 本身的问题，而是著作权法如何界定派生作品。有以下观点存在 观点：动态和静态链接违反 GPL 自由软件基金会（其拥有若干著名的 GPL 软件产品和许可文字本身的著作权）声称，使用动态链接库的可执行档确实是派生作品。然而，这不适用于彼此通信的单独程序。自由软件基金会还创建了 LGPL，LGPL 与 GPL 极为相似，但额外允许以“使用库”为目的的链接。理查德斯托曼和自由软件基金会特别鼓励库作者根据 GPL 来进行许可，以便专有程序无法使用 GPL 库，透过为自由软件世界提供比专有世界更多的工具来保护自由软件世界。 观点：静态链接违反 GPL，但动态链接则有待厘清 有些人认为，当静态链接产生派生作品时，不清楚动态链接到 GPL 代码的可执行档是否应被视为派生作品（请参阅 Weak Copyleft ）。Linux 作者 Linus Torvalds 同意动态链接可以创建派生作品，但在这种情况下不一致。一位 Novell 律师写道，动态链接不算是派生作品的观点合理但是不够明确，专有的 Linux 内核驱动程序就是善意的动态链接的一大明证。在 Galoob 对任天堂案中，美国第九巡回上诉法院将派生作品定义为具有“形式”或“永久性”，并指出“侵权作品必须以某种形式包含一部分受著作权保护的作品”，但是没有明确的法院裁决来解决这一特定的冲突。 观点：链接无关 根据 Linux Journal 的一篇文章，Lawrence Rosen （一次性开源计划总顾问）认为，链接的方法与一个软件是否是派生作品的问题大不相干; 更重要的是关于软件是否旨在与客户端软件和 /或库连接的问题。他指出：“新程序是否是派生工作的主要指示是原始程序的源代码是否以[复制粘贴方式]使用，以任何方式进行修改，翻译或以其他方式更改新程序，如果没有，那么我会认为这不是派生工作“，并行出了关于意图，捆绑和联动机制的许多其他观点。 他进一步在他公司的网站上论证，这种“以市场为基础”的因素比链接技术更重要。 还有一个具体问题是，一个插件或模块（如 NVidia 或 ATI 显卡内核模块）是否也必须是 GPL，如果它可以合理地被认为是自己的工作。这个观点表明，如果工作是 GPLv2，则可以根据任意许可证，为设计使用插件的软件提供合理的单独插件或插件。特别感兴趣的是 GPLv2 段落： “ 您可以修改本程序或其任何部分的副本或副本，从而根据本程序形成工作，并根据上述第 1 节的条款复制和分发此类修改或工作，前提是您也符合所有这些条件：…… b ）您必须将您分发或发布的任何作品全部或部分包含或派生自本计划或其任何部分，根据本许可证的条款无偿授予所有第三方。 ...这些要求适用于整体修改后的工作。 如果该作品的可识别部分不是源自该程序，并且可以被合理地视为独立和独立的作品，则本许可证及其条款在将其作为单独作品分发时不适用于这些部分。 但是，当您分发相同的部分作为基于程序的工作的整体的一部分时，整体的分布必须符合本许可证的条款，其许可证持有人的权限将扩展到整个，和每个部分，无论谁写的。 ” GPLv3 有一个不同的条款： “ 您可以根据第 4 节的条款，以源代码的形式传达基于本程序的工作，或从程序生成的工作，只要您也符合以下所有条件：…… c ）您必需根据本许可将整个作品整体许可给任何拥有副本的人。 因此，本许可证连同任何适用的第 7 条附加条款适用于整个工作及其所有部分，无论其包装方式如何。 本许可证不允许以任何其他方式许可该作品，但如果您已单独收到，则不会使该许可无效。……与其他单独和独立的作品的汇编，而不是其涵盖的作品的性质延伸，而不是与其组合，以形成更大的程序，在一个或多个如果汇编及其产生的著作权不被用于限制编辑用户的访问权限或合法权限超出个人作品允许的范围，则称为“汇总”。 合并中的被覆盖的工作不会导致本许可证适用于合并的其他部分。 ” 作为一个案例研究，一些据称为 GPLv2 CMS 软件（如 Drupal 和 WordPress ）的专有插件和主题 /外观已经受到打击，双方均被采纳[62][63] FSF 区分插件如何被调用。如果通过动态链接调用插件，并且它对 GPL 程序运行函数调用，那么它很有可能是派生工作。[64] 与非 GPL 程序的通信和绑妥 与其他程序通信的行为本身并不要求所有软件都是 GPL; 也不用 GPL 软件分发 GPL 软件。但是，必须遵循较小的条件，确保 GPL 软件的权利不受限制。 以下是 gnu.org 的 GPL FAQ，该常见问题解答介绍了允许软件与 GPL 程序进行通信和绑妥的程度： “ Q：“合辑”（ Aggregate ）与其他类型的“修改版本”有什么区别？ A：“合辑”由多个单独的程序组成，分布在同一个 CD-ROM 或其他媒体上。GPL 允许您创建和分发合辑，即使其他软件的许可证是非自由的或 GPL 不兼容的。 唯一的条件是，您不能根据禁止用户行使每个计划的个人许可证授予他们的权利的许可证发布合并。 Q：两个单独的程序之间的区别在哪里，一个程序有两个部分？ A：这是一个法律问题，最终法官会决定。 我们认为适当的标准取决于通信机制（ exec，pipes，rpc，共享地址空间中的函数调用等）和通信的语义（哪些信息被互换）。如果模块包含在相同的可执行文件中，则它们在一个程序中被明确地组合。 如果模块设计为在共享地址空间中连接在一起运行，那么几乎肯定意味着将它们组合成一个程序。相比之下，管道（ pipe ）、接口（ socket ）和命令行参数是通常在两个独立程序之间使用的通信机制。 所以当它们用于通信时，模块通常是单独的程序。 但是，如果通信的语义足够亲密，交换复杂的内部数据结构，那么也可以将这两个部分合并成一个更大的程序。 ” 因此，FSF 想在“库”和“其他程序”之间透过以下两种方式划清界线：1 ）信息交换的“复杂性（ complexity ）”和“亲密程度（ intamacy ）”； 2 ）信息交换的“机构（ mechanics ）“，而不是“语义（ semantic ）”。但让问题不明确，而又复杂的情况下，交由判例法来决定。 |
| 8 ungrown OP |
 | 9 nuk 2020-10-12 11:06:12 +08:00 如果张三脱离李四能独立工作，或者王五提供的不是必须的功能，才能脱离 GPL，否则不能使用非 GPL |
 | 10 luojiyin87 2020-10-12 11:24:32 +08:00 把 GPL 部分编译出二进制可执行文件， 然后调用 |
 | 11 kangsheng9527 2020-10-12 11:43:02 +08:00  1 |
 | 12 dyv9 2020-10-12 11:53:37 +08:00 @kangsheng9527 大杀手锏 |
 | 13 kaedea 2020-10-12 11:53:37 +08:00 via Android 用系统调用 API 隔离一下 |
 | 14 reus 2020-10-12 11:54:26 +08:00 via Android 不愿意接受，那就不要用 gpl 的库 |
 | 15 no1xsyzy 2020-10-12 13:16:42 +08:00 不是 GPL 照样可以在 Linux 下 syscall，不说 POSIX 兼容的部分，照样可以 epoll 不是 GPL 照样可以作为 Linux 内核模块 但一般建议作为生态的一部分仍然使用同许可，不是法律要求而是社区习惯，也有 “让别人放心用” 的目的在。 @kangsheng9527 没头没脑不知所云 一些修辞方式让我感觉你母语不是汉语 |
 | 16 wzzzx 2020-10-12 13:38:04 +08:00 如果一定要用。可以单独整一个可执行程序调用这个库，然后开源这个可执行程序。你真正的应用跟这个开源的可执行程序进行一些通信就可以了 |
| 17 kangsheng9527 2020-10-12 13:48:00 +08:00 @wzzzx 跟 2 楼说法差不多 |
| 18 dyv9 2020-11-03 08:24:59 +08:00 via Android 我觉得以 TCP 远程调用 “未经修改的” 可以隔离，因为 2 个程序并不共享内存空间和指令集，法官不能认定我的作品是 GPL 的派生作品，我的作品独立于 GPL 的库，这有利于证明我只是 “使用未经修改的库”。开源的基本原则是大家只是使用它一直都没有限制，但再发布 redistribution 就是受限制的。也就是说我把它拿到我家公司自己用（外包项目），不卖出去是没问题的。如果是产品卖出甚至是白送都是需要受条款限制的。 |
Select Language