Before I jump into my topic, here is some background for those new to open source licenses.
Open source licenses, like any license, grant the licensee certain rights that are usually reserved by and for the copyright holder (the author of the open source software (OSS) code), and spell out conditions that must be met by the licensee. You may use the OSS according to the grants given, so long as you comply with the requirements of the license.
The first question to ask regarding potential copyright infringement: Is there an act involved that is restricted by copyright law? If there is, you need permission from the copyright holder to proceed with that act. If the copyright holder has granted a license, you must comply with the conditions of that license. In the case of open source licenses, the operative question ends up being: Is there a distribution? Distribution is the key act that triggers the license requirements of most open source licenses. If there is a distribution, there must be compliance by the person or entity making the distribution.1
Distribution, under copyright law, occurs when a copy is transferred to another person or entity.2 So, if distribution is the key trigger, it follows that how you use open source will ultimately affect applicable compliance requirements.
To keep things simple, here are four main types of general usage models: 1. Internal use, 2. Software as a Service (SaaS) or hosted applications, 3. Commercial software applications, and 4. Commercial hardware applications and embedded systems.
Consider your usage situation to make an assessment of your risk, and the overall effort required to comply with the various OSS licenses. The types of usage models are listed in an increasing order of complexity and associated risks.
1. Internal use. There is a myth that if you use OSS for internal projects, you never have any compliance requirements. While initially you may have very little to no obligations, you still need to consider the future implications of open source compliance. The main concern is whether the application may someday be distributed. For example, say you create an internal website where you host an application, then later make the application available to contractors or partners. At that point, you are technically distributing the application outside your organization, and additional compliance steps may apply. While you may not have any explicit compliance obligations initially, it is important to track the use of OSS in your internal application in the event it is ever distributed.
Another consideration is acquisition. While acquisition of your application may not trigger additional compliance requirements, the acquiring party may want to know what third-party applications and licenses are used in your application. It is much easier to track OSS as you build it into your application than it is to search for it later.
2. SaaS or hosted applications. In the example above, additional compliance steps “kick in” when making an internally hosted application available to users outside your organization. The good news is that those triggered license requirements, if any, are minimal. But, let’s look at potential additional requirements. While a primary concern centers around obligations triggered on “distribution,” how does that translate in the case of a hosted application? In this case, you can think of distribution in terms of the location where the application runs. In hosted applications, the majority of the application code probably runs on an organization’s computer systems. (For purposes of this article, we will not go into the implications of Cloud-computing compliance.)
There are some licenses that include access via a computer network to be a distribution. Most notably Affero General Public License v2 and v3 (AGPL) and the GNU General Public License v3 (GPL) was specifically written to address the issue of distribution as it pertains to hosted or network-based applications.
3. All advertising materials mentioning features or use of this software must display the following acknowledgement: "This product includes cryptographic software written by Eric Young (firstname.lastname@example.org)" The word 'cryptographic' can be left out if the routines from the library being used are not cryptographic related :-).
4. If you include any Windows specific code (or a derivative thereof) from the apps directory (application code) you must include an acknowledgement: "This product includes software written by Tim Hudson (email@example.com)"
4. Commercial hardware or embedded system. Hardware and embedded systems add a bit of complexity that may not be present in software only distributions. With software, any additional software dependencies can often be placed as requirements the end user fulfills. For example, the Java Runtime Environment: there is no need to include a copy (and worry about complying with its license), simply have your customer download and install it.
With hardware systems, you may not have that luxury, and may need to bundle additional components, adding the complexity and risk associated with compliance. Another key consideration for embedded systems is the inclusion of operating system components. Most OSS kernels and utilities are licensed under GPL. With the inclusion of these components, you now need to consider how the components and the code you have developed interact with each other. Depending on whether you have modified the kernel, or how closely your code works with the kernel, may trigger obligations tied to derivative works. To understanding these types of obligations better, I recommend you look at the Licensing FAQ 3 supplied by the Free Software Foundation, or read the excellent guide to GPL compliance hosted at the Software Freedom Law Center. 4
The value of using OSS far outweighs the extra effort required to comply. And making sure you comply significantly lowers any potential legal risks associated with using it. Compliance is a “win/win” situation for all involved.
What distribution models are you using?
1http://www.openlogic.com/blog/bid/226481/Apps-App-Stores-and-Open-Source-Part-22For more about what constitutes "distribution" under U.S. copryight law, see Heather Meeker's 'The Gift that Keeps on Giving – Distribution and Copyleft in Open Source Software Licenses', IFOSS L. Rev., 4(1), pp 29-40, available at: 10.5033/ifosslr.v4i1.663http://www.gnu.org/licenses/gpl-faq.html4http://www.softwarefreedom.org/resources/2008/compliance-guide.html
Dave has worked various sales, technical, and management positions in the microcomputer software industry for over 25 years. He first joined OpenLogic in 2006 in a technical sales positions and has since helped the company in developing its open source content strategy and technical support department. Currently, Dave is the director of open source software auditing services. He lives in Boulder, Colorado with his wife and two sons. In addition to his love for all things technical he also enjoys running and playing the trumpet with the local community orchestra and various jazz groups in the area.
Allowed tags: <a> link, <b> bold, <i> italics
If you read a post on The Enterprise OSS Blog, please leave a comment. Let us know what you think, even if it's just a few words. Comments do not require approval, but they are moderated.OpenLogic reserves the right to remove any comments it deems inappropriate.