3. Certification of projects with non-open components

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 # 3, which reads: “Should it be possible for projects with non-open components to be certified as open source hardware? If so, how should the process handle such projects? Is a part-by-part label desirable because it gives specificity or undesirable because it complicates understanding the label for less technically sophisticated community members?” For other question forums, as well as a general comment forum, click [here].

This is another “spectrum” question. Where an open product uses a closed component, there should be a cert available, but not the top cert. In every open hardware device, some closed part is used. Often we confuse a simple, small, or ubiquitous bit with openness, and indeed we have to draw the line somewhere. Are the LEDs used on Arduinos open hardware? They need not be for the Arduino design to be considered fully open.

I think it should have some levels of openness: fully open hardware, mixed open hardware (open hardware with non-open components) and barely open hardware.

We all know that there are useful OSHW components that are missing important parts of the technical documentation. The most obvious offenders are GPUs that require a non-open “binary blob” and FPGAs that do not document the bitstream format, requiring FPGA designers to use the vendor’s tools. On Thread 2 I’ve suggested two levels of certification: “mostly open” which allows such components and “fully open” which does not. See my comment there for more detail.

@aharper noted this issue could be referred back to the “spectrum vs single certification” question. In my reply to that question I noted how the question of the inclusion of non-open/close/proprietary elements in the design was one dimension of openness with the units denoting at what level of the design the system was open (down to the atom … up to the integration of commercial systems into a system of systems). In looking over the comments in this thread, I think I see an additional unit of measure: the degree to which a non-open element is available.

Consider the LEDs @aharper mentions from the Arduino. LEDs are a very commonly available component with well defined specifications. Any vendor’s compatible LEDs could be reasonably substituted for the parts specified by the Ardunino team. Compare this to a component that is only available from a single vendor and for which there is no easy substitution (or where the substitution is non-trivial). I would argue the former example, while still not completely open (after all, it is not like everyone making an Arduino from scratch is going to be expected to construct their own LEDs), is more open than the latter example.

I would further propose that it is worth discussing if and how to note this relative openness and when it matters. I think it will clarify one of the places where the current definition (and community norms) is a little bit muddy, in particular how the availability of key components of OSHW projects ties those projects to the continued support of suppliers.

There will be a lot of exceptions that keep a project from reaching maximum open source. Not all of them will be under the developer’s control and not all of what’s under their control will be practical.

For example, a project could have a legitimate open source license but be confined to American citizens by export control laws. I think that qualifies as open source in the minimal sense. Another example is that a project might have an open source license, and no restrictions, but require exotic materials or absurdly expensive processes. I think that also qualifies as open source in the minimal sense.

So if a project is open source, but some of the components it depends on carry restrictions that are outside of the developer’s control, I think that still counts as minimally open source.

It’s important to keep in mind that we really don’t want to say that every single thing the end result depends on has to be accessible enough for an under-skilled and under-capitalized person to control. The only projects that would qualify would be based on sharp sticks. A big part of open source is pushing technology forward and that requires depending on infrastructure and partnerships we can’t control. Who cares if a great chip is closed source? The design that uses it will be old news in two years anyway.

Perhaps the key is to certify two things: the design and the object.

To be a certified open source design, one must follow the best practices and fully document the project. This sounds fairly trivial, but it is much more difficult than it sounds. while open source software permits a lot of inline documentation (commenting the code for example), any documentation effort of open hardware breaks the workflow of actually making the thing. This effort should be honored with the basic certification, and could be accomplished with a self cert and basic review / critique by OSHWA. This review will help the certification mean something, and the critique will help to improve both the documentation and the skills of the maker(s) involved in the project.

An open source object (hardware) certification will be much harder to achieve by definition. It would require the design to be certified as an open design, the software to be open source, and the components / subsystems to be either open as well, or ubiquitous to the point of vendor neutrality. This becomes problematic when it comes to processors, and highlights the need / opportunity for an open hardware CPU.

Yes, Projects with Non-open components should qualify for open source hardware certification ( We all know Almost all open electronics projects belong to this category!, atleast currently.)

As posted on question 2. Hardware an be seen as made of layers- idea, process or design or object, etc ( schematic, PCB, casing, BoM, CAD file, melting process, etc). Nutrition Label style approach should help address the non-open /open components. in some cases it can be part by part as well.

My answer would be: “Yes” but with a certain wording concerning the sentence which will claim the certification of openness.

Like this ? : “Permissive Openness Hardware - is made with almost one openness component, but also with possible non openness component”

The notion of non-hardware parts (software, raw material, services, vegetal plants, life material, non-atom particles, …) should also be cleared.

Yes, but with the restriction of qualifying for the top level certification only open source and open standard components are used. See my comment on question 2.