1.Extjs采用GPLv3带来的问题
Extjs是一个优秀的js框架,可惜授权协议是GPLv3。一个类库,用GPL授权是很不可取的。意味着你提供给客户使用的程序,“修改了extjs的代码”,你的程序就得开源。比如说,继承Ext.grid.Panel类,是一种“修改”(指OOP概念中的修改父类实现)。类库应该使用APACHE,MIT,BSD,LGPL等协议的,而提供给终端用户直接使用的软件产品(如linux系统),用GPL比较友好。
开源社区将不会积极贡献代码、bug、翻译文档等等给extjs,因为你努力贡献给他,他却拿去卖钱了,因为他可以给别人商业授权。--而你,到头来还得向他买许可。因此现在主要的开发人员是extjs公司自己。但话说回来,你用它的代码,就得按它的规矩来,这没什么好说的。他们觉得这是更好的生存之道,但是对extjs产品来说,得不到开源社区的支持,将来的发展很有挑战。GPL开源+商业许可授权,Extjs库和闭源软件差不多了,只是打着开源的幌子罢了。
2.规避措施?
对于国内大部分Extjs开发人员来说,这个影响不大。给别人定制开发一套系统,你就把代码给他看吧,注释全部去掉,开发文档也不给他,一般没什么的。国人很聪明,即使客户拿到源代码,程序也肯定跑不起来。
假如你开发了一款商业软件,很牛,建议前后台封装好,前台extjs只是用来画界面的,将它开源出去,免费。前后台交互采用标准的REST,Soap等协议,并公布出来。而后台代码采用二进制分发,单独销售。
假如你开发了一个类库,如operamasks之类的,本来主要功能就是做界面的,你可以开源出来,做技术支持挣钱;或者付给extjs授权费,然后向你的客户收钱。--这样的产品基本上不会存在,Extjs基本上不需要这样的封装。
开发供公司内部使用的系统,不受GPL协议限制,可以随便使用。就好像你只是学习extjs,开发软件自己用,没有人会限制你。