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 # 1, which reads: “Is certification something that OSHWA should be looking into all?” For other question forums, as well as a general comment forum, click [here].
My vote is yes, this is certainly something the OSHWA should be looking into.
The main goal is to provide a clear indicator of what constitues open source hardware or not. Having an organization lead the way on certification gives consumers and businesses clear goals to adhere to.
This is maybe mentioned in other forums but there have been many ‘bad actors’ claiming to be open source hardware but not actually being so. I think there are a few companies that have fallen into this category but the most common offenders that I’ve seen are projects under Kickstarter that garner community support by claiming to be open source hardware but not adhering to the open source hardware guidelines (as in, not releasing their schematics or source).
Often times this might be in good faith in that they promise to release their schematics and source when the project is funded. Certification would help in this effort by encouraging good behavior.
Yes. There simply isn’t much point of a national association if there is no standard. There is no point to a standard unless there is a way to verify compliance.
In my opinion, yes. There have been a number of projects/products that have claimed to be open source hardware, but inspection showed they weren’t. This gaming of the system has been enough of a problem that folks have repeatedly written about it. Here are a few examples.
I have long held that OSHWA should be the organization to address this issue. They have the necessary clout in the community and they developed the definition and best practices. I think this puts OSHWA in the best position to create a fair and sustainable certification process.
I certainly think that there should be a way of certifying that a project is actually open source hardware. However, at this stage in the open source hardware story, hardly anyone in the world has even heard of open source hardware, and if we make it too hard for people to get involved, it won’t happen at all. After all, I keep seeing supposedly open source hardware projects CC-licensed, which, as we know, doesn’t work for hardware.
Yes, Absolutely. Open source hardware progressing towards certification process is great step forward. This will help in promoting & adoption of open source hardware in a more professional way. The aspect of having various degrees of 'open’ness & accordingly types of certification is the way to go.
An important aspect is these certifications could vary geographically worldwide. in regions where even the term ‘open source hardware’ needs awareness, We need to allow time for promoting the concept & then have certifications. Else, there is a possibility certification formalities may act as a sort of indirect barrier to promote open source hardware adoption.
Yeah, it’s a question that keeps coming up. OSHWA should try to settle the question at least for a little while.
No. It is antithetical to everything the open source and maker initiative is about. First you vote to create a certification, then you you will need a way to enforce said certification, then you create legal frameworks and pretty soon people will just careless and everything crumbles. This smacks of an organization that is either power hungry or looking to create a lucrative funding source for themselves.
Be happy and proud to simply be a marketplace for discussion and trust that a fair and open market will take care of all issues that you think certification will solve.
The open source and maker initiative are about promoting freedom, openness and transparency. Providing a certification helps consumers and other people of the community know when a product upholds those ideals. Allowing for enforcement of the certification provides a strong disincentive to bad actors that claim to be open source hardware but aren’t.
Nothing about the OSHWA strikes me as corrupt, power hungry or overly litigious. From my perspective, the members of the OSHWA are trying to make a genuine effort to represent the will of the community, be transparent in their operation and promote open source hardware. There is a much larger risk of bad actors cashing in on the good will of the community by claiming to be open source hardware but not actually being so. This is happening right now (as of this writing) on a at least one KickStarter campaign and happens with fair regularity.
Enabling organizations, like the OSHWA, to hold companies accountable to the claims they make is part of making a fair and open market.
Wait, we want to promote “freedom and openness” yet we we want to add regulations and certifications. Seems pretty backwards to me.
I never said that OSHWA is corrupt in the slightest, in fact I like the work they’ve done in educating people up to this point. But I am telling you as someone with a licensed professional engineering background that once you go do the road of “certifications” it becomes a money grab more than trying to promote better behavior and best practices. Just take a look at the metric crap ton of IT certifications and other quasi-engineering certification (LEED, CEM) that have popped up over the years. They have done absolutely zilcho to actually provide better quality to customers, they simply exist to feed themselves. The point is, you may start off with the best of intentions, but eventually a bureaucracy becomes self-sustaining even after it’s outlived it’s usefulness. And in this case, I question the usefulness at the outset. Consumers barely understand the difference between iOS and Android, look at the debacle with Microsoft and their Windows 8 versus Windows 8 RT problems. Open Source Hardware is way more obscure and unfortunately the average consumer just doesn’t care. Those in the maker and professionals space,s people who do care, are smart enough to know the difference. My point is the community of people that is actually interested enough to know the difference between OSHW and non-OSHW is smart enough to know the difference and we don’t need a nanny state-style certification to do this. Lastly, and perhaps most critically let’s say you do create a certification. What mechanism do you use to enforce it? Do you really want the governments of the world to regulate this industry that has become the cradle for innovation and STEAM education? Seems to me it will kill OSHW vice save it.
In my opinion, and as the founder of an open source hardware startup, I’m leaning towards no certification. Usually, we have to certify things that we (the public) can’t easily check ourselves – FSC, organic, fair trade, RoHS, LEED, etc.) However, open source is something we can easily check – are the drawings and designs accessible to anyone with no restrictions on copying and reuse? I think a certification, at this stage, is unnecessary, and could hurt the growth of the OSHWA, especially if fees are involved or there is a threat of penalties – if there was any sort of financial risk, I’m fairly certain I would opt-out. I’m not labeling my products as open source as a way to justify higher costs or get more sales – I do it because I think the concept of open source hardware is important for promoting STEAM education. I’ll still make my designs available and offer educational opportunities showing people how to design and build properly. Regulations/certifications tend to hurt us small businesses and can be really discouraging as one more thing to do or pay for. Also, as another poster noted, I don’t think public knowledge of OSHW is widespread enough to justify any formal certifications at this point in time.
Perhaps, as an alternative to certification, an extremely simple guide or set of instructions can be put on the OSHWA site which easily walks the general public through how to confirm a project is truly open source (essentially making the public the certifiers – I think we’re at a point where, if we care about it, we won’t mind verifying it ourselves).
Maybe in the future certification will be something to revisit, but at this time, I think the cons outweigh the pros.
Certification doesn’t need to be unwieldy or coercive. I’m picturing it as basically just a formal subset of best practices. This seems like an appropriate stage in the development of the OSHW community to develop more mature standards.
Thinking of it: yes.
Trying to define it: yes
Running it daily for all comers: waoh ! how will we do it ?
So yes, that could be a could idea, very helpful to get better quality of deliveries, but until we found a way to make it applicable.
Yes, OSHWA should be looking into certification. In fact, you already are. It is like asking “Should I get wet?” after jumping into the pool 
But that aside.
I agree with all the points made before that are FOR certification.
I do not agree with some pints made before that are AGAINST certification:
What comes to mind as a possible way to go is an FSF RYF-kind of certification. I would love to see way more products certified RYF and would also love to have a type that says something about freedom of the hardware, not just the software on top of the hardware. That is where OSHWA with its certification would fit in, from my perspective.
To be fair, the question “should OSHWA make an OSHW certification” is not a settled question. That’s what this discussion is about. It might not be worth the trouble.
If you want an OSHW certification to serve as a one-minute guarantee of the open-source-ness of a project then you’re definitely looking for something restrictive like the RYF cert.
I don’t think that an open source certification is going to serve the same purpose as a free software certification. The FSF is motivated by purity of a clear moral standard. The RYF cert literally forbids a seller from using badge that says “works with windows” because it lends legitimacy to windows and also stipulates that the seller has to reference “free software” more often than they reference “open source.” They want to prevent as many projects as possible from being able to qualify so that the RYF cert means the project is absolutely perfect, up to and including the assertion that if free software for a secondary processor ever becomes available in the future, and the seller doesn’t build a fix or a whole new version to allow access to that secondary processor, the FSF will revoke the RYF cert.
Open source split off from free software specifically because it focuses on maximum usefulness rather than maximum freedom. It would be inappropriate and counterproductive for an open source cert to be exclusionary. Particularly when hardware is so much more complicated than software and when OSHW is so much younger.
Besides, a big part of the reason anybody would ever want a RYF cert is that the FSF has a globally recognized brand. OSHWA is basically unknown.
I’m very enthusiastic about the CERTIFICATION DISCUSSION here … it is important, no matter the eventual resolution. I would note though, that my concerns similar to others here, with respect to the deterioration that might occur from too heavy-handed a certification bureaucracy, were very much reduced by the current draft statement, its tone, and its conceptualization of how certification might evolve. I found it very thoughtful and inclusive.
While not responding to each question below, these do seem topics worth pondering and warranting some consensus – many helpful comments and thoughts have already been posted. There are many matters that represent gray areas for which there is no perfect stance, and for which input, experience, and experimentation may be the best approach. But getting conversation going seems highly constructive.
I particularly like the draft’s stance on self-certification. I can easily imagine a check list that allows the producer of a piece to OSH to complete a questionnaire that will allow anyone to see how the hardware in question complies or does not comply with important OSH tests and allows the designer/producer to respond with the compliance details and rationale for deviations. Such information would be pretty straightforward for users/observers to validate and would allow anyone with any interest in the item to understand the producers position.
There are two issues of particular concern to me:
With respect to the matter of different categories of certification; care needs to be taken in with any scaling of level or degree of “openness”. Not that the notion does not have some applicability, but there remain aspects of open licensing around which there are reasonable differences of opinion that would not make for appropriate litmus tests. For example, from my own perspective, “permissive” licenses are more open and less coercive than “copyleft” licenses. But, I appreciate that others do not necessarily see it that way. It would seem to me to be a mistake to consider one or the other of these approaches as higher or lower on a certification scale.
The question of whether an “open” piece of hardware may contain non-open components – as noted by others here – creates a lot of awkwardness because most any project is going to contain proprietary components. Any sort of list of how much in a project is or is not open is likely to be problematic to assess and characterize. I’m wondering if there is not some sort of way to take into account the breadth of a hardware design, considering what is under the purview of the designer/producer – that is, the unique stuff that is being served up in the offering. If what the designer/producer is contributing by way of design and innovation in the offering is fully open (ie. designer’s hardware plans, manufacturing info, and access all levels of software representative of the unique contribution) no matter what proprietary parts might be specified in the BOM, then that seems to me a strong case for “open hardware”. One should be able to make the thing from the available information. If, what the designer can share in a collaborative way is not fully shared (e.g. not providing low-level firmware that has been created for the offering and is part of it uniqueness), then it would seem to me the case is only for qualified openness. As an example from the software world, there can be a fully open apps, that run in Windows; there can also be entirely-closed, proprietary apps, that run in linux. Of course, we want to believe that starting with linux is a better way to go – as starting with fully open hardware components might be a better way to go for OSH – but for me, the questions of the handling of components that are central to the purview of the design seem the crux of the matter.
For any who might be interested in the approach we have taken in handling OSH and the licensing of Handibot, please see recent post: https://handibot.com/panaka-license.php
Ted Hall, Handibot/ShopBot
tedhall, I think this “…If what the designer/producer is contributing by way of design and innovation in the offering is fully open…” is the key. The most important factor is to only consider the things the designer has control over. The second most important factor is to consider what rights the designer gave away.
There’s nothing we can do about the laws of physics. Some stuff just requires a high degree of knowledge and skill that have to be earned instead of merely documented. Some stuff just requires exotic materials or complicated processing. We can encourage best practices that emphasize easy to replicate designs, but that’s it.
There’s not much we can do about good but not-open work. Everyone has the right to their own work and if they want to lock it down that’s their thing. We can try to influence them, but that won’t always work.
What Open Source Hardware hinges on is the work that OSHW developers add to the world and the restrictions they put on other people’s right to use that work. If you give away your work, and the rights to it, then you’re doing open source development.
Or, in a more general community sense, if you treat the rest of the world like everyone is on your team, then you’re living the spirit of open source development. As long as we have that the rest of the details will work themselves out.
Yes, because there are less IP rights to safeguard a OSS license style model.