[Discuss] discuss Digest, Vol 9, Issue 15

Thu Feb 28 17:23:25 UTC 2013

 David,

It looks like the problem is that y'all are trying to depend on WHERE the
logo is physically drawn for information regarding WHAT it refers to. That
seems like an inappropriate hold-over from licenses inserted into open/free
code. As you guys have all pointed out, where it is convenient and/or
possible to place the logo can have very little to do with which thing(s)
you are trying to give the consumer information about.

It made perfect sense back when the entire thing was a text file, but it
makes no sense now that the "thing" might include elements as diverse as
text files, binary files, PCBs, chips, adaptors, and parts made out of any
arbitrary substance (aluminum, steel, wood, etc) of any arbitrary size
(macro, micro, nano, etc). Then you have to consider that "placing" the
logo is actually a step in the manufacturing process, which may or may not
make sense in the context of that particular project because it might
require more time/money.

Hardware definitions quickly become significantly more ambiguous than
software definitions. It is possible to clearly define each and every
detail, but it is not possible to do that merely with the location and/or
color of a logo.

The way I see it, sticking the logo on something can only convey one or two
very simple pieces of information. For example, the logo could mean that
the thing it's physically on is open. It might also mean that something
inside of the thing it's on is open. If you put an arrow on it then maybe
it could indicate that something adjacent is open.

Only extremely simple hardware projects can get away with little-to-no
documentation. Any project of useful complexity is going to have some sort
of document associated with it, and that's the appropriate place to go into
detail on what is open, and how open it is, and stuff like that. The mark
should just indicate that the project has an open component. Or, perhaps
have two marks. One indicates that something about the project is open, so
check the documentation, while the other indicates that the specific thing
the mark is affixed to is open.

Then, of course, there's the question of what "open" means. The more detail
you want to put into the mark the more complicated it will get and the
harder it will be to render in the substance of the project.

Good discussion, Cheers.
Matt

> ------------------------------
>
> Message: 4
> Date: Thu, 28 Feb 2013 11:09:02 -0500
> From: "David A. Mellis" <dam at mellis.org>
> To: The Open Source Hardware Association Discussion List
>         <discuss at lists.oshwa.org>
> Subject: Re: [Discuss] OSHW Best Practices / Layers of Openness
> Message-ID:
>         <CAMmMv3d_rw0EmUfzMAbmnZCrEga=
> t9-aFgvtkeX+4CO2qYQ9Hw at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> These are interesting examples, Tom, but again I think they mostly point
> out the need to be specific about what part of a product you're calling
> open-source. For example, here I think it's clear that the PCBs for the
> SparkFun and Arduino products (I couldn't find files for the Adafruit one)
> are themselves open-source even if the components they use are not. I think
> we're much better off being specific about what's open and what's not
> rather than trying to set standards for, say, the relative complexity of
> the board vs. the components required for the overall product to be
> considered open-source -- especially given that basically every product
> uses proprietary components (whether ICs or radio modules or just screws).
> The latter approach seems like a potentially endless conversation. Again,
> look at Linux distributions, where people are still arguing about what
> level of proprietary software and binary blobs are appropriate to include.
>
> Also, my point about using the logo on an enclosure vs. on the PCB inside
> it wasn't meant as a comment on the relative importance of those two parts
> but of the semantic interpretation of placing the logo in those places. If
> I opened up a product and saw the OSHW logo on some part inside it, I
> wouldn't interpret it to apply to things around it. But if I saw the logo
> on the outside of a product, it's not clear whether or not it's intended to
> apply to the insides as well, making its use there confusing if the
> outsides are open-source but the insides aren't.
>
> As an example in the other direction (of electrical vs. mechanical) would
> be someone that uses a standard servo or DC motor and builds a complex
> mechanical assemblage around it. If they open-sourced, say, the CAD files
> they used to design the laser-cut parts that make up the assembly, I'd
> consider it reasonable for them to use the open-source hardware logo on
> their packaging or website, even if the motor were proprietary (since it
> would be just one component of the larger, open-source design). But again,
> these situations can be confusing and its important to be explicit about
> what's open-source and what's not.
>
>
> On Thu, Feb 28, 2013 at 7:16 AM, Tom Igoe <tom.igoe at gmail.com> wrote:
>
> >
> > On Feb 27, 2013, at 12:41 PM, Michael Shiloh wrote:
> >
> > 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?
> >
> >
> >
> > 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:
> >
> > https://www.sparkfun.com/products/11378
> >
> > 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?
> >
> > http://adafruit.com/products/746
> >
> > 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)
> >
> > http://arduino.cc/en/Main/ArduinoWiFiShield
> >
> > 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?
> >
> >
> > Contrast those three with this:
> >
> > http://logos-electro.com/zigduino/
> >
> > This is perhaps closer to the definition than the others, in that the
> > firmware for the radio module *is* open.
> >
> > 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.
> >
> > t.
> >
> >
> >
> >
> > _______________________________________________
> > discuss mailing list
> > discuss at lists.oshwa.org
> > http://lists.oshwa.org/listinfo/discuss
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.oshwa.org/pipermail/discuss/attachments/20130228/62055ca5/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> discuss mailing list
> discuss at lists.oshwa.org
> http://lists.oshwa.org/listinfo/discuss
>
>
> End of discuss Digest, Vol 9, Issue 15
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.oshwa.org/pipermail/discuss/attachments/20130228/715478af/attachment.html>