60楼#
发布于:2014-07-26 16:09
|
|
61楼#
发布于:2014-07-26 16:27
teredarguiterep:chromium回到原帖事实上 MPL 还是 BSD 许可对于商业公司开发 Gecko 核心浏览器没有很大影响 有方法可以绕过 MPL 的源代码公开限制 其他方面 MPL 和 BSD 并无太大区别 市面上也确实存在几款闭源的 Gecko 核心浏览器 |
|
|
62楼#
发布于:2014-07-26 16:34
jiangzhenjerry:你自己也说了,现在要靠扩展(你连“插件”和“扩展”还没分清,回去多补补课)来解决。开发扩展的人难道不需要动脑筋花力气的么?既然扩展开发者需要费精力来开发,那你让官方去弄官方也一样要花费精力,而现实就是官方没人手没精力去搞这个,光维护现在的A...回到原帖一个插件几天时间就能适配出来的老主题,你这说难难的,我就不想说什么了,反正用户会用脚投票的。 |
|
63楼#
发布于:2014-07-26 23:49
aaaa007cn:事实上我觉得你们的讨论走到了误区,这里说的授权针对的是完全链接后的最终产品,这也是为什么Mozilla源码中含有GPL代码,但是最终确定为MPL授权的原因,因为GPL代码并没有贡献到最终产品中(比如一些测试项目,一些独立的工具,一些js代码)。所以看某个软件违不违反协议,取决于哪些协议的代码影响了他。(比如如果确认GPL代码影响最终产品,那么不论怎么链接,这个软件都必须以GPL授权发布。如果有商业授权,就得看具体协议的分发内容) MPL在某种意义上与LGPL是相同的,所以完全可以进行商业使用,这有两个方面,一是动态链接,那么可以直接使用,完全不需要公开代码,即使修改了MPL模块,也只需要公开这部分代码即可,你的私有代码需要以动态链接的方式调用MPL模块,二是静态链接,这种方法的开源比较复杂,如果你没有进行任何的方法绕过,那么静态链接MPL组件必须公开你的全部代码,所以为了避免全部公开,一般需要要在MPL组件外部造一个接口库,这样只需要公开接口库即可。当然,对于Firefox这种大型的开源软件,一般都是使用动态链接他的组件。 另外,我查了一下chrome中的ffmpeg源码,看他的参数,是将ffmpeg配置成了LGPL授权,所以摒弃了ffmpeg中的GPL和商业代码。 最后,我想说下,这些协议的出发点都是分发时,只要你不分发,内部使用,怎么玩都行,自爽也挺好,所以后来又出来了AGPL协议限制这种行为。。。 |
|
|
64楼#
发布于:2014-07-27 11:50
pcxfirefox:我觉得你们的讨论走到了误区,这里说的授权针对的是完全链接后的最终产品,这也是为什么Mozilla源码中含有GPL代码,但是最终确定为MPL授权的原因,因为GPL代码并没有贡献到最终产品中(比如一些测试项目,一些独立的工具,一些js代码)。所以看某个软件违不违反协议,取决于哪些协议的代码影响了他。(比如如果确认GPL代码影响最终产品,那么不论怎么链接,这个软件都必须以GPL授权发布。如果有商业授权,就得看具体协议的分发内容)回到原帖 就像单纯使用 GPL 授权的 gcc 构建二进制并不会让生成的二进制也被污染成 GPL 一样 pcxfirefox:MPL在某种意义上与LGPL是相同的,所以完全可以进行商业使用,这有两个方面,一是动态链接,那么可以直接使用,完全不需要公开代码,即使修改了MPL模块,也只需要公开这部分代码即可,你的私有代码需要以动态链接的方式调用MPL模块,二是静态链接,这种方法的开源比较复杂,如果你没有进行任何的方法绕过,那么静态链接MPL组件必须公开你的全部代码,所以为了避免全部公开,一般需要要在MPL组件外部造一个接口库,这样只需要公开接口库即可。当然,对于Firefox这种大型的开源软件,一般都是使用动态链接他的组件。回到原帖 所以说只要绕过 LGPL、MPL 的源代码公开限制后 LGPL、MPL 和 BSD 对于商业公司来说也并无太大区别 这不会是商业公司选择 chromium 而不选择 gecko 的主要原因 pcxfirefox:另外,我查了一下chrome中的ffmpeg源码,看他的参数,是将ffmpeg配置成了LGPL授权,所以摒弃了ffmpeg中的GPL和商业代码。回到原帖 我觉得 google 不会在这种地方犯低级错误 teredarguiterep 有疑问的是 MPEGLA 的专利方面? 因为看他并没有提到 LGPL/GPL FFmpeg 特别提到了这点 http://ffmpeg.org/legal.html Q: Is it perfectly alright to incorporate the whole FFmpeg core into my own commercial product? 不过从种种事实来看 google 是有 MPEGLA 的专利授权的 这里还有一个好榜样 blink opera 直到 23 都不支持 h.264 的解码 pcxfirefox:最后,我想说下,这些协议的出发点都是分发时,只要你不分发,内部使用,怎么玩都行,自爽也挺好,所以后来又出来了AGPL协议限制这种行为。。。回到原帖 翻了下 AGPL 额外的限制是通过 B/S、C/S 这类方式来规避 GPL? 内部使用应该是仍然不受限的 |
|
|
65楼#
发布于:2014-07-27 12:26
aaaa007cn:就像单纯使用 GPL 授权的 gcc 构建二进制并不会让生成的二进制也被污染成 GPL 一样GCC授权协议是GPL+例外条款,所以呢,最终产品的授权也是受此影响,而例外条款影响的是GCC的运行时库(包含libgcc、libstdc++等)和头文件,对此需要着重指出的是运行时库,如果你要静态链接这些库,那么就失去了例外条款的庇护,自动转为GPL,当然这个问题GNU没有真正的追究,国内外大多数人是不会清楚这个协议转变的。 不清楚MPEGLA 的专利影响了哪些东西,所以要看chromium有没有采用MPEGLA专利的组件,如果没有的话,才是正常的。chrome作为一个商业软件,有没有都为正常,只要他有授权。 反正AGPL的产生背景就是我说的这种情形,我没有使用过这个协议将来也不会使用,我熟悉的开源软件中也没有采用AGPL的。 |
|
|
66楼#
发布于:2014-07-27 12:46
aaaa007cn:就像单纯使用 GPL 授权的 gcc 构建二进制并不会让生成的二进制也被污染成 GPL 一样我没有否认谷歌有授权。 我只是没看到授权证明,我相信很多人也会有这样的疑问。你一直把用户协议当作授权证明,这是不对的。谷歌与其他方签订的协议肯定会影响用户协议,例如加入声明等,但用户协议不是权利证明。chrome包含的MPEGLA协议是PERSONAL AND NON-COMMERCIAL USE,我相信chrome绝对不适用这个协议,只是chrome的使用必须遵守这个协议。 任何规避都是有风险的,尤其是对于商业公司。 |
|
67楼#
发布于:2014-07-27 18:06
teredarguiterep:我没有否认谷歌有授权。 我只是没看到授权证明,我相信很多人也会有这样的疑问。你一直把用户协议当作授权证明,这是不对的。谷歌与其他方签订的协议肯定会影响用户协议,例如加入声明等,但用户协议不是权利证明。chrome包含的MPEGLA协议是PE...回到原帖我扯出chrome是因为“厂家没有得到明确许可”,这是我们无法判断的,我并不关心chrome是否有授权。 |
|
68楼#
发布于:2014-07-28 11:03
MuJian:一个插件几天时间就能适配出来的老主题,你这说难难的,我就不想说什么了,反正用户会用脚投票的。回到原帖仿Chrome是为了将Chrome的用户招徕,但是不是起了反效果就要看分版本的市场份额统计了。 一个扩展作者几天时间就做出来……外国有个48小时游戏设计大赛,但可不是谁都能参赛的啊。 再说,Classic Theme Restorer (Customize Australis) 【https://addons.mozilla.org/zh-CN/firefox/addon/classicthemerestorer/】的作者本来就是专注于旧风格外观的附加组件设计者,他本身就是精于做这个的,开发出恢复旧主题的扩展对他来说驾轻就熟。 再说,从用上新主题开始的nightly,到正式发布,都很长时间(欢迎补充)了,这时间内可以作初步开发,不必要等到正式发布后再从头开始写的。 |
|
|
69楼#
发布于:2014-07-30 01:16
pcxfirefox:GCC授权协议是GPL+例外条款,所以呢,最终产品的授权也是受此影响,而例外条款影响的是GCC的运行时库(包含libgcc、libstdc++等)和头文件,对此需要着重指出的是运行时库,如果你要静态链接这些库,那么就失去了例外条款的庇护,自...回到原帖这个 GCC 例外条款有点意思 搜了一下 https://www.gnu.org/licenses/gcc-exception.html https://www.gnu.org/licenses/gcc-exception-3.1-faq.html I use a proprietary compiler toolchain without any parts of GCC to compile my program, and link it with libstdc++. My program itself does not include any runtime library code the same way that GCC-compiled programs include libgcc. Can I still take advantage of the exception? 不区分静态链接、动态链接 What libraries does the GCC Runtime Library Exception cover? 覆盖 libgcc, libstdc++ 组合这两个回答看 只要编译过程是合法的(见 https://www.gnu.org/licenses/gcc-exception.html 中的定义) 静态链接 libgcc、libstdc++ 仍然享受这个例外条款,不会导致结果 GPL 化? |
|
|
70楼#
发布于:2014-07-30 11:39
aaaa007cn:这个 GCC 例外条款有点意思看来MinGW(64)项目组一些开发者理解有误,反正很多开源库都有这样的例外条款的,比如wxWidgets虽然是LGPL授权,但是他也允许商业软件使用静态链接,Qt方面就没有这样的例外。 |
|
|
上一页
下一页