I’m looking into potentially releasing some infrastructure code (related to automated builds and deployments) as OSS and I’m curious about how the various OSS licenses effect it.
Specifically, LGPL prevents the code itself (part/whole) being modified into a commercial product (which is what I’m after), but allows it to be “linked to” in the creation of commercial products (also ok).
How does the “linked to” clause relate to infrastructure code, which is not deployed with the product itself? Would the application still be required to provide “appropriate legal notices” (which I’m not fussed over)?
Would I be better off looking at the Eclipse Public License?
1
I assume your code is something roughly comparable to the make tool.
Since your code is not distributed with the final product, just use the GPL if you do not want to have your code turned into a proprietary product (or a part thereof). Using the GPL for your tool does not affect the license of the program built with your tool in any way. You could also choose the LGPL, but that would allow your code to become part of a proprietary product (although that part would still be free as in speech).
Disclaimer: IANAL
Disclaimer: I am not a lawyer. I would strongly recommend you speak to one if you are considering licensing software, particularly if you want to use it in a commercial product now or in the future.
If you want your software to be freely used by all, the best licenses are ones like BSD and MIT. These claim no responsibility for the code except for copyright and allow modification. People and organizations can use it in their products will relatively little concern other than including an attribution and the license text. This will get your code maximum coverage but gives you the least rights.
Licenses like the Apache, Eclipse and the Common Distribution and Development License (CDDL) are a middle ground. They are more detailed and stricter that the MIT and BSD licenses but place fewer restrictions on what the user can do than GPU license.
Lastly, you have licenses like Gnu Public License (GPL) and Lesser Gnu Public License. The GPL is particularly onerous because it requires any modifications to also be open source. If you want to prevent your product being used in commercial software, use GNU.
Before choosing a license consider:
- Do I own the source code? This may be harder to answer than it first appears. Have you copied an example from a web site? Are you using other open source software? If you do not own the code, open sourcing it could violate copyright or other agreements.
- Does the source code contain patents, trade secrets or protectable intellectual property? If yes, open sourcing it may reduce or eliminate the protection offered.
- Am I ever going to want to sell this source code? If yes, open sourcing it means others can too. Open sourcing software can be a great way to get assistance from the wider community, educate others and help customers find bugs. It can also shut down a revenue stream and expose any security flaws in the product. Depending on the license, open sourcing a component may be effectively saying “I going to make money from services or something else other than selling this software”.
- Am I happy with other selling or modifying the source code? If not, a more restrictive license such as GNU may be in order. Alternatively, you can always provide the source code to paying customers with a license that prevents them from distributing it. Maybe a custom license is on order.
Whether your code is infrastructure or not is incidental. This is as much a business decision as ideological.
Remember that licenses are written by lawyers and certain terms may have specific or ambiguous definitions. Take the term “distribution”. I create a web site and the code is housed on the web servers only does that count as distribution? Another legal concern surrounds the term “use” or “integrate” because the boundaries of some modules are unclear.