John Resig on ExtJS, the GPL fiasco and open source community style

This post is almost insightful as your last post on the subject.

“We (the jQuery project) worked hard with them to try and fix bugs and add features for an ExtJS integration layer.”

Yes, this is true. They did fix bugs in jQuery so Ext JS could run on top of it. The “add features” was making jQuery able to do animations of multiple css properties in a single animation thread (something every other library already did). I don’t see how this is “using” the jQuery project, if anything itis helping it.

It’s worth noting that I wrote the integration adapter, not them.

“They turned around and built their own, specialized, library (removing the need for any of our work)”

As stated above, I wrote the adapter. I also wrote ones for prototype and YUI and one where you didn’t need any adapter (maybe that’s the specialized library he is mentioning?). All he did was fix bugs in his library.

“and then mutated the licensing into this bizzaro scheme that they have now.”

Bizaro scheme? Our license now, as of 2.1, is the standard dual licensing model many open source companies use.

“We can’t, in good consciousness, even recommend their library anymore due to its very nature.”

I think this has more to do with jQuery UI than anything we did.

“On top of this they ended up hiring our lead evangelist to promote their work.”

Yes, we thought he did a great job and wanted to pay him for his work. Is this a bad thing?

Rey and I intentionally discussed jQuery and our mutual agreement was – even though he was working for us, he was perfectly able to continue what he was doing with jQuery. We didn’t see jQuery as a competitor and in fact I have personally recommended them on many occasions for use in web pages on normal websites.

–

As for the rest of your post it sounds so much like a conspiracy theory that I won’t even bother responding.

“I don’t see how this is “using” the jQuery project, if anything itis helping it.”

Think of it this way: Let’s say the Wordpress project came to us requesting some specific issues be resolved in jQuery so that they could provide jQuery as a default library (along with other libraries). We work hard to fix the issues and release. They then decide to go ahead and build a different library to replace the functionality that jQuery provides, marginalizing its usefulness (who would pick some other library when you could just pick the new default and be done with it). I would be upset with Wordpress for not communicating their eventual plans to us – especially since we diverted valuable time and resources to help them. That’s not to say that the issue(s) would not have been resolved eventually but that we had to divert from our normal course of action, produce results, and watch them become less useful.

“maybe that’s the specialized library he is mentioning?”

I’m referring to the default core Ext library (the one that replaces the need for other libraries and adapters).

“Bizaro scheme? Our license now, as of 2.1, is the standard dual licensing model many open source companies use.”

In Ext 2.0.2 the intermediary agreement that a developer had to agree to before receiving the open source license was highly non-standard and caused a lot of frustration (as you’ve noted elsewhere).

However, the situation has not improved much in 2.1: there is still a huge amount of confusion and frustration surrounding the use and interpretation of GPLv3 in ExtJS. A couple quotes:

If you are generating any markup or javascript code via the server in a page that also includes Ext, then the server code will have to be GPL as well. -Jack Slocum

However, if the server is generating JS or markup SPECIFICALLY for use with Ext JS, then the code generating that JS or markup is designed to work with Ext JS and falls under the GPL. There is more information on this specific case on the GNU website. -Jack Slocum

Note that the GNU FAQ actually includes a special provision to discuss what is occurring here. By including the specified provision you can actually prevent what you mention, above (the viral leak of the JavaScript’s licensing into the server-side code). Leaving the license without the provision effectively makes it unusable in any corporate situation (and, really, in most personal uses as well). Since, as of right now, the ExtJS license page simply points to the default GPL, without the provision, I assume that ExtJS does not wish to honor it. This is a very important point and really defines the difference between using the GPL as a marketing tool (promoting “open source”) and actually using it as a reasonable means of licensing and development.

It should also be noted that the GPLv3 remains incompatible with virtually all other open source JavaScript libraries. This means that while ExtJS is fully capable of consuming code from other libraries (and placing it under the GPL) it is unable to contribute back to the general JavaScript community, which is a huge shame – and one that stifles innovation.

“I think this has more to do with jQuery UI than anything we did.”

No? jQuery UI was created because both the 1) Functionality of ExtJS (and similar libraries) was not sufficient for our users and 2) the licensing and restrictions provided by them were unacceptable for our users. Such as not being able to redistribute the images/css of the themes, for example (although, this is no longer the case with the new 2.1 release). The fact that portions of the code base were completely blocked from additional use only further confused the aforementioned licensing issues.

“Rey and I intentionally discussed jQuery and our mutual agreement was – even though he was working for us, he was perfectly able to continue what he was doing with jQuery. We didn’t see jQuery as a competitor and in fact I have personally recommended them on many occasions for use in web pages on normal websites.”

Absolutely – and we’ve appreciated that. It’s more a matter of being a good citizen in the world of open source development. If ExtJS was seen as a project then this would be as if the jQuery team actively sought out and brought on a member of the Prototype team. There’s no reason for actions like that in an atmosphere of sharing and collaboration (being what most open source projects provide). However, driving ExtJS like a corporation makes for decisions that are in the best interest of the company – not in the interest of the greater community.

All of this ties back to the larger point: ExtJS continues to consume to better the ExtJS users and the ExtJS corporation. When was the last time that ExtJS contributed something to an open source project? code? bug reports? Considering that it’s pretty much impossible for a project to take on ExtJS code, due to the licensing restrictions (it’s GPLv3 and no other JavaScript open source project is compatible with that license), it pretty much goes without saying that ExtJS serves as a black hole of innovation – it continues to consume and nothing escapes.

Ultimately it depends on what you feel the best direction is for ExtJS: Are you using the GPL as a way for users to ‘get a licensing scheme that works for them’ or are you trying to live up to its ethos: providing an air of openness and sharing, helping to better the development community at large? There is absolutely no problem with ‘trying to make a living’ or even running a business – but portraying yourself as a member of the open source community is quite disingenuous when, really, you’re in it in license alone.

I was using ext for one of my projects and was updating some stuff when I

came across the ext licensing brouhaha all over the internet. I must say

the licensing terms appeared sneaky from the beginning when I started

using the library, but since what I wanted to use it for appeared to be

LGPL licensed, I decided to go along with it. One of the major reasons I

decided to use it was that ext appeared to do some pretty amazing stuff

and with a really nice interface. BIG MISTAKE. The library was

horrendously hard to learn and to use and debug, not in the least because:
a) For a lot of the stuff in the API (which appeared to be well documented

but was really not because a lot of it was just repitition of not very

helpful comments) there was no contextutal information which can quickly

tell a developer how to use the api (to get an idea regarding what I’m

talking about, see jQuery API). Even YUI docs are better than ext.
b) Second, but more importantly, noobs were treated like crap in the

forums.
Anyways I went along since the benifits seemed to outweigh all that. With

the benifit of hindsight, it is now clear why it was not in the best

interests of the Ext team that the developers learn to use the library

easily and on their own – or how else would they make support money? Also,

lacking the budget for as big a testing/development team as the open

source comuunity, it was in the ext owner’s best interests to keep the

real nature of their motives hidden until they had a commercially viable

product ready.

This licensing fiasco is really the last straw. I really don’t have a

problem with paying, its the sneakiness on the part of ext people that

annoys me. I don’t care how many hours I spend porting over my code, but

as of now, I have thrown out the ext-js library from my project.

[...] Und mit dem letzten Wechsel hin zur GPL haben sie einige in der Community vergrault…. Siehe z.B: John Resig on ExtJS, the GPL fiasco and open source community style at Stephans Blog Pablotron: Don’t Use ExtJS [...]

Speechless, and I wanted to use it for my project. I think I’d rather to use something else. It is a shame for Open Source Community