Open-source hardware statement of principles and definition
October 8, 2010
Although Arduino has been doing open-source hardware for a while now, we haven’t had a good place to point people to explain what we mean by it. That’s starting to change, thanks to a recent effort I’ve been involved with to write up a statement of principles and definition for open-source hardware. We’ve just posted a new draft [ http://freedomdefined.org/OSHW_draft ] and are looking for public feedback. Here’s the statement of principles:
Open source hardware is hardware whose design is made publicly available so that anyone can study, modify, distribute, make and sell the design or hardware based on that design. The hardware’s source, the design from which it is made, is available in the preferred format for making modifications to it. Ideally, open source hardware uses readily-available components and materials, standard processes, open infrastructure, unrestricted content, and open-source design tools to maximize the ability of individuals to make and use hardware. Open source hardware gives people the freedom to control their technology while sharing knowledge and encouraging commerce through the open exchange of designs.
What do you think? Please share your comments here or on the Open Hardware Summit forum [ http://www.openhardwaresummit.org/forum/ ]. We’re hoping to find language that’s specific to what we do, but understandable and acceptable to a broad audience.
October 9, 2010
Nice, but I think the statement of principles could be improved in a number of ways:
1. For one, I would go for “Free and Open Hardware” versus “Open-source Hardware”. Given that the definition itself stresses the freedom part, I don’t see why the word “free” should be kept out of the naming, especially in light of all the problems and harm that the ideological opposition by some to the word “free” has caused in the software world. The personal voyage of Bruce Perens should teach much, to this regard.
2. On the selling part: I can’t understand how one could “sell” a design which is “free”. One could sell the implementation of that design (the hardware itself) or services related to that design (a course on how to build the hardware, a print of the design specification, a video explaining the design…) but the design itself? Maybe it’s just me, but I don’t get it.
3. The weakest points of all – though – is for me that the statement lack a reference to derivative work. I would argue that here the model to follow should be the LGPL, in which you can use the free software within a non-free project, but you cannot “close-source” that part of software which was initially open sourced. In particular I would make sure to prevent phenomenon like the TiVoization (like in v.3 of GNU licenses), i.e. modifications to the design that makes impossible to run the think other than on a specific platform/in a specific environment.
4. Being pretty new to electronics, there is furthermore a point that is not clear to me: how can one say that a given piece of hardware is “free” or “open-source” if its components are not? I am under the impression [please correct me if I am wrong here] that most of the off-the-shelf parts are not FLOSS, but proprietary designs by the producers. I would rather call the definition “Free and Open-source *Design* statement”, if I got things right.
Anyhow: nice that somebody is putting their head to this! :)
October 10, 2010
mac: you make some good points.
As for (1): to me, “free hardware” is even more confusing than “free software” – implying that you’re giving away the device itself rather than giving people the freedom to make or modify it. Also, I identify more with the attitude behind open-source (rather than free) software. For both reasons, I prefer “open-source hardware”, although I can see why some people would want to use “free”.
I agree with (2). I don’t think we need to explicitly say that you’re allowed to sell the design itself. This is more an accident of the particular phrasing than an explicit principle.
As for (3), we want to allow people to share the hardware under both liberal (BSD-like) and viral / copyleft (GPL-like) terms. That means the definition shouldn’t consider only the latter to be open-source hardware.
(4) is the trickiest issue here, and one we’ve been struggling with. On the one hand, it would be great if all the components in a product were themselves open-source. On the other hand, this doesn’t seem practical; I don’t think it’s true of any current open-source hardware projects. That’s how we ended up with the “ideally, open-source hardware uses readily-available components” phrasing. But there may be better ways to think about this. Suggestions welcome.
Copyright 2010 http://www.arduino.cc/