At last count, the Open Source Initiative (OSI) recognized nearly 60 different open source licenses. If you just want to install and use a packaged application, the license under which it was released shouldn't matter much. But it's particularly important to pay attention to licensing terms if you want to modify the code or use it in your own projects.
Easily the most recognizable open source license, and one of the most popular among developers, is the GNU GPL (General Public License). The GPL can be a problem for companies looking to develop proprietary applications because of its strict guidelines on reciprocal code sharing.
This problem led to the GNU LGPL (Lesser General Public License), which grants access to source code but still allows limited use in proprietary products without triggering a general source code release clause. JBoss favors this license, which is also the preferred license for various kinds of code libraries.
Another attempt at a commercial-friendly open source license is the BSD License. Many open source advocates view both the LGPL and especially the BSD License as being unfavorable, however, because they allow outside developers to use code from an open source project without giving anything back.
In an attempt to appease both camps, a number of open source vendors have turned to a dual-licensing model. They make their code available under the GPL but also offer a separate, commercial license for companies that don't want to be subjected to the GPL's terms. MySQL and Red Hat are well-known vendors that use this model.
There are dozens of other OSI-approved open source licenses, but many are similar on the point of redistribution. It's also important to note that the vast majority of open source licenses grant their developers complete immunity from warranty or support.
A particular headache for businesses, however, stems from the proliferation of so-called vanity licenses. Rather than standardizing on any of the more than 50 licenses that the OSI has approved, many vendors insist on drafting their own license. Although the terms of these licenses are often similar to those of OSI-approved licenses, they usually differ on some minor -- and occasionally major -- points.
Unfortunately, each new license you add to your environment calls for a new round of due diligence to ensure that the license's terms are favorable to your company's business practices. That means additional costs and lost time to market. And in some cases, the new license might actually be incompatible with the licenses of the software you're already using. So while a certain vendor's license terms may indeed turn out to be favorable in the end, sometimes it pays to stick with the ones you know.