API, SDK, and OSS: Precise Definitions and Their Legal, Contractual, and IP Implications
When an engineer says “we integrate via API,” “we use an SDK,” or “we leverage OSS,” the quality of due diligence depends on whether M&A practitioners and VC investors understand the full implications of those statements.
These three terms appear constantly as technical shorthand, but they are in fact concepts that connect directly to business continuity, license obligations, IP ownership, and supply-chain dependency. A due diligence process that cannot unpack what “we use an API” actually means is one that discovers unexpected costs after the deal closes.
Defining API, SDK, and OSS — and How They Relate
API (Application Programming Interface)
An API is the “interface window” through which software components exchange functionality and data.
The clearest example is a web service HTTP API. When an app embeds Google Maps, it follows Google’s defined protocol — endpoints, parameters, authentication — and receives map data in return. The definition of those exchange rules is the API.
If an API is a “window,” then the specification describing the window’s shape and rules is the API specification, and the actual communication following that specification is an API call. The side that provides the API is the provider (e.g., Google, Stripe); the side that consumes it is the consumer (e.g., application developers).
SDK (Software Development Kit)
An SDK is a toolkit that makes it easier to use an API.
Using the Google Maps API directly requires a developer to manually construct HTTP requests. With the Google Maps SDK, the same result can be achieved through intuitive function calls like map.addMarker(lat, lng). An SDK wraps an API into a more developer-friendly set of libraries and tools.
SDKs typically include not only the library code that handles API communication, but also sample code, documentation, test utilities, and debugging CLIs.
To summarize the API–SDK relationship in one sentence: an API is the “contract,” and an SDK is the “toolkit for following that contract.” Using an API without an SDK is technically possible, but the SDK improves development velocity.
OSS (Open Source Software)
OSS is software whose source code is publicly available and may be used, modified, and redistributed under defined conditions.
“Publicly available” and “freely usable” are not synonymous. Every published OSS comes with a license that defines the terms of use. This is the heart of the business and legal issue.
How APIs Affect Business: The Asymmetry of Dependency and Control
Using an API means constructing a relationship in which the consumer is subordinate to the provider’s decisions.
Three typical risks:
Price-change risk: When Twitter eliminated its free API tier, services that depended on that API were forced to reckon with their business continuity overnight. The provider holds the power to change API pricing and restrictions; consumers bear the consequences.
Specification-change and deprecation risk: When an API version is deprecated, consumers absorb the remediation cost. If existing code cannot keep pace with API changes, service disruption risk increases.
Terms-of-service restrictions: API terms are set unilaterally by providers. They may include clauses such as “no use in competing services” or “prohibited use cases for specific industries.” It is not uncommon for an M&A process to reveal that terms-of-service provisions were, in fact, constraining the scope of the business being sold.
In the investment and acquisition context, “which APIs a company depends on, and to what degree” is a critical risk-assessment dimension. When core product functionality depends on a single API provider, changes in that provider relationship can be existential.
License Issues Embedded in SDKs
SDKs are generally distributed under a proprietary license set by the provider. These SDK license terms can constrain how a product is designed or distributed.
In fintech startups, for example, payment SDKs are commonly embedded — but the SDK license may specify prohibitions such as “no resale as a standalone product” or “service provider certification requirements.” Being bound by license obligations without realizing it is a pattern that surfaces in technical due diligence with some regularity.
Key things to verify:
- Whether the SDK distribution license contains restrictive clauses
- Whether libraries bundled inside the SDK carry their own separate licenses (recursive license issues)
- Whether API provider agreements (including terms-of-service acceptances) were executed under an individual developer’s account rather than the legal entity, requiring transfer
OSS License Types and Commercial Use Risks
OSS licenses fall broadly into two categories: permissive and copyleft. This distinction maps directly onto business risk.
Permissive Licenses
| License | Notable OSS | Key Characteristics |
|---|---|---|
| MIT | React, Vue.js, Rails | Commercial use, modification, and redistribution are free with attribution |
| Apache 2.0 | Kubernetes, TensorFlow | Adds explicit patent grant and trademark restrictions on top of MIT-level permissions |
| BSD 2/3-Clause | nginx, FreeBSD | Similar to MIT; 3-Clause adds restrictions on promotional use |
Permissive licenses generally permit embedding in commercial products and redistribution without issue. That said, omitting copyright notices or distributing a modified version with the license text altered constitutes a violation.
Copyleft Licenses
| License | Notable OSS | Key Characteristics |
|---|---|---|
| GPL v2/v3 | Linux kernel, WordPress | Software incorporating GPL-licensed OSS may trigger source-code disclosure obligations upon distribution |
| LGPL | FFmpeg (portions) | Disclosure obligations may be relaxed when used as a dynamically linked library |
| AGPL | MongoDB (legacy license), Nextcloud | Source-code disclosure obligations may apply even when providing a web service without distributing software |
AGPL (Affero GPL) deserves particular attention. While standard GPL triggers disclosure obligations upon software distribution, AGPL extends that trigger to providing a service over a network. Simply offering a SaaS product may create source-code disclosure obligations.
Practical implications for investment and M&A: If copyleft OSS is embedded in the core product, there is potential for source-code disclosure obligations to arise. The legal assessment requires specialist counsel, but confirming “whether copyleft OSS is present at all” is something a technical reviewer can do (see A Technical Reviewer’s Guide to Preliminary IP Due Diligence).
Three IP and Contractual Issues Investors and M&A Practitioners Need to Understand
1. OSS Components Are Not the Company’s IP Assets
When assessing a product’s technical value, “what technology it is built with” and “who owns the rights to that technology” are different questions.
A feature built using OSS libraries does not mean the company owns the copyright to those libraries. It means the company is using them under the terms of a license. What genuinely constitutes the company’s IP assets is the original code, algorithms, data structures, and documentation it developed itself.
With this distinction in place, the question “where does this product’s core IP value actually reside?” becomes evaluable with precision. A product that merely sits on top of OSS and a product where proprietary technical accumulation is the source of differentiation carry very different investment value implications.
2. API Provider Terms of Service Are Not a Negotiated Agreement
API terms of service are typically “standard-form contracts” written by the provider. Consumers cannot negotiate the terms — they accept the provider’s conditions or they don’t use the API.
This is categorically different from a negotiated B2B contract. Terms of service can be unilaterally amended by the provider, and most include provisions that treat continued use after notice of changes as acceptance.
In M&A due diligence, business-critical APIs warrant scrutiny of their terms of service — specifically, what hedge mechanisms exist against provider-driven specification changes, price increases, or service termination.
3. OSS Fork Strategies and IP Complexity
Some startups choose to fork OSS — copying the code and modifying it independently — rather than using OSS as-is. Forking reduces dependence on the original OSS provider, but it introduces several complications:
- The copyleft license of the fork source may carry through to the modified version
- All maintenance after forking becomes the company’s own responsibility; reflecting upstream changes (updates to the original OSS) becomes an ongoing cost
- When proprietary implementation is mixed into forked code, the boundary between “what is the company’s IP” and “what is the forked OSS” becomes ambiguous
When a fork strategy is in place, verifying that “the license from the fork source, post-fork obligations, and the boundary of the company’s own IP are clearly defined” is an important technical due diligence task.
Due Diligence Checklist
Pulling the above together, the key items to verify in due diligence:
API dependency assessment
- Which core product features depend on external APIs?
- Who are the providers of those APIs? (Large incumbents like Google/AWS/Stripe, or smaller startups?)
- What is the blast radius if a critical API is deprecated or repriced, and is there a fallback?
- Do any API terms of service contain clauses that restrict business continuity? (Particularly: competition prohibitions, use-case restrictions, resale prohibitions)
SDK and library license review
- Does a license inventory exist for all SDKs and libraries embedded in the core product?
- Are any copyleft licenses (GPL/LGPL/AGPL) present?
- If AGPL is present, has legal counsel assessed whether source-code disclosure obligations arise in the SaaS delivery model?
- Have SDK agreements been executed at the corporate level, or are they under individual developer accounts that require transfer?
OSS fork usage
- For any forked OSS, have the fork-source license obligations been carried through?
- Are there sufficient internal resources to maintain the fork?
- Is the boundary between forked code and proprietary code traceable (e.g., through git history)?
These items can be integrated into the “external dependency risk” dimension of technical due diligence. For the overall technical due diligence framework, see Tech Due Diligence: The Complete Picture and Seven Evaluation Axes.
Related Articles
For the full scope of what a technical reviewer can do in IP due diligence — including OSS license verification procedures — see A Technical Reviewer’s Guide to Preliminary IP Due Diligence.
For evaluating technical competitive advantage through the lens of “proprietary IP” versus “externally dependent technology,” see Identifying the Sources of Technical Competitive Advantage: An R&D Evaluation Framework.
The API and OSS dependency assessment dimensions described here connect to the “external dependency” and “technology stack” sections of Tech Due Diligence: The Complete Picture and Seven Evaluation Axes.
Tied Inc. provides technical due diligence and IP assessment support for VC and corporate M&A teams. Visit our investor services page or contact us to learn more.