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

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

Since the idea of OSHW is an extension of (F)OSS and gaining traction a fair bit later it might prove worthwhile to draw inspiration from what the community around (F)OSS is doing. And guess what: They don’t just pretend the problem isn’t there.

In the following it is assumed the certificate is and remains a form of self certification.

Regarding penalty: It seems certain that abuse of a registered trademark, that everyone may use under the condition of meeting specified terms, can be ordered not to continue and cover the cost of proceedings by a court of law.
It appears very likely that for the duration of time where this abuse took place the offender can be ordered to either reimburse the vague damage, pay punitive damages or a sum that is laid out in the conditions mentioned above. This could help finance the OSHW movement and provide an incentive for proponents to check users of the trademark for gross violation of the conditions.

It could even be part of said conditions that someone, after self certification, has the obligation to register the project. Failure to do so would already constitute a violation and be grounds for the penalty stated in the conditions which, in doubt, could be basis for financing the review process of the individual case.

I do not believe the average user or general public does (yet) care enough about OS to show any interest or reaction in or to a list of shame. Individuals with such preoccupation then again need less than a minute to sniff out all published documents and arrive at the conclusion that vital parts needed for reproducing the hardware are not provided. Such list could be very valuable regardless. Especially when dealing with openess first and foremost one would expect all information about proceedings of any kind to be documented and publicly available. This way members of the community and public could review cases and acquire understanding about the standard to which certification is held in practice and also check for consistency in treatment of cases.

The idea of having a form of any kind which users, who have a suspicion, can use to report projects for review would definately be valuable. This would naturally corellate popularity of a suspicious project with chances of review. It would also prevent tunnel vision of a few who would otherwise contribute leads.