Building Open Source Hardware: Making a Derivative
- Derivatives and Open Source Hardware
- Blinky Buildings Project
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Alicia Gibb
- “Its province is to assist us in making available what we are already acquainted with.”
- —Ada Lovelace, on the Analytical Engine
This chapter gives an example of the source files and a physical object that you can copy, modify, make, and sell as a derivative under the Open Source Hardware Definition. This chapter first discusses derivatives and attribution, and then walks through a simple open source hardware kit named Blinky Buildings that readers are encouraged to alter or modify. Appropriate methods for creating a derivative are discussed. (The Blinky Buildings hardware kit can be purchased at www.bit.ly/blinkybuildings or at www.Sparkfun.com.) Readers can follow along with the instructions, thereby making their own derivative kit. You may have also noticed that this kit is referenced in other chapters throughout this book. The skills used in creating a derivative board consist of modifying the source files and understanding how to appropriately label derivative files and give credit. The Blinky Buildings kit is labeled with the open source hardware logo, meaning it is okay to copy and create derivatives from it. If you attempt to copy and create derivatives of hardware that is not open source, you may receive a cease and desist letter from the originating company. To be safe, look for the open source hardware logo, and stick to creating derivatives from what you know to be open.
Derivatives and Open Source Hardware
One of the reasons people open source their hardware is to allow derivatives to be built from that hardware. People create derivative hardware for many different reasons, ranging from personalized features to economic advantage. The Open Source Hardware Definition makes the following statement about derived works:
- 4. Derived Works. The license shall allow modifications and derived works, and shall allow them to be distributed under the same terms as the license of the original work. The license shall allow for the manufacture, sale, distribution, and use of products created from the design files, the design files themselves, and derivatives thereof.
Clearly stated in the definition is the approval to create hardware from the original design files, to make copies and distribute the design files themselves, or to create a derivative from the original design. Because open source hardware grants the right to make copies, the terms “clone” and “counterfeit” get thrown around a lot when talking about derivative works. Here are the definitions of these terms when referencing open source hardware derivatives:
- Derivative: A derivative is open source hardware that has been altered or modified but is based on an original design by another person or company.
- Clone or Copy:A clone or copy is an open source hardware product that has been directly copied and conforms with the Open Source Hardware Definition because it does not infringe on the trademarks of other companies.
- Counterfeit: With a counterfeit piece of open source hardware, the trademark has been copied onto a clone or derivative piece of hardware and does not abide by the Open Source Hardware Definition because the trademark is not owned by the person or company creating the derivative. Proper attribution does not include copying trademarks. Copying trademarks is illegal.
There are many examples of open hardware derivatives. In particular, the 3D printing and Arduino communities are great places to find open hardware and their derivatives. Keep in mind that Arduino itself is a derivative of Wiring, developed by Hernando Barragan, and Processing, developed by Ben Fry and Casey Reas. Some derivatives have small changes from the original; others have large changes. Changes for derivatives generally fall within four categories: (1) The function of the device is altered; (2) the form of the device is modified; (3) the change is economic, with the creator selling the same product at a different—usually lower—price point; or (4) the change enables a better design for manufacture (DFM), making it easier to manufacture or supply parts. Economic and DFM changes often go hand in hand and can be difficult to separate. All of these changes are permitted within the Open Source Hardware Definition, including a combination of the four.
An example of a board that changed drastically in both form and function is the LilyPad, which was created by Leah Buechley. The LilyPad was mashed up with the Arduino board, altered in both form and function so that it could be sewn into textiles. This particular derivative was quite extreme in the amount of changes made to the original Arduino hardware. The reason the alterations were so drastic was that Leah invented a sewable microcontroller prior to the development of the Arduino product. (For more on the history of the LilyPad, see the anecdote in Chapter 9.) When Leah’s design was put together with the Arduino board, one could argue that the Arduino’s shape, the form factor of pinouts, the thickness of the PCB, the typical construction materials used, and the main purpose of the board were all altered. This particular Arduino derivative’s function was to be embedded in wearables—a vastly different use than the Arduino team had previously imagined for their microcontroller. The circular, thin (not to mention purple) LilyPad is to be sewn into wearables with a needle and thread rather than solder and wire.
Of course, not all derivatives are this different. In fact, some are even more or less copies of the original.
Let’s take the Arduino example one step further by considering a derivative of the derivative. Adafruit’s Flora is a derivative of the LilyPad (which is derivative of the Arduino board). The Flora derivative has the same form factor as the LilyPad—it is circular in shape and flat, and has copper petals around the exterior for ease of sewing—but has a different function, with a different chip on board than found in the original LilyPad. The Flora hardware introduced the ATmega32U4 chip into wearables with different functionalities than the ATmega328 on the LilyPad (such as allowing for a USB hookup rather than using an FTDI cable). Because these designs are all open source, the LilyPad developer was then able to roll the Flora’s changes back into their design, and now LilyPad also offers an Atmega32U4 product. Naturally, both products can compete in the marketplace, because they are open source hardware, nobody is suing over rights; rather, everyone is focused on innovating. You can access the source files for LilyPad and Flora and compare and contrast the design files for yourself:
- Original LilyPad files linked from SparkFun’s product page: www.sparkfun.com/products/9266
- Flora derivative files listed in Github: github.com/adafruit/Adafruit–Flora–Mainboard
- New ATmega32U4 LilyPad design rolling in the Flora’s ATmega32U4 improvements: https://www.sparkfun.com/products/11190
This is how derivatives of open source work! People build off improvements and ideas from others rather than reinventing the wheel each time. This process moves innovation forward at a more efficient and more productive pace.
Why the LilyPad Arduino Has “Arduino” in Its Name
The fact that the LilyPad carries the Arduino brand name is a very important point to note. The name Arduino is a trademark held by the Arduino company. Leah Buechley made an agreement with the Arduino company to license its Arduino trademark for a fee. This arrangement should not be confused with Leah giving the Arduino team attribution for their original board. Arduino has tried to make an important distinction in its trademark over the years. Although it is an open source project, the logo and company name are trademarked, much as any other company in the open source hardware space (and even in open source software, for that matter) can obtain a trademark for its products. We use trademarks because trademarks protect consumers and say something about the quality of the brand they are buying, rather than to protect the intellectual property of the hardware. Unless you obtain a license from Arduino, as Leah did to enable her project to be called a LilyPad Arduino, you cannot use the word “Arduino” in the name of your derivative as a way to give credit or attribution because it is a trademarked name.1 You can help the community understand correct attribution of Arduino derivatives by attributing Arduino in your README file or your project description.
Giving Correct Attribution
The Open Source Hardware Definition states the following about attribution:
- The license may require derived documents, and copyright notices associated with devices, to provide attribution to the licensors when distributing design files, manufactured products, and/or derivatives thereof. The license may require that this information be accessible to the end–user using the device normally, but shall not specify a specific format of display. The license may require derived works to carry a different name or version number from the original design.
When creating your derivative, you will want to give credit to the original design without infringing on the trademark of one of original creation. As Michael Weinberg reminds us in Chapter 3, “Including a ‘share alike’ provision in a CC license is not a polite request that anyone who builds upon the work contribute back to the commons; rather, it creates a legal requirement.” This goes for attribution provisions as well. Due to the murky nature of licensing hardware, we tend to read the source files (which can be licensed cleanly with copyright or a copyright alternative) to understand the intention to list attribution or share it alike with the same license.
Attribution is like citing someone else’s work in a research paper; it is not copying and pasting the logo of the original creator and applying it to your board. Attribution can also be thought of as giving the work provenance. In the art world, giving correct provenance means identifying who had a particular piece of art before you owned it. In open source hardware, the equivalent is who hacked on that particular design file or piece of hardware before you. List their names just as you would in a citation or provenance document.
Ego or Accuracy?
Call it ego or call it accuracy, but the open source community loves credit. Credit, or attribution, is one of the many benefits to sharing your project openly. Getting attribution for something you created is at the root of most open source licensing structures, be it in hardware or software.
Accurate attribution is important to the life of your project. Giving accurate attribution lets the community know what your project was built on. Contributors, be they original creators or makers of derivatives, may be known within the community for their quality, work style, community involvement, approach, knowledge on a particular subject, and so on. Listing creators for your derivative gives users more information and certain expectations about your derivative.
How far do you go back? Most projects don’t include credit to the inventors of the transistor when using one on their board, or to the inventors of the C programming language when using Arduino. That practice is accepted within the community. We generally do not step further back than the first or second layer of original creators, although there will always be gray areas where credit is due. When in doubt, give credit. Even if your project no longer reflects any of the original design, you still may want to reference that previous versions were based on so–and–so’s contraption so that people do not feel left behind or forgotten. No one will fault you for giving too much credit to other people who wrote code or built hardware before you. Perhaps the open source hardware industry will eventually grow in such a way that our README files will start to look like movie credits and go on for at least seven minutes after the movie is over.