Links

Ben Laurie blathering


How “Free” Leads to Closed

The FSF is fond of banging on about how the GPL is more “free” than other open source licences, even though it is actually a more restrictive licence than many others (for example, the Apache Licence).

So I find it ironic that the much anticipated Raspberry Pi is about as un-free as it is possible to be. Yes, it runs Linux. Can you run anything else? No, because the chipset is not documented, it is impossible to write drivers for any other OS. Its hard to imagine what would have happened if the dominant open OS was BSD or Apache licensed, but it is interesting to speculate: would this have happened in that world? Possibly not – one of the reasons the ASF adopted a more free licence was precisely because it is business-friendly. Would chipmakers obsessively protect their chip specs in that world? Who knows, but I like to think not.

In any case, if I were building a device like the Pi, I would not be using undocumented chips.

7 Comments

  1. It’s not quite that bad. Raspberry Pi announced that documentation was available (but the pages are not up at present.)

    See http://arstechnica.com/open-source/news/2012/02/raspberry-pis-35-linux-computer-on-track-to-launch-later-this-month.ars or http://www.cnx-software.com/2012/02/07/raspberry-pi-releases-bcm2835-datasheet-for-arm-peripherals/ for a link to documentation on a lot of the BCM2835 chipset peripherals.

    Comment by Andrew Yeomans — 1 Mar 2012 @ 12:14

  2. It looks as though GPL vs. BSD is the least of your worries if you want a BSD-licensed OS on the Raspberry Pi; Linux users can’t have a fully free OS on it either, assuming they want to display graphics.

    The user-space parts of the video driver seem to be entirely non-free; the kernel module is free (GPL’d), but is not in upstream Linux, and not likely to be merged as long as it requires non-free userland. It’s a lot like the situation with the proprietary nVidia drivers for Linux, which have a small kernel module with source code available (not actually GPL-compatible in nVidia’s case, so it can’t go upstream anyway), but that kernel module is just a shim to call out to proprietary userland components to do the real work.

    So, RaspberryPi users aren’t stuck with Linux, so much as being stuck with a particular modified Linux, which requires non-free userland stuff to display graphics. Not exactly open hardware’s finest hour! It’s attracted criticism from embedded-Linux hackers too.

    “Would chipmakers obsessively protect their chip specs in that world?” – I don’t see why they wouldn’t? If Linux’s licensing is more open than chipmakers would like, surely that applies at least as much to *BSD, if not more?

    Comment by smcv — 1 Mar 2012 @ 13:32

  3. I don’t speak for the foundation, but as I understand it they do not have a dog in this fight. They chose Linux because it was cheap, as in beer. If Windows had come in cheaper they would have used that.

    Broadcom have taken the unprecedented step of releasing a datasheet for this chip. It does not describe everything, and particularly not the Videocore that is Broadcom’s crown-jewels. But it does allow exactly what you say cannot be done — The Raspberry Pi can run any OS, even one written from scratch. Albeit only with a dumb frame-buffer. I imagine even that can be reverse-engineered in time.

    I cannot imagine any possible way that Broadcom would have freely documented the entire SoC just because someone could have copied it easier.

    Comment by Richard Urwin — 1 Mar 2012 @ 14:55

  4. If the most popular kernel were under a permissive license, the drivers most likely to be written would probably usually be released under permissive licenses. What would make chipmakers in this more likely to publish specifications? The mechanism I can imagine is that they’d think it more likely that publishing specifications could reduce their software development costs or quality, as they could use code in the permissively licensed driver to support proprietary kernels that they need to support in any case. Do you have other mechanisms in mind?

    Comment by Mike Linksvayer — 1 Mar 2012 @ 19:59

  5. ps The FSF doesn’t claim the GPL is “more free”, rather they have a theory that it protects and incentivizes freedom better than permissive licenses do. Even their rant about open source you linked to doesn’t say the GPL is more free. https://www.gnu.org/copyleft/ and https://www.gnu.org/philosophy/pragmatic.html are more pertinent in any case. Their theory and strategy derived from it could well be wrong, which is why I ask for details about mechanisms that might lead to permissive licenses leading to more freedom above.

    Comment by Mike Linksvayer — 1 Mar 2012 @ 20:11

  6. I think we need to be careful here that every open source hardware project doesn’t become the toaster project in a vain attempt at ultimate openness.

    As you point out, the real issue is documentation.

    Arduino uses the (proprietary) ATMega microcontroller. This isn’t a problem because microcontrollers are exhaustively documented as they’re pretty much useless otherwise.

    The Open Compute Project (OCP) uses (proprietary) Intel processors and support ICs. Again this isn’t a problem, as the x86 ecosystem is well understood, and Intel tends to provide open source drivers for its chipsets, which can be reasonably easily ported to alternative platforms.

    The ARM based system on chip (SOC) manufacturers aren’t used to doing open documentation and drivers (yet). Their stuff has mostly found its way into single purpose appliances like smartphones, tablets and media players that aren’t intended to be hackable. They haven’t figured out yet that openness doesn’t hurt their business (as you have to put money in their pocket for silicon in order to make use of any documentation). I agree that on day 1 Raspberry Pi might not be as open as it could be, but I’m reasonably confident that will change over time. Part of the issue here is that the Broadcom SOC it’s using is very new, and chip manufacturers are cagey about releasing too many details ahead of a launch (believing that it might give too much away to competitors).

    The issue that might linger is where licensed CODECs are involved (I believe the Broadcom SOC used in RasPi supports H.264). This is where the lawyers start to get in the way as we get spillover into propping up Hollywood’s outdated business models.

    Comment by Chris Swan — 2 Mar 2012 @ 0:52

  7. Some good news on this recently. Broadcom have opened up their ARM BCM2835 GPU driver. I believe that means the entire stack on the Raspberry Pi is now Open Source.

    http://www.raspberrypi.org/archives/2221

    Comment by Steve Crook — 30 Oct 2012 @ 12:30

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress