Open Source Software ("OSS") is important business to your company. The improper integration of OSS into your company's information technology systems can impact company value. It has been estimated that intellectual property makes up 75% of the valuation of U.S. companies. Even if your company is not a seller of software, if OSS is not handled correctly, your company valuation can be affected.

There are tens of millions of lines of OSS source code available at no charge on the Internet. Developers are under pressure to meet deadlines and meet expense budgets. It is perfectly all right to use OSS to complete a software development project, as long as it is documented. OSS is available at no charge, yet it is not actually free because it comes with a license with certain encumbrances.

What is Open Source Software?

What is Open Source Software? First, source code is the English language version of software. It includes words such as "add", "move", "search" or "print". Source code is then passed through a compiler or interpreter such as Linux which then produces "object code". Object code is binary code in "0" or "1" (with a switch inside the computer either being "off" signaling a 0 or "on" signaling a 1). Humans can read and understand source code but cannot understand binary or object code. Thus, to have workable software that can be modified and maintained by a software developer, the developer must have the source code. If there is a bug in the code which needs to be fixed, the fix would have to be made to the source code and then the code would be run again through the compiler or interpreter to generate new object code which no longer includes the bug. Most software licensed by software owners is given to the licensee as object code. If the object code needs to be maintained, the licensee then must go back to the software owner, who can make the fix to the source code, to which the licensee does not have access.

Thus, the advantage of OSS is that the user can perform its own maintenance without the need to return to the vendor for a bug fix. This is a two-edged sword. Many users have no interest or skill in maintaining their own software -- they are very satisfied for the software owner to perform maintenance. But for those sophisticated users who want to perform their own modifications, OSS is a good vehicle.

What is in the License?

At last count, the Open Source Initiative ("OSI") listed 69 OSS licenses on its website. The best known OSS license is the GNU General Public License ("GPL"). These OSS licenses have become known as "Copyleft" licenses, which generally require that (i) if a company distributes code which includes the OSS code, then source code must be provided with the distribution; (ii) if the OSS code is distributed, it must be distributed under the same OSS license from which it was initially licensed; (iii) it is not required that te distributor contribute back to the original OSS code base; and (iv) there is no restriction to the use and modification of the OSS code.

Some of key elements of the GPL license are as follows:

  • The source code may be copied and distributed.
  • A copyright notice and disclaimer of warranty must be conspicuously published.
  • A fee for the physical act of transferring a copy may be charged.
  • The source code may be modified and distributed provided that (i) the modified files carry prominent notices that they have been changed, (ii) any modified program that in whole or in part contains the original OSS must be licensed at no charge to all third parties, and (iii) a notice must be displayed that there is no warranty.
  • The requirements apply to the modified work as a whole -- if identifiable sections of the work are not derived from the OSS and can be reasonably considered independent and separate works in themselves, then the OSS license terms will not apply to those sections distributed as separate works. But if the same section is part of the whole, then the OSS license does apply.
  • The object code may be distributed separately, but it must be accompanied by an offer to provide the source code at no charge.
  • If the modified code is distributed in violation of the license, then the original OSS license is void and automatically terminated.
  • The recipient of the modified software cannot have any further restrictions on the right to modify or distribute.
  • There is no warranty and the program is provided "as is."
  • In no event will the party who modifies and distributes the program be liable for damages.

Steps to reduce OSS risk

There are two types of fundamental risk for OSS. The first and most significant issue is the incorporation of OSS into a company's proprietary software and the effect of such incorporation. The second is the acquisition of a software (or other) company in which due diligence must be performed to determine whether the value of the software has been diluted by OSS. There are a variety of ways that companies approach OSS compliance. Some companies take a no-holds-barred approach and simply ban the use of OSS. This can be counter-productive in that the company limits its use of what could save it a great deal of development money; it is also difficult to enforce and could decrease productivity. Another approach is just ignoring the issue -- that approach is fine until a cataclysmic event occurs such as when the company is being sold and the OSS problem becomes front and center. Ignoring the issue could also result in major rewriting of the code or reputational damage to the company.

The best approach is for a company to take a number of steps to reduce the risk of OSS infecting the company's proprietary software:

  1. Appoint a Chief OSS Officer. Most companies are not going to have a Chief OSS Officer in the way they have a CIO or Chief Privacy Officer. But the risks of OSS are so significant that a company should have a senior officer in the IT department whose job it is to monitor use of OSS. This senior officer can implement policies, monitor OSS usage and give advice and guidance to the programming staff when needed.
  2. OSS Policy Implementation and Compliance. The CIO and OSS officer should set up a policy for usage of OSS. The policy should be relatively brief, or no one will read it. There should be clear guidelines with permission required if OSS is going to be integrated with proprietary software. The company should be certain that any third-party contractors are aware of the guidelines, and that there are repercussions if such contractors fail to follow the guidelines. The senior manager could be someone already part of the IT or compliance department.
  3. Independent Modules. OSS software can be segregated from proprietary software. If OSS is integrated into a software module, that module is no longer proprietary. There should be independently created interfaces between an OSS module and a company's proprietary software.
  4. Retain License Information. Whenever OSS is used, the license associated with the OSS should be printed out and retained. The OSS Compliance Officer should maintain copies of all these licenses. The Officer should also have most or all of the 69 licenses available so that the applicable license can be matched against the existing licenses.
  5. Document Any Modifications. Any modifications and changes made to the OSS should be documented. This can be accomplished by flagging all of the original OSS code with an identifier. Any further modifications should also have their own identifier in the code.
  6. Establish Controls and Checkpoints. There should be controls and checkpoints at critical stages during the "build" of a software project -- (i) when software is first added to a project, (ii) when internally developed software is created or modified (iii) at each transitional phase in the development process and (iv) when considering modifications on an open source project.
  7. Identify Development Phases When Component Reviews Will Be Conducted. In any development process, the phase for component review should be identified.
  8. Verify Every Final Software Product Before Release. Before final release of a software product, create a defined verification phase during which questions can be posed about all components of the product.
  9. Scanning. Some companies perform scanning of all OSS. This is an extra step which can be time consuming, but it is a good way to preserve a "time shot" of the OSS which can then be traced subsequently in the project.
  10. Headers. Headers in the OSS should not be disturbed and any comments included in the headers should be retained.
  11. Re-Naming. If at all possible, do not re-name modules in the OSS. This will make it easier at a later date to trace the original source code.
  12. Check the License. Sometimes the OSS license is too restrictive. Oftentimes, the same software can be licensed using a different, less restrictive license.
  13. Intellectual Property Risk. Even small changes to OSS code can affect a company's ability to file for patents or may impact a patent license.
  14. Interface Documentation. Interfaces between a company's proprietary code and OSS should be carefully documented.
  15. Cross-Disciplinary Approach. A cross-disciplinary team should be established for OSS compliance which includes legal, management and software engineering. The roles, responsibilities and leadership should be clearly established.

For any custom software purchase, a code audit and due diligence must be performed. There are companies which specialize in this activity, and they should be retained to assure that the value being paid for a software product will not be undercut.