API Licensing — Concepts (Draft, Not a Binding Agreement)
This document is a set of licensing concepts for counsel to structure into an actual Terms of Service / API License Agreement. It is not itself a contract, has not been reviewed by counsel, and creates no legal obligations for anyone. Do not present this document to a customer as terms. Nothing here should be treated as legal advice — it's a starting brief for the conversation with a lawyer, organized so the technical and commercial concepts (which do need to be decided before or alongside legal drafting) are clear.
The core distinction
A customer receives a limited license to access the API — not ownership of the API, the underlying software, the models, or the data. This is the same distinction commercial API platforms (Stripe, Twilio, Smarty) draw: you're licensing access, not buying a copy.
License types
| License | For | Typical access |
|---|---|---|
| Developer | Evaluation, sandbox development, prototypes | Sandbox credentials only |
| Commercial | Production applications | Production credentials |
| Reseller | Reselling services powered by the API to the reseller's own customers | Production credentials, plus a reseller agreement covering the reseller's own customers |
| OEM / White-Label | Embedding the platform into another company's product | Production credentials, after contractual review |
| Enterprise | High-volume usage, negotiated SLA, dedicated support | Access and limits negotiated per contract |
| Strategic Partner | Utilities, ISOs, energy retailers, aggregators, grid partners | Trading, settlement, device and grid operations, issued only as production credentials under contract |
Concepts to prohibit (for counsel to formalize)
- Redistribution or resale except under an approved reseller agreement
- Credential sharing
- Circumventing usage limits or metering
- Unauthorized scraping or bulk extraction
- Using the API to construct a substantially competing database or service, where legally enforceable
- Reverse engineering of proprietary components, where legally enforceable
- Sublicensing without approval
- Removing attribution or proprietary notices
- Bypassing billing or metering
- Unauthorized caching or retention of licensed data beyond an agreed period
SDK licensing — separate from API licensing
The SDKs in sdks/ (Python, JavaScript, PHP) are MIT-licensed and freely
redistributable. The API service itself remains entirely proprietary.
This is a deliberate, common pattern:
Open SDK → Proprietary API → Authentication → Authorization → Metering → Billing
A developer can copy the SDK freely; every call it makes still requires a
valid, scoped credential against the metered API. Each SDK's LICENSE
file states this explicitly — see sdks/python/LICENSE for the wording
used across all three.
What this repository does NOT decide
- Actual contract language, liability terms, warranty disclaimers, indemnification, governing law, dispute resolution — counsel's work, not engineering's.
- Whether any of the "prohibit" concepts above are enforceable in a given jurisdiction (reverse-engineering and anti-competing-database clauses in particular vary significantly by jurisdiction).
- Pricing amounts as binding commitments — see
PRICING.md, which is documentation-and-quoting reference, not a rate card with contractual force until counsel and finance sign off on it.