I believe Jeremmy Bennett has answered your question about Open Hardware in a very complete way...
Now, in order to make the things more complicated... what about licensing Open Gateware -- i.e. VHDL/Verilog code?? There is a huge gap to be filled here, and there is a lot of work in progress here in order to cope with the special issues that licensing HDL code implies.
@jeremybennett: "some serious legal brains are working on it."
You are completely right!! I'm following CERN-OHL mailing list from some time now and the debate is really smart and passionate. Andrew Katz is an active member and I can certify he is a real master on Open Hardware legal issues ;-)
I use GPLv3. This guarantees that users of my code will be able to enjoy the Four Freedoms:
0. The freedom to run the program, for any purpose.
1. The freedom to study how the program works, and change it so it does your computing as you wish. Access to the source code is a precondition for this.
2. The freedom to redistribute copies so you can help your neighbor.
3. The freedom to distribute copies of your modified versions to others. By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.
Freedom 1 means that if the program doesn't work, you can fix it yourself or hire someone to fix it. This was RMS' original motivation for software freedom. Freedom 3 comes with the requirement that when you distribute a modified version of your code you must make the source code available. This means that if you fix any bugs or improve the code in any way, the community as a whole benefits.
Linux uses GPLv2. This is a big reason why it's so reliable -- all bug fixes must be released to the community. A company is not allowed to release a binary-only version of Linux that fixes bugs only in that version -- the company has to "give back" to the community to help the product get better for everyone.
The problem with a permissive license like MIT is that someone can put your code into their product and sell the product in binary form. You get no compensation, and the community gets no benefits from any bug fixes that the redistributor made.
Code belongs to whoever wrote it (or paid for it to be written), and the owner has the exclusive right to decide what can be done with that code. People who believe in FLOSS want to ensure that all users of the code enjoy the Four Freedoms, and GPLv3 is the best way to ensure that. With a permissive license, your code may be distributed more but the end users may not be able to fix any problems with it. Their only recourse is to curse the person who wrote the code, even though the problems may have been added by the redistributor.
Important note: if you distribute your software under GPL, there is nothing to stop you from also licensing it in other ways if you wish. For example, if a company really wants to incorporate your code in proprietary software, you can sell them a non-exclusive license to do so and make money from it. However, your GPL version is still out there benefiting the world.
There certainly are serious options for open hardware. For starters look at the Solderpad License (permissive), CERN Open Hardware License (less permissive), and TAPR Open Hardware License (least permissive of all). As noted by Caleb Kraft, it is still an area of intensive discussion, although as the above examples illustrate some serious legal brains are working on it.
I wrote on the subject last year, following Andrew Katz's talk to the UK Open Source Hardware User Group: http://www.embecosm.com/2013/03/08/a-license-to-build/
Open source hardware is in a real wierd place right now. There are debates about what exactly constitutes open source when it comes to hardware. Does it stop at the code? blueprints and cad files? Mining practices for the minerals?
There is still a lot of talk right now about what OSHW really is. Can it be patented? How do derivites work? At what level is something even considered a derivitive?
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.