The Javascript trap I willingly step into
2009-03-23
A response to Richard Stallman’s The Javascript trap
We used to live in the world where software was the essential value in computing. It would take years for companies to develop software, which then would be sold. Users would buy software, install it and run it.
This is the world that Richard Stallman decided to change. Thanks to him Free Software1 exploded in popularity. Because of the growing number of people contributing to Free Software, its quality became comparable and then superior to that of proprietary software. Companies began to take notice.
Richard Stallman won this battle. The scales have been tipped: with a few exceptions2, it now makes more economic sense for companies to release much of their work as Free Software (or at the very least give some freedoms to users) than to keep the cards to themselves. There are benefits: aside from the good press, they can tap into a developer community, get improvements, coexist with other software.
However, in recent years, value has shifted from software to services. Software itself has less and less value, as it becomes easier to write, and as more of it gets created. It used to be that people would pay for a web server — today they have a number of free choices and no one in their right mind considers developing yet another web server. Many software component types become commodities.
Since it is easier to get lots of good software, we tend to do more with our computers. Our time is more limited, so we place value on things which didn’t matter ten years ago. Convenience and time are major considerations. Another important factor is software maintenance: there is so much software being developed so rapidly that keeping up becomes an issue.
That’s why these days we see more and more online applications. It isn’t because they are better than desktop applications: they aren’t. It’s because they are more convenient to use. You don’t have to install, you don’t have to update and most importantly, you gain additional functionality only available online. It could be storage, backup, online synchronization, data feeds or processing, but without it the application loses a lot of its appeal, or doesn’t make sense at all. So, many of these online applications are really services with an application frontend.
Many people don’t really care if they are able to modify the Javascript that is being shipped to their browser and run there. The reason for this is economic — it doesn’t make sense to invest time and effort into modifying the code. The reason we’re using someone else’s code and service in the first place is to save time and gain convenience. And in the online world it isn’t the application that has value: it’s the combination of application and service.
When considering Richard Stallman’s point of view, you should think about where to draw the line. Do you require your service providers to use Free Software exclusively? If so, you might agree with Richard and you might want to require that all Javascript shipped to your browser be free3.
But for some people the Javascript in the browser is really a part of the service — or part of the service providers infrastructure — and just as they don’t require the provider to only use Free Software, they don’t necessarily require all the Javascript to be under a Free Software License. And more importantly, there is no point in replacing or modifying this code. The whole point of using the code in the first place was to get the service from someone else, instead of writing code oneself.
I have nothing against the conventions proposed by Stallman for free Javascript programs (although I am not a fan of GPLv3 and I do have reservations about all versions of the GPL). However, I think the issue is much less important that it is made out to be. I willingly step into “The Javascript trap”, because I do not, and never will want to modify parts of my service provider’s code. If I become unhappy with it, I will simply stop using the service.
1 “Free” as in “freedom”.
2 Large and/or specialized applications are the exception here: packages like Mathematica and MATLAB, firmware for embedded devices, software for designing airplanes, etc.
3 Javascript libraries, large bodies of code shared across many sites, should be treated differently. They are still “software” in the classical sense. But they are also usually Free Software, so Richard’s article does not apply to them.
You are right. The software doesn't matter.
Client software doesn't matter one bit. On byte or however you wish to measure it.
Data, information NEEDS to be free. It doesn't matter how locked down the (name goes here) web app is. As long as I can plug another piece of software directly into my data everything is wonderful. I don't want to change your software, I want to be able to completely remove it from the picture.
Because damn it. The data is mine.
My own feeling is that software that is not compiled is inherently free, like speech if not like beer.
The idea of free software is to make it transparent and available- you don't get any more so than with a text based script file. It is all right there.
I feel like there are aspects of the web that are much less "free" than JavaScript. Any dynamically-loaded page is completely closed-source; PHP scripts, for example, are completely hidden from an end user. JavaScript, no matter how obfuscated, is always open source - it's the backends that are much less free. The entire point of JavaScript source code needing to be open seems moot, given that all of the data and most of the processing power lies in the hidden scripts that it loads.
Collin: you are absolutely right. I care very much about who owns my data. When I signed up with Squarespace, for example, the first thing I checked is whether I will be able to export all my data.
Kenneth: Stallman has a point about Javascript obfuscation. Javascript with single-letter variable names is almost like compiled code.
Will: yes, that was my point -- you deal with a service which is composed of many modules, Javascript code being only one of them.