According to IEC 62304 terminology, 3rd party software are Software of Unknown Provenance, aka SOUP.

What is a SOUP, what is a not SOUP?

Not every 3rd party software is a SOUP. Software developed and maintained with respect to IEC 62304 requirements or with respect to medical devices regulations are not SOUP.

Simple case

If 3rd party software is designed and maintained with respect to IEC 62304, and you have contractually access to the documentation, then this software is not a SOUP. This is the simplest case. It basically happens when the 3rd party is a sub-contractor or a software library manufacturer, with ISO 13485 certification or a QMS compliant to other regulation (eg 21CFR in the US), completed with IEC 62304 compliant processes.
This is the gold standard, but it is not always feasible.

Other simple case

At the opposite side, if software comes from an open-source repository, from a private research lab (even in your company), from a university, or from any other 3rd party that has no process complying with IEC 62304, then this is a SOUP.
The source may be the most truthful one in terms of quality of software or technological advance, it doesn't matter. If this 3rd party hasn't a QMS with IEC 62304 compliant processes, its software is a SOUP according to IEC 62304.
This is usually the case of the immense majority of 3rd party software.

Borderline cases

But in most of cases the situation isn't so simple. Here are some examples.
If the software is a legacy software developed before your company implemented IEC 62304, see the series on legacy software.
If the software comes from a 3rd party which is IEC 62304 but you don't have access to the software documentation, then try to change the contractual conditions (easy to say...) or treat it as a SOUP, or not, if you have a good justification to do so.
As a matter of fact, 3rd party software can be qualified as SOUP on a case-by-case basis. It mainly depends on the type of relationship with the software manufacturer and the nature of the documentation delivered with the software.

Examples of SOUP

Here are some examples of SOUP:

Operating Systems

Almost all OS's are SOUP: Windows, MacOS, iOS, Android, Linux and so on...
To my best knowledge, no OS is claimed being designed for medical purposes by their manufacturers (I heard that QNX was, but I haven't seen satisfying documentation yet).

Hardware Drivers

All drivers delivered by hardware manufacturers are SOUP. Unless this hardware is a medical device or an accessory of medical device, designed and maintained with respect to standards and regulations.

Software Development Frameworks

High level frameworks like J2EE, ASP.NET, Flash, Ruby on Rails are not SOUPs. Lower level frameworks delivered by microchips manufacturers are not SOUP either.
They are used in IDE at design time and never delivered to the end-user.

Runtimes

Contrary to frameworks, all runtimes used to make software work are SOUP: C runtime, ADA runtime, Java runtime, Common Language Runtime, runtimes delivered by micro-controllers vendors, any runtime language interpreter...

Open-source libraries

Whichever the license, open-source libraries are SOUP. The licensing terms found in open-source licenses like Apache or LGPL neither help nor make more difficult the use of 3rd party software in medical devices.
IMHO, Open-source is another debate.
One could argue that access to source-code is a help to SOUP management. Perhaps yes, in peculiar cases.

IDEs, compilers

Development tools are not SOUP, compilers either. They are used in factory, not in clinical settings. They shall be validated by IQ, OQ and PQ.
Just-in-time compilers can be categorized as SOUP as they run with software delivered in clinical settings.

Where are we?

This makes a lot of SOUP!
You may think this IEC 62304 standard is a real burden, that you have far more to do than you thought!

Well, not so much, IEC 62304 is not a basket case! We'll see in next articles how to deal with these SOUPS.