Maps to
QMSR / ISO 13485: §820.50
ISO 13485: §7.4.1
IEC 62304: §5.3.3
Requirement text
The manufacturer shall identify, evaluate, and comply with the license terms of all open-source software components used in the medical device software. A license inventory must be maintained, license compatibility must be verified, and attribution requirements must be fulfilled. License obligations that could affect the proprietary status of the device software (e.g., copyleft provisions) must be identified and managed.
What changed
The FDA's September 2023 final guidance replaced the October 2014 draft and represented a fundamental shift from voluntary best practices to mandatory, enforceable requirements backed by Section 524B of the FD&C Act (PATCH Act, effective October 1, 2023).
Section 524B created new statutory requirements for 'cyber devices' — any device that includes software, connects to the internet (directly or indirectly), or could be vulnerable to cybersecurity threats. Manufacturers must submit: a plan for postmarket vulnerability monitoring and patching, evidence of secure development processes (SPDF), and a machine-readable SBOM in SPDX or CycloneDX format including transitive dependencies and end-of-support dates.
FDA can now refuse to accept (RTA) premarket submissions lacking adequate cybersecurity documentation. Since October 2023, there has been a 700% increase in cybersecurity-related deficiency letters, with an average of 15 deficiencies per letter when cybersecurity is cited. Threat modeling deficiencies appear in a majority of these letters. The SBOM requirement goes significantly beyond the 2014 guidance — binary analysis is expected to find hidden components, and SBOMs must be continuously maintained, not static snapshots.
Atomic constraints
- •All open-source components must have their license type identified and documented in the SOUP list or SBOM.
- •License compatibility analysis must be performed to ensure no conflicting license obligations exist.
- •Copyleft licenses (GPL, LGPL, AGPL) must be identified with documented compliance strategy (isolation, linking method, source availability).
- •Attribution requirements (notices, copyright statements, license text reproduction) must be fulfilled in product documentation or user interface.
- •A process for reviewing license terms before adopting new open-source components must be defined.
- •License compliance must be re-verified when components are updated to new versions that may change license terms.
Common gaps
License compliance unmanaged for medical device software
moderateOpen source components are used without tracking license obligations. Copyleft licenses (GPL, LGPL, AGPL) are included without compliance strategies. FDA views restrictive licenses as a security risk if they prevent the manufacturer from modifying or patching code in an emergency. Attribution requirements are not fulfilled.
Evidence signals
- •
FILE_EXISTS
License.*Inventory|License.*Compliance|Open.*Source.*Policy|OSS.*Compliance|Attribution|NOTICES
- •
CONTENT_MATCH
Does this document contain a license inventory of open-source components with license types identified, compatibility analysis for conflicting obligations, compliance strategy for copyleft licenses, and fulfilled attribution requirements?
Audit defense
The Open Source License Compliance documentation for [your product] (Doc ID: [your document ID]) maintains a complete license inventory with compatibility analysis per IEC 62304 section 5.3.3, documents our copyleft compliance strategy, and fulfills all attribution requirements for open-source components.