Open Source Hardware

From Clothbot

(Difference between revisions)
Jump to: navigation, search
Revision as of 04:23, 16 July 2010 (edit)
AndrewPlumb (Talk | contribs)
(No Discrimination Against Fields of Endeavor)
← Previous diff
Revision as of 04:24, 16 July 2010 (edit)
AndrewPlumb (Talk | contribs)
(License Must Not Restrict Other Hardware or Software)
Next diff →
Line 101: Line 101:
== License Must Not Restrict Other Hardware or Software == == 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.+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 == == License Must Be Technology-Neutral ==

Revision as of 04:24, 16 July 2010

Contents

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.

Open Source Hardware (OSHW) Draft Definition

Documentation

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 to manufacture and assemble the project hardware in full.

These design files 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 must be clearly identified in the project documentation and managed separately from original project works to allow for future substitution.

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.

Derived Works

Embrace, extend and pay the bills.

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

Derived Works 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.

Free Redistribution

Pay for parts, not permissions.

Free Redistribution Details

The license shall not restrict any party from selling or giving away the project documentation 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.

Free Redistribution of Proprietary Materials

The use of proprietary materials is permitted so long as all associated royalties or fees are integrated into the off-shelf cost of said materials.

Attribution

Give credit where it's due.

Attribution Details

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

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, it 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 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 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.

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.

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.

Definitions

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 Hardware

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

Proprietary Hardware

All components, materials and other dependencies used in the project that are not available under and subject to the OSHW definition.

References

Open Source Hardware (OSHW)

http://freedomdefined.org/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