There’s been a flurry of blog posts today about the new Open Source Hardware Definition, which is currently on rev 0.3 (link), and a corresponding summit in NYC, which unfortunately I can’t attend since I’ll be on the wrong side of the world around that weekend. It’s very exciting to see the open source hardware movement maturing to the stage where there is a flourishing and fecund community of participating innovators. As many of my readers know, I’m very fond of open source hardware and it’s nice that the field is getting less lonely and more credible by the day.
Like the community of people participating in OSHW, the definition of the same is evolving. I think that the rev 0.3 definition is a good start, but it needs a little bit of broadening up to reduce friction with a large legacy of closed-source hardware components. Unlike F/OSS, it’s much harder to grow an ecosystem around hardware entirely from scratch; chip fabs cost substantial money (billions of US dollars) to make, maintain and use — unlike, for example, a compiler such as gcc.
The way the current definition is written, in order to comply with the OSHW definition, the system integrator bears the burden of choosing only components for which they can also share all required software to fulfill essential functions under an OSI-approved open source license. So, for example, there are no wifi solutions that I know of which comply to this definition — even the ubiquitous rt73 chipset, which offers open-source drivers, requires a firmware blob which is closed-source. Other interesting chips that do not comply to this definition include probably most cellular phone chipsets, bluetooth chipsets, graphics chips, camera chips, and surprisingly, most SoC CPUs. Every ARM SoC that I’ve encountered contains a small bit of internal ROM (32k or so — hey, that was a whole operating system back in the 80’s!) that’s written by the chip maker and that piece of code is closed-source (this includes the i.MX233 and the PXA168 used inside chumby products), and many ARM SoC’s have NDA-only datasheets for the register set (such as every Marvell CPU), which takes it yet another step toward closed-ness. Even the ubiquitous Intel desktop CPUs utilize microcode updates, which I believe are closed-source (there are F/OSS-friendly tools for deploying the microcode, but the actual microcode itself is distributed as a binary, afaik). Furthermore, systems that incorporate some proprietary code (like chumby, which uses a closed-source Flash licensed from Adobe), cannot release all code required to fulfill essential functions, such as playing apps.
Thus, as the OSHW definition is writ, it excludes the possibility of making any open source gadget with compelling, popular consumer features (such as wifi, cellular connectivity, chip cameras, high-performance and low power ARM CPUs) because most of the components required to achieve these features cannot comply to the OSHW definition version 0.3.
I don’t think that excluding all these devices from the OSHW definition was intentional; the intention of the software-release clause is well-meaning, but I think the definition needs some tweaking. I’d suggest that the burden of responsibility should be limited to the person or organization releasing the OSHW. Thus, one should only be responsible for sharing the source and documentation for the components developed with your own resources. For example, if you are a board or system-level OSHW provider, then the best you can do is release the schematics and layout for your design, and any code you wrote to tie the pieces together in your system; you are not required to also release code and datasheets on behalf of your chip vendors to customers in order to claim OSHW-compliance. While this is not an ideal solution in terms of open-ness, I think it finds a balance between providing featureful, useful, and modern designs to consumers while giving them a toe-hold to grab onto if they desired to modify, extend or repair their purchased hardware.
The other potential issue I have with the definition is the clause where documentation must be released “in the preferred form for which a hardware developer would modify the design”. This term was more or less borrowed directly from the GPL, and by and large that clause makes sense in the software world because ASCII text is nearly universally accepted as the form for source, and there are a multitude of interoperable text editors out there, with the single biggest problem being CR/LF translations and maybe unicode integration.
Unfortunately, in the hardware world, there is no consensus over a machine-readable intermediate schematic or circuit board layout format that also binds in all the interesting metadata you may need to quickly modify the design. In fact, the situation is much worse because a few of the biggest names in consumer electronics hardware actually have in-house proprietary schematic capture and board layout programs that don’t interoperate with anything, so they can play the game of releasing their files in their preferred form for modification and claiming OSHW compliance, which is essentially useless to the community at large since the tools are unavailable to read them.
As a result, I’m a proponent of requiring, in all cases, a minimum of a human-readable schematic provided in a common format (PDF, PNG, etc.) as the primary form for interchange, and optionally a machine readable format to the discretion of the particular designer. To me, the machine-readable format is less important than a quick human-readable format; I would prefer a PDF over an Eagle file any day (Eagle is a popular interchange format among the Arduino community), especially since I don’t use Eagle or even have a copy of it installed on my machine.
All that being said, I think it’s very exciting to see the OSHW community rally together to create a draft definition and hold a summit. This is very positive progress toward empowering individual consumers like you and me to also be innovators and the true owners of our technology — instead of our technology owning us.
Looks like we might need a “Lesser Open Source Hardware Definition” for the time being.
” chip fabs cost substantial money (billions of US dollars) to make, maintain and use — unlike, for example, a compiler such as gcc.”
With everything that has gone into GCC in the last 20+ years, the cost of time spent on it is fairly high. People have even done studies trying to estimate this:
http://www.linuxfoundation.org/publications/estimatinglinux.php
A more accurate statement would probably have been ongoing maintenance and support – you have to keep dumping money into any physical infrastructure to keep it up to date and working and supplied with raw materials, whereas “finshed” code doesn’t require that.
Totally agreed on the openness of documentation – there’s a network effect to file formats, and having data locked up in some proprietary format is effectively a “vote” for that entire proprietary software stack, thus how we end up with crap “standards” like “.doc”.
Also, non-code or non-machine readable documentation is a good idea as it forces some sort of human review of the material and not just a raw data dump.
I’m not trivializing the amount of effort that went into the design and creation of gcc (it is, of course, substantial), but rather pointing out the fact that if you wanted to build your own state-of-the-art “code foundry” you simply need to download and compile gcc — something you can do in your spare time on your own PC.
If you wanted to build a state-of-the-art “chip foundry”, it’s not something you can do in your kitchen sink with spare parts around the garage over a weekend, even if the plans for the entire fab were open-sourced. In fact, each instance of a chip foundry costs billions of dollars to copy.
As a result, the only option for would-be chip designers is to rent time on one these fabs and pay the multi-million dollar one-time fab fees for the privilege of creating a custom chip…and no, if your chip has a bug and doesn’t work, you don’t get a refund — and a chip these days have hundreds of millions of transistors on them, often times themselves the result of compiling millions of lines of VHDL or verilog code — not counting the test benches — and every register and flip flop instance is a potential race condition requiring careful synchronization checks.
Thus, my only point was the economics between software and hardware are radically different in almost every aspect, and that colors the parameters of open software vs. open hardware.
Because of the costs and difficulties involved in creating hardware, many hardware companies feel that the IP they create should at the very least be NDA. Whether or not they are right in that sentiment, they are the ones spending the essential mega-bucks to make the IP — so I’m inclined to cut them some slack.
I think some of these aspects are right of course, but I can also see a shift due to FPGAs adn other recent developments. Please also see my presentation from GOSH!2009:
http://www.gosh2009.ca/wiki/index.php/Why_Open_Source_Hardware%3F
Greets,
Juergen
I really like how things are turning out :)
I wonders why the FSF hasn’t forked off a FHF (Free Hardware Foundation) yet. I’d certainly prefer to get behind a FHF banner than an Open Source Hardware one.
With Open Hardware Initiative and quite recently with OHANDA [TM] – see http://www.ohanda.org – I had tryed to get FSF engaged for the last two years. Finally FSFE said:
> Hi Juergen
> …
> I am digging through the material from FSFE’s side. The
> president noted that FSFE is focused on software, and given
> that the organization is quite busy just dealing with that,
> he would be hesitant to actively take up the topic.
> …
> In short, FSFE probably thinks this belongs elsewhere. This
> should have been reported to you a long time ago.
So to me it looks like we need to find/form another entity to play that role for open source hardware issues. Suggestions welcome. Btw, I have checked with CC already … ;-).
Cheers,
Juergen
Also, here is one wireless chip where the vendor released the source code for the firmware needed by the device:
http://wireless.kernel.org/en/users/Drivers/ar9170.fw
Also, Calypso GSM chips are getting free firmware:
http://bb.osmocom.org/trac/
Some guys (as Wolfgang & friends from Qi-Hardware initiative) are doing some efforts to get all that binary blobs out of the chips (Milkymist project), joining open cameras initiatives (Ephel project), and in that community all the efforts are focused to get to the OSHW definition that we are talking about. Far from being close to that goal, all the steps gives us closer to it. But as bunnie said, the reality with the manufacturers is other, and we need to keep this in mind to achieve the goal. :)
For an electronic design of any complexity, I’m not sure that a PDF of the schematic would be sufficient to duplicate the product with a reasonable amount of effort. In my opinion, a machine-readable (i.e. ASCII) netlist would be a suitable requirement. I’m certain that with a modest amount of effort it would be possible to get just about any schematic capture program to import just about any netlist format.
Actually, Open Hardware licenses do not encumber the system integrator AT ALL unless there is a patent on the licensed design. You can’t, in general, encumber a hardware design with copyright. You can with a patent. The restrictions you can enforce with copyright are in regard to distributing the PLANS, not the actual hardware. So, manufacturers and integrators are generally off of the hook, unless the Open folks have gotten a patent, which is not what they’re interested in if they are for openness.
Open folks might be interested in patents if it allows them to spread freedom in a GPL style hack of the patent system.
[…] Open Source Hardware Definition 0.3 Released « bunnie's blog […]
As far as I can tell, Atheros ath9k based WiFi chipsets do not require any firmware and the driver is open source. They also seem to have open source firmware available for the ar9170 USB chipset.
My 802.11abgn router uses an ath9k chipset and I certainly don’t have any blobs in /lib/firmware. Incidentally, the Netgear WNDR3700 is an awesome modern router that pretty much runs OpenWRT flawlessly with no blobs or closed source drivers; I just bought mine and I already love it :-).
Just a simple editor’s note…
“instead of our technology owing us.” I think you ment “owning”.
I always look forward to your posts. ;D
Yes, good call. Thank you!
Just finished reading this blog post and I have to say it was a great read. Keep up the good work please.
Barging in from Google and after having a look around, I’ve seen a lot of Leet on here, keep up the good work Thnx!
Hey what a brilliant post I have come across and believe me I have been searching out for this similar kind of post for past a week and hardly came across this. Thank you very much and will look for more postings from you.