Many companies use open source software to produce goods and services, and many also actively develop software using open source libraries and modules. Open source software is commonly used for online software services, smart phone apps, downloadable executables, or embedded in the memory chips of physical products. Its use has grown because open source software is easy to obtain, actively maintained by a strong user base, performs well, and best of all, it is free. This makes it an easy choice, especially for young start-up companies trying to preserve precious capital. However, open source software relies on copyright law and built in license agreements to keep it “open”. Confusion about the legal issues involved tends to give rise to a number of misconceptions about open source software.
It’s free – so there are no restrictions to worry about. “Free” in the open source context means free to use within the confines of copyright law and according to the terms of the open source license. Open source license agreements are self-executing which means that a user does not have to click “I accept” when downloading open source code – but the terms of the open source agreement are still binding on the organization. Also, different open source software packages may be subject to different terms. There are currently at least 80 different open source licenses in play, and using multiple open source packages in a large system may mean agreeing to licenses that have conflicting terms. Failure to consider these issues in advance may be crippling. A long development effort could be wasted if the combined product includes open source modules with conflicting license terms that make it impossible to distribute the end product.
Our legal department will handle the licensing issues. Open source licenses are self-executing. That means a software developer who uses the software has already entered into a binding software license regardless of whether the organization has granted that individual the authority to do so. This is true whether the open source modules are used in-house or distributed as part of a product or service. The corporation would likely be required to abide by the license terms, whether or not management was aware of the license. Also, once the open source material is part of the end product or service, the corporation is vulnerable to the threat of termination of the license if the terms of the license are not met. On termination of the license, any later use of the software would infringe the copyright.
It’s a minor software thing, and not that big of a deal. Not true. Discovery that open source software is in use may come at the most inopportune times during a merger or acquisition, when an IPO or venture capital financing deal is in the works, or in litigation. This can leave the organization scrambling to resolve critical issues at the worst times. Finding this out at critical times may cast a negative light on the entire organization and can dramatically change the outcome. For example, when IBM was negotiating to acquire Think Dynamics in 2003, the discovery of open source software that was previously unaccounted for resulted in a reduction in the final offer from $67 million to $46 million.
We didn’t change the open source code, so we have no issues. Maybe. It is true that open source licenses usually require that modifications to the open source software itself must be licensed according to the terms of the original license – meaning they must be freely distributed to anyone who uses the software. Thus, modifying your copy of the open source code to include your proprietary algorithms is generally a bad idea if you want to keep them under wraps. But what if the open source code is unchanged, but it is compiled into a single executable with the proprietary code? What if the open source code and proprietary code are compiled separately and dynamically linked at run time? Does a mere reference to a simple sort routine or hash table algorithm in an open source library put the entire code base under the open source license? The answer is “probably not”, but no one can say for sure, and other specific details about the software could change that outcome. This area is especially gray because the courts have not decided what constitutes a derivative work in the open source context. Some open source licenses clarify things a little, but generally speaking, the full legal ramifications of using open source software alongside proprietary code are still unclear.
