4. Self-certification or pre-approval process by OSHWA

#1

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 # 4, which reads: “Do you prefer a self-certification process or a process that involves pre-approval of certifications by OSHWA?” For other question forums, as well as a general comment forum, click [here].

#2

My vote is for self certification. I think the ‘Self-Certification’ describes it well. Most notably, allowing for easy and widespread adoption.

#3

This is a tricky question. Of course, if OSHWA has to evaluate every request for certification that would, we hope, take a great deal of effort due to many projects opening up in the future! Thinking about fees might well be needed.

However, the risk of self-certification is that some projects claim the certification without meeting the requirements, either through malice or ignorance, and if such a project attracted media attention it could significantly dilute or damage the OSHWA/open hardware brand and concept.

Depending on the community response on other questions it might be worth looking at a hybrid model. Let us assume a spectrum of certification is available. Lower tiers, say “bronze,” might be available for self-certification, but the ‘gold’ tier might require formal submission and evaluation by OSHWA. This top tier process may or may not require fees, and may require projects to supply a portfolio of supporting evidence (to cut down OSHWA effort!). Projects failing to submit appropriate documentation could have their applications rejected with minimal effort.

The pre-approval process which enables ‘gold standards’ to be maintained could also be something limited, say, to projects which were looking at serious scale (whether commercial or otherwise). This would mean small projects could still get self-certified to a high standard of open hardware-ness, but if they were deploying some larger number of units from a central source then the pre-approval extra-strong certification would be strongly recommended, as this would help such projects demonstrate their seriousness in the market/community. This would cut the risk of a large scale project maliciously self-certifying and then bringing the open hardware movement into disrepute, as any large scale project would be required to be formally checked if it wanted to use the certification.

For comparison, I would point at the work of the Open Definition Advisory Council. This group evaluate licences which wish to be considered as compliant with the Open Definition (and also are stewards of the Open Definition itself). Because licence proliferation is a bad thing, and licences are designed for reuse, this should be a finite job; there are not an ever-increasing list of new licences to evaluate and never will be. Openness can grow and thrive without more licences being approved, so the manual process is OK. It also adds value as there are subtleties around language and interpretation of both licences and Open Definition at times where discussion and consultation is very valuable. The Open Definition is carefully policed, therefore, with every licence being checked before approval, and as a ‘gold standard’ and a binary open-or-not, this is important for the future of open.

However, OSHWA faces a very different situation. We wish to see more open hardware, and therefore more products which are certified (if certification is chosen). The number of projects/products requiring certification is something we want to see grow. We also hope that compliance is something reasonably clear and not subject to debate about language or subjective argument. So a manual process of evaluation is not so good - except, perhaps, for a small subset of potential open hardware projects, where the effort required adds value (and ideally can be compensated in some way).

#4

My fear is that not letting companies self certify will have a chilling effect on adopting the open source hardware certification. I have a few small open source projects of my own and don’t want to go through the hassle of asking permission from the OSI to use their trademarked logo even though my software is fully free and open.

My belief is that the risk of bad actors self-certifying as being open source hardware is low. If through ignorance they’ve certified themselves as being open source hardware when they’re not, a gentle reminder to either remove the certification or comply with the open source hardware definitions will probably solve most cases. In the few cases where bad actors refuse to remove the certification but won’t comply with the open source hardware definition, litigation can be pursued. I imagine this to a be a rare and extreme case, only pursued when all other options have been explored.

I believe that it’s better to trust that most people who want to put the open source hardware certification on their projects are genuine about their intention to be open source hardware compliant. My bet is that giving the community the benefit of the doubt will go much further than bogging down certification with approval processes and fees attached.

I also think simpler is better. Having people differentiate between bronze, silver and gold seems like it will just dilute the idea. My feeling is that it’s better to have one certifications that will give a clear signal.

I would be for adding an additional level of certification on top of being open source hardware compliant. Something like ‘OSHWA approved’, maybe with the text ‘OSHWA’ and a check mark next to it. This could have fees attached as to get OSHWA approval as there would be a need to process and approve an application. I hope I’m not being pedantic but for the end consumer, the little sigil or small piece of text on a PCB is the thing they see. If the sigil or text on the PCB isn’t distinct enough, confusion follows.

#5

Simply put, yes. There should be a self eval and cert program, but it simply cannot be ascribed the same gravitas that an independent review and certification would have. Consider safety. If you bought a toaster that the manufacturer said was safe, would this guarantee be comparable to UL listing? Again with the spectrum.

#6

I think self-certification is the way to go. Otherwise it could became expensive for hobbyist and small companies to get approaved certification. In the other hand OSHWA needs to enforce some law and penalties for people/organization using the open-harware logo/certification without fulfill with its requirements.

#7

I vote for self-certification.

However, in the spirit of openness, we could create a certification process that is essentially a form that requires filling in with the link to the relevant documents. For example:

Parts List is Open and available at: example.com/myproduct/partslist
Schematic is Open and available at: example.com/myproduct/schematic
Schematic uses AAA software
PCB design is open, using BBB software and available at : example.com/myproduct/pcb

Essentially, the OSHWA guidelines as a fillable form with links to the documentation. With an extra level if an independent person/company has successfully built the piece of hardware.

In a few years, after we’ve seen the success of this process, we can open it up for independent certification bodies around the world to run the certification process, but for now let’s keep it simple and accessible for all.

#8

My concern about self-certification is that it’s no different from simply describing a project as open-source hardware. Why add an extra layer of formality in the form of a certification, if it doesn’t come with any additional assurances that a project actually open-sources what it claims to?

#9

@david, certification does come with extra assurances. If the offending party failed to comply with the definition of open source hardware but still claimed to be certified, they could open themselves up to litigation.

Self-certification allows for projects to describe themselves as open source without explicit consent while still retaining the ability to address bad actors who use the certification without being open source hardware.

#10

That’s exactly why I propose that the certificate itself includes links to the sources.

#11

I think for the most part the only sustainable path is self-certification (just look at the backlog at the patent office for an example of how pre-approval can get bogged down). And, I think as long as it is enforceable and enforced (similar to addressing “bad actors” mentioned by @abetusk) then I think self-certification will be more than sufficient.

The better question in my opinion is how would OSHWA enforce self-certifications and can we make sure that enforcement covers the range of scale that we currently see (and expect to see in the near future) in terms of OSHW developers?

#12

I think the minimally open source standard should be hosted by OSHWA and each project should self-certify against it.

The maximally open source standard should also be hosted by OSHWA and each project should also self-certify against that.

In the future, if there comes a day when there is any commercial value, or regulatory leniency, or an ability to get into the most happening night clubs, due to being third-party certified as open source…then we can worry about whether or not OSHWA should provide that approval. Today I think that’s just a solution looking for a problem and effort should be spent elsewhere.

#13

The current process is self-certification. Those that believe they can benefit from being called open source stick the name and logo on and everyone repeats it without checking.
There’s already a definition and a logo and a community and it doesn’t police itself and fact check, so why would we expect another self cert methodology to work?

#14

Individuals, groups & community - who make their works & creation open are the driving force for Open source hardware . Self Certification should be be the way for promoting open source. A certification process should be created & made available for following, like the best practises.

#15

Pre-approval process by OSHWA could be great, but only based on an automatic declarative process like is done with CCC choice of license, proposing a specific sentence or logo to place on/with the openness hardware, with the link with the OSHWA definition certification, and a “report certification abuse” link.

I’m afraid any non-declarative or non-automatic process will be impossible to run for OSHWA.

#16

Self-certification for all but top level.
Pre-approval for top level. (A fee may apply.)
My reasoning in this is that for most people is hard to know if all components are open source or open standard.