The growing success of open source software has naturally spurred on others to apply its lessons elsewhere. Open content is perhaps the most famous translation, notably through the widely-used Creative Commons licences. But one of the most challenging domains to come up with something equivalent to the Open Source Definition (OSD) is hardware – not surprisingly, perhaps, since hardware is analogue, not digital, and hence very different in nature.
Nonetheless, the desire to do so has overcome the obstacles and come up with Open Source Hardware Definition Draft 0.3, which helps to define compliant open source hardware licences:
Open Source Hardware (OSHW) is a term for tangible artifacts -- machines, devices, or other physical things -- whose design has been released to the public in such a way that anyone can make, modify, distribute, and use those things. This definition is intended to help provide guidelines for the development and evaluation of licenses for Open Source Hardware.
Interestingly, it is explicitly based on the OSD:
OSHW Draft Definition 0.3 is based on the Open Source Definition for Open Source Software and draft OSHW definition 0.2, further incorporating ideas from the TAPR Open Hardware License.
Indeed, where the OSD has 10 criteria, the OSHW has eleven that are almost identical. The extra one flows from the added analogue dimension. So OSD's
2. Source Code
The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.
becomes the OSHW's
The hardware must be released with documentation including design files, and must allow modification and distribution of the design files. Where documentation is not furnished with the physical product, there must be a well-publicized means of obtaining this documentation for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The documentation must include design files in the preferred form for which a hardware developer would modify the design. Deliberately obfuscated design files are not allowed. Intermediate forms analogous to compiled computer code -- such as printer-ready copper artwork from a CAD program -- are not allowed as substitutes.
2. Necessary Software
If the hardware requires software, embedded or otherwise, to operate properly and fulfill its essential functions, then the documentation requirement must also include at least one of the following: The necessary software, released under an OSI-approved open source license, or other sufficient documentation such that it could reasonably be considered straightforward to write open source software that allows the device to operate properly and fulfill its essential functions.
That's because open hardware generally needs software, which must obviously be open source, but also has associated design files that need to be open too.
The other major change concerns attribution. The OSHW has:
The license may require derived works to provide attribution to the original designer when distributing design files, manufactured products, and/or derivatives thereof. The license may also require derived works to carry a different name or version number from the original design.
There is a further comment on this topic in the introduction:
It is important to note that hardware is different from software in that physical resources must always be committed for the creation of physical goods. Accordingly, persons or companies producing items ("products") under an OSHW license have an obligation not to imply that such products are manufactured, sold, warrantied, or otherwise sanctioned by the original designer and also not to make use of any trademarks owned by the original designer.
Overall, I am impressed how close those drafting the OSHW have managed to keep to the original OSD, and how robust the latter's key concepts are proving, even in new fields. I look forward to seeing some OSHW-compliant open source hardware licences in due course, as well as further revisions of the definition itself.