<div class="gmail_quote">
<div>Catarina,</div>
<div> </div>
<div>As you pointed out hardware itself can be open sourced. However, I think it's important to think of the actual hardware like compiled code. The literal hardware itself isn't open, but if you deliver the "uncompiled" design files along with it then the project is open source. The user could then "compile" their own version from the original or altered plans. </div>

<div> </div>
<div>Using that perspective as a starting point, it seems fair to call any project that provides useful design files "open." In software it's at least theoretically possible for someone to write new code to replace any closed component of a larger application, but that's not possible in hardware. There will always be a certain percentage of the project with design information that the user either isn't allowed to have (patent, trade secret, etc) or wouldn't be able to do anything with if they did have it (high capital investment, unsafe materials, etc).</div>

<div> </div>
<div>This is particularly evident when you factor in the wide variety of manufacturing steps that are as much a part of open hardware as the components themselves. If a cut has to be made then the tool that does the cutting is a prerequisite to capture the benefit of the design files. A drill is just as important as the bolt that will go through the hole, but a project should still be called "open" even if it doesn't include design files for the drill or the bolt themselves. Only the defintion of the hole itself needs to be opened.</div>

<div> </div>
<div>Therefore, I think it makes more sense for an open project to define all of the parts that are open, rather than the parts that are closed. Just let it be assumed that anything unmentioned is closed (or opening it is unnecessary). Taking this approach would negate the argument over whether or not a hardware project is "really" open. It will ALWAYS be a matter of degrees, so just let them get the open hardware badge if they provide design files and leave it up to them/the community how much of the project eventually has an associated design file.</div>

<div> </div>
<div>Obviously the mark should be controlled. Some standard of reasonableness has to be enforced, but I don't think it needs to rise much above common sense.</div>
<div> </div>
<div>For example, if they have claimed that they will release design files at some point (like when preordering is done) then they aren't actually open source yet. They can have the mark when they cough up the files. If their files are in a proprietary binary format that can only be read in an expensive application, then they aren't actually open source yet. They can have the mark when they export into a common format. Likewise, if they provided old version 1.0 design files a year ago, and haven't released anything since, then they don't get to put the mark on their new version 3.0 project until they release those files. Etc.</div>

<div> </div>
<div>Maybe a list of acceptably "open" formats could be maintained. Like Alibre files wouldn't qualify as open, but STEP files would. That way everyone would know where the cutoff is. </div>
<div> </div>
<div>I'm not sure if it makes sense to attempt to distinguish between different levels of openness. It would be really hard to avoid arbitrary cutoffs.</div>
<div> </div>
<div>Anywho, those are my thoughts for the moment,</div>
<div>Matt</div>
<div> </div>
<div>------------------------------<br><br>Message: 5<br>Date: Fri, 1 Mar 2013 16:05:34 -0500<br>From: Catarina Mota <<a href="mailto:catarina@openmaterials.org">catarina@openmaterials.org</a>><br>To: The Open Source Hardware Association Discussion List<br>
        <<a href="mailto:discuss@lists.oshwa.org">discuss@lists.oshwa.org</a>><br>Subject: Re: [Discuss] What should come of this discussion?<br>Message-ID:<br>        <CAH-asVb9ZjMUhTi8qrvT_Kyg2_=<a href="mailto:003HSTEgymnBhLQMu5oQBmg@mail.gmail.com">003HSTEgymnBhLQMu5oQBmg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br><br>As for changes, I'm a big fan of the great work you, Nathan and Phil did in<br>defining best practices for publishing files, but we must also consider<br>
that open source hardware can also apply to bicycles, cars, buildings,<br>washing machines, coat hangers, etc.<br><br>And can we work something in about clearly declaring closed source parts<br>(the designer's own as Marco defined them)? Or to not say that product X is<br>
open source if some of its parts (critical or not) are not?<br></div></div>