Open Source Hardware
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
- Documentation: Establish and facilitate the right to repair
- Necessary Software: Operates using Free Open Source Software
- Derived Works: The right to fork the project.
- Free Redistribution: Pay for parts, not permissions. No restriction on the sale of parts.
- Attribution: Give credit where it's due.
- No Discrimination Against Persons or Groups: Respect is earned.
- No Discrimination Against Fields of Endeavor: Make recommendations, not restrictions.
- Distribution of License: Share Alike.
- License Must Not Be Specific to a Product: The right to re-use.
- License Must Not Restrict Other Hardware Or Software: Play well with others.
- License Must Be Technology-Neutral: The right to modify.
Open Source Hardware (OSHW) Draft Definition
Facilitate the right to repair.
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.
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.
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.
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.
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.
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.
All non-proprietary contributions toward the design of the project subject to the OSHW definition.
All non-proprietary parts of the project derived from project works or other projects defined by OSHW.
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.
All parts of the project purchased from external suppliers not derived from project works or other projects defined by OSHW.
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.