What are the minimum required files to comply with https://www.oshwa.org/definition/?
It is quite clear to me from that that Gerber files or a .pdf would not be sufficient.
But regarding the original design files. If the design is done with EAGLE for example, would it be okay to only release design.BRD but to not release design.sch?
My position is that it would not be okay but I would like to know what OSHWA has to say about this.
What is the consequence of only releasing the BRD and not the BRD and the sch?
And why would you be motivated to only release the BRD and not the sch as well?
The consequence of releasing only the BRD and not the SCH would be that the design could not easily be modified or even studied anymore.
And it is not about me, I am only trying to find out if such a behaviour is in violation of the open-source certificate or not.
If it is not I can stop asking for it.
If it is I can point out that the manufacturer in question should deliver it to comply with the certificate.
Alright, I understand. A really interesting question, I will try to help in answering it, however I am not a lawyer and was not part of the creation of the certification. Nevertheless, I believe the goal of the (self-)certification is that it should be possible also for non-lawyers to be able to answer these kind of questions.
Looking at: http://certificate.oshwa.org/
What I read is:
Create products that comply with the community written open source hardware definition hosted by OSHWA.
This definition is found here: https://www.oshwa.org/definition/
Which reads:
Open source hardware is hardware whose design is made publicly available so that anyone can study, modify, distribute, make, and sell the design or hardware based on that design. The hardware’s source, the design from which it is made, is available in the preferred format for making modifications to it.
The hardware must be released with documentation including design files, and must allow modification and distribution of the design files
(continuing quoting from http://certificate.oshwa.org/)
Ensure that all of the creator’s own contributions to an open source product using the certification mark are shared as open source in accordance with the agreement and these requirements.
Ensure all parts within the creator’s control are open source.
As noted above, in order to be certified under this program all parts, designs, code, and rights under the control of the creator must be made open according to the open source hardware definition hosted by OSHWA.
My conclusion from all this: if the .sch is the standard ‘source file’ of EAGLE and it is required to have that .sch file in order to study and modify the design and if publishing the .sch file is under the control of the creator of the design, then the .sch file should absolutely be included for the item to be regarded Open Source Hardware. And not doing so, would violate the OSHWA Certification.
What do you think?
Hi Rudolph. Let me try and shed a bit more light on how we try and answer this question. As noted already, the definition essentially requires documentation (including files) to be adequate to allow downstream users to use and build upon the hardware.
While that is an easy principle to state, it can be hard to apply in any specific situation. Adequacy can vary based on the type of hardware, the types of files involved, and the types of knock-on activity that users would want to engage in.
Since OSHWA knows that we will never have the in-house expertise to evaluate every situation ourselves, we rely on the community to help us work through issues.
For example, we have had community members raise concerns about various pieces of certified hardware. At the time of certification it appeared to the review team (which does not necessarily have expertise in a given area of hardware development) that there was adequate documentation and files for users. However, a community member with deeper expertise in the area raised the concern that the documentation and files were not actually adequate for the types of uses that should be possible under the definition.
In response to these concerns, we usually work with the community and the party responsible for the original certification to update the documentation. If the responsible party is able to update the documentation to meet the certification requirements, we consider the issue to be resolved. If the responsible party is not able to meet what appear to be reasonable requests from the community, we may revoke certification.
I’m sorry that does not give you a specific “we require X” type answer. I hope that it does give you a better understanding of the process, and even a sense of why there is not a single answer to that important question.
Hello,
I am wandering in a bit of a minefield here. 
I do not want to point them out and therefore risk them losing the certificate.
I am conviced that they want this to work and and that they are trying.
But so far they failed to met what I would consider open source alltogether.
At the same time they failed to demonstrate that they even understood the issue.
We are talking about a machine here that has electronics and mechanics.
And while I admit that mechancs are not my playfield I was surprised about the level of detail that has been provided.
For the electronics however only a fraction of information has been made available so far.
No circuit diagram has been produced to show how the whole thing is connected together.
No list of the electronic components used, no specifications, nothing.
And for the controller-board itself only the layout and a bill-of-material has been provided but for a revision of that board that is not even delivered with that machine and the BOM does not even list the names of the components.
And we know that at least one connector on that board has been replaced with a capacitor, yet this is not to be seen in the layout.
So yes, I could have the board produced and for the most part I could populate it with parts and with some effort may even get it right and it still might not be working as a replacement in this machine because of undisclosed changes to that board.
But it is not even about building this thing on your own. It is about repairability and the possibility to improve it, probably even to the benefit of the manufacturer.
And talking about studying that thing, you can not even really do that either without the schematics to this controller board.
I was hoping for a little help to point out to them that what they think is in compliance with the certificate is indeed not enough and that they need to do more to fullfill that comitment.
Or annother outcome would be that I am wrong and that is all I can expect to get in which case I just would stop to push it.
And making things more complicated I am not a native English speaker, well, I should have made that clear already without intending to.
But they are not as well.
In my opinion asking ‘what is the minimal disclosure a project can get away with without falling out of the scooe of certification’ is missing the point of the certification. The mindset is incompatible. The point is to provide the public with all documentation needed to produce the hardware, change the hardware and redistribute those documents while aiming to assist the public in doing so, meaning not only enabling to do so but also making it easy to do so. This especially includes not holding back documents that already exist and play a significant role in reachung the goals mentioned above. If adding the document to a release does not add more unnecessary noise than it does to reach those goals it should be added. The license must be permissive.
Depending on the projects nature such files can be, but are not limited to, schematics, layouts / boards, 3D / CAD models, BOMs, lists of known good sources of materials and instructions.
I hope my approach is of any use. To me the question is one of intention amd ethics, not legal definition. There is plethora of ‘open washed’ projects out there that are closed commercial projects, confusing users about the nature of open source and open hardware. This is detrimental to the perception of open *, especially the perception of value open * holds.
Yes, but that was not why I asked.
I am a customer that wanted to know what the minimum is that can be expected when something is advertised as OSHWA certified.
And my main concern was repairability.
But since then I have given up completely on OSHWA, I personally consider the certificates to be worthless.
I love the idea of Open Source and what I can release of my hardware and software projects, I do release with everything under MIT license.
When I pointed out a certificate in private mail in order to trigger a friendly nudge towards the manufacturer, not at all asking to revoke the certificate, I was met with incompetence on OSHWAs part and the refusal to even talk to the manufacturer.
To me it looks like OSHWA is more a self-certificate, you throw in a bunch of unrelated files and receive a certificate with only superficial checking, if at all.
I am done with OSHWA and this is my personal opinion.
And before you ask, I will not point out which certificates lead to this.
I did never mean to imply you were someone trying to paint a project that is not OSHW as such, my apologies if I came across that way.
I agree with your assessment, OSHWAs certificate is self certification.
I too find there is room for improvement. But in my opinion this is exactly why support of the idea and its discussion are important.