[Discuss] OSHW Best Practices / Layers of Openness

[Michael James]

Interesting discussion!

-I plan to release the files in 3/6/12 months, can still use the open
source hw logo?

I would agree with pretty much every one above - good intentions do not
equal OSH

-Can I use the oshw logo if my project is only partially open source?

I say yes.  I know a group that has been working for several years to
develop an OSH charge-controller for controlling the output from PV cells,
the initial idea of the creator was that they would be able to create a
module that would be designed so well and cost effective that larger
companies might want to use the charge-controller as sub components of
larger assemblies - basically design in the OSH part.  The focus of the
group has changed, but that idea sticks with me.  And while it feels
misleading to have a product with the OSH logo be only partially composed
of OSH, I feel like getting the logo into the world, especially in consumer
products, would be a boon for the community.  This may be dumb,
or manufacturing restrictive, but what if the logo had two colors.  The
blue logo means - this *whole* product is OSH (with Michael Shilohs' point
1 being the qualifier - can it reasonably be reproduced with the files
provided).  And the Orange means - this product *contains* OSH.  It seems
clear to me from the discussion that we should not neglect the partial OSH,
and I also think that we will find that "OSH Purity" is going to be hard to
define.

- How do I or will OSHWA approach a company who has the open source hw logo
on their boards but no files?
I am for letting the community shun them.

- Must supplier details be given to use the oshw logo?

I agree with Peirce Nichols here, and say no - too restrictive.

- This movement feels like you're leaving out mechanical designs /
architecture / nanotech, how can I interpret your definition to include my
projects? (This comes to us a lot, which perhaps prompted Catarina to start
exploring a space that would better include them.)

Just spoke with a gentleman about this exact issue/problem.  These people
have made a "substance" or a "material". What source files would be
necessary? i.e. Is the recipe for playdough the design file?  On an aside,
if you have any advice where I could point these folks please shoot me a
line...

- Can I release some of the software for a license, like a pro version, or
does that go against Free Redistribution, or is it okay because of clause
12 in the definition?
I say go for it.  It gives companies selling OSH an option for revenue.
 With Davids caveat that the provided software should be
necessary and sufficient for the use of the item.  And that there would be
nothing restricting the user from making there own software that would do
the same thing or better than the pro version.

- What are the best practices for releasing a piece of open source hardware
and its documentation under the definition?
I  really like how Spark Fun does it.  They list a bunch of the design and
source files right on the product page of the items - there is no digging
around for them.  I think it will be hard to define exactly what files, as
the scope of OSH includes so much stuff.  Maybe leaning back to Michael
Shilohs' point 1 being the qualifier - can it reasonably be reproduced with
the files provided.

- Can I directly copy open source hardware (sans trademark), the oshw
definition says 'yes', but articles on oshw have a resounding 'no'.
- Is a different economic model (selling hw for cheaper or more expensive)
enough to call copied hardware a derivative?
Direct copies seem a bit lame, but if the "copier" is improving a
process(es) in the manufacturing that makes the product more economically
feasible, than it seems let shady.

Best,
Michael




On Wed, Feb 27, 2013 at 2:38 PM, Alicia Gibb <pip at nycresistor.com> wrote:

> This is all just my personal opinion here.
>
> *Best Practices response:*
>
> For this question:
>
>> - Can I use the oshw logo on my product if I am using
>> a proprietary enclosure from another company, but the insides are mine?
>
>
> I think for me it's important that the proprietary enclosure can be
> physically open to get at the hardware inside - sort the ifix if you can't
> open it you don't own it approach.
>
> - Can I directly copy open source hardware (sans trademark), the oshw
>> definition says 'yes', but articles on oshw have a resounding 'no'.
>
>
> I think if we're really about being open, this should actually be okay -
> think of all the open source code that gets copied and pasted directly
> (with attribution of course). And as David states, there may be times when
> it is necessary  If the community is largely not okay with this, then it
> should be worked into the definition that open source hardware is
> for derivatives only (personally, that kind of restriction would make me
> sad). Otherwise, I think as a community we need to change our attitude and
> be accepting that someone may copy you and price you out.
>
> - Can I use the oshw logo if my project is only partially open source?
>
>
> I agree with David's response, and when Michael used the word
> functionality that made me think, maybe the line is drawn at: Can the
> hardware function as planned with the files provided, or must the user
> create hacks to make it work? If someone has to create a hack in order to
> use it, it shouldn't be using the oshw logo. Furthermore, (/me is all
> sharey-sharey and barfs rainbows) if hacks were done to a partially open
> source project, and the creator decided to sue for infringement, I hope
> they would lose in court as I think the social norm will tend to be
> accepting about hacking partially open source hardware. Would be
> interesting to hear Bre's take on this comment, not that MB has sued anyone
> of course, but I'm interested to know how the logistics of some open / some
> closed would manifest. This is also where clarity would play a huge role -
> also I think MB is clear about what is what.
>
> - This movement feels like you're leaving out mechanical designs /
>> architecture / nanotech, how can I interpret your definition to include my
>> projects? (This comes to us a lot, which perhaps prompted Catarina to start
>> exploring a space that would better include them.)
>
>
> To start addressing this problem, we contacted Massimo Menichenelli and
> hope that he joins the conversation. He's working on an Open
> Design Definition<http://www.openp2pdesign.org/2013/open-design/working-on-the-open-design-definition/>,
> which relates closely to the oshw definition. Maybe we could combine best
> practices, somehow partner or nest the definitions, as I think the oshw
> definition was heavily based on the open design definition  written in
> 2000 <http://opendesign.org/odd.html>?
>
> *Certification Response:*
> *
> *
> @Marco - The idea of the certificate I think is only a matter of time if
> this movement continues to grow on the path it has been. As Cameron says
> though, I'm not real sure a monetary structure with that certification
> would be appropriate. Maybe for large companies that can afford it. But
> OSHWA will have to make its money somewhere if we take on a project like
> this that will require we have a FT staff. Also, I think to enable
> something like that as OSHWA we'd have to start a separate 501(c)5 - a
> business league, but maybe not if it's community driven and the branding is
> just housed at OSHWA, like the logo is now. Speaking of the logo - there's
> been some confusion out there, the oshw logo is not trademarked. We
> realized with the pickle trademark law put OSI in to stop others from
> using derivative marks (like ours), it didn't really seem like a good idea
> to close down something created for and by a community.
>
> We dabble in talking licenses with all this definition stuff, and every
> time so far have decided a social norm is best. But perhaps we're talking
> about it from the wrong side, maybe we should be talking about building
> upon public domain rather than stripping licenses. This really interesting
> article on public domain came to me via Catarina Mota:
>
> http://www.h-online.com/open/features/Why-it-s-time-to-stop-using-open-source-licences-1802140.html
>
> First off, his research about whether open-source-type users use licenses
> echos ours: He found that people no longer apply licenses in GitHub at the
> same rate they once did. A lot of code is now uploaded with no license at
> all - which he recognizes that may be problematic as well. Similarly, in
> the data we collected from about 2,000 oshw participants, the vast majority
> did not use a license. Perhaps that is because licenses are becoming less
> relevant.
>
> Perhaps instead create a new type of public domain that requires
> attribution (and share-alike), which is the suggestion from the lawyer
> who's paper is being reviewed in this article. Since all hardware is
> technically open until patented, maybe the thinking about open source
> hardware as a license is thinking about it top down instead of bottom up
> for lack of a better parallel. The difference in hardware and software may
> lay in the fact that hardware does attempt direct economic advantage,
> whereas this author states that within software: "The literature suggests
> that the purposes of individuals in contributing to open-licensed projects
> have little to do with direct economic advantage; rather, their interests
> in contributing primarily lie in creativity, reputation-enhancement, and
> indirect economic rewards." But! I would argue that so far open hardware is
> proving to be lucrative and have direct economic advantages, even with many
> creative derivatives (Arduino). The largest issue we've collectively seen
> in the community is a problematic copying everything including the original
> company's trademark. And public domain inherently protects Trademark,
> because Trademark protects the consumer rather than the intellectual
> property.
>
> If we chose to move toward the path of a certificate or some kind of
> new-fangled social norm, I would challenge us to think from public domain
> up.
>
> Cheers,
> Alicia
>
>
>
> On Wed, Feb 27, 2013 at 10:41 AM, Michael Shiloh <
> michaelshiloh1010 at gmail.com> wrote:
>
>> I see two recurring themes in these responses:
>>
>> 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?
>>
>> 2) That the discussion continues as we continue to think this through,
>> and as we develop projects that explore areas we had not considered.
>>
>>
>> On 02/27/2013 08:54 AM, David A. Mellis wrote:
>>
>>> Here's my take on these. What do the rest of you think?
>>>
>>> On Tue, Feb 26, 2013 at 12:51 PM, alicia <amgibb at gmail.com> wrote:
>>>
>>>  - I plan to release the files in 3/6/12 months, can still use the open
>>>> source hw logo?
>>>>
>>>>
>>> No. Or, at least, not until the files are released. Until then, it's not
>>> actually open-source.
>>>
>>> - Can I use the oshw logo if my project is only partially open source?
>>>
>>>>
>>>>
>>> This one is tricky and I think it depends on which parts are open and
>>> where
>>> and how the logo is used. For example, I think it would be fine to put
>>> the
>>> logo on an open-source circuit board that's inside a proprietary
>>> enclosure
>>> but the reverse might be misleading. To put the logo on a product's
>>> packaging, I think the primary component(s) of the product should be
>>> open-source but it's not necessarily clear what those are. Similarly for
>>> using the logo on the product's website. In these kinds of cases, it's
>>> important to be specific and clearly indicate which parts are open-source
>>> and which parts aren't.
>>>
>>> I think it's also interesting to look at how open-source software handles
>>> this question. In large part, the strategy seems to be specificity about
>>> what constitutes a project (i.e. giving open-source components their own
>>> name and identity) rather than clear conventions about how to handle
>>> partially-open bundles of software (cf. the ongoing debate about the
>>> appropriateness of including proprietary software or binary blobs in
>>> Linux
>>> distributions).
>>>
>>>
>>>  - How do I or will OSHWA approach a company who has the open source hw
>>>> logo on their boards but no files?
>>>>
>>>>
>>> This seems like something OSHWA should do, although I'm not sure what the
>>> best approach would be.
>>>
>>>
>>>  - Must supplier details be given to use the oshw logo?
>>>>
>>>>
>>> In general, I would say no, particularly if you're using standard parts
>>> (e.g. 6 mm plywood or a SOT23 transistor). I don't think, however, that
>>> you
>>> can use supplier anonymity as an excuse for not specifying the parts
>>> used:
>>> e.g. when the supplier is a defining feature of the part (e.g. an "Atmel
>>> AVR ATmega328" vs. "8-bit microcontroller").
>>>
>>>
>>>  - Can I use the oshw logo on my product if I am using
>>>> a proprietary enclosure from another company, but the insides are mine?
>>>>
>>>>
>>> Again, I think this one is tricky. If the enclosure is a simple generic
>>> project box and the primary component of the product is your custom,
>>> open-source circuit board, I think using the logo would be okay (although
>>> you should specify that the enclosure is proprietary). The more complex
>>> the
>>> enclosure and the simpler the insides, however, the less appropriate the
>>> use of the logo seems.
>>>
>>>
>>>  - This movement feels like you're leaving out mechanical designs /
>>>> architecture / nanotech, how can I interpret your definition to include
>>>> my
>>>> projects? (This comes to us a lot, which perhaps prompted Catarina to
>>>> start
>>>> exploring a space that would better include them.)
>>>>
>>>>
>>> As long as there's a source file (that can be used to produce the object)
>>> and you share it in an appropriate way (e.g. in the preferred format for
>>> making modifications and allowing commercial re-use), I don't think there
>>> should be a problem. While there may be some clauses in the definition
>>> that
>>> sound specific to electronic circuits, I think this is more of an issue
>>> of
>>> communication and culture than the definition itself, but certainly one
>>> we
>>> should be addressing.
>>>
>>>
>>>  - Can I release some of the software for a license, like a pro version,
>>>> or
>>>> does that go against Free Redistribution, or is it okay because of
>>>> clause
>>>> 12 in the definition?
>>>>
>>>>
>>> As long as you satisfy clauses 1 (releasing the design files) and 3
>>> (necessary software), it's probably okay (although not ideal) to also
>>> charge for a better version of the software / firmware, as long as people
>>> don't need it to use the product's essential functions. Clause 12 means
>>> that you can't release your design under a license that requires people
>>> to
>>> use a particular technology (e.g. a specific family of microcontrollers)
>>> in
>>> their derivatives. That's a separate issue from the information you need
>>> to
>>> release in making the design open-source.
>>>
>>>
>>>  - What are the best practices for releasing a piece of open source
>>>> hardware and its documentation under the definition?
>>>>
>>>>
>>> Good question. It's great that we're having a discussion about these and
>>> we
>>> should definitely document them.
>>>
>>>
>>>  - Can I directly copy open source hardware (sans trademark), the oshw
>>>> definition says 'yes', but articles on oshw have a resounding 'no'.
>>>>
>>>>
>>> It's allowed but obnoxious unless there's a good reason for it. (For
>>> example, large import duties in your country might be a good reason for
>>> making a local version.)
>>>
>>>
>>>  - Is a different economic model (selling hw for cheaper or more
>>>> expensive)
>>>> enough to call copied hardware a derivative?
>>>>
>>>>
>>> This sounds like a restatement of the previous question, since the
>>> difference between a "derivative" and a "clone" seems to be mostly one of
>>> perspective and attitude. Again, it seems that most people are annoyed to
>>> someone who simply copies hardware without a good reason but it's not
>>> clear
>>> if a different economic model counts.
>>>
>>>
>>>
>>> ______________________________**_________________
>>> discuss mailing list
>>> discuss at lists.oshwa.org
>>> http://lists.oshwa.org/**listinfo/discuss<http://lists.oshwa.org/listinfo/discuss>
>>>
>>>  ______________________________**_________________
>> discuss mailing list
>> discuss at lists.oshwa.org
>> http://lists.oshwa.org/**listinfo/discuss<http://lists.oshwa.org/listinfo/discuss>
>>
>
>
> _______________________________________________
> 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/e3bc62f7/attachment-0001.html>