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.
"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."
@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?
@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.")
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.
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.
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.
@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.
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.