Software in Medical Devices, by MD101 Consulting

Open-source software

Open-source software is a very big family. Hence it's not its technical characteristics that make it open-source, but its legal characteristics.
Broadly speaking, open-source requires to share the source code with others. It gave birth to the notion of copyleft.
From the point of view of IEC 62304, this doesn't change the way open-source software is managed. Open-source is 3rd party software, not developed with the processes required by IEC 62304. So it is a SOUP.

Since open-source can't be defined by technical characteristics, there are plenty of different open-source software, here are a few examples:

• OS's, drivers
  • GNU/Linux distros
  • Free BSD distros
• frameworks
  • PHP
  • GNU packages for C development
  • Apache framework
• specific libraries
  • dcm4che
  • (post your favorite lib here)
• general purpose libraries
  • Math libraries, like LAPACK
  • GUI frameworks, like Qt
• standalone software
  • Mozilla firefox, thunderbird,
  • every open-source software replacement of closed-source software.

Note: I didn't mention software development tools like IDE's. They're not SOUP, as seen in the first post of this series.

Technically speaking, open-source software is like any software. The main difference is that we have access to the source-code.
OK, what are the advantages?

Reminder - What IEC 62304 expects for SOUP

Skip this part if you've read previous posts.
IEC 62304 requirements about SOUP are:

• Software requirements: The manufacturer shall describe what requirements (functions or non-functional) are necessary to have the SOUP work.
• Architecture: The manufacturer shall define the software architecture to have the SOUP work in appropriate conditions.
• Maintenance: The manufacturer shall monitor the SOUP lifecycle: patches, new versions...
• Risk analysis: It is mandatory to do a risk analysis related to the SOUP.

Open-source software is a SOUP

Let's see what are the advantages of open-source software.

Requirements

Having access to the source-code doesn't help much to define the requirements of the medical device. Sometimes, when open-source software lacks technical documentation, it may be harder to define the right requirements to have it work properly.

Architecture

Contrary to requirements, having access to the source code may help to design better the device software architecture. But this remains theoretical. Personally, I've never seen software architects diving into open-source code to define a better architecture.
Likewise, having access to the source code doesn't mean that it is necessary to reverse engineer the open-source software architecture. There's nothing like that in IEC 62304.

Maintenance

Pros and cons of open-source software get right balanced, when thinking about maintenance.
Obsolescence Some open-source projects are maintained by a team of volunteers. They can be discontinued when the team ceases to have enough contributors.

Some others are supported by private companies, for some strategic reason. They can be discontinued when the company ceases to support open-source projects, when it changes its strategy.
Obsolescence of open-source projects can be problematic, when there's no more developer to maintain the source-code. However, this can be also the case for commercial software. Private companies are not eternal and they can suddenly change their strategy or their products portfolio.

Fixing bugs Having access to the source-code is definitely a huge advantage to search for causes of bugs and make patches. But, once again, this advantage remains marginal, compared to all the tasks that are necessary all along the software life-cycle.
More, it can be tempting to fix a bug in an open-source software. But, given their licensing terms, it can become a legal mess.

Risk-Analysis

Once again, pros and cons of open-source software get balanced, when thinking about risks analysis.
Functionalities It's more the use of a library or an executable that makes it risky, than its nature or its legal framework. Think about two libraries that deliver identical functions. The first is open-source, the second is closed-source. What's the difference from the point of view of risks assessment? None. Same functions, same risks.

Defects, failures Are open-source software more prone to defects than closed source software? I let you answer this question. I don't think that there is an evidence that one is more guilty than the other.



To sum-up, open-source software doesn't help much to be compliant to IEC 62304. Open source-software has its own advantages linked to the licensing scheme. Open-source allowed the software industry to do giant leaps forward, but it's another debate.

Next time, we'll continue our journey in the SOUP world with a post on standalone software.