The Web Trap

Philosophy is a battle against the bewitchment of our intelligence by means of language. (Ludwig Wittgenstein)

The issue of code distributed via the World Wide Web for client side execution by the browser has been briefly considered in the Free Software context by Richard Stallman. However, his analysis has been largely limited to JavaScript and his conclusions might be considered inconsistent with the general principle of free tools. Thus, it might be wiser to consider the central premise of The JavaScript Trap – one might be running non-free programs on one’s computer every day without realizing it through one’s web browser – in a wider context than JavaScript and various other client side code execution environments commonly recognized as such, e.g. Flash and Java. At the most fundamental level we have to consider the role of SGML/XML, (X)HTML, CSS and SVG – the foundations of any website.

XML and SGML on their own are pure mark-up languages. On their own they do not convey any meaning, be it declarative or imperative. As software should be free to give user control over his/her own computer, it is easy to see that meaningless data can safely be non-free* from a FOSS vantage point.

Continuing to the web standards, I feel compelled to begin with CSS. Semantically, CSS is a collection of directives that tell the browser how to display a website. Thus, CSS can and should be considered a special purpose programming language. It does not only represent the design, but it also instructs the computer to display that design. Thus, CSS files are and should be considered computer programs, which means that they should be subject to the same freeness requirements the community imposes on JavaScript and traditional software. Fortunately, CSS is often enough distributed in non-obfuscated source form. Unfortunately, it is not often that CSS is licensed under a free license.

Furthermore, CSS is not the only standard with that problem. SVG – Scalable Vector Graphics – is as problematic: on the one hand, it is a picture, on the other, it is a program interpreted by the web browser to draw the picture. And once again, the community ought to hold it to the same standards it holds any other program.

Now, one might be tempted to apply this line of reasoning to any meaningful data processed by a computer and the one would be right. What is the difference between a raster image and an SVG image? An SVG image tells the computer that it should display a shape, a raster image tells the computer that it should display a pixel. Ideally a raster image would thus also be free. However, it is really hard to obfuscate a raster image. A high resolution version might be preferable for some modifications, but generally there is not much one can do to obfuscate a raster image.

On the other hand, obfuscating CSS and SVG is really easy. If one has ever tried editing a complex SVG image created with Inkscape by hand, it should be utterly clear that it is rather daunting. In case of a picture created with Inkscape, there is no preferable form to use for editing it. In case of a hand-created picture with nice identifiers and comments, it would be an abomination to strip the comments and replace the identifiers with random ones – i.e. make it impossible for the user to reasonably alter the image. And that is the reason this essay centres on web standards.

As the most important of the four is the freedom to use – for it is a prerequisite for all the other ones -, style sheets and vector graphics must be usable. For if the user cannot even use the product he or she is paying for with money, clicks or just pure attention, the product should not be used. Such a product does not even deserve to be called a product.

So, when is a style usable? Style is usable if and only if one can apply it to the content that is supposed to be styled. However, that is only possible if the style is easily alterable**, which means that the freedom to modify is a must too. Consider the following example: Alice has a website where tables are used for design, Alice obtains a gratis design from Eve, Bob tells Alice that tables-for-style are a bad practice and helps Alice rewrite the HTML code to use divs. Now, Alice and Bob would like to apply Eve’s design to Alice’s reworked website, but they cannot do that: first, it would be illegal, secondly, Eve has stripped all the comments and obfuscated the code as much as she has been able to. Thus, they go looking for a collection of GPLed CSS files and live happily ever after once they will have found those… No, really, Alice and Bob would be in a pretty bad situation. In a situation the GPL has been designed to avoid.

One can imagine a similar situation for SVG images. Suppose that Eve presents Alice with a nice SVG logo for a zero fee. Alice is happy for a long time, but then she wishes to put a frame around that logo in a specific use case. As Eve gives her neither the know-how nor the right to alter the logo, the best option Alice has is to find a new logo. She could also try embedding Eve’s creation in another SVG image consisting of a frame, but it could be argued that this would create a derivative work…

Point is, SVG and CSS must be licensed under a free license.

So, how does HTML fit in? It has got more to do with content than representation, does it not? Unfortunately, no. As I pointed out earlier, HTML is far too often used to style web pages. Tables, anybody? In addition, with the web progressing from a text-based medium to an interactive one, HTML is more about presentation than ever. Think about audio, video and canvas tags. HTML is not the content, it is a tool to create an interactive user experience out of multiple content sources. And thus if we wish to avoid FUBAR scenarios, HTML must be free too.

Back to Stallman’s conclusions regarding JavaScript. As HTML, SVG and CSS should be free, it becomes clear that trivial JavaScript, as a “mere extension of HTML markup”, ought to be free too and thus all JavaScript, regardless of its complexity, must be free.

The situation is identical to the situation with traditional software. It is only logical to impose identical freeness requirements on both the tools we use to display content via the web and the tools we use to display content offline without the web.

The main problem** with the approach requiring free HTML, CSS, SVG and JavaScript is that not all in the Free Software community agree whether writings should be free or not. Thus, this approach would require a new licensing model separating the content (the text) from the technical means used to present it, making it possible for the tools to be free, while the content remains proprietary. However, a new licensing model is a small price to pay for increased freedom.

To conclude, I urge everyone to think whether the traditional discourse of HTML, SVG and CSS as something inferior than “true programs” works or not. As I have made clear, in my humble opinion it is more consistent to treat HTML, SVG and CSS as tools that should be as accessible to everyone as software in general should be.

*   I personally think that even meaningless data should be free. However, that is not relevant to this piece of writing.
**  That requirement can take two forms: in its weaker form, the design itself need not be modifiable but it must be applicable to altered markup; in its stronger form, the design should be equated with any content and should be freely modifiable.

Updated the presentation on 2011-01-04T16:04:00Z to better reflect the medium.

Comments are closed.