Open Source Software in Corporate Mergers: Identifying Intellectual Property Risks During Local Acquisitions (Philippines)

Introduction: why open-source code can become an acquisition liability

In Philippine tech acquisitions, open-source software (OSS) is often treated as “free code.” In reality, OSS comes with license conditions that can affect ownership, distribution rights, confidentiality, and commercialization. For a foreign buyer acquiring a Philippine startup, the risk is not limited to “missing paperwork”—it can translate into post-closing exposure where the acquirer inherits operational and legal problems tied to the target’s codebase, releases, and customer commitments.

This article focuses on a common scenario: a Philippine startup built a commercial product using OSS with restrictive conditions (for example, strong “copyleft” obligations), then gets acquired. The buyer must assess whether OSS use has created copyright exposure, contractual breaches, or commercialization limits that could impair the value of the acquired product.

Philippine legal foundations relevant to OSS risks in M&A

1) Copyright is statutory, and infringement risk depends on what the law grants and protects

Philippine copyright protection is defined by statute. The Supreme Court has emphasized that copyright is a statutory right and its scope, boundaries, and enforceability are governed by the Intellectual Property Code and related rules (Philippine Home Cable Holdings, Inc. v. Filipino Society of Composers, Authors & Publishers, Inc., 2023; see also its discussion of copyright as purely statutory and the “metes and bounds” being defined by law).

In an OSS context, infringement analysis often turns on whether the target’s acts—such as reproducing, adapting/modifying, distributing, or making software available to the public—were authorized under the applicable OSS license and consistent with how the software was deployed commercially.

2) OSS license breaches can convert “authorized use” into infringement exposure

OSS is typically offered through licenses that grant permissions conditioned on compliance (for example, attribution, source code availability, license notice preservation, or distribution conditions). If the target failed to comply with those conditions, the startup may lose the benefit of the license permissions and face claims that its copying, modification, or distribution became unauthorized.

While OSS licenses are private instruments, their breach matters because the acts they regulate are acts within copyright control. For diligence, the question is not whether OSS exists in the codebase (it almost always does), but whether compliance is complete for each OSS component used in the product and in the company’s distribution model.

3) Successor exposure: business-enterprise transfer doctrine and assumption of liabilities

Philippine jurisprudence recognizes the general rule that a buyer of corporate assets is not liable for the seller’s liabilities, subject to established exceptions (the “Nell Doctrine”). The Supreme Court has applied a protective doctrine for creditors where a transfer of all or substantially all assets renders the transferor incapable of continuing its business—often discussed as a “business-enterprise transfer” scenario—so liabilities may attach to the transferee even absent express stipulation if the circumstances fall within recognized exceptions (Y-I Leisure Philippines, Inc., et al. v. Yu, 2015).

For foreign acquirers, this matters because OSS-related exposure may be framed as a mix of contractual obligations(license compliance undertakings) and intellectual property liabilities (claims arising from alleged infringement), and deal structure may not fully insulate the buyer if the acquisition effectively takes over the enterprise.

4) Mergers and IP-related rights generally pass by operation of law (and practical use of names may follow)

In a merger, the surviving corporation generally acquires the absorbed corporation’s rights and liabilities by operation of law, rather than through piecemeal assignments. SEC guidance has also discussed that the surviving corporation may use trade names previously used by the absorbed corporation, subject to ownership and permission issues when marks are held by an entity other than the absorbed corporation (SEC OGC Opinion No. 25-11, 2025).

The analogy for software is straightforward: if the target’s product was distributed under certain brand and licensing representations, the surviving entity will likely continue that product line. If OSS compliance was incomplete, the surviving entity may inherit both the operational duty to correct compliance and the reputational/legal fallout if enforcement occurs after closing.

5) Technology transfer restrictions as a separate diligence angle (when the deal includes licensing terms)

If the transaction includes technology licensing, distribution, or broader “technology transfer” arrangements, Philippine law can invalidate certain restrictive clauses. For example, the Intellectual Property Code lists prohibited clauses in technology transfer arrangements (Republic Act No. 8293 or the Intellectual Property Code of the Philippines, 1997, Section 87 on prohibited clauses).

This is relevant when the acquirer expects to impose aggressive non-contest clauses, R&D restrictions, or liability exclusions in post-closing technology agreements with founders, developers, or the Philippine entity. These provisions can be unenforceable if they fall under prohibited clauses, which affects how risk is allocated contractually.

Common OSS risk patterns seen in acquisitions of Philippine software companies

1) “Copyleft” obligations collide with a closed-source commercial model

Restrictive OSS licenses may require that if the company distributes a product incorporating covered OSS, it must provide corresponding source code and license notices, and allow downstream redistribution under the same license terms. If the startup sold the product under proprietary EULAs and did not follow OSS obligations, the acquirer may inherit a product that cannot be commercialized as expected without remediation.

2) Missing attribution, license texts, and source offer commitments

Even when there is no immediate public dispute, missing notices can be a compliance failure that later becomes a legal and commercial issue—especially during customer audits, security reviews, and enterprise procurement where buyers ask for a software bill of materials (SBOM) and OSS notices.

3) Undocumented inbound code from contractors and founders mixed with OSS

Many startups rely on contractors, interns, or short-term developers. If work-for-hire arrangements, IP assignment documents, or code contribution policies are weak, the company may not fully own the proprietary parts of the software, and it may also lack traceability on what OSS was introduced and under what license.

4) Distribution model mismatch (SaaS vs downloadable, embedded devices, API distribution)

OSS duties often depend on how the software is delivered. A startup may assume it is “just SaaS,” while in reality it distributes SDKs, mobile apps, desktop clients, on-prem binaries, docker images, device firmware, or customer-specific deployments. These distribution methods may activate obligations that were overlooked.

5) Patent and other IP clauses in OSS licenses (and their effect on deal value)

Some OSS licenses contain patent grants or patent retaliation conditions. If the acquirer’s broader IP strategy includes patent enforcement, the presence of certain OSS components may affect how patents can be asserted without triggering license consequences.

Where liabilities can surface after closing

OSS issues commonly emerge through:

• Enterprise customer due diligence (procurement questionnaires and SBOM requests);
• Security and compliance audits (especially for fintech, health, and critical systems);
• Competitor and community scrutiny (public repos, binaries, containers, and app packages can be scanned);
• Terminated employees or founders who disclose compliance gaps during disputes;
• Post-merger integration when code is combined into the acquirer’s products, spreading the issue.

Due diligence checklist for foreign acquirers: what to ask for and what to test

1) Documentary requests (legal and engineering)

• Software Bill of Materials (SBOM) for every shipped product version and deployment format (app, container, on-prem installer, firmware).
• OSS policy, if any (approval workflow, permitted licenses, notice handling, source code publication procedures).
• Third-party notices file, attribution lists, and archived copies of license texts shipped with products.
• Repository access (including private repos), dependency lock files, build scripts, and CI/CD logs.
• Inbound IP assignments from founders, employees, contractors; contribution agreements where applicable.
• Customer contracts and EULAs to check whether the company promised “all proprietary,” “no copyleft,” or gave IP warranties that could be false.

2) Technical verification steps (to validate representations)

• Automated OSS scanning across source code and shipped artifacts (binaries, containers, mobile packages).
• Dependency provenance checks (confirm actual licenses in use, not just package metadata).
• Build reproducibility review to ensure what is scanned matches what is shipped.
• Code origin review for copied snippets and “unknown source” modules.

3) Legal analysis questions tied to Philippine liability realities

Because liability can follow the enterprise (depending on structure and circumstances), the acquirer should evaluate:

• Whether the deal effectively transfers the operating business such that post-closing claims will target the surviving/transferee entity (Y-I Leisure Philippines, Inc., et al. v. Yu, 2015).
• Whether target representations and warranties about IP ownership and non-infringement are supportable given OSS compliance evidence.
• Whether post-closing technology or licensing arrangements include clauses that may be unenforceable under Philippine restrictions on technology transfer provisions (Intellectual Property Code of the Philippines, Republic Act No. 8293, 1997, Section 87).

Deal structuring and contract protections (what buyers typically do)

Foreign acquirers commonly protect themselves through a mix of structure, pricing, and contractual risk allocation. Typical tools include:

• Special indemnities for OSS compliance failures and third-party infringement claims.
• Escrow or holdback tied to remediation milestones (e.g., delivery of clean OSS notices and completion of scanning).
• Conditions precedent requiring OSS remediation before closing for high-risk components.
• Covenants controlling post-signing code changes to prevent additional risky OSS intake.

These mechanisms should be aligned with how liability may attach under Philippine doctrines on asset transfers and enterprise continuation (Y-I Leisure Philippines, Inc., et al. v. Yu, 2015) and with the reality that post-merger operations usually continue under the surviving entity (SEC OGC Opinion No. 25-11, 2025).

Table: OSS diligence red flags and their likely business impact

Red flag	What it can mean post-closing	Typical mitigation
Use of restrictive copyleft OSS in distributed product	Possible obligation to disclose source code; product model conflicts with proprietary licensing	Replace component; isolate via architecture changes; comply with disclosure/notice duties if acceptable
No SBOM or incomplete third-party notices	Customer audit failures; delayed enterprise sales; remediation cost	Generate SBOM; ship notices; adopt OSS policy and tooling
Contractors contributed code without assignments	Unclear ownership of proprietary layer; dispute risk	Execute confirmatory assignments; tighten onboarding and contribution terms
Customer warranties claim “no open source” or “no copyleft”	Breach claims, termination rights, damages exposure	Disclosure schedules; renegotiate; specific indemnities and reserves
OSS compliance managed ad hoc by engineers	Inconsistent compliance across versions; recurring exposure	Centralize compliance; legal review gate; continuous scanning

Examples of typical acquisition scenarios (and what to do)

Scenario A: The target sells downloadable on-prem software to Philippine enterprises

If the product is distributed as installers or containers, the diligence focus is on embedded OSS and whether the company met license conditions for distribution (notices, source offer, license text inclusion). The buyer should require a verified SBOM for shipped artifacts, not just repository scans.

Scenario B: The target is “SaaS,” but ships a mobile app and an SDK

Even if the core service is hosted, distributing an app/SDK can create separate license obligations. The buyer should review app packages and SDK distributions for included OSS components and required notices.

Scenario C: The target’s product will be merged into the acquirer’s global product suite

Integration can “spread” the compliance issue if copyleft-covered code is combined with proprietary modules. The buyer should plan segregation, replacement, or compliance pathways before integration.

Conclusion: buyer recommendations

For foreign acquirers of Philippine tech startups, OSS risk is best treated as a product integrity and transaction risk, not a minor legal footnote. Buyers should insist on evidence-based OSS diligence (SBOMs, scans, notices, and contract review), align deal protections to the possibility of successor exposure in enterprise transfers (Y-I Leisure Philippines, Inc., et al. v. Yu, 2015), and ensure post-closing licensing and technology arrangements avoid prohibited restrictions under Philippine law (Intellectual Property Code of the Philippines, Republic Act No. 8293, 1997, Section 87).

When managed early, remediation is usually possible and far cheaper than post-closing enforcement, customer disputes, or a forced re-licensing of the product.

About Nicolas and De Vega Law Offices

 Nicolas and de Vega Law Offices is a full-service law firm in the Philippines.  You may visit us at the 16th Flr., Suite 1607 AIC Burgundy Empire Tower, ADB Ave., Ortigas Center, 1605 Pasig City, Metro Manila, Philippines.  You may also call us at +632 84706126, +632 84706130, +632 84016392 or e-mail us at [email protected]. Visit our website https://ndvlaw.com.