Right and Left
Lets start by defining the legal term copyright. When an object is subject to copyright, the owner of the work has the exclusive legal right to display, copy, change, etc., that work. Copyright applies to text (documents), works of art, music, and so forth. (This is not to be confused with the two other common types of intellectual property: patents, which apply to ideas, and trademarks, which apply to branding elements like logos and slogans.)
Software source code is clearly text, so copyright law applies to it: therefore, the author of the code has the exclusive right to control it including the right to give those rights to others. And so heres the cool hack that underlies the open source license system: an author can license his code to anyone one else who wants it, in such a way that those licensees also have the right to further distribute it, under those exact same license terms. This sort of turns copyright upside-down, and so has come to be called copyleft.
What conditions then should be present in a copyleft license agreement? The Open Source Institute (OSI), a nonprofit group that serves as a clearing-house for open source licensing, has defined a set of properties that an open source license must have to be considered as open. Among these are properties that assure that the source code licensee is free to:
use the code for any purpose whatsoever,
make copies of the code and distribute them without payment of royalties, and
create derivative works of the code.
Two Licenses
Broadly speaking, there are two different classes of open sources licenses in use today. While they both allow you as a licensee to use the source code in your product, they have different philosophical objectives a difference which can affect your product and your own closed sources.
The first class is the Academic or Attribution license. The goal of these licenses is to produce a commons of source code that anyone can do anything with, up to and including incorporating it into closed/proprietary programs. You can even take code out of the commons, by making proprietary modifications and not releasing those changes back to the community. In general, the only requirement is that you acknowledge (credit) the copyright of the authors of the code youre incorporating (the attribution clause). The two most popular forms of attribution licenses are the BSD and MIT licenses.
Some hold the philosophical position that the idea of being able to take code out of the commons is wrong: any changes to code from the commons should be required to be put back into the commons, so that all can continue to benefit from the work in question. The second class of open source license, the Reciprocal license, addresses this issue. Under reciprocal licenses, the source code for all derivative works must be publically available.
This may present a problem for developers of proprietary software. By including reciprocally licensed software into your product, your product becomes a derivative work and therefore must itself become open source. For this reason, reciprocal licenses are sometimes (pejoratively) called viral licenses, as they infect other software they come in contact with.
Philosophical issues about software freedom aside, there is one strong practical argument for using a reciprocal license. Consider the implementation of a file format that is intended to be widely used. By keeping this code under a reciprocal license, the developers of the file format can essentially prevent a (nefarious) third party from breaking the file format by introducing proprietary (and likely incompatible) changes to it. [The compressed form of LAS, known as laszip, uses this approach.]
The GNU Public License (GPL) is the most well-known form of reciprocal license. It is used, for example, throughout the Linux kernel. A variant of the GPL, called the LGPL, is used for licensing of code for shared libraries which may be used to avoid some of the reciprocity issues faced by proprietary developers, in that use of dynamic linking doesnt necessarily trigger the derivative work clause.
I Am Not a Lawyer (And You Probably Arent Either)
There are lots of good articles on the web discussing the pros and cons of the various open source licenses out there. Be warned, though: people get very passionate about these issues, and all too often some of the arguments are, shall we say, legally misinformed. If you are going to be using open source anywhere in your product, you need to do your own homework. And youll need to consider issues specific to your product and market, such as:
Will derivative works be important? What about relicensing and sublicensing?
Is reciprocity a good thing or a bad thing?
Are patent rights desired? Trademark rights needed?
Are copyright notice requirements okay? Other attribution notices?
License-compatibility with other source code you may use?
Contributor agreements: how will you assure the provenance of all your contributions?
Who has legal standing in the event of litigation?
Two excellent books [1] [2] should cover all the legal and strategic issues you need to know. Getting a lawyer on your team is always a good idea, of course, but as a practical matter it may be too expensive and not really needed: while it can get complicated, for most situations you can often figure out what you need without legal aid.
Links
[1] Open Source Licensing: Software Freedom and Intellectual Property Law, by Lawrence Rosen
http://www.rosenlaw.com/oslbook.htm
[2] Understanding Open Source and Free Software Licensing, by Andrew M. St. Laurent