License Fake-out hits ExtJS and Java Service Wrapper: Communities Alienated

by Tim O'Brien

In Choosing an OSS License and the Ext-JS saga, Graeme Rocher (of Groovy on Grails fame) reacts to the recent ExtJS switch from LGPL to GPL. Here's a quote:

What they have effectively done is built up a community, taking full advantage of the open source model by accepting user contributions and patches and then turned around and kicked their own community up the backside. It is projects like Ext-JS that give open source a bad name. How can a company have faith in open source if the people behind it can't even decide how to license the thing?

In related news, the Java Service Wrapper did something similar. Jason Van Zyl commented on the JSW license switch on the Maven developer's list:

Project[s] that start using a commercially liberal license and then switch[ licenses] long into the life of a project is wrong. If you want to do the GPL/commercial thing then say so from the start. [There is] nothing wrong with this model, but for libraries and tools using a commercially liberal license is the best way to get community adoption and then to flip the license I find a little unsavory.

Anyone interested in forking it and maintaining the version that was not GPL?

In related news, ActiveMQ is opting to move away from Java Service Wrapper.

Update (5:45 PM Central): A little madness thinks ExtJS has discovered step 2 of the elusive Slashdot business model:

The model works because step 1 allows you to build a community around the more liberal LGPL license. In particular, as the LGPL is commercial-friendly, the community will include many people building commercial applications. Once the community is suckered in and committed, the license is changed, leaving them high and dry. Well, not quite: they can continue to use new versions of the library by buying a commercial license. Hence the profit!

Update (6:17 PM Central): More from Stephans Blog


David Ron
2008-04-28 16:24:14
You missed some really important points:
1. With a large user base comes a large community developer base. The developer base would surely fork the project and continue development for free. Example: Redhat Enterprise Linux and it's free alternatives: CentOs, Whitebox, and others.
2. With a large user base, the users will only tolerate being charged so much before a community will crop up to fork and perhaps even charge a really low fee to continue maintenance.
2008-04-29 18:40:17
1. With a large user base comes a large community developer base. The developer base would surely fork the project and continue development for free.

wrong - if you look at the extjs "version" of lgpl they put in a sneaky exclusion clause that disallows forking...

Rafael Ribeiro
2008-04-30 09:13:08
Seems like Ext-js in itself is violating LGPL license:
Copyright (C) 2007 Free Software Foundation, Inc.
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Rob Whelan
2008-04-30 14:18:41
@rafael -- ExtJS wasn't/isn't violating the LGPL, because they didn't modify the license itself; they simply added additional licensing restrictions, which is perfectly allowable for the copyright holder.

The change that they made was legal, I think (assuming everyone submitting patches, etc. surrendered copyright to them), but it's morally questionable and I perfectly understand that the community feels cheated. I also see why ExtJS is making this change (everyone needs to earn a living), but they've earned the backlash they're getting; they took advantage of people's assumptions that they would remain commercially-usable for free to gain a lot of users, visibility, and valuable input to the project.

I tend to think people should have avoided the project in the first place, because of the non-OSS license (LGPL, sure... the no-forking clause should have raised questions, though). Not everyone's a licensing expert, though, and people tend to be trusting of other developers....

So the core unacceptable issue was the initial license. With a standard LGPL project (or a standard GPL license, if they'd started with that), the license protects us from this kind of bait-and-switch.

They should never have been listed as an OSS project in wikipedia, library comparisons, articles, etc. -- they were not. Now they've "fixed" that in a way they could not have if they'd started with a real OSS license in the first place.

If I were running ExtJS, I'd reinstate the LGPL-with-no-fork-limitation option. Possibly with a time limitation (so people have time to migrate away if they so choose)... but *some* solution so that actively contributing but commercial users don't feel they've had the rug pulled out from under them like this.

I think Jack doesn't understand the difference between giving a thing and jerking it away suddenly vs. never giving it at all. There are plenty of principled reasons to justify never giving commercial users a free ride... but he doesn't get the psychology of giving then unexpectedly retracting.

2008-05-29 18:20:42

Look at this...
2008-06-03 05:45:32

I have been relying on Java Service Wrapper for some time and there for I am affected by this license change.
Open source sw developers also need to make a living. There are different ways of doing this. Some will charge for support others for documentation. Changing the license is, I agree, misleading. But it is the right of the author to do whatever he wants. Commercial products may also disappear without warning. The good thing is that with open source we at least have the source code and we are therefore in position to maintain it.

As for Java Service Wrapper I have started an alternative project:

The goal is to provide a complete Java API for the application and the controller. By using JNA no native development is required, it is all java. Configuration is mostly compatible with the original, so migration should be very easy. Current Alpha version is a proof of concept and is available only for win32. I am looking for people who would like to join the project and adopt it for other platforms.

Another alternative would be:

- Ron

2008-06-05 10:34:36
I think that's the real "lure" of open source. Get the community to do the heavy lifting and TESTING to perfect the app then go private with it. Even more so, make the license fee an annual fee instead of a one-time fee. What's the difference? The end of day advantage of starting out open source is to save money on development and testing while reserving the option to go private when the product is "perfected". It appears to be a good business model for a startup software company not to mention the annual residual license income. It may lack a bit of class. But it works. The MySQL approach is classier though. They provide support and added value for the commercial version while fostering a healthy community version. Sometimes class implies longevity. Only time will tell. Even so, clever entrepreneurs are always going to take advantage of not only technological innovation but also innovation in licensing practices etc. While I applaud them for their cleverness, I'm sure they hang their collective clever heads in shame as they check their respecive bank balances..for a second or two. Rafael, I would like for you to expound a bit on the psychology of giving then unexpectedly retracting. Moreover, did you mean the economics of giving then unexpectedly retracting? Would you wager that the retraction was intended all along? In so doing, I'm sure they did some price elasticity analyses to determine at what dollar ammount the commercial users having built their application infrastructure around ExtJS would pay or walk away. There have been many examples of this (going private) approach since the inception of the open source concept. It should have been no surprise, especially with something that 5w33t. The lesson learned here is TINOFL - people don't start open source projects because they're philanthropists.