Open source software: What you don’t know could hurt you
The old saying ‘if something is too good to be true, it probably is,’ applies
Open source (or so-called “free”) software has become a popular tool for software developers and technology companies that write software applications, because the source code is available at no charge and it saves the developer from having to write code from scratch or hire a third party to write it for a fee.
Aside from being available at no cost, open source software usually is provided without the typical copyright restrictions.
The Linux operating system is a well-known example of open source software. Because source code is the essential building block for writing computer programs, the availability of open source software has shortened the time and lessened the expense of creation of software applications by developers and technology companies. These savings frequently can be passed on to customers.
However, the old saying “if something is too good to be true, it probably is,” applies in some important respects to open source software.
The driving concept behind open source software is that the source code should be freely available for all to use, and if someone uses it to create new source code and a new application, that new source code should be freely available for others to use as well. While this relaxation from copyright protection and restrictions on use is great for developers who want to make their code available to others, it creates a potential trap for the unwary commercial software developer who incorporates open source code into a commercial program that it wishes to keep confidential.
The value in the commercial software typically comes from it not being easily figured out, so customers are willing to pay money to use the software application. But when a developer incorporates open source software into a proprietary application under a license agreement that requires the source code of the new work derived from the original open source code to be made freely available to others, the developer has a big problem.
Nightmarish result
Open source software typically is released through some sort of license agreement that imposes certain limitations on or obligations in connection with its use. Some license agreements can be as simple as requiring the user of the code to attribute its authorship to the original developer. Others, however, have far more stringent requirements. Perhaps the most well-known and widely used open source licenses are the various versions of the General Public License (GPL) put forth by the Free Software Foundation. Many open source software programs are issued under one of the versions of this license agreement.
The most significant aspect of the GPL is that it requires users of open source code who incorporate that code into their own programs and then distribute those programs, to make both the pre-existing source code and the source code for the new work available to recipients of the new software. This requirement arises when the new work is derived from or based upon the pre-existing code.
There is some question as to whether static or dynamic linking of the prior code with the new code, as opposed to modifying or adapting the pre-existing code, triggers this obligation. If it does, then even that type of connection also would require the source code for the new work to be made available to those to whom the new software is distributed.
And all those who receive the program may distribute it to anyone else with the source code. This scenario can be a nightmarish result for a software company that has developed a unique and potentially lucrative program, because the value in that program comes from others not being able to duplicate it. If others have access to the source code without restriction, they can make their own versions of the program, so they would have no reason to pay for the original program.
So what’s a software company to do? Here are some best practices to help minimize an unexpected adverse impact from using open source code in proprietary software:
• Educate your programmers about the open source issues and limitations
• Have a legal review undertaken of the license agreements applicable to open source code planned to be used to better understand the limitations and risks of using each piece of code
• Have each programmer involved in a project keep a log of all open source code used, including what programs it is incorporated into and how (this step is particularly important in case of litigation, or due diligence in connection with sale of your company)
• For each log entry, identify the applicable license version (e.g., GPL Version 2) and append a copy of the full license agreement to the log identifying which code it relates to
Open source can be a very efficient and cost-effective means of creating new code, so long as you know the limitations.
Douglas G. Verge, a shareholder in the law firm of Sheehan Phinney Bass + Green, chairs the Franchise Law Practice Group and is a member of the firm’s Intellectual Property Law Practice Group.
