Whats the easiest way, of telling if I can redistribute it in a piece of commercial software?
In license agreements I often read the terms GPL, OpenSource, Freeware, Artistic License but have never got a definitive answer on what the differences are.
Rough summaries:
GPL: If your application is distributed to others, then you may not integrate or link GPLed source code unless your app is under a GPL-compatible license. This means that you can still use GPLed code for internal or private applications.
LGPL: You may not integrate LGPLed source code unless your app is under an LGPL-compatible license, with the same caveats as the GPL. You may link LGPLed code, statically or dynamically as an external library (.dll, .so, etc), so long as the LGPLed portion may be replaced by the user.
MIT/BSD/Expat: Do whatever you want, just don't claim you wrote the other party's code.
For exact definitions, you'll have to read the licenses themselves.
The FSF maintains a list of licences. While it's understandably biased in favor of their own, it also gives a good overview of free- and open-source software licences in general.
However, almost 90% of the time you'll be interacting with one of the three at the top of the post anyway.
Usually the site with the software will link to the exact license. If your business depends on it, check with a lawyer.
That being said (and remembering that I am not a Lawyer), here's some quick guidelines that you should double-check
GPL -- commercial use allowed, but you have to provide the source code of your application if requested by the user.
BSD or MIT -- very permissive, usually ok
LGPL -- usually ok, but only if replaceable by end user
I am making this wiki answer so others can fine tune with their thoughts
A few links:
Wikipedia and another Wikipedia with a table about them.
I agree, it can be confusing... I found the table helpful in summarizing them.
I've always wished there was a program to graphically display a legal document such as a software license.
Basically display entities like licensee or copyright holder and display their rights or obligations symbolically.
Maybe in a use case diagram.
Surely if legaleeze is definitive enough to protect you in law it should be clear enough to parse.
Update I would really appreciate if people who want to downmod my answer to post a comment with where exactly I am wrong. I'd love to learn more about the various licenses out there. Thanks in advance.
Update 2 Edited the GPL and OpenSource sections to remove any wording that can be construed to be subjective.
Get a lawyer to look at the actual license of the 'free' software library and tell you if you can distribute it and what conditions it imposes on any derivative works.
Here's my understanding of the various types of license. Keep in mind that I am not a lawyer; nor am I very actively involved with free/open source community, so I might be wrong about some of these.
GPL requires that any product that incorporates a GPL-licensed source to be also GPL-licensed, if it's distributed to third parties. GPL gives a lot of freedom to what the users can do with the licensed product, but limits the terms of distribution and licensing model for any derivative works that include parts or the whole GPLed product.
In particular, paragraph 2 of GPL v2 (the most widely used GPL revision), states that any derivative work must be also licensed under the terms of GPL v2 if distributed. Exact verbiage: "...any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof... to be licensed as a whole at no charge to all third parties under the terms of this License" (http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt)
There's also LGPL, which allows for linking to libraries under it without requiring the linked product to be GPL/LGPL-ed as well, though only in certain scenarios.
There are other OpenSource licenses, which give you the right to look at, modify or reuse the source code and/or create derivative works without imposing requirements on the licensing of the end product.
A Freeware license is a license that gives you the right to redistribute the software; however, you are not allowed to charge and make profit from it, except some minimal charge to recuperate the costs of the distribution (the CD cost for example). Freeware is not necessarily open source; it might be that just the binaries are distributed.
Artistic license gives you quite a freedom what you can do with the product or its sources without setting a lot of limitations on the derivative work. However, quite often artistic license is limited to a non-commercial derivative works only (you can't sell the derivative work for profit) and requires attribution, usually something in the lines of "Based on ... by ..."
AS others said... let a lawyer look over it.
GPL has to be handled with care as long as a library is linking against it. With LGPL or BSD style licenses you are on the safe side (MS Windows uses BSD network code, Mac OS X is based on a BSD kernel). For Java there are GPL licenses with the classloading exception (e.g. Java FX). This means that commercial CS Java applications may use such JAR files.
The SFLC has the authoritative guide here in terms of avoiding violations of open source licenses.
One area that hasn't been covered wrt to the GPL is the route that was taken w/ CS-RCS. In short, you can rely on a GPL product and write your logic around it as long as you are working with a clean separation across separate processes.
Here's from their FAQ:
The CS-RCS front-end and GNU RCS are two separate applications that run as separate Windows processes. The CS-RCS application is proprietary, but the GNU RCS application is distributed under the terms of the GNU GENERAL PUBLIC LICENSE (GPL). CS-RCS is not linked with RCS because such linking would violate the terms of the GPL. The Free Software Foundation affirms that running the two as separate processes, with a clean well-defined general interface between them, justifies the view that they are two separate programs.
You're probably confusing "commercial app" and "closed source". Most open-source licenses allow you to sell software containing that source.
I've personally experienced the legal problems you can have with adding Open Source to an existing commercial app. I'd side with John Millikin on the GPL and BSD-style licenses. For the LGPL, I'd disagree. First, the LPGL'ed part has to be replacable. In general, this is not possible with a statically linked library. Secondly, you need to meet the other LPGL conditions on your own application. E.g. you have to allow reverse engineering. Many EULAs disallow this.