Building an Open Source Hardware Certification with OSHWA

This is a discussion draft and proposal to create an official certification for open source hardware housed in the Open Source Hardware Association.  It contains an overview of the proposal and raises some specific questions related to the development and implementation of a certification.  Once you have read the draft, please provide feedback in the OSHWA forums.

Brief Overview

This is a proposal to develop one or a series of open source hardware certifications administered by OSHWA.  The certification requirements would be developed collaboratively with the community and could possibly vary by degree of openness .  Users would self-certify compliance in order to use the certification logos.

A single certification threshold would have the benefit of clarity and simplicity.  However, it may not contain enough flexibility to capture the diverse paths towards openness in the hardware world.

A tiered certification would have the potential to muddy the waters around what really is “open” and could potentially be gamed by bad actors.  However, by creating a spectrum of certifications and examining their use over time, OSHWA could collect real-world information about what degree(s) of openness feels most viable to the community by tracking the adoption of the various tiers.  Over time, the spectrum of licenses could be consolidated based on adoption rates (this evolutionary model was used by Creative Commons to simplify and focus their license structure over time), thus bringing additional clarity to what is and is not truly OSHW.

An additional benefit of certification could be to make it easier for “outsiders” to participate in OSHW by bringing additional clarity to the definition, thus expanding the reach of OSHW and its exposure to new communities.  The following is a short sketch of elements of this proposal.

Process

OSHWA is opening this proposal to the larger community because OSHWA is a community-driven organization and open source hardware succeeds on the strength of the open source  hardware community.  The goal of this process is to arrive at a consensus-based certification process for open source hardware.

In order to achieve these goals we have structured the following process:

June 2, 2015: Public release of proposal v1

June 26, 2015: Comment deadline on proposal v1

July 14, 2015: Public release of proposal v2 (if necessary)

August 7, 2015: Comment deadline on proposal v2 (if necessary)

Open Hardware Summit 2015: Release of Open Source Hardware Certification v1

Comments will be accepted via the OSHWA forums.  Each specific question will have its own branch.  There will also be a general branch that will act as a catchall for comments that don’t fit neatly into a specific question.

We have created the option for a second round of comments.  This second round will be used if the first round comments do not indicate that the community is moving towards a consensus.  If needed, the second round should give everyone a chance to weigh in on questions left unresolved in the first round.  If the first round of comments point to a conclusion we may not have a second full round.

All comments will be reviewed by the Open Source Hardware Association board, which will also be responsible for revising and finalizing the proposal.

Primary Goals

• Make it easier for the public to identify open source hardware.
• Move towards common expectations of what qualifies as open source hardware, including how non-open elements of putatively open source hardware is handled.
• Expand the reach of open hardware by making it easier for “outsiders” to participate by setting clear expectations and definitions.

Optional/Secondary Goals

• Encourage the creation of OSHW database
• Develop an additional sustainable funding source for OSHWA

Clarifying Terms

The Open Source Hardware Definition and Open Source Hardware Best Practices were massive steps towards clarifying what actually qualifies as open hardware.  However, questions still remain about how to apply the definition and best practices properly to a given project, and also about how closely a project must adhere to all of the best practices in order to qualify for  opensource hardware certification.  Notably, “open source hardware certified” and “open source hardware” do not have to be absolutely synonymous.  The purpose of  the certification process is to try and provide some sort of certification of compliance for others.  Nothing in this certification process prevents someone from calling their project open source hardware.  The certification only has meaning if, over time, the community decides that the existence of the certification helps them identify projects that comply with their understanding of what open source hardware means.

One way to handle questions relating to how to apply definitions and best practices to a given project would be to develop a single canonical litmus test for openness.  This would create a clear distinction between what is “really open” and what is merely trading on the popularity of the term open source hardware. While bringing many benefits, a single test may not fully capture the community understanding of what qualifies as acceptable and unacceptable compromises in a move towards openness for a given project.

An alternative path is to develop a spectrum of tests of openness.  As long as they are clearly differentiated, it would allow a project to navigate its specific limitations by claiming “partial openness,” “full openness,” or recognized degrees in between.  The project could be transparent about its level of openness, but still get whatever credit it can get for incorporating some level of openness.  Levels could be indicated via a level system (Gold OSHW, Silver OSHW, Bronze OSHW), a laundry/nutrition-style label, or other indicators.

Over time, a spectrum of tests could help give rise to a more accurate understanding of how creators actually apply open principles to hardware.  The criteria that are embraced could be promoted, while the criteria that are avoided could be reconsidered and even depreciated.

Such a spectrum does come with downsides.  It has the potential to make it even harder for end users to really understand what an “open” label means. It could also allow bad actors to game the system in order to claim openness for marketing purposes while avoiding adhering to the spirit of open source hardware.

Expanding Reach

Another advantage of formal certification would be to make it easier for “outsiders” – developers and companies without strong personal ties to the open source hardware community – to confidently offer their products up as OSHW.  This is especially important in recruiting larger companies into the OSHW world.  Of course, attracting larger companies into OSHW is a debatably valuable goal.  The benefits of expanded awareness must be balanced against threats of being coopted and the watering down of the definition of true OSHW.  However, if such an outcome is worth exploring, providing clarity and a glide path may make it easier for outside developers (both independents and those at larger companies) to embrace openness without fear of unintentionally violating misunderstood community norms.

Self-Certification

In order to avoid turning OSHWA into a large certification bureaucracy, once developed the licenses could be offered up for self-certification.  That would mean that anyone would be free to use the certifications as long as they felt that they complied with the terms of the certification.

Critically, self-certification would not simply mean that anyone could call themselves open source hardware.  In order to self-certify, a project would need to agree to abide by open source hardware requirements.  Perhaps more importantly, the project would also have to agree to comply with sanctions and penalties imposed by OSHWA if they were found not to comply with the requirements.

While it would still require OSHWA to enforce the certification rules, self registration is a low-impact alternative to a much more onerous system that required anyone to get formal pre-approval before adopting the certification.

Registration

While not required, certification users could be encouraged to register their certified projects with OSHWA (or a third party registrar) as part of downloading the registration logos.  This could help create the long-discussed open hardware registry.  Additionally, it could create a way for OSHWA to track and compare the uses of various flavors of certification (if such flavors of certification exist).

Fees

This proposal does not require the collection of any fees in order to function.  However, certification logos could be used as a source of funding for OSHWA if OSHWA was so inclined.  The lowest impact way to impose fees would be to impose either a one-time fee or royalty on the use of a certification logo in a commercial product.  Such a fee could be tied to volume or revenue so that small projects would be exempt, but more successful products had to pay on a sliding scale.  Of course, the fee would need to be low enough to avoid acting as a disincentive to adopt the certification logo.

Enforcement

There is a broad range of potential options when it comes to enforcing proper use of certification logos.  Options include, but are not limited to, maintaining a “list of shame” online for companies and projects that misuse the logos, maintaining the option to demand the removal of a logo on noncomplying products, operating some sort of public complaint process to identify misuse, and even imposing some sort of financial penalty (perhaps after an opportunity to correct is given) for misuse of the logo.  These options are not necessarily mutually exclusive.

Questions

Please provide your thoughts on the following questions.  Explanations for your preferences are appreciated.  You can also make general comments here.

1. Is certification something that OSHWA should be looking into all?
2. Do you prefer a single definition of openness or a spectrum of options?  Please explain your preference.  If you prefer a spectrum, do you have a preference between a tier-based spectrum or a nutrition/laundry label-style approach.
3. Should it be possible for projects with non-open components to be certified as open source hardware?  If so, how should the process handle such projects?  Is a part-by-part label desirable because it gives specificity or undesirable because it complicates understanding the label for less technically sophisticated community members?
4. Do you prefer a self-certification process or a process that involves pre-approval of certifications by OSHWA?
5. Should registration be part of the certification process? If so, should there be a single central repository or a distributed set of repositories that comply with base-level requirements?
6. Should certification require fees?  If so, should those fees take into account the size of the person/company behind the project, the commercial nature of the product, and/or the number of units sold?
7. What is an appropriate penalty for projects that fail to meet certification requirements?  Should the penalty process include an opportunity for those projects to correct the error before the penalty is imposed?
8. Should OSHWA maintain a public database of certification complaints and how those complaints were addressed?  If so, should the entire process be public or should there be a grace period for private resolution?
9. Should there be a distinction between mandatory requirements and simple best practices?  If so, should there be some way to indicate that a project also/only complied with best practices?
10. Is reaching out to companies outside of the current open source hardware community a goal worth pursuing?