<div>You're welcome. I think the most interesting part is Huang's implied endorsement of a working definition for "open" in a hardware context. </div>
<div> </div>
<div>"<em>I have only pushed one layer down of openness, namely, into the circuit card assembly design. It's the one and only piece that I personally have full control over and have the full freedom to choose to make open</em>."</div>

<div> </div>
<div>This, to me, is a great start at resolving the seemingly never-ending arguments over whether or not a hardware project is "open." As long as the developers have released all of THEIR work according to the open source hardware definition, then the project would be open. If the developer doesn't have control over it then it should be irrelevant to determining openness. </div>

<div> </div>
<div>Additionally, if it's not part of the hardware, it should also be irrelevant to the definition. Business processes are not addressed by the open source hardware definition. A developer would only have to release the hardware designs, not the way they manage logistics, for example. </div>

<div> </div>
<div>I'm not claiming that Huang said that, I just think his approach illustrates an ideal case of a functional resolution to the argument over what is/is-not open source hardware.</div>
<div> </div>
<div>Cheers all,</div>
<div>Matt<br><br></div>
<div class="gmail_quote">On Wed, Jan 15, 2014 at 8:33 AM, Pablo Kulbaba <span dir="ltr"><<a href="mailto:pablokulbaba@gmail.com" target="_blank">pablokulbaba@gmail.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">
<div bgcolor="#FFFFFF" text="#000000">Interesting. <br>Thanks for sharing, Matt. 
<div> </div></div></blockquote></div>