What is open source hardware?
Our statement of principles puts it like this: “Open source hardware is hardware whose design is made publicly available so that anyone can study, modify, distribute, make, and sell the design or hardware based on that design. The hardware’s source, the design from which it is made, is available in the preferred format for making modifications to it.” Note that open-source hardware refers specifically to sharing the digital design files for physical objects; while we support other forms of sharing, we think it’s important to be clear about the meaning of open-source hardware.
There’s also a growing community of companies, individuals, and groups designing and making lots of cool open-source hardware! Some examples include microcontroller development platforms, satellites and 3D printers.
We think open source hardware is a great way to share knowledge and facilitate development of new products. We hope this FAQ helps you understand what it’s all about and whether it makes sense for you.
What do you mean by hardware? What fields is open-source hardware relevant for?
Initially the definition was written with electronics and mechanical designs in mind. But more and more fields are adopting it and broadening the term “open-source hardware” to mean anything physical that has public source files. Open-source hardware has been applied to fashion, furniture, musical instruments, farm machinery, bio engineering and much more.
What files do I need to share?
Open-source hardware means sharing the files needed to build *and* modify your hardware. As the open-source hardware definition explains, that means the version of the files that you would prefer for making changes to the design, not an intermediate or obfuscated version. For mechanical stuff, this means the original CAD files. For circuit boards, it’s the original schematic and board layout files.
Unfortunately, the original design files for hardware are often in proprietary formats for expensive software tools. In this case, it’s helpful and encouraged to also offer versions of the design in alternative or intermediate formats that can be viewed or edited with common or free programs. For example, PDFs of circuit schematics, Gerbers for circuit board layouts, and IGES or STL files for mechanical objects. These allow people without access to expensive or proprietary software to make at least some use of your design. Please note, however, that this is not a substitute for releasing the original files – the core of open-source hardware practice.
When and how should I share my design files?
Many companies producing open-source hardware publish their design files on their website when the product goes on sale. Others store their files in online version control systems (e.g. GitHub or Google Code), making them public throughout the design and development process. You might also consider using a website specifically designed for sharing hardware designs, like Thingiverse.
In some cases, you might decide not to publish the design files until sometime after the product has been released; that’s fine (unless your product derives from another open-source hardware project whose license requires the open-sourcing of derivatives) but the product isn’t open-source hardware until the files are available. Instead, you might say something like “we plan to open-source this product in the future.”
What is a license and how do they apply to hardware?
This is a complicated question with no easy answer. Here’s some information to help you make sense of the possibilities.
First of all, it’s important to understand what a license is. Licensing is a way to give people rights — that they wouldn’t otherwise have — to use your intellectual property (IP) and, in return, to place restrictions on how they exercise those rights. In open-source, licensing is typically used for copyrighted information, which includes the source-code to computer programs, the text of books, photographs, recordings of music, etc. By placing an open-source license on a copyrighted work, you give people permission to make copies of it — a right they wouldn’t otherwise have. In return, you can require them to, for example, license derivatives of your work under the same license (a condition known as “copyleft”). This works well for source code, documentation, and other works for which copyright applies.
Things are more complicated when in comes to hardware. Here’s how it’s explained at openhardware.org:
Under U.S. law, and law in many other places, copyright does not apply to electronic or physical designs. Patents do. The result is that an Open Hardware license can in general be used to restrict the plans but not the manufactured devices or even restatements of the same design that are not textual copies of the original.
The applicable section of U.S. copyright law is 17.102(b), which says: “In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.”
There are similar statements in the laws of other nations.
The effect of this is that the license restricts the publication of a schematic or a laser-cutting plan, rather than the use of the schematic to make devices that are sold. You can control how people sell the plans with your license, but you can’t keep them from commercially manufacturing and selling the devices with your non-commercial license, unless you have a patent.
That said, it’s still useful to apply a license to your hardware design. To the extent that copyright applies (i.e. in the copying of the designs themselves), the license grants people rights that they wouldn’t otherwise have and makes clear the conditions under which they can exercise those rights. Even in situations in which the license isn’t legally binding, the license helps make clear the ways in which you would like people to use your design files (e.g. whether or not you think they need to share designs that derive from yours).
See the next question for some specific licenses you might use for your designs.
What license should I use?
In general, there are two broad classes of open-source licenses: copyleft and permissive. Copyleft licenses (sometimes referred to as “viral”) are those which require derivative works to be released under the same license as the original; common copyleft licenses include the GNU General Public License (GPL) and the Creative Commons Attribution-ShareAlike license. Other copyleft licenses have been specifically designed for hardware; they include the CERN Open Hardware License (OHL) and the TAPR Open Hardware License (OHL). Permissive licenses are those which allow for proprietary (closed) derivatives; they include the FreeBSD license, the MIT license, and the Creative Commons Attribution license. Licenses that prevent commercial use are not compatible with open-source; see this question for more.
Please note that the open-source hardware definition is not a license, although it does describe some of the license terms which are compatible with the practice of open-source hardware.
In choosing a license, you should first want to decide whether or not you want to require people to open-source derivatives they make of your design. If so, pick a copyleft license; if not, a permissive license. Beyond that, the differences between licenses can be subtle, you may want to talk to a lawyer or someone with experience in open-source to help you pick one. The folks at openhardware.org are in the process of recommending licenses for open-hardware.
What are other best practices for open source hardware?
- Make it clear how your hardware is licensed by providing a copy of, or at least a web link to, the license with the hardware.
- Be clear about what parts of the hardware are open-source (and which aren’t).
- Put the OSHW logo on your hardware and use these guidelines. You can find lots of different versions at oshwlogo.com.
- Keep your source files in a (free) publicly-available source code repository like Github. This makes it easier for people to track their changes to your files. It also makes it easier for them to send improvements back to you. The tools for this kind of data exchange are still pretty weak for hardware projects, but for software, they’re mature.
Won’t people rip me off?
Maybe (and open-source hardware definitely isn’t for everyone). Our experience, however, has shown that it’s possible for open-source hardware to be commercially successful despite its openness. There are many reasons for this.
For one thing, even with access to a product’s design, it’s not trivial for someone else to make and sell it. They need to source components, manufacture and assemble parts, test for quality, establish distribution channels, and more. If you’re already offering the product at a fair price, there’s not much incentive for someone to bother, especially if it’s not clear that there’s a market for the product. If you’ve already established a market, then you’re probably also growing a community around your product – a community that’s likely to support you (the original designer and maker of the product) rather than buying clones from an unknown competitor. Further, if someone really wanted to rip you off, they could probably reverse engineer and replicate your product even if you didn’t open-source it – and you wouldn’t have the goodwill or support that comes from open-source hardware.
That said, there are strategies for minimizing the potential for someone to undermine your business. Most of them revolve around creating awareness of and trust in you and your products (i.e. the same things you need for any business). Making and selling good products at fair prices will help people feel confident buying from you, even if others offer products based on the same design. Strong branding (e.g. trademarks) can help make it clear which products are made and supported by you – again, even if others are using the same designs. Finally, creating a community around your business will encourage people to buy from you, even if they can get similar products elsewhere.
People will, of course, “rip you off” in the sense that they will use your designs as the basis for more advanced designs. If you don’t want that to happen, you probably shouldn’t make your hardware open source. Those of us who do build open source hardware want people to build on our designs, or at least think the benefits of the situation are worth the competition.
There are a few reasons.
If you place a non-commercial restriction on your hardware design, other people don’t have the same freedom to use the design in the ways that you can. That means, for example, that if you and someone else both release designs with non-commercial licenses, neither of you can make and sell hardware that builds on both of your designs. Rather than contributing to a commons of hardware designs for everyone to build on, you’re limiting others to a very narrow range of possible uses for your design.
In particular, because making hardware invariably involves money, it’s very difficult to make use of a hardware design without involving some commercial activity. For example, say a group of friends wanted to get together and order ten copies of a hardware design – something that’s often much cheaper than each person ordering their own copy. If one person places the order and the others pay him back for their share, they’d probably be violating a non-commercial restriction. Or say someone wants to charge people to take a workshop in which they make and keep a copy of your hardware design – that’s also commercial activity. In general, there are just very few ways for someone to use a hardware design without involving some sort of commercial activity.
How does open-source hardware interact with hardware regulations?
Not always very well. Many rules and regulations about hardware assume that it is being produced by large, proprietary companies and may be problematic for small businesses or open-source products. For example, Mach 30 has done some good work on the implications of export controls for open-source hardware.
What’s a USB vendor ID (VID) and product ID (PID) and what should I do about them?
USB vendor IDs (VID) and product IDs (PID) are 16-bit numbers used to identify USB devices to a computer or other host. Each vendor ID is assigned by the USB Implementer’s Forum (USB-IF) to a specific company, which in turn assign a PID to individual products. The VID and PID are then embedded in the product and communicated to the computer when the device is plugged in, along with text strings describing the vendor and product and additional descriptors about the communication protocols supported by the device.
This cost to obtain a vendor ID is currently $5,000. Once a VID is obtained a company can assign product IDs to their given products. Both VID and PID are 16-bit allowing up to 65,536 products under a single vendor ID.
For the greater open source hardware community OSHWA recommends that users do not use a random VID and PID nor, when making a derivative, should they use the VID/PID of the original hardware as this can cause compatibility issues and confusion within the community.
If you’re using an off-the-shelf chip for USB communication, you may be able to use the VID/PID of that chip (e.g. with FTDI chips). OpenMoko has opened up their VID for use by free and open-source software and hardware communities. Here’s one attempt to get a VID for open-source projects. Ian Lesnet also gave a good talk on the USB VID/PID situation (slides) at the 2012 Open Hardware Summit.
OSHWA cannot offer a PID sub-licensing service to community members as this violates internal USB-IF rules as well as the 501c3 non-profit regulations in the USA. OSHWA is interested in improving this situation by educating the USB-IF about the needs of the open-source hardware community and to explain the USB VID/PID situation to the open-source hardware community. If you’re interested in helping out with this effort, please get in touch.
Thank you to David Mellis who has been writing the FAQs regarding Open Source Hardware
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.