9. Distinction between mandatory requirements and best practices

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 # 9, which reads: “Should there be a distinction between mandatory requirements and simple best practices? If so, should there be some way to indicate that a project also/only complied with best practices?” For other question forums, as well as a general comment forum, click [here].

I think once one uses terms such as “certification”, one is implying compliance with some specific requirements. There has to be a clear way to tell whether or not a project is correctly certified, particularly given the idea of self-certification, which forces third parties to be able to spot problematic self-certifications and raise concerns. One has to be able to tell, without subjective opinion, whether a project meets the criteria for certification or not. Therefore everything making up the certification must be ‘required’ and visibly delivered (or not).

Best practices are of course splendid and there’s nothing wrong with saying that a project followed them. If they are firmly defined and the project can clearly be seen to have followed them, then they are not really different from mandatory requirements when setting a certification standard. If they are loosely defined (eg “do your best to X”), or it is hard to tell whether or not a project followed them from the outside, then they may be written down as best practice to aspire to, but should not be used as elements of a certification scheme.

This does not preclude a certification standard that requires a mixture of ‘hard’ requirements (eg “X type files must be licensed under licence Foo”) and ‘soft’ requirements (eg “the project community must have the opportunity to review X before it is certified”). It just means the ‘soft’ requirements must be such that an external public evaluator can tell whether or not they were done.

A certification denotes compliance with a standard. Should best practices be met as well, perhaps the effort should be honored, but the focus of the certification should be on the minimum standards compliance.

I would start with a single clear process - open source hardware compliant yes/no.

Attempts to introduce gold, silver and bronze levels of open source hardware will only confuse things at this stage.

Maybe I’m misunderstanding the question but I don’t see how OSHWA could impose mandatory requirements on independent projects. The whole point of open source is that you don’t need to ask permission.

I think there should be a minimal open source standard and a maximal open source standard. The former would be something like a list of ways to be open source and if you’ve got one then nobody should waste time asking if you’re technically open source or not. The latter would be a list that’s so impressive if you meet everything on it then nobody should waste time asking if you could be more open source.

There should also be a much larger list of best practices.

Declaring the degree of 'open’ness of each layer of hardware using something like Nutrition label style should take care of this.

I think @makegeneve is right to say creating openess levels could make things confuse, but I don’t see another way to incentivate people to adopt the best practices.

Currently many projects are using the Open-Hardware gear logo but doesn’t release their design files. Since it is a self-certification, it is very difficult to change people actions.

My humble answer would be: “oh yes”, there should be a distinction between “requirements” and “best practices”.

But, has I explained in previous questions, there must also be a distinction between the “Openness Certification Definition” and the legal terms and conditions under which the hardware stuffs are published. That means, “Requirements of Openness Certification” should have absolutely no legal consequences.

Distinction should be made by level. Top level the best practices are mandatory, in other levels all best practices should be leading, hard requirements for all levels.