Wednesday, December 3, 2008

What is Open Source Hardware, really? Part 2 and the CoreBoard

Somehow it didn't feel right to spend all that time thinking about Open Source over the last few days, only to make another file using Microsoft's very, very proprietary Powerpoint file and format :(

Anyway, thanks Limor (p.s. can I come over and use your laser etcher?!) and especially Phil for the ideas and comments (they've definitely thought long and hard about this). So I spent some time last night and today reading up on the huge threads over at OpenCollector, Slashdot and Opencores.org, where there are some really interesting ideas too. I tried to summarize everything I read, and some of my thoughts as well into "What is Open Source Hardware - Part 2".





Incidentally, it's funny that folks don't feel comfortable writing comments on a blog, and prefer to send emails instead, but whatever works :) I think I'm the same way on other blogs too...


Also, since I thought it was a good example of the licensing issues, I figured I might as well talk about my CoreBoard project. It was originally something I just built for myself, and I was kind of embarassed to release it because it technically doesn't work with the Arduino IDE (instead, you have to use either something from here, or from here on Linux).






























































It's a little Basic STAMP carrier board that converts all of my old STAMPS that I had lying around from the pre-Arduino days. It's shaped just like an Arduino, but colored black, and it has a little ZIF socket in the middle that's perfectly shaped for all kinds of 24-pin STAMP varieties floating around out there (like ARM, Java, or PIC-based ones). I also pinned out all of the Basic Stamp's I/O to the Arduino female pin header rows, so writing code for it wouldn't be too hard. I wanted to be able to use the shields like the TouchShield or wave shield with them.





















Here's some open source code to make the CoreBoard blink LED 15 - I'm releasing this code snippet under the GNU GPL license :-)

' {$STAMP BS2e}
' {$PBASIC 2.5}
' {$PORT COM21}

LED PIN 15
IsOn CON 0
IsOff CON 1
Setup:
OUTPUT LED

Main:
DO
LED = IsOn
PAUSE 500
LED = IsOff
PAUSE 500
LOOP


I've release all the schematics, diagrams, bill-of-materials, parts list, and gerbers under the Creative Commons license so have fun ... And now that I've written a blog article about it, I've also thrown it over at liquidware.com. If you buy one, I'll assemble and solder it for you!

3 comments:

Unknown said...

this is great, it's really drilling in to a lot of what folks are talking about, nicely done!

Matt said...

Thanks a lot :) I also grabbed a bunch of quotes and snippets I thought were really interesting from other sites:

http://www.opencores.org/forums/cores/2005/01/001350
Jecel Assumpcao Jr

So what can be done? We have two cases:

- people who want to allow unrestricted commercial use of their cores

In that case there is no attempt to control the use, so a variation of
the BSD license is good enough. It uses copyright to make sure everyone
who gets a copy of the core agrees not to sue the author (not quite -
actually just those who distribute copies, but close enough in
practice).

- people who want to force companies using their cores to contribute
back any improvements they make

The GPL won't do this, as I explained in the previous email. You have to
force each person receiving the core into a contract with you, and not
just those who are distributing it.

...

So the solution to using copyright to enforce some terms on the *use* of
a core is to forbid people who have a copy from giving one to anybody
who has not agreed to those terms. Copyright doesn't even allow them to
distribute to those who have agreed, but the contract can allow that. If
someone is using the core in conditions not permitted by the contract
then they are either in violation of that contract themselves and can be
sued or they got a copy without agreeing to the contract and the person
who gave it to them is in violation and can be sued.

Personally, I prefer the BSD route. Previously I had seriously
considered the use of two patents (just one would be too risky since it
can be judged to be invalid, while more than two would be far too
expensive) to force people to contribute back any improvements (or to
negotiate an alternative license with me and pay royalties). Now I am
thinking of a scheme were the cores are kept secret until the next
version is ready, then the previous version would be released under a
BSD-like license. I am not happy with this (which is similar to how
GhostScript is licensed) but it seems to strike a balance between my
need to make some money and my wish to make it available to others
without restrictions.

No single solution will make everybody happy here. But having eight
different solutions (licenses) is sure to make us all unhappy. So we
should review the basics and then create a few (probably two; at most
three) standard alternatives with reasonably well understood
consequences.



http://www.opencores.org/forums/cores/2005/01/001298
Joachim Strömbergson

> In those articles I also urgently suggested using BSD style licenses, as the
> (L)GPL licenses are simply not suited for hardware. But so far most people
> keep using them .........

And I have to side with you and Rudi on this - and it's not only because I'm
generally a BSD-dude (FreeBSD to be precise). I think that a license that
legally describes the way IP-cores are used and somehow integrates the
interests of the developer, protects the code from being ripped off, while
still allow for a good usage, would be the thing to have. My hope was that LGPL
would be that license. But, when I read it, I get stuck at too much things that
does not grok with the nature of IP-cores.

Unknown said...

what might be easier to start with -- what are "shipping" makers currently calling 100% "open source hardware" - defined by the makers themselves.

-arduino.
-evil mad scientists kits.
-adafruit kits.

maybe starting there with folks who call their OSH and allow commercial use would have one end of the spectrum -- from there you'd have OSH and then move on to OH-NC (open hardware non-commercial) and that's where we'd dig in to the specifics of how you can use it and what the makers are using for licensing.

i hear a lot of hypothetical scenarios when people talk about hardware "it might get ripped off in china, etc" - but so far that hasn't happen with OSH and really, if someone in china wanted to "rip off" something they just would, there are ipod clones on canal street right now. what i think matters is looking at what makers are actually doing who want to go OSH.

after that, i'd look at monome, very cool project, it's OH-NC -- they haven't exactly said that, but it might be good to chat with them and then see where it lands on the OH-NC to OSH species chart.

i have some ideas on how to track and record this based on your previous slides, so i think there's a great opportunity to really document this and maybe arrive at some interesting suggestions.