<div dir="ltr"><div class="gmail_default"><br></div><div class="gmail_default" style><span style="color:rgb(51,102,102);font-family:verdana,sans-serif">Very thought provoking...there are a lot of questions that need addressed. </span><br>
</div><div class="gmail_default" style><font color="#336666" face="verdana, sans-serif"><br></font></div><div class="gmail_default" style><font color="#336666" face="verdana, sans-serif">Even though in all three examples the part which provides the primary functionality of the device is not open, I would lean toward saying there is no need for differentiation of openness in these cases (where the primary functionality is provided by a non-open component). I am thinking these components are </font><span style="color:rgb(51,102,102);font-family:verdana,sans-serif"> covered by line 11 of the OSHW Definition:</span></div>
<div class="gmail_default" style><font face="verdana, sans-serif"><div class="gmail_default" style="color:rgb(51,102,102)"><br></div><div class="gmail_default"><font color="#6aa84f">11. License Must Not Restrict Other Hardware or Software</font></div>
<div class="gmail_default"><font color="#6aa84f">The license must not place restrictions on other items that are aggregated with the licensed work but not derivative of it. <i>For example, the license must not insist that all other hardware sold with the licensed item be open source, nor that only open source software be used external to the device</i>.</font></div>
<div class="gmail_default" style="color:rgb(51,102,102)"><br></div><div class="gmail_default"><font color="#336666">...but I may be misinterpreting the intent of this criteria.</font></div><div class="gmail_default" style="color:rgb(51,102,102)">
<br></div><div class="gmail_default" style="color:rgb(51,102,102)"><br></div><div class="gmail_default" style="color:rgb(51,102,102)">-Michael</div></font></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Feb 28, 2013 at 7:16 AM, Tom Igoe <span dir="ltr"><<a href="mailto:tom.igoe@gmail.com" target="_blank">tom.igoe@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div class="im"><br><div><div>On Feb 27, 2013, at 12:41 PM, Michael Shiloh wrote:</div><br><blockquote type="cite"><span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium">1) The overall guideline might be "can someone reproduce this project to a reasonable degree (e.g. functionally the same, if perhaps the case is not identical) with the information provided?</span></blockquote>
</div><br><div><br></div></div><div>So, let's pick a few specific examples, all of which think highly of, and use myself (admitted bias on the third). But I struggle with defining them as entirely open:</div><div><br>
</div><div><a href="https://www.sparkfun.com/products/11378" target="_blank">https://www.sparkfun.com/products/11378</a></div><div><br></div><div>The major piece of hardware on this board is a proprietary module from Roving Networks. Though SparkFun's support schematic is clearly open, the module that makes this functional is not, nor is it reprogrammable. The API for it is open, though. Is this OSHW? What's the replacement part that could drop into this board and make it work, with minor modifications?</div>
<div><br></div><div><a href="http://adafruit.com/products/746" target="_blank">http://adafruit.com/products/746</a></div><div><br></div><div>Similarly, the major piece of hardware (the GPS radio) is proprietary, even though Adafruit's support schematic is clearly open. What's the drop in part (note: Adafruit hasn't put the OSHWA logo on here, so it's possible they don't claim this is open)</div>
<div><br></div><div><a href="http://arduino.cc/en/Main/ArduinoWiFiShield" target="_blank">http://arduino.cc/en/Main/ArduinoWiFiShield</a></div><div><br></div><div>The WiFi radio on this board is proprietary, even though the support processor and its firmware and board schematics are open. This is perhaps a more complex board than the other two, but I'm not sure that complexity changes things much. Or does it?</div>
<div><br></div><div><br></div><div>Contrast those three with this:</div><div><br></div><div><a href="http://logos-electro.com/zigduino/" target="_blank">http://logos-electro.com/zigduino/</a></div><div><br></div><div>This is perhaps closer to the definition than the others, in that the firmware for the radio module *is* open. </div>
<div><br></div><div>My question is: do we need to differentiate between these in terms of their openness,or not? There are plenty of other examples I could pull. I know my work would suffer if I decided not to use these parts, they're all staples in my work. And I'm not an open source hardware absolutist, I use plenty of proprietary hardware. But I'm genuinely not sure where the line is with some of the products we make and use every day.</div>
<span class="HOEnZb"><font color="#888888"><div><br></div><div>t.</div><div><br></div><div><br></div><div><br></div></font></span></div><br>_______________________________________________<br>
discuss mailing list<br>
<a href="mailto:discuss@lists.oshwa.org">discuss@lists.oshwa.org</a><br>
<a href="http://lists.oshwa.org/listinfo/discuss" target="_blank">http://lists.oshwa.org/listinfo/discuss</a><br>
<br></blockquote></div><br></div>