Saturday, April 26, 2008

extjs - when open source kills community progress

Two days ago, Jack Slocum from extjs announced a license change for the JavaScript/Ajax framework extjs (http://www.extjs.com). The previously "dual-licensed" frameworks stays dual-licensed - for open source and closed source software. This is no real news, mainly only one letter changed, the letter "L". "L" like in (large) big. I recognized the change because I was on the page to buy 5 developer licenses. I am not sure to do so now.

GPL vs. LGPL - the difference

extjs 2.1 and later is licensed under the GPL now, earlier versions (up to 2.0.2) are under the LGPL. The "lesser" or better "library" GNU general public licence is less restrictive than the original GPL. In short words, the LGPL was created to grant the user of a program/framework the right to use it without giving the complete source code back. Using any GPL source code or part of it requires you to open source all your code, the LGPL only requires you to publish the changes you did to the LGPL-code. So using extjs in a, let's say commercial application, was okay until now.

extjs dual licensing model

Software development is expensive, to pay your rent you have to sell something. In the open source world often training, proprietary licenses, special programming or consulting is available from the "vendors" of the software, companies like RedHat show that it is possible to earn money with GPL-software if you have a good business model. extjs (additionally) used the approach by selling development licenses. It is forbidden to build a framework or development base from extjs unless you meet certain circumstances. Anyway, having the library under the LGPL granted you the permission to sell your own work with extjs built in. The new dual licensing model including the GPL passage now forces the developers to buy developer licenses. This is not a bad thing per se, as mentioned before, this is no problem for me. The problem is that I do not exactly know what I buy with a development license, which was no problem as long as the LGPL-fallback was effective. But now other questions are important: Can I give away extjs as often / where / when I want to do it? Are my customers bound to buy a developer license too, if they simply want to improve the JavaScript of my application or is my application then completely GPLed? Do I need to forbid this explicitely?

The consequences I: extjs and the community

Putting extjs under the LGPL helped to build the community which is very active, as seen in the forums of extjs. The word was spread, the framework used. And the product thrived and prospered from large companies and/or many programmers using it. Not at least because of the license. extjs is a good framework, but what is it good for if nobody uses or extends it?

Reading the forum at the moment is no fun. It reflects many of my own thoughts and worries about the future of extjs. Many people relied on the framework, built software with it, extended their own programs and are not sure what is happening at the moment or how the future will go on. This decision may kill the community, many users request a fork of extjs based on the last LGPL version (2.0.2).

The consequences II: extjs and the fork

"Forking" is a process where someone takes the open source part of a software to create a new open source project. One of the most known forks is Joomla, a content management system that forked from Mambo by taking the source code and advancing it from that base.

extjs up to version 2.0.2 - technically - is under the LGPL. In principle it is possible to take this code base and create a new branch (or fork) of it. Anyway, the old license too tried to avoid that by prohibitting derivative work that is a framework or development toolkit. But the download of the version 2.0.2 includes a LICENSE.txt which says that you may use the LGPL if you "Are using Ext in a commercial application that is not a software development library or toolkit, you will meet LGPL requirements and you do not wish to support the project" which is, in my opinion, not hard enough to avoid forking. The fork then needs to derive from version 2.0.2 and under the LGPL, thats all.

So it is GPL then, GPL is a good thing, why the hassle?

The uncertain future (any license changes again, anyone?). The imprecise actual commercial license (please, please, please, make it clear!). The community that will perhaps not forget or forgive and most certainly shrink from now on. The unknown handling/procedures, i.e. developing plug-ins for extjs (is it then GPL? Commercial? May I post it, because then its derivative work and I may need a developer license? If I submit the code, who possesses it - do I need to GPL my other code if I "use it back"?). This very last point - the uncertainty - prevents me from sharing my experiences with extjs in their forum at the moment.

I develop software and live for and from it. Ergo I pay for software that I need to do my on-a-daily-base-job. We integrated extjs and spent some hundreds of hours to develop (with) it, so we wanted to buy the licenses without any real need (because we meet the LGPL/extjs license agreement). This should have been a contribution for the excellent work of Jack Slocum and his team. But I am not willing and not obliged to support uncertain business decisions, especially when they compromise my own software and business. I'll stay with extjs 2.0.2 and keep an eye open to their policies. Or other frameworks. A pitty, I thought I do not need to do that for some two years or so.


Labels: , , , , , , , , ,