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?
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/
@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 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.
@Betajet: "Why wouldn't GPL work for VHDL/Verilog code?"
I'm not an expert in this topic, but AFAIK things start to be obscure & fuzzy when trying to mix a GPL licensed VHDL/Verilog code in a bigger logic system.
One on the main issues is connecting the GPL hardware to the rest of the system, i.e. attaching a peripheral to a bus such as AMBA or Wishbone. In this case... are you "linking the code" or everything acts as a whole thing? GPL is often called a "infectious" license, but in a HDL system is not clear what is the "vector" for the disease ;-)
A common practice is licensing the HDL code under LGPL (Lesser/Library GPL), because everything seems to fit better. If you get a LGPL licensed IP-Core, you can use it "as is" as a piece of a bigger proprietary design; but if you modify the IP-Core code, you must share the improved/modified code.
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.
The GPL is very useful for many types of project. But it is not a good choice for code that is designed to work as part of a bigger system - unless you are sure that such systems will all be GPL. So it is generally a poor choice for library code or other reusable code. On "big" systems, such as Linux or Windows, you can make the library code LGPL and put it in a shared library - but that won't work for embedded systems without dynamic linking or a (user accessable) method of updating just the library part.
A number of embedded libraries use a modified GPL rather than an BSD-style license (or MIT licence), in which the programmer must abide by the GPL in regard to the files in the library, but are free to choice their own licence for their own files. FreeRTOS is an example of such code. So when you use FreeRTOS, any changes you make to the FreeRTOS code must be published, but you can use any licence (including the "standard" company licence of "it's our code, and it's a trade secret") for your own modules.
The Mozilla Public Licence (used for Firefox and friends) is a very similar licence.
Max, since ths project uses the arduino , the license requirements(of the arduino) will force you(and other developers using the system) to release object files, which isn't commercial friendly,unlike the MIT license.
That's why,for embedded projects, the mbed is much preferable.
GNU or any public license thats free, comes at a cost that you might have to make it work in all the conditions. IT might not be tested in differnt conditions of input and output. Someone wrote the code and it worked in his case so here it is to use it.
@alex_m1: Max, since ths project uses the arduino , the license requirements(of the arduino) will force you(and other developers using the system) to release object files, which isn't commercial friendly,unlike the MIT license.
Que? I don't understand. Are you telling me that I cannot release my Arduino Sketches under the MIT license?
"Using the Arduino core and libraries for the firmware of a commercial product does not require you to release the source code for the firmware. The LGPL does, however, require you to make available object files that allow for the relinking of the firmware against updated versions of the Arduino core and libraries. Any modifications to the core and libraries must be released under the LGPL."
@Max: There's a lot of misunderstanding about the GPL.
Disclaimer of liability is important, but not the only reason or using it. The potential issue for GPLed code is that it's viral: if your code links against GPLed code, it too becomes GPLed.
This can cause a problem for developers of code that for one or another reason cannot be GPLed. If it must link against GPLed code in the target environment to function, maybe it simply can't be used there.
Other sources of misunderstanding include "Can I use GPLed tools like GCC to develop proprietary code?" (Yes, you can.) and the issue of providing source.
The GPL requires you to provide the source code for your efforts. One common question is "Must I provide the source with my binary distribution?" No, you don't have to. Many, possibly most, users just want the binaries and may not be able to use the source if they do have it. But you must provide it on request in a form convenient for the user. The stickier issue is that it must be the source code you used to build your binary. The intent is that the user should be able to get your source, reproduce your build environment, and get an exact duplicate of your binary built on their own system. So a simple pointer to a repository with the latest and greatest verion of your source won't do, if that isn't the version you used to build the binary you distributed.
Also, GPLed code is "Free as in freedom", but not necessaarily "Free as in beer". There is nothing in the GPL that says you can't charge for your code, though most GPLed products are issued without charge. And if you license under the GPL, you still retain the rights. If someone wishes to take your code and create a proprietary closed-source fork, they can contact you and get a closed-source license if you can agree on terms. ("I want to build a closed-source fork of your code." "Cross my palm with X amount of silver.")
I needed a license for an open source computer comipiler and chose a BSD license and added a statement to the effect that "This software may not be used in any what that harms <my company>."
The BSD license is generous in terms of the priveleges it allows (which is what I want for an open source project), but I do want some kind of protection from someone doing something harmful to me with the project.
Drones are, in essence, flying autonomous vehicles. Pros and cons surrounding drones today might well foreshadow the debate over the development of self-driving cars. In the context of a strongly regulated aviation industry, "self-flying" drones pose a fresh challenge. How safe is it to fly drones in different environments? Should drones be required for visual line of sight – as are piloted airplanes? Join EE Times' Junko Yoshida as she moderates a panel of drone experts.