Firefox 频繁的更新默认主题，更改默认设置为那般啊？

默认主题总是换，我记忆中29以前有一次主题小更新，然后29大更新，而且可恶的是默认主题强制你使用，真的搞不懂，你保留一个老主题难道很难么？要知道客户的习惯是非常难以改变的，看看windows，直到目前win8.1了，经典win95主题还能用！win95主题我用到vista时代才换，因为xp什么的主题太原始，根本没感觉。
再说一些默认设置，升级后总被改，比如30升级到31，默认最后一个标签页关闭ff就退出，我以前是不退出的！还有标签页关闭按钮，这个我一直隐藏，好好的功能说取消就取消了。想想一些实用功能，比如鼠标右键里的“属性”按钮，比如“附加组件栏”说取消就取消，真的不知所谓，虽然差不多都能补救回来，可是真的很麻烦！！！

前2天吧cnbeta看新闻，FF占用率又下降了，我一点都不意外，自从FF大版本号疯狂增加后，这种忽视客户体验的浮躁越来越多了，不知道，我还能坚持多久。

aaaa007cn：这个 GCC 例外条款有点意思
搜了一下
https://www.gnu.org/licenses/gcc-exception.html
https://www.gnu.org/licenses/gcc-exception-3.1-faq....回到原帖

看来MinGW(64)项目组一些开发者理解有误，反正很多开源库都有这样的例外条款的，比如wxWidgets虽然是LGPL授权，但是他也允许商业软件使用静态链接，Qt方面就没有这样的例外。

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?

    Yes. While combining libgcc with GCC-compiled object code is probably the most common way the exception is used, neither the GPL nor the GCC Runtime Library Exception distinguish between static linking, dynamic linking, and other methods for combining code in their conditions. The same permissions are available to you, under the same terms, no matter which method you use.

    Note that if you distribute libstdc++ as an independent library, you will need to follow the terms of the GPL when doing so. For example, if you distribute the library itself in object code form, you will need to provide source code to your recipients using one of the methods listed in section 6 of GPLv3. But as long as you are eligible to take advantage of the GCC Runtime Library Exception's permissions for your own program, the GPL's terms do not extend to it.

不区分静态链接、动态链接

What libraries does the GCC Runtime Library Exception cover?

    The GCC Runtime Library Exception covers any file that has a notice in its license headers stating that the exception applies. This includes libgcc, libstdc++, libfortran, libgomp, libdecnumber, libgcov, and other libraries distributed with GCC.

覆盖 libgcc, libstdc++

组合这两个回答看
只要编译过程是合法的（见 https://www.gnu.org/licenses/gcc-exception.html 中的定义）
静态链接 libgcc、libstdc++ 仍然享受这个例外条款，不会导致结果 GPL 化？

MuJian：一个插件几天时间就能适配出来的老主题，你这说难难的，我就不想说什么了，反正用户会用脚投票的。回到原帖

仿Chrome是为了将Chrome的用户招徕，但是不是起了反效果就要看分版本的市场份额统计了。
一个扩展作者几天时间就做出来……外国有个48小时游戏设计大赛，但可不是谁都能参赛的啊。
再说，Classic Theme Restorer (Customize Australis) 【https://addons.mozilla.org/zh-CN/firefox/addon/classicthemerestorer/】的作者本来就是专注于旧风格外观的附加组件设计者，他本身就是精于做这个的，开发出恢复旧主题的扩展对他来说驾轻就熟。
再说，从用上新主题开始的nightly，到正式发布，都很长时间（欢迎补充）了，这时间内可以作初步开发，不必要等到正式发布后再从头开始写的。

teredarguiterep：我没有否认谷歌有授权。 我只是没看到授权证明，我相信很多人也会有这样的疑问。你一直把用户协议当作授权证明，这是不对的。谷歌与其他方签订的协议肯定会影响用户协议，例如加入声明等，但用户协议不是权利证明。chrome包含的MPEGLA协议是PE...回到原帖

我扯出chrome是因为“厂家没有得到明确许可”，这是我们无法判断的，我并不关心chrome是否有授权。

aaaa007cn：就像单纯使用 GPL 授权的 gcc 构建二进制并不会让生成的二进制也被污染成 GPL 一样


所以说只要绕过 LGPL、MPL 的源代码公开限制后
LGPL、MPL 和 BSD 对于商业公司来说也并无太大区别
这不会是商业公司...回到原帖

我没有否认谷歌有授权。 我只是没看到授权证明，我相信很多人也会有这样的疑问。你一直把用户协议当作授权证明，这是不对的。谷歌与其他方签订的协议肯定会影响用户协议，例如加入声明等，但用户协议不是权利证明。chrome包含的MPEGLA协议是PERSONAL AND NON-COMMERCIAL USE，我相信chrome绝对不适用这个协议，只是chrome的使用必须遵守这个协议。
任何规避都是有风险的，尤其是对于商业公司。

aaaa007cn：就像单纯使用 GPL 授权的 gcc 构建二进制并不会让生成的二进制也被污染成 GPL 一样


所以说只要绕过 LGPL、MPL 的源代码公开限制后
LGPL、MPL 和 BSD 对于商业公司来说也并无太大区别
这不会是商业公司...回到原帖

GCC授权协议是GPL+例外条款，所以呢，最终产品的授权也是受此影响，而例外条款影响的是GCC的运行时库（包含libgcc、libstdc++等）和头文件，对此需要着重指出的是运行时库，如果你要静态链接这些库，那么就失去了例外条款的庇护，自动转为GPL，当然这个问题GNU没有真正的追究，国内外大多数人是不会清楚这个协议转变的。

不清楚MPEGLA 的专利影响了哪些东西，所以要看chromium有没有采用MPEGLA专利的组件，如果没有的话，才是正常的。chrome作为一个商业软件，有没有都为正常，只要他有授权。

反正AGPL的产生背景就是我说的这种情形，我没有使用过这个协议将来也不会使用，我熟悉的开源软件中也没有采用AGPL的。

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?
A: You might have a problem here. There have been cases where companies have used FFmpeg in their products. These companies found out that once you start trying to make money from patented technologies, the owners of the patents will come after their licensing fees. Notably, MPEG LA is vigilant and diligent about collecting for MPEG-related technologies.

不过从种种事实来看
google 是有 MPEGLA 的专利授权的
这里还有一个好榜样
blink opera 直到 23 都不支持 h.264 的解码

pcxfirefox：最后，我想说下，这些协议的出发点都是分发时，只要你不分发，内部使用，怎么玩都行，自爽也挺好，所以后来又出来了AGPL协议限制这种行为。。。回到原帖

翻了下 AGPL
额外的限制是通过 B/S、C/S 这类方式来规避 GPL？
内部使用应该是仍然不受限的

aaaa007cn：事实上
MPL 还是 BSD 许可对于商业公司开发 Gecko 核心浏览器没有很大影响
有方法可以绕过 MPL 的源代码公开限制
其他方面 MPL 和 BSD 并无太大区别
市面上也确实存在几款闭源的 Gecko 核心浏览器回到原帖

我觉得你们的讨论走到了误区，这里说的授权针对的是完全链接后的最终产品，这也是为什么Mozilla源码中含有GPL代码，但是最终确定为MPL授权的原因，因为GPL代码并没有贡献到最终产品中（比如一些测试项目，一些独立的工具，一些js代码）。所以看某个软件违不违反协议，取决于哪些协议的代码影响了他。（比如如果确认GPL代码影响最终产品，那么不论怎么链接，这个软件都必须以GPL授权发布。如果有商业授权，就得看具体协议的分发内容）

MPL在某种意义上与LGPL是相同的，所以完全可以进行商业使用，这有两个方面，一是动态链接，那么可以直接使用，完全不需要公开代码，即使修改了MPL模块，也只需要公开这部分代码即可，你的私有代码需要以动态链接的方式调用MPL模块，二是静态链接，这种方法的开源比较复杂，如果你没有进行任何的方法绕过，那么静态链接MPL组件必须公开你的全部代码，所以为了避免全部公开，一般需要要在MPL组件外部造一个接口库，这样只需要公开接口库即可。当然，对于Firefox这种大型的开源软件，一般都是使用动态链接他的组件。

另外，我查了一下chrome中的ffmpeg源码，看他的参数，是将ffmpeg配置成了LGPL授权，所以摒弃了ffmpeg中的GPL和商业代码。

最后，我想说下，这些协议的出发点都是分发时，只要你不分发，内部使用，怎么玩都行，自爽也挺好，所以后来又出来了AGPL协议限制这种行为。。。

jiangzhenjerry：你自己也说了，现在要靠扩展（你连“插件”和“扩展”还没分清，回去多补补课）来解决。开发扩展的人难道不需要动脑筋花力气的么？既然扩展开发者需要费精力来开发，那你让官方去弄官方也一样要花费精力，而现实就是官方没人手没精力去搞这个，光维护现在的A...回到原帖

一个插件几天时间就能适配出来的老主题，你这说难难的，我就不想说什么了，反正用户会用脚投票的。

teredarguiterep：chromium回到原帖

事实上
MPL 还是 BSD 许可对于商业公司开发 Gecko 核心浏览器没有很大影响
有方法可以绕过 MPL 的源代码公开限制
其他方面 MPL 和 BSD 并无太大区别
市面上也确实存在几款闭源的 Gecko 核心浏览器

aaaa007cn：chromium 不全都是 BSD 授权回到原帖

火狐也不全是MPL

teredarguiterep：chromium回到原帖

chromium 不全都是 BSD 授权

aaaa007cn：原话中没有 BSD回到原帖

chromium

teredarguiterep：相对于bsd。回到原帖

原话中没有 BSD