Discern these open source license terms to avoid legal snags
Fluent in Ruby but at a loss in legalese? Open source licenses obligate developers to observe specific conditions, so you must know these terms. Let's break them down in plain English.
Open source code packages are essential elements of many software projects, as they enable fast, creative and collaborative development.
But open source software isn't public domain. Developers and business leaders must understand and adhere to open source license terms and conditions that govern distribution and use.
When license violations occur, the involved parties typically undergo mediation, arbitration or litigation over the matter. If a license holder seeks injunctive relief, it could prevent the infringer from distributing the noncompliant software, effectively taking it off the market. There can even be findings for actual and statutory damages.
Learn key open source license terminology
Legal standards, processes and outcomes vary among jurisdictions around the world, which often complicates open source software license entanglements. There are many possible implications, but many licenses cover the same familiar open source concepts and terminology. To safely work within an open source software license, developers and software project teams as a whole must understand this common legalese -- and consult legal counsel to evaluate any prevailing guidance.
Linking. A software development project can use numerous source code elements. These elements are linked, or combined, together to create an object, or executable result.
An open source license might specifically address the linking of code organizations release under that license, possibly limiting the rights to only link that code component with other code that shares the same -- or a similar -- license. This effectively limits the ways to use that code package.
As an example, most licenses, including Apache License 2.0, openly permit linking, while the GNU General Public License permits linking only with other GPL version 3.0-compatible licensed code. Other licenses, such as the Creative Commons CC BY-SA, impose copyleft restrictions which bind anything derived from original open source code by the same license conditions.
Distribution. Developers almost always redistribute open source software in some form, regardless of how much they modify it. An open source software license often specifically addresses how and where developers are allowed to distribute the code, possibly limiting how they deploy or share the resulting software project.
Most licenses, including MIT and BSD, permit distribution on a global basis. They might also outline the mechanisms of distribution, such as through flash drives or online downloads. However, the GNU Lesser General Public License, GNU General Public License and Mozilla Public License impose copyleft limitations to distribution. This effectively means that any project that results from use of that open source code requires the product to carry a corresponding GNU license, which might be undesirable for your project scenario.
Modification. An open source principle is freedom to use and modify the code. Developers rework code for many purposes, such as to improve performance or enhance compatibility. While an open source license might not restrict the use of a component, it can limit the rights to modify the code.
BSD and Apache 2.0 permit modification, while licenses like CC BY-SA, GNU and Mozilla impose copyleft restrictions that require any resulting modified code to carry the same license type and terms. Some other agreements, such as the Eclipse Public License, impose specific limitations on modification; for example, if developers modify a program and distribute the object code but don't charge for it, they still need to make the source code accessible. However, no open source license outright prohibits code modification.
Usage. Any organization can redistribute or publish modified, or forked, source code to the open source community under a suitable license. However, consider whether an obligation to release the resulting source code will affect the project. Some development projects generate valuable intellectual property. Developers should avoid integrating open source components into a code base if they intend to only create a proprietary product, as some licenses obligate the user to share modified code with the community.
Many open source licenses allow for private use. GNU GPL or Mozilla might obligate the user to retain the same license as the original code, but these open source license terms do not obligate the developer to release their forked source code to the community. Still, organizations with a sizable investment in intellectual property should pay close attention to the details of open source license terms and conditions. When in doubt, discuss the protection of intellectual property with legal counsel.
Relicensing. When an organization redistributes open source code in its unmodified form, the code typically retains the same license it initially came with. But when developers modify open source code and then redistribute it, the business might want to utilize a different license for the source code or binary code -- a practice called relicensing, or sublicensing.
Open source licenses, such as BSD, Apache 2.0, MIT and others, provide permissive terms to relicense code. However, Mozilla, GNU and other licenses that impose copyleft restrictions force open source code developers to use the same license for modified code. And some agreements, such as CC BY-SA, prohibit relicensing entirely.
When sublicensing code, it's not typically an issue to switch from one with more permissive legal terms to one with less permissive rules. For example, developers that obtain Apache 2.0 for open source code can modify and relicense it as GNU GPL 3.0 without issue. But it's impossible to go in the opposite direction, which presents conflicts in license use as open source code evolves.
Five open source licenses you should know
Open source agreements set the terms for how organizations must treat open source code. While various licenses cover a lot of the same aspects of software development and use the same open source terminology, the specific details can vary greatly.
Review the unique restraints imposed and freedoms granted by the likes of the Apache License 2.0, BSD licenses, GNU licenses, MIT License and the Mozilla Public License. Once you determine which policies fit your organizational needs, you can safely and smartly work with open source projects.
Patents and trademarks. Copyright laws typically cover software. Copyright is a type of intellectual property that gives the creator exclusive legal control over how, if at all, others can use and copy that work. But businesses are also concerned with patents and trademarks. A patent gives the owner the legal rights to decide who can make, use or sell an invention -- such as a process, in the case of software. A trademark is a unique identifier, such as a sign, design or phrase, that relates to a specific product or service.
An open source software license typically covers copyright, and it might also address patent and trademark terms -- important considerations for a business when intellectual property is part of its competitive advantage. Say a project involves the use of open source software with a patented algorithm to accomplish a specific task. Apache 2.0 and GNU GPL allow patent grants, including clauses that protect licensees from code contributors' patent claims, as well as protect contributors from licensees' claims. However, many open source licenses, such as CC BY-SA, do not cover patents. When the software involves patents, the license should also accommodate patents.
When the license includes a trademark grant, adopters can use trademarks related to the licensed code and its contributors. Trademark grants are relatively rare, and most open source licenses do not grant trademark rights -- at least, without specific requests. The GNU licenses are some that do.
