Technology companies widely use open source software (“OSS”), which carries with it many potential benefits.  It can reduce the time and cost of development, and, to the extent that the code has been vetted by numerous other developers, may contain fewer bugs.  OSS can also reduce dependency upon third party vendors and associated pricing risks.

In the healthcare space in particular, OSS has been cited as one potential way to reduce the cost of developing and delivering digital care solutions, which in turn may mean improved access to or quality of treatment for underserved populations.¹And indeed, OSS is frequently used in healthcare IT.  In fact, the EHR system for veterans, VistA, is available as open source code² and now deployed by a range of healthcare organizations.³

Of course, as with any third party technology, when incorporating OSS into a technology, it is important to carefully consider the soundness and security of the OSS code, as well as the legal terms on which the code is made available.  Below we highlight some key considerations for digital health ventures that either currently do or wish to use OSS for their technology: (1) security, (2) how license terms may impact the ability to commercialize the technology, and (3) how the use of OSS may impact corporate transactions, such as mergers and acquisitions.

1. Security

For digital health ventures, privacy and data security are of preeminent importance due to the nature and quantity of sensitive information that such businesses tend to collect.  While open source code may give developers greater opportunity to vet software for bugs, it also makes it easy for hackers to analyze vulnerabilities, and exploit them.  By targeting vulnerabilities in widely-used OSS, hackers may do significant harm.  Moreover, OSS is frequently distributed with a disclaimer of all warranties and without indemnification provisions, which may mean that a business has little recourse against the OSS provider should the OSS give rise to a security incident.  By contrast, with proprietary solutions, it may be possible to negotiate some warranties and/or indemnities from the vendor, which could provide the business more recourse in the event of a security incident.

It is also important to note that updates to open source code are not generally pushed through to users unless the OSS distribution is supported by a commercial entity such as Red Hat; for much OSS, businesses must track and implement these.  For entities that are regulated by HIPAA, carefully vetting third party solutions and security updates are of particular import, in order to meet regulatory obligations, such as those under the HIPAA security rule.

2. Commercialization

Most OSS licenses include restrictions and requirements that apply when the licensed software is commercially distributed.  For example, some open source licenses contain “copyleft” provisions that can, depending upon how the OSS is used, require a company to disclose and provide to customers proprietary source code that has been commingled with the OSS.  Whether these provisions are triggered depends on usage; just because a technology contains “copyleft” OSS does not mean that the “copyleft” license provisions are triggered.

To provide an example, the GNU General Public License Version 3 (“GPLv3 License”) requires that any derivative works incorporating the OSS also be provided under the same royalty-free GPLv3 License, and that the source code for such derivative works be made available to the recipient of the work.  However, these obligations are only triggered if the derivative work is distributed to third parties (e.g., making the software available for download onto consumer’s computers, or distributing hardware that contains embedded software).  The general view is that under a Software-as-a-Service (SaaS) model, in which the software is hosted and accessed as a service over the Internet, there is no “distribution” of the software, and thus no trigger of the copyleft provisions of the GPLv3 License. That said, certain SaaS solutions may trigger copyleft provisions in other licenses such as the GNU Affero General Public License.

It is therefore important for the business to keep track of the open source code it is using, and how it is using it, to ensure that the business does not inadvertently trip any licensing wires.  Even if a business does not view its solution as particularly valuable at present, in some situations taking measures to protect a technology may be worthwhile for the longer-term, as future acquirers or other investors might view the software as valuable (or, a strategic buyer may wish to combine its proprietary software with such code, which could have the effect of exposing a buyer’s technology to copyleft licensing obligations).

3. Implications for Corporate Transactions

Even when a business does not distribute software (for example, because the business operates on a SaaS model), it is still important to be aware of and track OSS usage.  One reason is that OSS usage is a very common subject of due diligence during acquisitions and other corporate transactions.  Buyers are likely to investigate a target’s software development practices and may even hire third parties to audit key software assets for OSS, including by using technology that scans for the presence of OSS.  Developing clear policies and procedures around software development, including by carefully vetting, tracking and managing third party code including OSS, and operating a systematic approach to license compliance, can save on time and transaction costs down the line, and will give buyers and investors less grounds for raising concerns on a deal.  OSS presents many potential benefits, but those benefits are only fully realized if a business takes some steps to appropriately manage the use of OSS within their organization.

[1] See, e.g., Syzdkova, Assel, et al., Open-Source Electronic Health Record Systems for Low-Resource Settings: Systematic Review, JMIR Med. Informatics, 2017 Oct.-Dec., https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5703976/.

[2] See About Vista, http://worldvista.org/AboutVistA (last visited Jan. 25, 2018).

[3] See Other VistA Adopters, http://worldvista.org/AboutVistA/copy_of_index_html (last visited Jan. 25, 2018).