With the majority of companies using open source, it’s important to understand the underlying licenses associated with the software and projects. Chances are developers in your organization are using different open source projects to build software and applications for your company, so it’s imperative that you fully know what’s involved and the implications. Unfortunately, licensing can be confusing and is typically written in legalese that isn’t easily understood and choosing a project based on the wrong license type can open the door to a legal nightmare for a company. I’m hoping this blog will provide a bit more context to help you navigate through the Open Source licensing maze.
We’re going to look at two major types of licensing: GNU General Public Licensing (GPL) and permissive licensing.
GNU GPL
There are four variants in the GPL family of licenses. They all have the principle of Copyleft as the basis, but each variant applies conditions that have increasing degrees of restriction.
Copyleft in its purest form is very strict– any modifications or extensions that you have made to open source that is based on a Copyleft license, must in turn also be open source. It can sometimes be negatively referred to as a “viral license” since you must license your new software under GPL.
“You may modify your copy or copies of GNU Emacs …provided that you also …cause the whole of any work that you distribute or publish, that in whole or in part contains or is a derivative of GNU Emacs or any part thereof, to be licensed at no charge to all third parties on terms identical to those contained in this License Agreement.”
Created by Richard Stallman, Copyleft was based on the philosophy of “software freedom for all” and used for GNU projects in the mid-80s. In 1989, GPLv1 was developed as a subroutine by the Free Software Foundation so that everyone could use it. Over the years, two newer evolutions of the licensing emerged (GPLv2 release in 1991) and GPLv3 (released in 2007). While GPLv2 may have replaced GPLv1, GPLv3 did not do the same for GPLv2, so currently both of are being used today…depending on the project (read the fine print!)
LGPL
The introduction of Lesser General Public License (LGPL) by the FSF provides slightly less restrictive licensing that “…allows developers and companies to use and integrate software released under the LGPL into their own (even proprietary) software without being required by the terms of a strong copyleft license to release the source code of their own components.”
The ability to combine LPGL with other proprietary code makes it more flexible and can be seen as a compromise between GPL and more permissive licensing. An example of LPGL licensing is C on Unix.
Permissive Licensing
While Copyleft is seen as restrictive and will not be suitable for your proprietary projects, there are a few other projects that use “non-copyleft” or permissive licensing that you can comfortably leverage in your organization.
Both Apache 2.0 and MIT licenses allow you to sub-license it without restrictions, and work with or build on it commercially. Another popular permissive license is BSD-style (Modified BSD and FreeBSD–without the endorsement clause) which gives similar flexibility for commercial purposes, but doesn’t explicitly mention sub-licensing. Patent grants is another item that you need to watch out for when reviewing licensing for software–this is only automatically done with an Apache 2.0 license.
ActivePerl, ActivePython, ActiveTcl Licensing
Given the issues and the level of complexity associated with licensing, we recognize the many layers involved in ensuring that your company is compliant and on-side from a legal perspective.
We base our language distributions on permissive licensing. For Perl, we build ActivePerl based on the Artistic 1.0 license. This is a permissive license formulated for Perl that grants freedom to modify and redistribute the software freely. With Python and Tcl, they also have their own custom license that enables users to distribute their software without requiring companies to open source their code.
As part of our enterprise offering, we review as many as 280+ licenses when putting together our distributions with customized modules and/or packages to ensure our customers are not out of compliance. Companies who purchase Enterprise contracts from ActiveState avoid the nightmare of having to review each individual module license (for compliance and restrictions) themselves and instead let us do all the heavy legal lifting.
In a nutshell, when enterprises purchase our software, they are entering into a license agreement with ActiveState and our terms and conditions act as the Master License and overwrite the terms of licence at the open source language level. However, it’s important to note that if you’re using modules NOT sourced by us (i.e. not part of our core deliverables), then you are responsible for understanding and knowing the licenses associated with them…they are not governed under the ActiveState agreement.
Indemnification
I’ve talked about indemnification before in prior blogs and can’t stress enough the important role it plays. We often casually refer to it as an “insurance policy” that protects you and your company against licensing “accidents” such as potential IP/copyright/patent infringement lawsuits from community contributors to open source code. When a product is based on open source (like our code is), vendors can’t provide indemnification “out-of-the-box” the way a proprietary vendor can because there are a large number of added checks that need to happen to protect both the vendor and the vendor’s customers.
Conclusion
It’s important for every user of open source projects to have a clear understanding of what lurks in the licensing especially as they decide on what open source projects to leverage for their own applications. Being caught in the GPL spider web is a major hassle that organizations looking to produce their own software just don’t need. However, if you decide that you do want to build proprietary deliverables then our first piece of advice is to stay away from GPL based projects. If you just can’t for some reason, then make sure that at a minimum that you tightly manage all licensing aspects, scan for open source and fully understand the potential risk.
For companies who do use our Enterprise language distributions they know that they are getting not only the validated language builds, core modules/packages that we’ve included, but also the guarantee that there are no “active GPLs licenses in play” which leaves them free to modify and tweak as they need without repercussions down the line.
Title image courtesy of Arek Socha on Pixabay.
