March 2008

« February 2008 | Main Index | Archives | April 2008 »


The process goes something like this:

  1. FooCorp offers some service that involves the hosting, distribution or modification of user-generated content
  2. Company sends memo to lawyers: "we need a EULA"
  3. Lawyers panic. How can FooCorp possibly protect itself from all possible avenues of litigation when their entire service is predicated on processing digital copies of someone else's copyright material?
  4. Lawyers put a standard boiler-plate clause in the EULA granting FooCorp a "royalty-free, nonexclusive, perpetual, irrevocable, and fully sublicensable license to use, distribute, derive revenue or other remuneration from, reproduce, modify, adapt, publish, translate, publicly perform and publicly display such Content (in whole or in part) and to incorporate such Content into other Materials or works in any format or medium now known or later developed."
  5. Service is launched.
  6. Within minutes, someone actually bothers to read the EULA, and points out that this clause is complete bullshit.
  7. Users of said service revolt
  8. Company retreats with egg on its face and rewrites EULA

The first time I remember seeing this happen was when Geocities was bought by Yahoo back in 1999. Why, then, is it still happening today?

As more and more of our interactions with companies are governed by explicit legal agreements, companies need to realise that your legal terms are part of the public face of your company. The clauses in your EULAs are the most explicit evidence available of the regard in which you hold your customers, more than anything else because you know somebody has sweated over them word for word to give them a precise, legally binding interpretation.

(Similarly, your employment contracts say what you really think about your employees once the feel-good bullshit has been swept out of the way.)

Adobe don't want to claim ownership of your photos any more than Yahoo wanted to ruthlessly exploit a few hundred thousand pastel-coloured Charmed fan-sites back in 1999. It's just a lot easier, in the face of the possibility that some legal edge-case in copyright law might expose you to damages later on, to claim you have the right to do anything you want "just in case".

Often when a lawyer makes such an ambit claim, there will be another lawyer on the other end ready to strike a bargain somewhere in the middle. Other times there will be a large number of disconnected third parties who either won't read the fine print, or who figure there's nothing they can do to change the terms.

The Internet turns all these disconnected users into a community, though, and turns what used to be the private acceptance of an unavoidable EULA into an exercise in collective bargaining.

Most companies take great pains to make sure their public-facing statements present the company in the correct light. It's about time lawyers were subject to the same processes.

(Further reading: Dangerous Terms: A User's Guide to EULAs by the EFF)


  • 8:05 AM

The top 20 most listened to theme songs in the last week, as tracked by

The top five are: Knight Rider, MacGyver, Teenage Mutant Ninja Turtles, Baywatch and Inspector Gadget

On a similar note: my new favouritest Wikipedia page ever, List of problems solved by MacGyver:

MacGyver uses his pocket knife to disarm the self-destruct device of a downed military satellite. He then uses parts of the satellite’s retrieval system - namely metal tubing and large sheets of flexible plastic - to fashion a makeshift hang glider.

…which narrowly beats the List of Scientology Security Checks:

This long Sec Check, consisting of hundreds of questions, takes stock of the subject’s entire time track, including all their past lives. It includes questions such as:

  • Did you come to Earth for evil purposes?
  • Have you ever smothered a baby?
  • Have you ever enslaved a population?
  • Have you ever destroyed a culture?
  • Have you ever torn out someone’s tongue?
  • Have you ever zapped anyone?
  • Have you ever eaten a human body?
  • Have you ever made a planet, or nation, radioactive?

The iPhone SDK was announced today, and it has a few interesting characteristics. The environment for developing iPhone apps is:

  • Mac OS X
  • XCode
  • Objective-C
  • Cocoa

Of course, some of these layers can be quite thin -- I doubt any of the games demonstrated today used Cocoa or Obj-C for more than was necessary to set up an OpenGL context. On the other hand, the common refrain from the demonstrators was: "We'd never done any Mac programming before, and... hey, look what we came up with!"

If the iPhone continues its strong showing in the smart phone market, which today's announcements seem to set it on the road to doing, there's going to be a demand for iPhone developers in the mobile space. Which means there's going to be a bunch of people learning Mac OS X development who wouldn't otherwise have given it a look.

One imagines that kind of injection of new blood can't be bad for the platform as a whole.

The following is a not uncommon occurrence in Java:

try {
    s = new String(byteArray, "UTF-8");
} catch (UnsupportedEncodingException e) {
    throw new Error("UTF-8 is missing??");

This code is the result of two conflicting factors. On one hand, since the constructor in question takes an arbitrary character encoding, the case of the encoding being unavailable must be taken into account. On the other hand, 90% of code that calls this constructor will be explicitly invoking a character set that is required to be provided with the Java Runtime Environment, and its absence would be an error serious enough to justify terminating the VM entirely.

Similar structures can be found in code that performs cryptography or reflection.

As such, the JSR-666 expert group recommends the introduction of the yoda code-word to the Java language. This keyword commands that the virtual machine "Do, or do not", where there is no corresponding try.

While in yoda-mediated code, any matching exception will automatically be caught and rethrown as an AssertionError (even if assertions are otherwise disabled):

yoda (UnsupportedEncodingException) {
    String s = new String(byteArray, "UTF-8");

Or at the method level:

public void myMethod() 
    yodas UnsupportedEncodingException { ... }

Warning: the yoda keyword should only be used in places where the presence of an exception would indicate the Java Runtime Environment is misconfigured or broken. Misusing the keyword may cause a great disturbance in the Virtual Machine, as if millions of voices suddenly cried out in terror and were suddenly silenced

This proposal acts as a companion to the previous JSR-666 exception handling proposal.

A recent post on our internal wiki asked for T-shirt slogans of the style: "Java developers do it with...". I didn't quite stick to the format, but here are my submissions for posterity:

  1. Java: because everyone loves the strong, static type
  2. Java developers do it with java.lang.Class
  3. Java: dragging C++ programmers halfway to LISP since 1995
  4. Java: making Smalltalk nerds cry since 1995
  5. Java developers do it with primitive types
  6. Java developers do it with 0xb6-0xb9
  7. Java developers do it with COBOL's rotting corpse

I actually want #6 on a t-shirt. Alan Green wins the "nerd of the day" award for being the first to get the reference.

On a related note, I spent a lot of yesterday trying to come up with a Java byte-code joke. The best (and this is really stretching the definition of 'best') I could come up with was the following:

Q. What did the invokespecial say to the invokevirtual?

A. I'm super(), thanks for asking!

Thank-you, I'll be here all week.

I was reading my preview of the Artima Scala book over the weekend when I had a sudden moment of clarity.

In Scala, generic types have by default non-variant subtyping. That is, with Queue defined as above, queues with different element types would never be in a subtype relation. However, you can demand co-variant subtyping of queues by changing the first line of the definition of class Queue as follows.

class Queue[+T] { ... }

Prefixing a formal type parameter with a + indicates that subtyping is co-variant in that parameter. Besides +, there is also a prefix - which indicates contra-variant subtyping. If Queue was defined

class Queue[-T] { ... }

then if T is a subtype of type S this would imply that Queue[S] is a subtype of Queue[T] (which in the case of queues would be rather surprising!).

Scala is a multi-paradigm language that many in the developer intelligentsia are annointing as the 'successor' to Java.

Its syntax is based on Java's, and it remains compatible enough that you can call existing Java code and libraries directly from Scala, just as you can expose Scala objects within Java code. However, it brings along an improved type system, first-class support for functional programming, an actor system that imitates Erlang, and so on. The cost of all this is the addition of a not-insignificant chunk of complexity to the language.

That's right.

Scala is to Java as C++ is to C.

Seeing as Java started off as the language that removed and simplified a lot of the stuff from C++ that developers tended to shoot themselves in the feet with, I find myself wondering more what language might bill itself as Scala's successor, and how it might distill the best parts of that language to a more manageable, coherent whole.

(The first smart-arse to answer "LISP" wins a swift kick in the nuts.)