This post originally appeared on the OSHWA website.
Last weekend, during the Open Hardware Summit, OSHWA unveiled version 1 of the Open Source Hardware Certification. This certification was the result of a community discussion process that began back on June 2nd and continues to this day. Since the announcement there has been a great discussion about the certification, including onHackaday (including in the comments), in the comments for the original announcement, and on the Evil Mad Scientist blog. Those discussions have raised some concerns and shed light on some potential misunderstandings, and it seemed reasonable to begin to address both with a blog post.
First, OSHWA appreciates that the community takes this proposal seriously enough to discuss and debate it in the first place. It is called version 1 for a reason, and we pushed it forward knowing that it would inevitably evolve over time. That being said, we feel that the current proposal addresses many of the concerns that led to the start of this process in the first place.
What the Certification is Not
The OSHWA certification is not designed to place restrictions on the use of the term “open source hardware” or to restrict how people use the open source hardware open gear logo. Nothing in the proposal requires anyone to use the certification, or gives OSHWA the power to sanction a project that decides – for whatever reason – that the certification is not for them.
The certification is not designed to force everyone doing open source hardware into a single box, or to exert exclusive control over the world of open source hardware. Such a task would be impossible, and counter to the purpose of OSHWA.
What the Certification Attempts to Do
Instead, the certification process is designed to be an addition to the open source hardware landscape. It is being created to address a concern that has been raised a number of times by the community – easily the #1 request we get from the community and OSHWA members. In Windell Oskay’s post about the certification on Evil Mad Scientist, he accurately sums up the problem:
“But there is something [] rotten, deeply rotten, in the world of open source hardware. And that is that the label “open source hardware,” either in words or represented by the OSHW logo (the keyhole-gear thing above) has been misused so much that it can’t really be trusted.
If you put that label on a piece of hardware, we might expect that this hardware meets the open hardware definition. The definition specifies (amongst other things) that you should be able to obtain the original design files (the “source”), and use them without a “noncommercial use” restriction (the “open”). But it seems like every day I hear about some drone, robot, or development board that turns out to be OSHWINO —Open Source Hardware In Name Only.”
This problem has a number of causes, including some of the licensing challenges related to open source hardware. Regardless, the certification was the result of OSHWA trying to find a way to give both creators and users of a piece of hardware a degree of certainty that hardware that called itself open source hardware actually complied with a commonly understood definition of open source hardware. That is, while anyone can call themselves open source hardware, only hardware that actually complied with the rules set out by OSHWA could call itself OSHWA-certified open source hardware.
The Value of Certification
There is no intrinsic value in certification. For users, it only matters if they feel that a certification provides them with useful information about a piece of hardware they are considering spending time with. For producers, it only matters if they believe that people will look for the certification and care if they find it.
Neither of these results are inevitable. Fortunately, if it turns out that the certification is not useful to people, it dies a quiet death of neglect.
OSHWA believes that – properly executed – it will be useful. That is why we are spending the time to create it and present it to the community. But it may be that there really isn’t a demand for a way to know that open source hardware complies with a commonly held definition of openness. Or it may be that there is a demand for such a thing, but that this certification isn’t the right way to achieve it. In either case, OSHWA will go back to the drawing board to try again.
Enforcement
Some members of the community have raised concerns about the enforcement mechanism for noncompliance, specifically the fines. As was explained in the presentation at the Summit, the enforcement mechanism is an attempt to balance two competing concerns.
On one hand, there has to be a way to punish bad actors who use the certification without complying with it. That punishment must be significant enough to deter abuse. Escalating fines are a good way to do that.
On the other hand, we are in the early days of open source hardware and there are not well established ways to apply the definition and best practices to every situation. In light of that, it is critical that creators acting in good faith have plenty of opportunities to discuss their goals and work towards a resolution before penalties are applied. The earliest stages of enforcement are designed to create that space.
OSHWA believes that the enforcement process outlined in the certification balances those two concerns. When reading the certification, it is important to remember that no one has to use the certification and that OSHWA has neither the interest, power, nor authority to punish projects that simply describe themselves as open source hardware and/or use the open gear logo. The entire regime only applies to projects that decide to opt in to the certification process.
Where We Go Now
The first hard part was taking a proposal through a process of community feedback and discussion. The next hard part is developing the legal license that will make the system described in the certification document enforceable for projects that opt in.
The execution of this next part is important as the development of the specification itself. We are cognizant of that, and are doing our best to create licensing language that is clear, approachable, and accurate. Part of doing that means being as transparent as possible about the process, and open to community feedback. That is why we launched this idea with a call for community input, and why this blog post exists today.
If you have concerns about the proposal, let us know. You can use the comments below, contact us, or open a discussion in the forums. In the meantime, we’re going to focus on finalizing the certification process and not screwing it up.