Open Source Hardware

I had a stimulating talk with Jim Mason of All Power Labs/Gasifier Project[1] on Thursday about what shape an open source hardware license (OSH) could take, and how the application of open source hardware best serves the Gasifier project.

These are the relevant notes from our conversation:

+ The analogy between open source software and open source hardware is easy to make; however in software, a license is a necessity.  In hardware, a license is a novelty.

+ OSH should be a protection of manufacturing methods (“how you are going to realize the physical thing”), not the specific incarnation of the object

+ Delimited “fair use” to give rise to innovation

+ Gen. principle is materials agnostic.  It doesn’t matter what you make the thing out of.

+ OSH needs to be designed to be “makeable”

+ OSH strives for the greatest propagation of a [good] thing.

+ OSH strives to best facilitate someone’s ability to make said object.

+ Are hardware areas similar under HW umbrella? e.g. can OSH accomodate & apply to gasification, biology, electronics, etc.

+ OSH wants to give a sense of how ideas are propagated and how they are used

+ OSH should create a healthy commons involving collaboration & building on each other’s work

+ It’s only OSH when the ideas in use are documented/defined

+ Solution to issue of profit-maker/free riders who do not contribute back to community? (this issue already exists in OSS/the gasifier community)

[1] All Power Labs (http://www.allpowerlabs.org/)

Advertisements

3 Comments

Filed under Uncategorized

3 responses to “Open Source Hardware

  1. I’d be interested to hear your thoughts on what you see the use cases for an OSH license being. I feel like the much bigger problem in hardware is not the licensing [for now], it’s the practicability of building things. While that’s changing, I think it’s quite a ways away.

    Part of the difficulty about licensing and OSH is the point that you make about the object being separate from the process. Applying protection to a process sounds pretty unenforceable.

    I usually think of the primary goal of IP protection as trying to find the balance between rewarding creators and enabling riffing off of creations. Right now, I think that practical barriers to building stuff are a much bigger impediment to sharing/riffing than anything else.

    My personal instinct is that because of the formal complexity of specifying a license that works across domains and toolsets (consider the depth of discussion around computer programs, where there are many fewer moving parts and much more commonly shared toolsets) it makes the most sense to create a license that addresses problems as they arise, as opposed to trying to figure it out _a priori_.

    Consider harkopen [1]: only three of the projects have any posts, and I haven’t heard or seen much about them, despite their taking aim specifically at some of these questions. I suspect that part of the reason is their tagline, “osh is the new big thing!”–it’s closer to “osh might be the next-next big thing, in a few years” =)

    Another question is what the line is between functionally and nominally open source–for instance, you talk about the need to document and design for “makeability.” Could you expand on those points? Because I think you’d be hard pressed for anyone to choose a license that requires more work than making the thing (kinda like a license that requires commented code that’s easy to modularize–it’s a standard that’s hard to nail down).

    I’d also be interested to hear about the gasifier project’s issues with profit-maker/free-riders. In OSS, I don’t think this is an “issue”–I think it’s embraced and taken for granted that 95%+ of users won’t ‘contribute’ per se.

    [1] – http://harkopen.com/projects?order=post_count&sort=desc

    • Another question is what the line is between functionally and nominally open source–for instance, you talk about the need to document and design for “makeability.” Could you expand on those points? Because I think you’d be hard pressed for anyone to choose a license that requires more work than making the thing (kinda like a license that requires commented code that’s easy to modularize–it’s a standard that’s hard to nail down).

      The thought was along the lines of, It’s only “Open Source Hardware” if it’s designed to be makeable. Comments in code isn’t exactly the same as software that’s editable, but in the case of the Gasifier project, a lot of thought is put in to making sure that it’s buildable given ubiquitous tools, and that difficult to produce designs, or designs that require specialized tools, are kept to a minimum. I feel this is an important tenet of producing Open Source Hardware, but of course is not requirable. In sum, if you’re going to call something open source hardware, you ought to be keeping makeability in mind.

      I’d also be interested to hear about the gasifier project’s issues with profit-maker/free-riders. In OSS, I don’t think this is an “issue”–I think it’s embraced and taken for granted that 95%+ of users won’t ‘contribute’ per se.

      In OSS it’s not an issue, because copying someone’s source code and selling the product one state away with no attribution, is not viable. This has already occurred in the gasifier community (detrimentally; my understanding is people are now more reticent about sharing innovations)

      • Makeability feels like something separate from the issue of the openness of the design, in part because it’s mostly a reflection of the toolset available to you. In the case of the gasifier’s audience, there’s a very minimal lowest common denominator toolset. But OSH is something that could be enormously compelling to companies, where they might be able to assume a common toolset of pick-and-place or injection molding. So I guess this is just two different ways of saying the same thing, “If you want something to be ‘open’ for your audience, make sure you know and respect the limitations of your audience in the makeability of the hardware.”

        I understand why it’s not an issue in OSS, I may have just been misinterpreting “this issue already exists in OSS”