Category: Coding

Tivoization still possible with GPLv3 (draft4)?

The latest draft of the GPLv3 contains many improvements over the previous ones. It also still contains several minor issues, some of which date back to the first draft. Among these, there is a paragraph that remained unchanged since the first draft, although there were several comments saying that it could provide a loophole:

The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source.

The problem is that “automatically” is not defined and it could lead to abuses, including preventing users from running modified versions of GPL software on some devices (the Tivoization problem that GPLv3 tries to prevent). “Automatically” can cover current practices such as generating Makefile from Makefile.in using autoconf, generating parser.c from parser.y using bison, etc.

But “automatically” could also include some operations that are impractical in terms of time or special equipment required. A file that can be regenerated automatically but requires several hundred years of computation on a supercomputer will effectively prevent most people from compiling the software and installing it on their device (if that file is required during installation or during run time). The canonical example would be if the tool that regenerates the missing source file requires the factorization of the product of two very large prime numbers.

As long as the company selling the device provides the complete Corresponding Source (including tools necessary for regenerating the missing files) and Installation Information, then they would be compliant to the GPLv3. As long as the source code (with the missing file) is the “prefered form of the work for making modifications to it”, then they have followed the GPL to the letter… while still preventing users from running modified code on their devices.

Of course I reported this problem and I included links to the previous comments on the same issue. But it looks like this issue has been ignored so far, despite the fact that the comments on the first draft are more than a year old. 🙁

Unmaintainable Code?

How To Write Unmaintainable Code

Two days ago, I enjoyed reading the collection of tricks titled How To Write Unmaintainable Code and I mentioned it to a colleague. We both had fun reading it and commenting on some entries, but then forgot about it.

The Mysterious JSP Bug

Yesterday, he came to me to check if I could help him debug an application. That was a bit of JSP code that I had written some time ago and that he extended. Note that I seldom write JSP or even Java – he is a much better Java programmer than I am. The problem was that after his modifications, the JSP page did not produce the expected results. That page was supposed to display some results after submitting a form, but it didn’t. There was a rather large amount of code in that page, but I will spoil the fun for you by quoting only the part that caused the problem (of course he initially thought that the problem came from a completely different part of the code):

<%
    String submit = request.getParameter("submit");
    if (submit == null) {
        /* if the user did not confirm, go to the exit page */
        %><jsp:forward page="./SomeExitPage.jsp" /><%
    }
    do.something(useful);
%>

Nothing very fancy in that code. Now, since he was testing a modification of that code, he was not sure that the form submission would always be correct. So he did the obvious thing and commented out some parts of the code that were not ready yet for testing, including the one that I just mentioned. That part of the code now looked like this:

<%
    String submit = request.getParameter("submit");
    // if (submit == null) {
    //     /* if the user did not confirm, go to the exit page */
    //     %><jsp:forward page="./SomeExitPage.jsp" /><%
    // }
    do.something(useful);
%>

Nothing unusual, right? Just commenting out a few lines that are not ready yet. Well, this is wrong! I found out that the problem was precisely there: the unexpected results that he got were just the contents of the exit page. The problem did not come from some other part of the code that we were looking at. It came from the lines that were commented out.

Why? Well, it should have been obvious: the scope of the JSP tags <...> and <jsp:.../> is evaluated before the language-specific features such as comments, etc. As a result, the <jsp:forward.../> was not commented out. On the contrary, it was now unconditionally included, since the if condition had been removed. That was a nasty trick!

Epilogue

The bug was fixed quickly, but we thought again about one of the interesting examples in “How To Write Unmaintainable Code”, specifically the one titled “Code That Masquerades As Comments and Vice Versa”.

XHTML2 and the noscript element

More than two years ago, I reported an issue to the XHTML working group: the specifications for all versions of HTML and XHTML (up to the XHTML2 draft that was current at that time) forbid the usage of the <noscript> element in <head>. As a result, it is difficult for a page author to have a fallback solution in case scripting is disabled and the header of the page contains a script generating a link to a style sheet or generating the title of the page. Well, in reality it is possible because all browsers support the usage of <noscript> in <head>, but this is not allowed according to the HTML and XHTML specifications.

The main issue is that due to the way the DTDs for the various versions of HTML and XHTML were defined, the <noscript> element could only contain elements allowed inside <body>, but not the elements allowed inside <head> (such as <link>, <title>, <meta> and <script>). So <noscript> was simply not allowed in <head>.

I was pleasantly surprised when I received an e-mail message yesterday telling me that this issue had been addressed some time ago in the XHTML2 draft but they forgot to notify me earlier. The way this issue was solved (together with other related issues) is interesting: they introduced a new Handler module to XHTML2, defining a <handler> element that basically replaces the old <script> and <noscript>.

This is nice. But I’m wondering how long it will take for XHTML2 to become an official standard, and how long it will take before XHTML2 is implemented in the browsers and used by web designers…

Attribution-ShareAlike 3.0
This work is licensed under a Attribution-ShareAlike 3.0.