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:
1) 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.
2) 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