A lot of people have mentioned that the current EULA for chumby is a little bit interesting for an open source project. This post expresses my own opinions about it (not necessarily Chumby’s opinions).

To be honest, it is a work in progress, and we are looking for suggestions to improve it. There is one piece of code on the chumby that is not open source, and that is the Flash player, and Adobe requires us to publish a EULA with our product to protect their proprietary interests. While we evaluated many open source Flash solutions, we found that the Adobe Flash player was the most broadly compatible and had the largest base of developers, something very important for growing a network of content that requires the support and enthusiasm of the Flash artist community.

A problem we found in launching an open source hardware platform is that the traditional mechanisms for open source–GPL, creative commons, etc.–did not have legal language that matched the unique needs of hardware. For example, a creative commons license says nothing about how patents are handled. This is because creative commons cannot be used on functional works. Thus, the creative commons license printed on a chumby core board refers to the mask work only, as that is the only piece of “artwork” that can have a creative commons license validly applied to it. However, I think the final hardware license is fairly tasteful. I fought with our lawyers a bit over it, but I think that in the end it is something I can live with: it explicitly gives you the rights to modify and copy our hardware design kit, and to modify/build your own chumby, and to even resell your modified chumby, as well as kits for modifying it. In particular, academic applications for chumby should have no fear or charge for using any piece of the chumby HDK and SDK in course materials or research apparatus.

There is, however, one clause that says you cannot use the chumby development kit to build or modify chumbys that compete with our widget service. The thing the CEO wants to prevent is someone copying our schematics and plans, and launching a “Crumby” service that leverages our hard work and steals our bacon. I can definitely see his point of view, as the core revenue model–the thing that in part will help pay my salary so I can continue to build hardware that I can share with you in this open-source style–is potentially based on service subscriptions. Note that our plan is to offer a wide variety of widgets for free on our network, so if you get a chumby and don’t buy our service, it is still a pretty useful device, just not as useful as it can be. Plus, if you’re a hardcore open-source guy, you’d hack the hell out of the chumby anyways so you’d have no need to go to our service for widgets (we do not consider you running your own widgets on your own machines as competing with our service–it is your hardware after all–and you aren’t required to buy a subscription). We also plan on being fairly liberal with the ratio of subscriptions to devices, e.g., you are free to copy your subscription within certain boundaries, so you aren’t buying a subscription for every chumby in your house.

Significantly, I want you to be able to use the chumby device with other non-competing networks, such as Skype, IM, or any other thing that may tickle your fancy. The trouble is defining what a competing network is–it’s sort of like Justice Potter Stewart’s famous quote on pornography, “I know it when I see it”. This is something we will hammer out over the next couple of months before our general product deployment phase. While I realize that some of the open-source purists will be put out by the terms like this, the unfortunate reality is that hardware development does cost real money, and so does a colo with servers, and thus a compromise needs to be struck between total openness and a sustainable, protectable business model.

chumby is Free as in “free speech”, but not free as in “free beer”–however, you are free to download the plans for a chumby and brew your own.

More posts to come in a couple of days–need to announce winners of name that ware and throw up a new ware–but in the meantime, more fun stuff to talk about.

Last month I had the priviledge of hosting the MIT ORCA team at my place–and at the complex’s swimming pool–for an evening while they worked on debugging their autonomous underwater submarine. Their machine is a fine piece of engineering, I think–it has come a long way. I used to be on the MIT ORCA team for the first five or so years, and they are now on their 9th year. Check it out:

Yep, just about everything you see in there is custom-built, cut, or welded–probably the only stock part is the PC104 core as far as I can tell. A pretty impressive amount of electronics in a tiny space. They even have flashing blue running lights that look pretty snazzy, and they have a neat little waterproofed wifi dongle that they float on the water surface that they use for debugging the unit with a shore box while it is submerged. And yes, it is still running linux.

Ah, back in the day.

Many years ago–I reckon 8 years almost to the day–I was a graduate student just freshly admitted to MIT, and I was redesigning the infamous 6.004 “Nerd Kit” under the guidance of Gill Pratt. 6.004 was the “Computation Structures” class, or as Steve Ward once put it, the course that taught you about everything from “NAND gates to Bill Gates”–although Gill’s take on the class included a section on information transmission on wires, which proved to be absolutely invaluable throughout my entire career. Essentially, 6.004 was MIT’s introduction to computer architecture, and it was mandatory for any student studying for an undegraduate degree in EE or CS. Nerd Kits were the substrate on which students implemented their lab work. Prior to my revision, students wired up 74xx-era logic chips on large breadboards to build a microcoded microprocessor from the ground-up. It was a great experience–it forced you to learn rigorous discipline and debugging techniques to build anything that complex–but breadboarding was rapidly becoming a thing of the past, and the curriculum was becoming outdated.
The new kit was to use FPGAs extensively–something new for that era–and in a manner that allowed students to focus on learning architectural concepts as opposed to syntatic and mechanical details of how to program an FPGA. As a result, the FPGAs were used as “legos” so to speak, and each FPGA communicated with another using a 32-bit serialized bus. This way, students could build a 32-bit RISC processor out of these legos without the pain of wiring up 32 individual wires. In addition, I included alphanumeric displays that would read out the value of any bus running anywhere on the chip, which was pretty neat–you could go over to your adder and see the A and B inputs and the output while single-stepping the clock and watch the whole RISC machine do its thing. The kit was expandable so you could wire up multiple kits and build superscalar RISC machines as well.

At any rate, it has come to my attention that these (barely used) kits have finally been retired and released to the reuse pile at MIT. I have had a number of requests for documentation about the kit, and since the kit is so old and deprecated, I have decided to release the entire source code, schematics, and board layout for the kit, as far as I have it, as well as the design rationale and design documentation for people to use. Hopefully these kits will find a good home and someone can make them do something clever.
Here’s an old-school picture of the kit. I think this was taken with a real film camera and scanned.

Here is a more modern picture of the kit, with a hi-res version so people can see it better. Ah, digital cameras!

As usual, you can click on the above image for a very large, very hi-res version.

The design documentation can be found in the links below. Note that they are fairly large files, and I am not anticipating a lot of people downloading them. I am hosting the bandwidth and paying for it myself. If for some reason they do become popular I will move them off-line and post a torrent to them intsead.

• schematics, board layouts, design rationale, source code for ROM monitor, and mechanicals for the mounting plate. ZIP, 13 MB.
• gerbers for mainboard. ZIP, 409 kB
• gerbers for application board. ZIP, 49 kB
• kitcomm java applet, used to configure the kit from a host (GUI for setting module identities, essentially). ZIP, 994 kB

You know, back when I made this design, the storage requirements for this really pushed the limits of my hard drive and my computer, and I was using a 64 kBit/s frame relay to get into campus (or did we have our T1 by then at my frat?). I’m lucky I could find these files…I had considered so many times deleting them to make space. Hmm…if I remember correctly, it was an AMD K6-III at around 450 MHz or so, and something like a few hundred megabytes of hard drive. Now I write this blog post on a laptop with a 2 GHz x86 core duo, and 100 GB of hard drive…and enough bandwidth to share files like this. Geez, I think the video card in this laptop has more video memory than my hard drive had back then. My how times have changed!