ramblings on PHP, SQL, the web, politics, ultimate frisbee and what else is on in my life
back

Mitigating the risk of license changes

This is just a very short note about the recent license change from LGPL to GPL made by the author of extJS. When choosing an open source product make sure that the contributors are fragmented across enough organizations to prevent any chance of being able to do a license change. If that is not the case make sure that the community is large enough so that you have a good chance at succeeding with a fork if the need arises. In the case of extJS the later seems to be the case. As such the license change itself is not soooo big an issue, since a lot of people do not consider their frontend code to be proprietary anyways. The source is there for all to see. So for the most part people are fine considering their frontend to be licensed under the GPL. That being said, extJS guys are trying to make people believe that using extJS on the frontend has any effect on the backend licensing. Kinda reminds me of the MySQL client license stunt and the days when MySQL sales reps intentionally confused people about the GPL .. good that those days are over.

Comments



Re: Mitigating the risk of license changes

Tp put it bluntly, that Licensing Overview page is complete rubbish. Does it's author have a clue about the GPL or is he intentionally misleaded readers?

The GPL is quite strict, but assuming any code directly linking to extJS it's going to be in plain text, javascript, and restricted only to directly linking files which will be substantially less than your full application - excluding everything else not making direct links to the library. This commercial license borders on bogus.

I'm tempted to make a proprietary website, add no extJS linked javascript (nothing new to distribute under the GPL then), and laugh at whoever tries to push me into buying a commercial license while I am obviously not in breach of the GPL license ;).

Somebody fork this library already and rob that idiot of his gains from ignorance.

Re: Mitigating the risk of license changes

@Pádraic:
Not only that, but GPL software can be used on a web server without restriction. Suppose for example you link your PHP app with a GPL library (like libmysql). Are you required to make your app open source? No.

The GPL has a sort of loophole when used on web servers, because you aren't _distributing_ the code, you're merely running code "in house," even though technically you do allow the public to invoke your code remotely, via http.

There is a license called the Affero GPL license that is designed to close this loophole. Read about it on Wikipedia. If extJS folks want to close this loophole, they should use this license, not GPL. So for now, I don't believe anyone is required to buy the commercial license of extJS to avoid the viral effects of GPL on their own project.

JavaScript might constitute a gray area, though. Does it count as "distributing" your code with the extJS library if it's downloaded to the user's browser? Does that apply only to the front-end code, or to the whole project? These are questions for lawyers to address.

Re: Mitigating the risk of license changes

Lukas,

you're wrong here. The GPL does not make a distinction between frontends and backends. Legally, if you distribute a web application, it's one work. The GPL also only knows the concept of a work. Wishy-washy juggling with semantics is not going to help. The GPL will affect all of the application.

And the MySQL situation is different. Back then, they tried to lure people into buying licenses by making them believe that any non-GPL application that _talks_ to a MySQL server needs a commercial license. That is not true. However, if you embed MySQL in one of your products, the viral aspect of the GPL comes into effect and makes your application GPL, too.

That said, the extJS people are correct. If you want to _distribute_ your product, then using extJS means you need a commercial license if you don't want your app to be GPL. Simply making a web app available online is not distribution. That's the "loophole" (it isn't one; the GPL intentionally does not cover this situation) the aforementioned AGPL addresses.

Re: Mitigating the risk of license changes

David. You are missing one thing here too I think. You are only distributing the frontend application and not the backend. That means, a request just tells the webserver what to return. This is like a download link for an application. This application is mixed with a GPL lib, so yes the GPL applies to this application. However the application that provided this code is not bound by the GPL. Thats my take on this anyways. Just because there are various different requests that will lead to different variations of a GPL'ed application to be returned, does not mean that anything has changed imho.

That being said, I still would stay clear of extJS anyways.

Re: Mitigating the risk of license changes

Of course if you hand your client a mix of your proprietary code and extJS, then things get even murkier. But since I do not have any proprietary code to hide from clients, this is not one of my concerns.

Re: Mitigating the risk of license changes

Time to use jQuery. ;) It's dual-licensed, GPL and MIT.

@Lukas:
When I sign into your captcha, I get redirected to the frontpage and then I need to click on the entry again, in order to comment.