Open-Source Hardware FAQ

Index

What is open source hardware?
What do you mean by hardware? What fields are open-source hardware relevant for?
What files do I need to share?
When and how should I share my design files?
What is a license and how do they apply to hardware?
What license should I use?
How does the first to file system affect open source hardware?
What are other best practices for open source hardware?
Won’t people rip me off?
Why aren’t non-commercial restrictions compatible with open source hardware?
How does open-source hardware interact with hardware regulations?
What’s a USB vendor ID (VID) and product ID (PID) and what should I do about them?
Does OSHWA build Hardware?

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 are 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.

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.

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. (Thanks to Michael Weinberg of Public Knowledge for helping us draft this answer.)

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. Licensing is often 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 it comes to hardware. Mostly, that is because copyright does not apply to hardware in the way that it does to software. In the United States (as well as many other nations), useful or functional objects are excluded from the scope of copyright protection. (The expression of the objects in a design file, however, may be covered by copyright. More on that below.) Functional objects can be protected by patents but applying for a patent is an expensive and time-consuming process — in contrast to copyright, which applies automatically. As a result, many potentially patentable items will not actually get patented.

The line between “creative” works protected by copyright and “useful” works protected by patent can be blurry sometimes (17 U.S.C. § 102 contains the definition of the distinction). However, a good rule of thumb is that anything in a piece of hardware that is critical to its operations – that means servos, arms, and sensors as opposed to cool flames on the side – falls on the “useful” side of the line. Without a patent, that hardware (except for the software and non-functional design elements) will not be protected by an intellectual property right. Without an underlying intellectual property right, no one needs permission to copy, modify, or build upon the hardware. This means that they do not need a license from the creator and, therefore, license terms (like “copyleft” terms) generally cannot be enforced.

It is crucial, however, to make a distinction between the design files for the hardware and the hardware itself. The design files are likely protected by copyright, even if the hardware itself is not. (A potential exception is if there is only one or only a handful of ways to express the functional ideas of the hardware in the design file. In that case the expression may “merge” with the ideas and not be protectable by copyright.) Copying the design files (potentially including doing so as a step in making the hardware) would be copyright infringement, while using the design files as a basis to create the hardware in a way that did not copy the files would not be. Similarly, deriving new design files from the hardware itself (without copying the original design files) is probably not copyright infringement.

The end result: while the design files of your open source hardware project can probably be protected by a license, the hardware itself probably cannot be. Unless you have a patent, someone else can manufacture the hardware without your permission, assuming they do so without infringing your copyright on the design files.

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).

Finally, this lack of protection means that much more hardware is in the public domain by default, just waiting for you to build upon it. And that is a good thing.

For more information on the copyright in the U.S., see the FAQ at copyright.gov and this PDF. Creative Commons also has some information you should know before licensing.

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 (also referred to as “share-alike” or “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. The Solderpad Hardware License is a hardware-specific permissive 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.

How does the first to file system affect open source hardware?

There is nothing that protects you from someone else trying to patent your open source hardware work other than prior art, first to file does not negate prior art. Many members of the community publish their work on blogs and websites frequently (prior art must be public), but there is no guarantee that a patent office will find your work. In a perfect world, the patent office would not be able to award a patent if you’ve published prior art publicly.

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 the Open Source Hardware Logo page.
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.

Why aren’t non-commercial restrictions compatible with open source hardware?

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.

Does OSHWA build hardware?

OSHWA does not build hardware ourselves, we do what we can to support your efforts to build hardware! We provide information, options and understanding of what building open source hardware can look like.

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.