7. Penalty for failure to meet certification requirements


The Open Source Hardware Association is taking input on the proposal for an open hardware certification in this forum. This thread is devoted to question # 7, which reads: “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?” For other question forums, as well as a general comment forum, click [here].


I think the question is a little unclear. I assume we mean “if someone is claiming to be certified, but is not” (but it could be interpreted as “if a project applies for certification and we put effort into this but then they fail”!)

The challenge here is that it is unlikely there would be much legal basis for imposing a financial or formal penalty (unless we set out to create one). Without a legal basis, only ‘well behaving’ projects would pay any penalty (and of course such projects would likely not be failing to meet the criteria, or would fix any issues if they were told about them). “malicious” projects simply would not pay (and even if they stopped using the certification, would probably already have benefitted). To achieve the goals of the certification project, greater understanding and engagement of open hardware, such malicious projects need to be firmly discouraged.

A legal basis for imposing a penalty could be something like having the certification logo and name trademarked, at which point OSHWA could use trademark law as the basis of a legal complaint against a project using the logo/name inappropriately.

Such a legal basis would also be necessary were OSHWA to wish to be able to demand that a product cease using the logo.

A “list of shame” could be effective if OSHWA was sufficiently well known that consumers would avoid companies that OSHWA disrecommended, and of course that consumers, or review sites or media drew attention to a company or project being on the list of shame. Such a list would need some curation as projects were added and removed etc. Of course, some projects would find being on such a list, and discussed in the usual open/FOSS/etc forums would be a bad thing and they would avoid this; but larger projects seeking to profit off the ‘open hardware’ concept in more mainstream markets would likely not (and the sales they would lose would probably be very small).


If a project which has been self certified fails to meet the standard, to maintain the integrity of the OSHWA brand the certification and all marks must be removed from the project and its documentation.

Should a project change in a way that invalidates an independent review and certification, again, to maintain the integrity of the OSHWA brand the certification and all marks must be removed from the project and its documentation.

It can get ugly if someone refuses, which means that lawyers and legal fees will factor into these certification fees. Not where we really want to be, but it may be a necessary evil.


Publication of a list of shame, with a page per project would do. If we adopt a simple self-certification process, we can also clearly state on this page what the company would need to do to be compliant again, upon which we would remove them, from the list of shame, and add them to a list of good guys.


I’m having a hard time imagining how a penalty would even work.

I could see how publication of the best open source projects would work. I can also see how publication of misunderstandings would work because those developers would self-correct. But I can’t imagine how a developer who’s not intrinsically motivated would ever respond to a “penalty” imposed by OSHWA.


A better way could be to have a online forum, where people can challenge on credibility of “Openness” a open source hardware projects. Allow anonymity.

This will filter & bring up cases which may really be worth reviewing.


If a “certification abuse” process is clearly proposed by OSHWA and clearly included inside the sentence/logo certification shown by the opensource hardware, then it will be possible to organize a “certification abuse” process with steps and repository of list “certification abuse” projects.

But … that will cost to run … The question is linked with “financial resources of OSHWA”.


Public warning.
Blacklist item(s).
Exclusion of registering new items.
Fine in the form of an percentage of the profit of the item(s). If the profit can’t be determent, a percentage of total sells of the item(s).