Open source code is commonly found in embedded systems, but the licenses that accompany that code can quietly put your intellectual property at risk. One overlooked copyleft component in software can force disclosure of proprietary source, halt shipments, create legal exposure that lingers for years, or increase risk of exploitation.

Embedded engineering teams are aware of the risks and looking for tooling that surfaces license risk early in the development pipeline. RunSafe’s license compliance feature addresses this need by detecting licenses in your code and enforcing your organization’s risk profile to prevent the release of affected code. Teams can ship faster, with the permissions they’ve set, and without risking IP.

Listen to the Audio Overview

 

Why License Compliance Is Harder for Embedded Systems

Software license compliance means following the legal terms attached to every piece of code in your product, including proprietary, open source, or vendor-supplied. When you ship a device with firmware or deploy a software update, you’re accepting the obligations tied to every component inside. 

Embedded teams face unique challenges:

• Heavy static linking: Increases likelihood of triggering copyleft obligations
• Long device lifecycles (10–20 yrs): Mistakes persist for years and can’t be easily fixed
• Mixed vendor + OSS inputs: Hard to track attribution and inheritance
• No package manifests in C/C++: License detection becomes manual and error-prone

How Copyleft Licenses Raise Compliance Stakes

Copyleft is a licensing approach that uses copyright law to keep software open. If you distribute a program containing copyleft-licensed code, you’re typically required to release your modifications—and sometimes related components—under the same copyleft license. That reciprocal obligation separates copyleft from permissive licenses.

If a copyleft license is violated,  the potential implications include:

• Mandatory source code disclosure: Courts can order you to release not just the copyleft component but also your modifications, build scripts, and sometimes the proprietary code you linked against.
• Increased risk of exploitation once code is public: Once your source code is released, it makes it easier for malicious actors to analyze and exploit any latent vulnerabilities. Embedded devices are already at risk, the last thing teams want is to accelerate exploit development. (While the goal is to prevent reaching this point through license compliance, if a team finds itself in this situation, RunSafe Protect hardens binaries against exploitation, even when source code is exposed.)
• Legal action and settlements: License holders can seek injunctions to halt product sales, plus damages and legal fees that quickly reach six or seven figures.
• Product recall costs: Fixing a license violation after devices ship may require firmware updates, replacement units, or new packaging with proper notices.
• Reputation damage: In regulated industries like medical devices or defense, license violations signal weak governance and can disqualify you from contracts.
• Supply chain disruption: Customers may freeze orders until you demonstrate compliance, and certification bodies may suspend approvals.

The longer violations exist in shipped products, the more devices are affected and the harder remediation becomes.

How Does Copyleft Happen? A Common Scenario

1. A developer adds a library to meet a deadline
2. The project statically links against a GPL component
3. No manifest exists or an SBOM lacks the detail needed for tooling to flag the risk
4. Firmware ships
5. A customer, auditor, or regulator requests the SBOM
6. Legal discovers the violation, and remediation becomes painful and expensive

Without an accurate SBOM and automated license enforcement, it’s difficult to stop copyleft from entering your codebase. That’s why embedded teams need RunSafe’s file-level SBOMs and license compliance, which surface licenses early and then allow you to block or approve them before release based on your specific risk profile.

How RunSafe Improves License Compliance and Addresses Copyleft Risk

RunSafe’s license compliance feature gives embedded teams control over licenses to prevent violations before code ships. We combine build-time Software Bill of Materials (SBOM) generation with automated policy enforcement to simplify and standardize the process.

Step 1: Set Your Organization’s License Rules

RunSafe lets you define clear licensing policies across your entire organization, and will be adding support for project-level license compliance to allow for more granularity and flexibility in how you configure your rules. Specify which licenses are approved, which are banned, and which require review. Whether you need to block GPL variants, flag AGPL dependencies, or restrict any copyleft terms, RunSafe allows you to set rules that make sense for your organization.

In the RunSafe Security Platform, you’ll see a list of all the licenses in your software detected by RunSafe’s build-time SBOM generator. You can also view a list of common open-source licenses and choose which to allow or deny. By defaulting to the licenses actually present in your software’s SBOM, your organization can focus on dependencies in use without getting bogged down by unnecessary compliance reviews.

Step 2: Choose Your Enforcement Posture for New Licenses

This is where RunSafe balances control with practicality. For any license you haven’t explicitly classified (unset licenses), you choose one of two approaches:

Allow by default: New dependencies flow through automatically unless they match your explicitly denied list. This keeps development moving while blocking known copyleft risks.

Deny by default: Any unrecognized license halts the pipeline until you review and approve it. This guarded posture ensures maximum protection as your dependencies evolve.

Step 3: Enable Automatic Pipeline Enforcement and Alerts

Once configured, enforcement happens automatically in your CI/CD pipeline. As your CI tool runs your builds, RunSafe generates SBOMs and checks them against your license policy. Pipelines containing denied licenses will fail with clear output in your logs, identifying exactly which licenses triggered the block. 

Step 4: Adapt as Your Dependencies Grow

As your team adds new libraries or updates existing ones, newly detected licenses automatically appear in your unset list. Depending on your enforcement posture, they either flow through (if allowed by default) or stop the pipeline for review before releasing code (if denied by default). You can adjust individual license decisions at any time, moving them between allowed and denied as your policy matures.

SBOMs: The Prerequisite for License Enforcement

You can’t enforce license policy if you don’t know what’s in your build. SBOMs solve that, but most SBOM tools fail in C/C++ environments because license data lives in:

• File headers
• Top-level LICENSE files
• Repository metadata
• Vendor drop-ins with no manifest at all

Without file-level SBOM accuracy, compliance becomes guesswork. This is where RunSafe differentiates itself. By generating SBOMs at the file level during build-time, RunSafe can accurately capture license information for embedded projects. This then leads to greater confidence in license compliance.

Protect Your Proprietary Code

By enforcing license policy at build time and pairing it with accurate SBOMs, you can reduce copyleft risk before it reaches production. 

Interested in giving it a try? Sign up for a free trial of the RunSafe Security Platform.