不要使用ExtJS（1）

英文来源：http://pablotron.org/?cid=1556

不要使用ExtJS

2008年 5月15日，星期四 07:26:16

 

几年前就有人向我推荐 YUI和Ext（正式的说法是YUI-Ext）。但我的想法已将改变了，压根就不要使用Ext。只从法不依赖，Ext的许可文件改变了4次，而且每一次许可都会变得更加苛刻。

历史

最初， Ext是作为YUI的一种扩展出现的。与YUI一样，它遵循BSD-许可方式。YUI-Ext增加了一些YUI非常需要的特性。其中最显著的是布局系统、TreeView部件和DataGrid部件（尽管与Ext相比缺少一些灵活性，但YUI也曾添加过这些部件）。最后，还增加了对jQuery和Prototype的支持。Ext团队去掉了前缀“YUI-”，YUI-Ext也就变成了Ext。

Ext1.0的许可遵循 LGPL。尽管从BSD方式转为了LGPL并没有什么坏处，但这也是值得注意的，因为LGPL比BSD要严格。

最终， Ext团队又一次改变了许可方式。最新的许可是一种定制许可，该种方式下对LGPL使用权的授予附加了条件。基本上应用LGPL用途，但是以你不会开发一个库或Ext复制品为前提的。

困惑了吧？事实上，我也是。下面是从旧的 Ext“开源许可”中摘录的文字：

Ext许可也遵循开源许可 LGPL3.0的条款，你在满足下面条件的情况下可以得到许可： l         将 Ext用于排除使用非开源软件的开源项目中 l         将 Ext作为个人，教育性的或非盈利的用途 l         如果正在商业应用而非软件开发库或工具包中使用 Ext，你应该符合LGPL的要求，而且你不能获得我们对项目的支持

大部分开源的开发者对于这样混乱的许可感到困惑都是值得理解的。最大的问题它没有明确指出该许可是不是与其他的开源许可相一致。而且，它也没有明确 Ext是否可以与开源软件一起合法的发布，因为许可仅仅授予了LGPL使用权而没有LGPL发布权。

    迫于这样的抱怨， Ext团队又对许可做了变更：Ext最近的版本的许可遵循GPLv3。对于许多用户来说最近的变更使事情变得复杂了许多，关于此我们将会在下一部分中看到。

问题

GPL比 BSD和LGPL要严格的多。它很少用于开发库，因为如果开发库用作任何的非GPL软件时，病毒条款就会生效。事实上，这样的问题在16年前创建LGPL时就遇到了：

1990年的时候，一种低限制性的许可将战略性的用于一些软件库的趋势就变得明显；因此，当 1991年6月GPL第2版（GPLv2）发布的时候，一种第二许可-开发库通用大众许可（ Library General Public License ， LGPL）就同时被介绍，并且作为补充将版本号定为了第 2版。1999年当LGPL发布2.1版时版本号发生了冲突，以至将其改名为轻量GNU通用大众许可（ GNU Lesser General Public License）以反映其在 GNU体系中的地位。

（那么，）这样的变更会影响到谁呢？（下面以并）不特别的顺序（给出描述）：

l         （ Ext）扩展的制作者：原来的Ext用户扩展可能就像制作者看起来合适的方式许可了。这对于Ext最近的版本不再有效；新的用户扩展必须遵循GPL许可，因为病毒条款禁止将Ext用于非GPL许可。

l         商业用户：以前的许可，即使有疑问的定制许可，都允许在接近源的商业应用中使用 Ext。对于最近的Ext版本，这不再适用，因为病毒条款禁止将Ext用于非GPL的商业许可。

l         非 GPL的开源开发者：BSD和LGPL许可的Ext版本能用于其它的非GPL软件。对于最近的Ext版本，这也是无效的，因为病毒条款禁止将Ext用于非GPL许可。

当你考虑链接和发布的时候，事情会变得越发“黑暗”。当链接到 Ext时生成动态页面计数吗？关于那些使用Ext的应用程序和访问一个通用API会反馈诸如SOAP端点或RSS的东西吗？

这些问题在 ExtJS论坛上一个关于许可变更的议题中得到了解释。

下面是来自 Jack Slocum-主要的Ext开发者做出的回答：

在一个页面，特别是为 Ext设计得页面中，如果你要生成任何的经由服务器markup或javascript代码，那么服务器代码也必须遵循GPL。 例如： l         假设你有一个包含了 ExtJS的文件index.php，根据FSF，这种情况下，index.php也要遵循GPL，因为它用到了Ext。由于它必须遵循GPL，那么其源代码就必须发布。由于它必须遵循GPL，GPL的病毒条款就会生效而且在服务器端任何使用index.php的情况也要遵循GPL。（注意：这是一个相当灰色的区域） l         假如你是用服务器端代码生成与 ExtJS交互的Javascript，那么这些代码也要遵循GPL。 就像 MySql和其他的GPL软件，在没有得到GPL许可的情况下使用的GPL代码将不能与你的应用程序绑定或一同发布。即使你让最终用户（开发者？）自己下载并安装了ExtJS，他们也绑定到了（GPL）许可上而非你或你的软件。 为了解答相关问题，我们已经在下面这 2个页面中定义并解释了一些原因和许可含义： http://extjs.com/products/license.php http://extjs.com/company/dual.php 在开头给出的例子只是我的看法，它们并不能代表什么。而且，对于我们来说去分析每个人（对于 Ext）的用途,并说出是不是有人遵循GPL是不可能的。事实上，那是一个律师甚或对你的应用程序以及使用ExtJS的方式有很好地了解的人的任务。 最后，我希望 ExtJS在发展的层次上能友好的开源并具有一个好的商业模式。原有的Ext许可在开源方面是不友好的并且在开源项目中很大程度上扼杀了用户的选择权。那不是我们的目的，因此我们必须变更。

上面的描述存在一些问题。最大的问题是早期的 BSD许可和滞后的LGPL许可没有这样的含糊不清。

换言之， Ext团队试图去解决的问题是他们自己造成的。如果哪还不够糟糕，这样的解答确实伤害了许多开源开发者，而远远超过了它所给于的帮助。

尝试着为非 GPL开源开发者澄清状况，我列举了一些在Ext许可中存在的问题。我也在Reddit发表了有关许可变更的帖子并总结了下面的问题：

作为长达 8页的有关许可变更的思考，我接受对于注解的任何部分的简单的或者其他方式的反馈。 下面是那些注解： 新的许可阻止那些使用 GPL之外许可方式的开源软件使用Ext。那些使用了流行的开源许可，如LGPL许可、BSD许可、MIT许可以及Aristic许可的应用程序将被要求同时遵循GPL，在你的发布中（请）小心设计你的应用程序以适应这样的要求，使用一个原有的LGPL许可的Ext版本，或者完全移植到其他开发库上。 还有下面的一则： 那些为他们的软件提供一个比 GPL更加宽松的许可（MIT或 BSD）的制作者怎么样？ Jack 你好， 我能明白，无一例外的改变许可方式会让事情变得较为简单，但是那些我们以非 GPL许可方式（如BSD、MIT和Artistic）发布的开源软件怎么样？ 在 Ext还是YUI-Ext的时候我就已经是它的用户了，但事实上，我似乎不能就令我警觉和相当置疑的一个简单的问题得到一个直接的答复。

John Resig - jQuery和 Processing.js的作者，给出了下面的答复：

重要的是要明白 OSS开发者根本不是它们的目标受众。我100%的确信我们不能给出一个明确的答复。他们把“开源”作为一种--的卖点来吸引那些公司，通过病毒许可迷惑他们，并且（通过集团律师所做的明显的阻行）把责任强加给他们，让他们购买一个完整的、共同的许可。这是非常卑鄙的，十分危险的，并且是给整个开源的发展抹黑。

在Reddit上这些帖子已经发布了3周了，我的任何问题都没有在Ext许可页面上，或多达68页的Ext论坛的主题中给出答复。