RSS FeedBlogs
RSS FeedSubscribe to this blog
About Author
Andrew Katz

Andrew Katz is partner and head of the IT/IP team at Moorcrofts LLP, a boutique law firm based in the Thames Valley providing corporate and commercial advice to knowledge-based industries. Andrew qualified as a barrister and requalified (and now practises) as a solicitor. He financed his way through bar school by jobbing as a (fairly incompetent) programmer (in turbo pascal). He now specialises in free and open source software law and has written and lectured widely. He is a founder editor of the International Free and Open Source Software Law Review, a fellow of the Free Software Foundation Europe and advises businesses and communities on free and open source licensing and strategy worldwide. He is slightly obsessive about live music. These are his opinions, and not those of his firm.

Open source hardware: Announcing a new licence

Why copyleft may not be right for hardware

Article comments

Open hardware is coming of age. I'm currently working on projects as diverse as open source cars, open source boats, open source wind turbines and open source electronics.

A problem is that there are only two open licences designed for hardware: the CERN open hardware licence and the TAPR open hardware licence. Both of these are copyleft licences, and attempt to impose the same licence terms on any distribution of the original hardware, in a form similar to GPL: so called "copyleft".

I'm not convinced that copyleft is the right way to go for hardware (actually, I'm not convinced it's the right way to go for software, but that's another story). Hardware and software are different. It costs zero to replicate software, but will always cost something to replicate hardware, even if you have unrestricted access to the blueprints. The upshot of this is that the cost differential between adopting the GPL and designing around it (for software) is vastly greater than the cost differential in circumventing a copyleft hardware licence. This is one reason why hardware copyleft is not a great idea.

Another reason is that it's relatively easy to circumvent any hardware copyleft licence. How to do so will depend on local law, but in essence, if company A takes some copylefted hardware (which I'm assuming is patent free and doesn't itself contain some software), modifies it and manufactures it, then so long as it is compliant with the licence when it passes the items to friendly company B (by passing on the blueprints, for example), company B will be able to flog the products on to third parties without complying with the original licence (it doesn't contravene any intellectual property rights in doing so so it doesn't need a licence).

There are other reasons (which I will enumerate in greater depth in a subsequent blog post), but the upshot of this is that it may not be that helpful to spend too much time worrying about copyleft. It occurred to me the simplest thing to do would be to avoid this issue completely, and use a permissive licence. I used Apache 2.0 (as an already existing and respected permissive licence) as a base and hacked a hardware version from it. The result is here (Andrew Back at has been kind enough to host it for me).

I'm currently engaging with a number of bodies to get the licence certified as open and free. In the meantime, I welcome any comments on the licence (there will be a comments mechanism in due course).

Incidentally, I have already been accused of promoting licence proliferation, which is a little strange as it is, so far as I can find out, the only permissive open hardware licence in existence at the moment.



Send to a friend

Email this article to a friend or colleague:

PLEASE NOTE: Your name is used only to let the recipient know who sent the story, and in case of transmission error. Both your name and the recipient's name and address will not be used for any other purpose.

We use cookies to provide you with a better experience. If you continue to use this site, we'll assume you're happy with this. Alternatively, click here to find out how to manage these cookies

hide cookie message

ComputerworldUK Knowledge Vault