Software for the Raspberry Pi is quickly moving forward. Beyond the several core Linux distros, another couple dozen systems are available, with NetBSD, FreeBSD, and Chromium imminently stepping into the mix. (Ubuntu will not join them as it requires ARMv7 and the Pi is ARMv6). Two dozen programming languages are available, including Python, Perl, Java, Ruby 1.9.2, BASIC, and more. Since the Pi
is a full fledged ARM computer, it should run nearly any ARM app within its system requirements. See the RPi Wiki or Foundation website for more info.

Not sure if I understand this about the drivers... I had gotten the impression that they've already made the drivers open-source. The part that's still proprietary is the chip's internal firmware, which is something you don't need to access its functions.

I suppose it means you can't fix Broadcom's bugs for them, and you can't repurpose the GPU for other computing tasks (OpenCL?), but those seem more like quibbles than real obstacles, to me.

Not sure if I understand this about the drivers... I had gotten the impression that they've already made the drivers open-source. The part that's still proprietary is the chip's internal firmware, which is something you don't need to access its functions.

I suppose it means you can't fix Broadcom's bugs for them, and you can't repurpose the GPU for other computing tasks (OpenCL?), but those seem more like quibbles than real obstacles, to me.

The argument is that, if a firmware is so complex that there's a GLSL compiler in it, then it's a co-processor with a closed-source OS of its own, not mere firmware on a subordinate processor.

Heck, on the Pi, the GPU is responsible for loading the image off the SD card and setting up initial state before handing off to the CPU so, if you're of the tinfoil hat persuasion, you could plausibly rant about the possibility of backdoors and the risk of techniques similar to Ken Thompson's hypothetical compromised C compiler.

The argument is that, if a firmware is so complex that there's a GLSL compiler in it, then it's a co-processor with a closed-source OS of its own, not mere firmware on a subordinate processor.

As further clarification. The GPU runs what you'd consider a graphics driver on an RTOS (threadX). The application processor running linux then sends commands to the GPU much like an application would send commands to the OGL driver.

Things that require direct access to the hardware like OpenCL, or even X acceleration (Render) cannot be done (without broadcom offering updated firmware).

Objectively, it is quite an interesting encapsulation, but ultimately a useless one if you want access to the hardware. Ultimately, the Rpi foundation was mischaracterising the open nature of their driver.