Open Source Software (OSS) is software with a copyright license that includes the right to view and alter the source code and to distribute derivative works. Usually, OSS is available free of charge and therefore offers the possibility to get a significant head start on your medical device development.

In this blog, I’ll be talking about using OSS libraries within a Software System of a Medical Device or In Vitro Diagnostic Device. You’ll notice that I’m using all sorts of IEC 62304 terms. Incidentally, the general term for software that has not been developed in accordance with 62304 for your medical device or IVD is software of unknown provenance (SOUP).

There are many different licenses, from highly permissive ones (like MIT and BSD) that impose few if any restrictions on the legal use of the software to more restrictive licenses (like LGPLV3) which force you to release derivative works under a similar OSS license and stipulate providing the capability to the user of modifying or upgrading the library.

Why use it?

Some OSS has such a vast community of contributors and users that it’s rare to have a problem that someone else has not discovered, fixed or addressed with a work around. This is often more effective than paying for a maintenance contract with a proprietary software vendor. Many OSS libraries are simply solving a problem that has been well understood for ages and someone felt it was worth putting the software out there freely to save others the effort.

Don’t underestimate the advantage of having the source code. Documentation is great, but if you really need to know the nuances of how code works – or doesn’t work – you can’t do better than looking at the source. Anyway, sometimes you can’t help using OSS. It’s almost impossible nowadays to use an OS that does not have a substantial amount of OSS in it.

Why not?

There are still a bunch of valid reasons to avoid OSS. Plenty of terrible code is out there; this is true for both open and proprietary libraries. Just because something is available does not make it valuable. It is your responsibility to decide whether a library is truly suitable for your application. Even if you decide to embrace the use of OSS, you should still think carefully about whether a particular library will truly help you. Often it’s more work to incorporate existing SOUP than to write it from scratch. Also, if a software item is Class C, you won’t be using any code that was not developed under 62304, open source or not.

What about license gotchas!

When developing medical devices and IVDs, there are many regulations and guidances that must be followed and these are often interpreted as incompatible with many licenses. One valid concern that comes up frequently is clause 4d of the LGPLV3. This states that you must either enable the user to alter and recompile the library, or to swap out the library with a newer version. How can we be sure that the safety and efficacy of our device will not be impaired by such an occurrence? After all, we’re the ones who are responsible if an adverse event occurs and someone is harmed. One solution might be to simply avoid code with this license. Another solution is to evaluate the potential risk and mitigate only if necessary. A possible mitigation is to make it clear to the user that altering the software configuration of the device – just like altering the hardware of the device – could impair its function. This could be augmented with GUI warnings if alterations are detected.

What to do?

It’s highly likely that whatever happens you will end up using some OSS. With this in mind, here are a few things that you should do. Keep track of what OSS you’re using and the licenses. Incidentally for Class B and up, there’s a bunch of required tracking, documenting and testing of SOUP; the additional burden of tracking licenses is often not excessive. Read and understand the license of each library you are thinking of using. Fortunately, most OSS uses one of just a few main licenses; you’ll become familiar with them and understand the implications of each.

Sometimes it makes sense to evaluate the implications of one of the terms of a license during your Risk Management process. If you can mitigate, great. If you can’t then don’t use it.

Decide whether the terms of each license are compatible with your business model. If not, then you can’t use that library. If the license forces you to release a critical piece of intellectual property then you’re stuck. Note that in some cases the software might be available under an alternative, closed source license as well.

Evaluate the library to be sure you understand how to use it, how it works and its suitability for your application. As with any SOUP, it’s up to you and your team to gain sufficient understanding of it to use the libraries effectively. Note that you should go through this investigation early in your design process so you don’t have to change tack midway through.

What about bugs?

When you find bugs in OSS you will likely follow the same process of characterizing and searching for solutions as with any SOUP. With OSS you will likely do web searches, explore forums, reach out to the developers and finally if necessary, dig into the source and fix it.

I can think of quite a few times that a project I’m working on has been saved by making our own modifications to a library’s source. If you’re leveraging the thousands of hours of volunteer effort that goes into writing OSS and you find and solve an issue, I recommend that you push it back up or post it to give it back to the community.