Do we need an open hardware license?

Nokia researcher Jamey Hicks recently proposed a Open Source Hardware License (OSHL) for approval by the Open Source Initiative (OSI). Is there a need for a hardware-specific license? If so, what makes hardware different from software?

Hicks says that the license is related to “research on chip and system design” being done jointly by the Massachusetts Institute of Technology (MIT) and Nokia. “As part of that work in the Armo project, MIT has developed some chip components in a hardware description language called Bluespec. Bluespec is based on MIT technology and is commercialized by Bluespec.com. For the most part, we are not fabricating any actual chips, but we are designing ASIC components or ‘IP blocks’ from which chips could be produced.

“These research projects are being carried out as open innovation — we can talk about them in public, and students and faculty can write papers and theses based on the work. In some of the projects, Nokia and MIT have decided that there is even more value in the work if the source code is shared so that others can use it and others can contribute to it. That is very straightforward in the software projects because there are very common, well-accepted licenses to choose from. We want to do something similar with these hardware components, using an LGPL-like license. Nokia and MIT would also like others who modify and use these open source components to share their modifications. We are currently looking for a license that would be satisfied by the initial contributors to the project that fits these goals.”

The proposed license is based on version 2.0 of the Artistic License. Hicks originally used the first version of the Artistic license, but utilized version 2.0 after Allison Randal pointed out that 1.0 was outdated and had a few “ambiguities.”

The new license removes “language referring to the interpreter, scripts, and object code” as well as language that required that standard forms of the package be distributed along with modified versions.

Reaction on the OSI list has been lukewarm at best. Many express confusion over why hardware needs a special license.

For and against a open source hardware license

On OSI’s license discuss list, Phipps writes that the distinction between hardware and software “is getting harder and harder to make.” In another post, he points out that hardware is actually software “until very late in the design process.”

Phipps says that the Verilog, a hardware description language, used for UltraSPARC design “is definitely software, and the GPL (or any other Free Software license approved for open source community use by OSI) seems 100% applicable to me.

“If we allow special ‘hardware’ licenses because the copyrighted work is used for that purpose, we are on a slippery slope towards many other specialist (an in my view redundant) sub-categories.”

Brian Behlendorf, CTO at CollabNet, says that existing licenses could cover hardware. “While I can see ‘source code’ in the language of many OSI licenses, I never took that to mean that the licenses could only be applied to software. Software in source code form may have been the context in which these licenses are described and considered, but a GPL-licensed collection of source code, documentation, UML diagrams, paper napkin sketches, and audio recordings of the developers’ favorite original jokes, are all still GPL-licensed.”

Hicks says that some of the existing licenses “include language that refers explicitly to software or the ability to replace components at run time, which makes them either less useful or more open to interpretation when applied to hardware.”

He does say that “depending on the goals of a project, MIT, BSD, GPL, Eclipse Public License, or CDDL would be usable. LGPL requires that a user be able to replace the open source components at runtime with new versions, so it would seem to me not to be usable for hardware.”

However, none of the licenses Hicks deems suitable for hardware meet all the goals of contributors to his project. “CDDL and EPL would fit our needs except that at least one of the contributors, MIT, will not use a license with explicit patent grants. The Artistic License is very close to our needs, so I am proposing this Open Source Hardware license, derived from Artistic License 2.0.”

Does it do any good for hardware to be open?

Assuming the OSI approves Hicks’ license, or one like it, is it likely to get much use, and is open hardware going to take the world by storm? Obviously, most people don’t have ready access to a fabrication facility to get chips made or the expertise to tweak chip designs on their own — so how useful is it for hardware designs to be open source?

Sun is one of the few companies to actually have hardware licensed under an open source license, and to have had others take advantage of the openness of the hardware. Sun released the designs for its UltraSPARC T1 chip, codenamed Niagara, in 2006.

Phipps says that releasing the T1 designs under the GPL have actually borne fruit. “In fact, we were gambling to some degree … and I think that gamble has paid off with the creation of freedoms that haven’t existed before, and has grown the knowhow of the free software communities.”

He points out that David Miller added T1 support to the Linux kernel, and that two companies have used the design for new chips.

Phipps did note that the open collaboration process does not work quite the same way with hardware as it does with software. He says that once chip designs are finalized, they’re not likely to roll new features into the chips in production — but Sun can roll improvements from others into future generations of the UltraSPARC. “Next time we’re designing a successor chip, we will build into the next chip design knowhow we have gained by looking at what others have done in the community.”

Hicks also acknowledges that “the closer to hardware designs you get, the fewer contributors you will find. I have worked with open source projects from the scripting level down through libraries, driver, kernel, firmware, and now hardware, and the number of people who can participate, contribute, or use the source code decreases as you go down those levels.”

Still, Hicks says that it’s possible to use open source hardware designs with field-programmable gate arrays, “which are quite affordable,” and points to OpenSPARC and the OPENCORES community of open hardware designers as examples of real-world usage of open hardware.

Phipps says that he sees open hardware following in the footsteps of FOSS, though he says mainstreaming of open hardware “will take much longer … to get a foothold.”

But, that doesn’t mean he finds the slower pace discouraging. “Yes, having a fab is really handy, but not the only way you benefit from the code. Creating vectors of freedom is always a good thing to do.”