Open-source software (or “OSS”) is computer software distributed under a license whose source code is available for modification or enhancement by anyone.  This is different than free (or public domain) software, which is not distributed under a license.  Free and open-source software are alternatives to “closed source,” or proprietary, software.

Companies use OSS for a variety of reasons.  In some cases, it’s used as part of a project deliverable, such as a DLL or a JavaScript library. In others, it’s used as a tool as part of the development process or production environment, such as a compiler, development environment, web server software, database software, etc.

The Rewards of OSS.  There are significant benefits to using open-source software in your business.  Here are some of the most significant:

• Enhanced Security. Anyone can modify and enhance OSS, resulting in a larger developer base than proprietary software. This means that security holes are often found more quickly, and patched more quickly, than proprietary software.
• Lower Cost. There is no license fee for open-source software.  (That does not mean it’s totally free – OSS is subject to license requirements.)
• Dev Cycle Streamlining. Using OSS in a project cuts down development time by allowing developers to avoid “reinventing the wheel” on needed code if an OSS version of that code is available.
• Perpetual Use. As long as you abide by the terms of the open-source software license, you can generally use it forever.  There are no annual renewal fees or license renegotiations for mission-critical software.
• Adaptability/Customizability. Users of closed source software must find the software package that most closely aligns with the business’ needs, and adapt to it.  There’s no need to settle with OSS – since it can be customized and adapted, you can start with the existing code and modify it to fit your company’s exact needs.
• Better Quality. Since there is a larger developer base, new and enhanced features and functionality are often rolled out, and usability bugs fixed, at a more rapid rate than in proprietary software.
• Support Community. Many common closed source software packages require the purchase of a maintenance subscription along with a license.  Well-used OSS has a robust developer community that can help with questions.There are also companies that have sprung up around common OSS packages to provide support solutions.

Know Your OSS Licenses.  The author of software code owns the copyright to that code.  If the author released software into the public domain, he/she is waiving his/her copyrights in that code, making it free for anyone to use.  However, if someone creates a derivative work of public domain code, the new portions of code are protected by copyright, and are not in the public domain.  In other words, by adding his/her own modifications, someone can take public domain software and make it proprietary.

That’s the primary difference between free software and OSS.  In most cases, when an author makes his/her software code open-source, that author is allowing use of his/her copyrighted code under an open-source software license, but is not relinquishing his/her copyright.  Under the OSS license, the author grants others a right to use the author’s copyrighted code to modify, copy and redistribute it, but only if they follow the terms of the open-source software license.  There are hundreds (or more) open-source licenses out there.  However, there are relatively few that are considered generally accepted with a strong developer community.  The Open Source Foundation (OSF) categorizes the most common OSS licenses here.  The most common are the GNU General Public License (GPL), the GNU Lesser General Public License (LGPL), the “New” BSD License, the “Simplified” BSD License, the MIT License, and the Apache License v2.  However, not all OSS licenses are the same.  There are many websites that can help you analyze the differences between OSS licenses, including tl;dr Legal and Wikipedia’s Comparison of Open-Source Software Licenses.

Many OSS licenses are “permissive” licenses, meaning that a work governed by that license (e.g., a BSD License) may be modified and redistributed under a different license as long as you comply with the requirements of the permissive license (e.g., attribution). Other OSS licenses are “copyleft” licenses.  A copyleft license is one under which a work may only be used, modified or distributed if the same license rights apply to anything derived from it.  The copyleft license will “infect” modifications and derivations of the source (some think of it as a “viral” license).  It’s a play on words as copyright and copyleft are converse terms: copyright gives exclusive rights to a work to one person, and copyleft gives non-exclusive rights to a work to everyone.  There are two types of copyleft licenses:

• “Strong” copyleft licenses (e.g., the GNU GPL) state that if you modify code governed by a copyleft license, you must distribute the software as a whole under that copyleft license, or not distribute it at all.
• “Weak” copyleft licenses (e.g., the GNU Lesser GPL) state that if you modify code governed by a copyleft license, portions of the software containing modifications (e.g., a software module or library) must be distributed under that copyleft license, but other portions may be distributed under a different license type.

The Risks of OSS.  Due to its benefits and rewards, most companies use open-source software, whether the management and Legal teams know it or not. Quite often, developers rely on OSS to deliver software development projects on time and within budget. The bigger question is whether developers are using OSS in a way that exposes the company to risk.  Unless your company has a well-defined OSS policy that has been well-communicated to the developers at your company, you’re “flying blind” when it comes to OSS usage. Here are some of the risks and considerations for companies using OSS:

1. OSS makes more sense for “utility layer” software needs than for “competitive/proprietary layer” software needs. Think of the software used in business as two layers. The first is software at the “utility layer” – software packages that go to the general operation of the business and its IT infrastructure, and do not give the business a competitive advantage based on the code itself. Examples are web server software, database software, and standard APIs.  Above that is the software at the “competitive/proprietary layer” – software that gives your company a competitive advantage you’re your competition, or provides significant offensive or defensive IP protection. Examples are custom functionality on your website and specialized software applications. OSS makes a lot of sense at the utility layer – you don’t need something better than everyone else, just something that works and works well. Introducing OSS at the competitive/proprietary layer can be problematic as you may want to ensure the entire solution is proprietary.

2. You can’t get IP warranties or indemnification for OSS. When you negotiate a software license agreement for proprietary closed source proprietary code, in most cases the software licensor will provide warranties and/or indemnification against claims of IP infringement. With OSS, there is no IP warranty or indemnity. If someone introduced proprietary code into the OSS earlier in its life, you bear the risk of infringement if you use it.

3. Some OSS license types can snuff out IP rights to your own developed code (and even expose it). The type of OSS license governing OSS used in your business, and how you use OSS software, can directly affect your IP rights to your own developed code. If you use OSS governed by a strong copyleft license to enhance your own codebase, your entire codebase could potentially become governed by a copyleft license.  This means that a savvy competitor or customer that suspected or learned of OSS in your code could send you a letter demanding a copy of your source code under the copyleft license, or just decompile it and modify it, putting you on the defensive as to why your software license should override the copyleft open source license.

4. If you don’t follow the license terms, you can be sued. Open source software is licensed. That means there are license terms you must follow.  If you don’t, you may face litigation from competitors or others.  There has been a recent upswing in litigation for breach of the terms of open source licenses, and that trend is expected to continue.  For example, VMware was sued in March 2015 alleging that it violated the GNU GPL v2 license by not releasing the source code for VMware software that used OSS subject to the copyleft license.

Implement a Company-Appropriate OSS Policy.  To mitigate the risks associated with OSS, all companies should implement an open-source software policy governing the when, why and how of using open-source software in the company’s codebase.  Here are some important considerations:

• Ensure there is alignment on the goal of the OSS policy at the outset. Different stakeholders may have different views on the goal of an OSS policy.  To Legal, it make be to protect the company’s intellectual property; to IT, it may be to leverage OSS to reduce costs; to developers, it could be to ensure they are free to keep using the OSS they need to meet goals and deadlines.  One thing stakeholders cannot do is go in with the mindset that OSS is bad for business or that they can keep it out of their code.  OSS in business is a reality that can either be ignored or accepted.  The policy’s goal should be to ensure OSS is being used effectively to advance the company’s business objectives while protecting its IP and living within its risk profile.
• An OSS policy must balance the practical needs of developers with risk management. OSS is the domain of the developer, not the Legal department.  While the risks are something lawyers consider, a policy written and imposed by non-developers on your developer corps will likely face an uphill battle, or worse, be viewed as “out of sync with the goals of the business” and just ignored.  The attorneys’ role in creating an OSS policy is to provide guidance on the risks of OSS to the company as a whole, provide “best practices” guidance in OSS policies, and to draft the actual policy from the outline in plain English (remember, developers, not other attorneys, are the audience).  IT management’s role is to provide guidance on the outside contours of the policy.  Developers need to be directly involved in developing the policy itself as they are the ones using OSS in their daily work.  Developers, Legal and IT should develop the company’s OSS strategy, and its OSS policy, as equal stakeholders.
  • Ensure senior management buys into the policy before it is finalized; it’s important that management understand how OSS is used in the business.
  • Ensure the policy covers key topics, e.g., sourcing OSS; selecting OSS code for use at the utility layer and the competitive/proprietary layer; the OSS approval process; support and maintenance requirements; redistribution; tracking OSS usage; and audits/training.
  • Ensure the policy covers independent contractor developers as well as employees.
• OSS code review and approval must be a streamlined process. If the review and approval process is complicated, developers will be more likely to just skip it.  Make approval easy.  Provide a “pre-approved list” of OSS – certain combinations of license types, utility level software categories, and/or specific code packages that only need notification of usage for tracking purposes.
  • Have a simple process for vetting other usage requests, asking the critical questions (e.g., What is the name and version number of the software package for which use is requested? What license type applies? Where was the code sourced from? Will the code be modified? What is the support plan?  Will the code be distributed or used internally?  What is the expected usage lifetime of the code? Are there closed source alternatives? Etc.) so that the legal and business risks can be measured and balanced against the benefits of usage.
  • Determine who will do the first review and escalated review (IT, Legal).
  • Turn requests quickly as delays can impact development timeframes.
• Keep a database of all used OSS, including where is it used and what license type applies. Knowing what OSS you’re using is critical to avoid introducing code that has a bad reputation or is governed by an OSS license your company is not comfortable with (e.g., a strong copyleft license). IT should maintain a database of OSS used by the company, including the license type for each OSS.  This database is also helpful when responding to security questionnaires and is often needed in M&A due diligence.
• Other Considerations. Consider conducting quarterly or semi-annual reviews of OSS usage, e.g., questionnaires to developers.  Consider having developers acknowledge the OSS policy at hire, and on an annual basis.  Consider conducting OSS training if your company’s learning management system (LMS) has an available course module on OSS.  And most importantly, review the OSS policy no less than once a year with all stakeholders to ensure it is evolves as the world of OSS, and the company’s own needs, change over time.