Open Source Hardware

From Clothbot

Jump to: navigation, search


Work In Progress - Open Source Hardware

As it currently stands with version 0.3 more changes need to be made before it can scale to meet the demands of hierarchical design flows and dependencies.


I don't know the answers, I'm just thinking aloud based on related topics I've encountered over the years.

Open Source Hardware (OSHW) Executive Summary

  1. Documentation: Establish and facilitate the right to repair
  2. Necessary Software: Operates using Free Open Source Software
  3. Derived Works: The right to fork the project.
  4. Free Redistribution: Pay for parts, not permissions. No restriction on the sale of parts.
  5. Attribution: Give credit where it's due.
  6. No Discrimination Against Persons or Groups: Respect is earned.
  7. No Discrimination Against Fields of Endeavor: Make recommendations, not restrictions.
  8. Distribution of License: Share Alike.
  9. License Must Not Be Specific to a Product: The right to re-use.
  10. License Must Not Restrict Other Hardware Or Software: Play well with others.
  11. License Must Be Technology-Neutral: The right to modify.

Open Source Hardware (OSHW) Draft Definition


Facilitate the right to repair.

Documentation Details

All schematics, layouts and associated collateral original to the project shall, at a minimum, be available in a human readable format. These human readable files shall be sufficiently complete for someone versed in the art of manufacture and assembly of the project hardware in full.

These project works must be licensed in a manner that allows for free distribution, modification and subsequent redistribution of derived materials.

Proprietary Documentation Dependency Corollary

All project dependencies pertaining to proprietary components, documentation, hardware, intellectual property and materials (proprietary works) must be clearly identified in the project documentation and managed separately from project works to allow for future substitution. Their inclusion must pass the Box Test for Proprietary Works.

Necessary Software

Operates using Free Open Source Software.

Necssary Software Details

If the project 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.

Proprietary Software Dependency Corollary

All dependencies on proprietary software must be clearly identified in the project documentation and managed separately from original project works. Their inclusion must pass the Box Test for Proprietary Works.

Derived Works

The right to fork the project if you want to take it in a different direction.

Derived Works Details

The project works shall be licensed in a manner that permits modifications and the creation of derived works.

The license shall allow for distribution under the same terms as the license of the original project works and hardware.

The license shall allow for the manufacture, sale, distribution, and use of products created from the design files or derivatives of the design files.

Free Redistribution

Pay for parts, not permissions. Selling project hardware is allowed.

Free Redistribution Details

The license shall not restrict any party from selling or giving away the project works as a component of an aggregate distribution containing designs from several different sources. The license shall not require a royalty or other fee for such sale. The license shall not require any royalty or fee related to the sale of derived works.

The license shall allow for the manufacture, sale, distribution, and use of products (including project hardware) created from the design files or derivatives of the design files.

Free Redistribution of Proprietary Materials

The use of proprietary materials is permitted so long as any and all royalties or fees are integrated into the off-shelf cost of said proprietary works and hardware. Their inclusion must pass the Box Test for Proprietary Hardware.

Free Redistribution Caution

Some design software tools make available fully-functional freeware versions with explicit non-commercial use clauses.

Example: CadSoft EAGLE Freeware limits its use to non-profit applications or evaluation purposes:

If you earn (or save) money by using the Freeware version of EAGLE Light, you have to register it.

It is the responsibility of the project maintainers and participants to ensure that such limitations do not come into conflict with this Derived Works section or any other part of the OSHW definition.


Give credit where it's due.

Attribution Details

The license shall require derived works to provide attribution to the original designer when distributing project works, project hardware, and/or derivatives thereof. The license shall also require derived works to carry a different name or version number from the original design.

The inclusion of project works in proprietary systems must satisfy the OSHW Definition and pass the Box Test for Project Works.

No Discrimination Against Persons or Groups

The license must not discriminate against any person or group of persons.

Incompetence begets its own reward.

No Discrimination Against Fields of Endeavor

The license must not restrict anyone from making use of the project hardware in a specific field of endeavor.

For example, the license may not restrict the project hardware from being used in a business, or from being used in nuclear research.

Nuclear fusion is most certainly not the same thing as nuclear fission!

Proprietary Limitations Against Fields of Endeavor

All proprietary works and hardware used in the project containing limitations against fields of endeavor must be clearly identified in the project documentation.

Distribution of License

The rights attached to the project works and hardware must apply to all to whom the product or documentation is redistributed without the need for execution of an additional license by those parties.

Proprietary Distribution of License?

??? How should the inclusion of proprietary works and/or hardware in the project materials be accommodated here, if at all?

License Must Not Be Specific to a Product

The rights attached to the hardware must not depend on the hardware being part of a particular larger product. If the hardware is extracted from that product and used or distributed within the terms of the hardware license, all parties to whom the hardware is redistributed should have the same rights as those that are granted in conjunction with the original distribution.

The right to re-use.

License Must Not Restrict Other Hardware or Software

The license must not place restrictions on other hardware or software that may be distributed or used with the licensed hardware.

For example, the license must not insist that all other hardware sold at the same time be open source, nor that only open source software be used in conjunction with the hardware.

License Must Be Technology-Neutral

No provision of the license may be predicated on any individual technology or style of interface.

I'll use squid ink in my printer cartridge if I darn well please, thank you very much!

Good/Better/Best (GBB) Practices

Documentation - GBB

Follow Open Standards / Avoid Closed Standards

Open standards should be unencumbered by paid access or licensing fees. Many standards and data formats in EDA and similar industries purporting to be open are merely available in source form, not free of cost for use and distribution in open source projects.

Design with Reuse in Mind

Larger designs make extensive use of hierarchy. If you can draw a box around a functional element, attempt to make the element self-contained and parametric to facilitate re-use.

Design with Substitution in Mind

Where ever external dependencies reside, whether they be transistors, ICs or radio modules, design them into the project in such a way that existing equivalent components might be substituted.

Design with Revision Control in Mind

This is the elephant in the room of EDA, and likely other CAD and related design fields.

Name Your Instances and Interfaces

Whether it's a SPICE netlist, Verilog RTL, or COLLADA model file, at least assign useful names to your instances and interfaces (ports, buses, important nets).

Sort Hierarchy Alphanumerically

When given the choice, sort levels of hierarchy alphanumerically. In EDA, many netlisters sort output based on database ID-order - it's faster to write out instances as they appear in sequence than impose any kind of order.

It's easier to track incremental changes in the design without resorting to complicated (and expensive) equivalence checking software solutions.

Necessary Software - GBB

Pick BSD, GPL and Equivalent Options

Derived Works - GBB

Use Open Source Tools

The easiest way to avoid conflicts with any of the OSHW definitions is to use open source tools throughout your design flow.

Pay For Your Own Tools

Many proprietary tools stamp version and other tool and licensee information into their databases and created design data. Help everyone stay honest when commercial options are chosen. Proceed with caution if using your work's assets for project contributions.

Free Redistribution - GBB

Use Open Standards

Remember GIF vs JPG vs PNG, MP3 vs Ogg Vorbis.

Attribution - GBB

Revision Control Logs

At the very least, use revision control logs to establish time-line and attribution of contributions and inclusion of external source material.

Format Agnostic

The OSHW Definition itself needs to be format-agnostic. As long as a given project's works are available in a human-readable format, an unencrypted manufacturable format, and the source files in which edits are performed, it should be considered Open Source Hardware.

  • If the design files are available in human-readable form then I (the end user/consumer) can understand how things work, debug problems, and "edit" my hardware. This is also the most future-proof format you'll ever get.
    • Think of all those 50yo tube radios with schematics pasted to their insides. They can still be fixed and re-built from scratch if you can source or make the parts yourself.
    • Worst-case, I will be able to re-capture the project into my preferred design environment and fork to my heart's content independent of whether the manufacturable and/or editable forms are accessible.
  • If a manufacturable format is present, I can send the DXF drawings to the machine shop, gerber to the factory, STL to the fab house, and/or print off my own versions of that specific implementation.
    • I can import these files into the editor of my choice and do tweaks as needed, or instantiate them as required in my own project(s).
    • This is less future-proof in that "manufacturable" changes over time. For example, most semiconductor fabs won't take designs on rubylith these days; GDSII is the norm. The forward-port can be automated, but it might be faster to start with the human-readable source to adapt to everything else that has changed in the meantime.
  • If the source design files and databases are available, I might be able to do edits directly, but for legacy reasons I don't depend on that being possible for all time.
    • This may very well be the least future-proof option of them all.
    • Choose an tool-agnostic formats where you can to future-proof them. I prefer plain-text and zipped XML (OpenOffice, Collada, even MS Office XML) because they preserve the hierarchy and are easy to postprocess in nearly all programming and scripting languages. When necessary, I parse "native" formats into an XML intermediary to do the same.
    • It should be up to the project managers to define what subset of formats submissions (if any) may be made in.


Human Readable Format

Human readable formats are those for which free and preferably open-source viewers are available. These include, but are not limited to the following formats: PDF, SVG, PNG, IGES, STEP, Gerber x274, GDSII, CDL, SPICE, Verilog, VHDL, DXF, OFF, STL.

Project Works

All non-proprietary contributions toward the design of the project subject to the OSHW definition.

Project Hardware

All non-proprietary parts of the project derived from project works or other projects defined by OSHW.

Proprietary Works

All components, materials and other dependencies used as inputs in the project that are not available under and subject to the OSHW definition. These may include such things as data sheets, application notes, source code and standards documents.

Proprietary Hardware

All parts of the project purchased from external suppliers not derived from project works or other projects defined by OSHW.

Box Test

The Box Test is simply defining a container (drawing a box, storing in a file, separating a part) such that all interfaces and interactions between contents within the box and those outside the box are distinct and preferably well defined. If you can easily remove the box contents and substitute with a new box contents, the box test succeeds.

Box Test for Project Works

All project works are said to pass the box test if all non-project works are easily removed and/or substituted with different material of a proprietary or OSHW definition compatible nature.

Box Test for Proprietary Works

All materials of a proprietary nature are said to pass the box test if they are maintained and used in such a way that future whole (not partial) substitutions of said materials with different OSHW or proprietary solutions may be made.

It is sufficient for intermediate derived works to mix (e.g. gate-level netlists synthesized from a combination of proprietary and project RTL for use in an FPGA) so long as their inclusion in the project does not conflict with the OSHW definition.

Proprietary works included by reference in project works should pass the box test. Examples include, but are not limited to the following:

  • Instantiation (the reference) of Verilog modules containing said proprietary works
  • Construction of intermediate files by way of m4 macro processor
  • Application of proprietary materials using patch.

Proprietary works included by copy-paste action will likely fail the box test. Use reference mechanisms instead.

Box Test for Project Hardware

Project hardware used as components in proprietary applications and systems is permitted so long as OSHW Definition criteria are met and maintained for these components.

Box Test for Proprietary Hardware

All component hardware of a proprietary nature used in project hardware pass the box test so long as the following criteria are satisfied:

  • Their inclusion can be substituted with equivalent proprietary or OSHW defined material at some future point in time.
  • In the case of composite materials (e.g. two part epoxies, cement aggregates, carbon fibre composites), no limits are placed on the use of the resulting project hardware that conflict with the OSHW definition.


Open Source Hardware (OSHW)

This Document Licensed CC-BY

Since MediaWiki doesn't let me change the licensing footer per-page: the contents of this page are CC-BY licensed to match OSHW page license.

Personal tools