linux 点 cn/article-11683-1.html
https://linux.cn/article-11683-1.html

太长不看了，谁简单解释一下

太长不看了，谁详细解释一下

"当然，笔者没太多精力去调查技术细节，点到为止，有兴趣的读者可以进行深入研究。"

这俩是老冤家了



HBuilder 起诉 APICloud，， 大概是说 APICloud 中插件代码抄了 HB 插件输入法功能插件、真机运行功能插件、边改边看功能插件源码...
争议的焦点围绕 GPL 协议各种许可，及插件 和主软件的从属关系...

之前就看过这个案子。
简单来说，就是一个名为 HBuilder 的工具包，里面有很多插件，后来一个叫 APICloud 也做了一个类似的工具包，并且用了 HBuilder 三个插件。然后 HBuilder 把 APICloud 告上法庭。
APICloud 用的三个插件直接有 HBuilder 的源文件，连数字签名都有，所以就在用了这点没有异议。双方争辩的点在于这几个插件到底是不是 GPL 开源。
原作者 HBuilder 说不是，因为他们根目录没有 GPL 协议，这几个插件目录也没有 GPL 协议，只是其他目录有 GPL 协议。
APICloud 认为是，他们认为 GPL 有传染性，所以 HBuilder 其他目录有开源协议代表这三个插件也是开源。HBuilder 则认为传染性在这里不适用，他们认为这三个插件是独立程序，不是 HBuilder 里其他开源程序的衍生品。
一审法院支持原告 HBuilder 的诉求，认定这三个插件不在开源范围，是三个独立作品，认定存在三个侵权行为（这个跟赔偿有关系，著作权法规定每个侵权最多赔偿 50 万），然后就侵权行为判赔 125 万，还有赔礼道歉以及赔偿一些其他的合理支出。
二审法院也认定三个插件不在开源范围，但又认为三个插件不能独立于 HBuilder 运行，所以不认为存在三个侵权行为，就承认一个侵权行为，然后就侵权行为判赔 50 万，其他的基本没变。

简单看了下，好像是说如果 HBuilder 是 GPL，会与 eclipse 的 EPL 许可证冲突

GPL 还是 LGPL ？

大前提说明国内法律还是认 GPL 约束的

我第一个版本就是 GPL
今天发布第二个版本，用的新的授权协议，参考禅道的。
https://github.com/tianshiyeben/wgcloud

这个案件依旧回避了 GPL 传染性的有效性，甚至二审在推翻插件独立性认定之后，仍然没有确认 GPL 的传染性。
再等以后其他更多案例吧，毕竟我国不是判例法。


只能说确认了 GPL 许可有效，不与我国法律冲突，但对于 GPL 最主要的目的也就是传染性却完全回避。如果没有传染性，GPL 与 MIT, Apache 之类许可就没多大差别了。

发一个让人编辑后才能访问的超链接是哪里的习惯

我是 windows 系统，点哪里可以看？

没认证手机，不能直接发，需要处理一下。

还是 DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE 简单粗暴，哪有那么多花里胡哨的玩意

估计是没绑手机号和邮箱发不出来，其实去掉 http(s)还是可以发的

文章的意思好像是：Eclipse 本身是 EPL 协议而不是 GPL 的，而其中有一个叫 Aptana 的插件在使用 EPL 的同时也使用了有例外的 GPL，以防止污染 Eclipse 的协议。而原告 HBuilder 本身并没有申明 GPL 协议。但被告好像抗辩时用 Aptana 的 GPL 来传染原告，最后没被法庭接受。

其实主要是 Eclipse 本身其实不是 GPL 协议的，而是 EPL 的。只是其中有插件是 GPL 的。被告抗辩称因为有这个插件，所以污染了整个原告的代码。但是文章中指出，这个插件的 GPL 是带例外的 GPL，以保证不会污染 Eclipse 的 EPL 协议。综上所述，其实这个案件不太能作为 GPL 有否污染性的确认。



原来是这样啊。我印象中当时不认证手机号帐号就不让用了，早知道我也不认证了。。。

aptana 基于 eclipse，而 apicloud 和 hbuilder 又基于 aptana，aptana 有双重协议 epl 和 gpl 协议附例外声明，hbuilder 在 aptana 基础上开发了 3 个插件，然后 apicloud 拿去使用了。按照 aptana 协议声明，hbuilder 开发的插件按理是受 gpl 协议的传染性影响