How to Write a EULA for an API or SDK You License to Other Developers

If your product ships as a client library, a native module, or an SDK that other developers drop into their own codebase and ship to their own customers, an API terms of service is the wrong document for the job it needs to do. A terms of service governs how someone is allowed to call your endpoints: rate limits, key handling, acceptable traffic patterns. A EULA governs something categorically different: the right to take a piece of code you wrote, embed it inside a product someone else builds, and redistribute it to people you'll never have an account relationship with. If your licensing terms only cover the calling relationship and never address the copying and redistributing one, the part of your business with the most actual exposure is the part with nothing written down.

Two documents, two different relationships

The confusion usually comes from the fact that a lot of developer platforms genuinely need both documents at once, one for the hosted API their customers call over HTTP, and a separate one for any SDK, client library, or embeddable binary that ships as a copy inside a customer's own build.

Our terms of service guide for a SaaS API covers the left column: rate limits, credential responsibility, versioning notice, and acceptable use for automated traffic. This guide covers the right column, which a straight API terms of service was never written to reach.

Step 1: Define exactly what is being licensed

Before writing a grant clause, be specific about what a developer actually receives, because "the SDK" is not one thing legally. Most SDK distributions bundle compiled object code (the binary or package a developer installs and calls), header files or type definitions, sample or starter code meant to be copied and modified freely, and documentation. Only some of that should carry the same restrictions. Sample code is usually licensed permissively, or explicitly public-domain, precisely because its purpose is to be copied into someone else's project wholesale. The compiled library is where the real restrictions belong. Naming these categories separately in the license section, rather than one blanket "the software" definition, avoids a licensee later arguing that a restriction on "the software" was never meant to reach the sample snippet they copied straight into production.

Step 2: Set the scope of the license grant

The grant clause is the paragraph that actually does the licensing, and it needs to answer four questions plainly: is the license exclusive or non-exclusive (almost always non-exclusive, since the same SDK gets licensed to many developers), is it revocable or does it survive termination for copies already distributed, is it worldwide or geographically limited, and is it tied to an active subscription or perpetual once granted. A common, defensible default for a commercial SDK is a non-exclusive, non-transferable, revocable license limited to the term of the developer's active account, since that lets you cut off further use the moment a subscription lapses without having granted something you can't take back.

Gate the grant by plan tier if your pricing works that way. It's standard for a free or evaluation tier to license internal, non-production use only, testing, prototyping, internal tooling, with redistribution to the developer's own end users unlocked only on a paid or enterprise plan. Say this explicitly in the license section itself, not just on the pricing page, since a developer who reads only the legal document should be able to tell whether their tier permits shipping your code to their customers at all.

Step 3: Decide what redistribution actually permits

This is the clause an API terms of service has no equivalent for, and it's the one that matters most once a developer actually ships something. Cover three specifics. First, whether redistribution is limited to compiled object code, with source code (if delivered at all, for debugging or IDE support) remaining your confidential property that the licensee may reference but not further distribute. Second, whether the licensee may modify the code before shipping it, or whether the license requires redistribution only in unmodified form, which keeps behavior predictable and keeps your support team from debugging a version of your own SDK you've never seen. Third, whether the license extends a limited sublicense to the licensee's own end users to run the embedded code as part of the licensee's product, since without that sentence, a developer's own customers are technically running your code under no license at all.

Step 4: Require attribution the way you actually want it enforced

An attribution clause that just says "you must give appropriate credit" gives a licensee nothing to comply with and gives you nothing to point to later. Specify the actual mechanism: a "Powered by [Name]" notice in a settings or about screen, a specific string that must appear in generated output, or a notice file that must ship unmodified alongside the compiled library. If a higher plan tier removes the attribution requirement for white-labeling, say that explicitly in the tier that grants it rather than leaving developers to guess whether they're allowed to strip your branding.

Step 5: Add field-of-use and competitive-use restrictions

A license grant without a field-of-use limit implicitly permits any use at all, including uses you'd never have agreed to if asked directly. Common, enforceable restrictions worth naming rather than assuming: no use of the SDK to build a directly competing API or developer platform, no publication of benchmark or performance comparisons without prior written consent (a standard clause for database and infrastructure SDKs specifically, since a bad-faith benchmark can do real reputational damage), and, where relevant to your risk tolerance, no use in safety-critical or high-risk systems where a failure in your code could cause physical harm, medical devices and industrial control systems being the recurring examples. None of these are exotic, but none of them are implied by a generic "you may use the software" grant either.

Step 6: Cover ownership, feedback, and indemnity

State plainly that the SDK is licensed, not sold, and that you retain all intellectual property in it; the licensee owns whatever original code they write around it. Add a feedback clause: if a licensee reports a bug or suggests an improvement, you can incorporate it without owing them anything, which avoids a later dispute over who owns a fix a customer's engineer happened to suggest first. For a commercial SDK with real enterprise customers, also decide your position on IP indemnification, whether you'll defend a licensee against a third-party claim that your unmodified SDK infringes their patent or copyright, since larger customers routinely ask for this before they'll sign, and having an answer ready (even a limited one, capped and conditioned on prompt notice) moves that conversation faster than drafting the clause under deadline during a procurement review.

Step 7: Decide what happens to already-distributed copies on termination

Termination in a normal terms of service just cuts off access. Termination in an SDK EULA is more complicated, because by the time an agreement ends, copies of your code may already be running inside thousands of installations of the licensee's own product, on devices you have no way to reach. Most commercial SDK licenses handle this by distinguishing between the license to distribute (which ends on termination, so no new copies may ship) and the sublicense already granted to end users for copies already in the field, which is typically written to survive, since revoking a license from an end user who has no relationship with you and no reasonable way to know their app's SDK dependency was terminated isn't practical to enforce and rarely serves any real purpose. State this distinction directly rather than leaving "termination ends all rights" to be read literally against installed copies nobody can actually recall.

This same distribution-tail problem shows up in WordPress plugin and theme EULAs, where a similar split, this time forced by the GPL rather than by practicality, separates what a vendor can lock down from what keeps running once it's left their hands. If you're unsure whether your product needs this kind of document at all versus a standard terms of service, the EULA vs terms and conditions comparison walks through that threshold question first.

Building the license terms without starting from a blank page

A license grant, redistribution scope, attribution requirement, and termination tail are specific, interlocking terms, not boilerplate that reads the same from one SDK vendor to the next. Our EULA Generator builds these sections around the license type, platform, and redistribution choices you actually make, so the license grant your developers agree to matches what your SDK actually lets them ship, instead of a generic desktop-software template patched after the first enterprise customer asks whether they're allowed to embed your code in a product they sell.

The information in this article is for informational purposes only and should not be construed as legal advice on any matter, and does not create a lawyer-client relationship.