The past 14 years of my computer programming career have been a joy thanks to the existence of open source software. Using open source libraries allow me to create software quickly without having to implement certain tasks other developers around the world have completed. I’m able to dig through the source code to learn how certain technologies work. I’ve even become a better programmer because of reading other people’s code. When building a commercial product that uses open source software, educating yourself on the various open source licenses is mandatory to avoid litigation over how you use that open source software. The purpose of this two-part blog series is to give a brief overview of the major open source licenses and list some applications that use an open source license and companies that contribute and distribute open source software using the discussed licenses. The focus of these blogs is for companies that wish to sell and distribute their applications that use open source software. If your application will not be distributed to customers (such as in a Software as a Service scenario), then all but the last license (discussed in part two) do not apply.
Apache and BSD
These licenses provide developers and software companies with the most leniencies when distributing software that uses libraries released under these licenses. You are free to modify the source code and release the results as a commercial closed-sourced product. All that is required is that the license file and any files acknowledging the authors of the original Apache or BSD licensed software remain intact. The BSD Unix operating systems use different versions of the BSD license. Apple’s closed source Mac OS X were legally allowed to use parts of FreeBSD and NetBSD. The Apache Web Server (most used web server on the Internet), the mobile operating system Android from Google, Derby (an open source embedded database for Java), and thousands of other open source software use the Apache license.
The Eclipse Public License is slightly more restrictive. You can still bundle object code generated from source code licensed under the EPL. Where the EPL differs is that any modifications to the original software released under the EPL constitute as derivative work, and all source code to the derivative work must be released under the EPL. However, if a module was written that requires the EPL’d software, then that module does not have to be released under the EPL since a module depending on EPL’d software does not count as derivative work since the source code to the EPL’d software is not modified. Eclipse uses this license.
The GNU Lesser General Public License is very similar to the EPL. An application’s source code does not have to be released if it is dynamically linking (where the link is formed when the program is executed) to the LGPL’d library. The source code has to be released if it is statically linked (application’s produced object code contains the LGPL’d library). JBoss and OpenOffice.org use the LGPL.
The EPL and LGPL are weak forms of copyleft licensing, which is a viral type of open source software licensing that requires your application to use the same copyleft license as the libraries your application depends on. In part two, I will discuss the stronger copyleft licenses GPL and AGPL along with citing examples of companies that give back to the open source world.