[Discuss] discuss Digest, Vol 10, Issue 6

[gabriella levine]

Hey  -

Matt, and some others have pointed out something along these lines:

"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.
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."

But I have some questions about that that I am currently grappling with :
If I run a company and we are total proponents of releasing full
documentation of CAD designs, hardware (PCB, schematic layout, hardware
stacks), software, etc, and I am early in my stage of manufacturing and
distribution, and therefore haven't documented everything yet but plan to
do so no later than the release date of the product to the market, can't I
still say I run an open source hardware company? or is it more correct to
say "I am a proponent of open source hardware"?
If I want to spread open source hardware and want to see my technology in
the hands of many people, then could I use the open source hardware logo on
my designs? Even if I haven't yet released all my documentation online, but
plan to do it no later than the product is in the market? And Can I have
pre-sales going if my documentation is not yet published, but call myself
open hardware company?

It sounds like you are saying no, I cannot then use the mark (the logo) on
my designs (ie my website or my PCB or my mechanism), if I haven't yet
released the design files or documentation?

This confuses me because if the company is totally a proponent of
documentation, adhering with some sort of standard of open source
documentation practices, but has not done so yet, it cannot think about
using the logo on its designs?

On phrasing :
I also thought it might make sense for a company to not release files
before the date of sales of the product, but is this therefore
contradictory to my stating "my company is an open source hardware company"
if I am still in manufacturing phase? ... is it better therefore to say "my
company is a proponent of open source hardware and will release all the
design files and documentation on the day the product goes to market". ANd
then I wonder what happens during pre sales time?

Anyway I guess I'm just looking for clarification about what it means to be
an "open source hardware company" and a lot of it stems back to what this
conversation was a few days ago: it is helpful for me to think of the *goal
*or mission of the product / company, and then understanding if open source
hardware is a means to that end. And then being transparent about why that
is the case, and what is open / documented and what might not be.

Matt,
I see the value that a company should document only what is open and assume
that what is not will be assumed, but what about a company that leaves some
stuff secret in order to make money on one part of the project, and
therefore I find that transparency is better (in other words, at least a
short description on what is NOT open / documented, and WHY)

Thanks!
gabriella


On Sat, Mar 2, 2013 at 5:08 AM, Chris Church
<thisdroneeatspeople at gmail.com>wrote:

>
> On Mar 1, 2013, at 3:55 PM, Matt Maier wrote:
>
> >
> > 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.
> >
>
> Hi Matt,
>
> I think this is a great point, in some ways it is analogous to not
> requiring to include the std c libraries with every project that uses them.
>
> I wonder if, with mechanical parts, the software analogies hold up.  For
> example, a STEP file for non-trivial parts is more of a description of the
> output of a piece of software than the source code for the software.  Much
> like Gerber files with PCBs, it may be more appropriate to share standard
> GCODE if we're relating the hardware to the same level of sharing as we
> would see with software and PCBs.
>
> Obviously, for those parts that are 3D-printed and expected to be printed
> using slicing software, that's not required (nor may the author actually
> ever know what the GCODE was), but for more complex parts - it may be
> required to not only express the shape and form of the part, but the
> critical inputs for how to generate the right GCODE on the right machine.
>  (For example, surface finish, tolerance, maximal runout, tempering
> processes, etc.)
>
> Perhaps the requirement should include "a description of the manufacturing
> inputs and processes required to make a functional part." even if they
> don't describe fully how to make an actual replica. (Which may be useless
> to someone with different machines/tools/processes.)
>
> Chris
>
> _______________________________________________
> discuss mailing list
> discuss at lists.oshwa.org
> http://lists.oshwa.org/listinfo/discuss
>



-- 
COO Protei Inc <http://protei.org/>.
While at sea check
here<http://www.levinegabriella.com/category/unreasonable-at-sea/>for
updates.
portfolio: gabriellalevine.com
blog: levinegabriella.com
skype: gabriellalevine
int'l number: +19177254217
US number: +19177340587
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.oshwa.org/pipermail/discuss/attachments/20130302/ff089edd/attachment.html>