[Discuss] OSHW Best Practices / Layers of Openness
pip at nycresistor.com
Wed Feb 27 19:38:54 UTC 2013
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
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
@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:
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
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
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
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
>> 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
>> - 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
>> 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
>> 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
>>> projects? (This comes to us a lot, which perhaps prompted Catarina to
>>> 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
>> 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,
>>> 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)
>> their derivatives. That's a separate issue from the information you need
>> 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
>> 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
>>> 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
>> if a different economic model counts.
>> discuss mailing list
>> discuss at lists.oshwa.org
> discuss mailing list
> discuss at lists.oshwa.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the discuss