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 on Hackaday (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.
Look to other standard for guidance. Legally there is no footing for gobbling up a concept. You can’t cleanup something that can’t be owned.
USB is a standard, there are rules and regulations that must be met to get the USB stamp. If you do not confirm, you cannot use the trademark. But you can make USB devices that do not confirm. The biggest example is 15′ USB extension cables. They do not conform, they do not have the trade mark.
You need to have something that you own (and the concept of open-source is not property) that you can leverage legally as part of your penalties. Today you have no legal standing. You cannot say that nc is not open-source in a legal sense as it is not your property to define.
You can however make a trademark, define a standard and fine people for miss using your trademark.
I ask all for a standard for open source, but do it within your rights, and within the scope of the law.
That’s exactly what we intend to do. The open source hardware certification mark will be a registered mark that you can license from OSHWA on the condition that you comply with the terms of the license.
I’ve read Windell’s blog, the hackaday post and comments, this response etc and was at the OSHWA summit when the certification was announced. It took me a while to realize that a) The certification logo is different than the standard hardware logo, and this has not been created yet. b) It is introducing a “self-certifying” step that could potentially result in being fined if you silk screen a logo onto your product. Although this fine is likely to not be enforced – its bad energy for a mostly aspirational community which is essentially an umbrella for a spectrum of hardware developers: from purists to folks that simply publish their files to create community.
Since the whole goal of introducing the certification process is reducing “in name only” openwashing – the solution that appeals to me is a hybrid of the current proposal and Windell’s suggestion to have a website that rates how well a board meets the OSH definition. So after thinking about it for a while – what if something like the Common Parts Library that is gaining traction had an additional field for OSH rating. In order to get the “bonus” field on your product listing you would fill out a form with questions that correspond the the “musts” and “mays”. Then at least 2 volunteers in OSHWA would “verify” the answers are true before that rating is posted. Instead of “certified” which sounds a bit bureaucratic for an aspirational community, “verified” serves as an indication to skeptical developers who are not sure if they will truly be able to make a derivative of your product – or at least learn from it. (which is all I do most of the time).
Hi Seth. I like that idea, and I don’t think that it is necessarily incompatible with the certification (or “verification”) that we’re looking at. If the Common Parts Library is interested in implementing something like that I’d be more than interested in taking to them about it. I do worry that it does end up in a similar place. Can you advertise your part as OSHWA verified in places that are not the Common Parts Library? If so, how is that type of advertisement controlled? The most logical way (at least to me) would be to have some sort of registered “verified by OWSHWA” mark, which kind of gets you back to the same place.