Open Source Support Contract Checklist: What to Check Before You Sign or Renew

The short answer

Before you sign or renew, check seven things: the term and how it renews, the notice period, the price basis and how far it can rise, how the contract defines what is covered, what happens when a version reaches end of life mid-term, what the SLA credits are actually worth, and what the vendor owes you when the contract ends. Most of the cost of a poor support contract sits in those clauses, not in the headline price.

This is a buyer's checklist written by a support vendor, not legal advice. Have your own counsel review the contract.

1. Term and auto-renewal

• Initial term. One year is easy to leave. Multi-year terms usually trade a lower price for less flexibility; check whether the discount survives the first renewal.
• Auto-renewal. Many contracts renew for a full new term unless you give notice. Record the renewal date and the last date to give notice, not only the renewal date.
• Renewal term length. Some contracts renew for the original term, so a three-year deal renews for three more. Ask for annual renewals after the first term.
• Renewal reminders. Ask the vendor to send written notice of the renewal and the new price before your notice deadline.

2. Notice periods

The notice period decides when you must decide. A 90-day notice clause on a contract that renews on 1 January means the decision is due in early October. Put every support contract's notice deadline on one calendar; the guide to consolidating support contracts explains how to use that calendar to sequence vendor changes.

3. Price basis and uplift caps

• Unit. Per core, per node, per GB of memory, per vCPU hour, per instance or per cluster. Ask what the price would be if your largest cluster doubled in size. The answer tells you whether growth becomes a contract event.
• Counting rules. For per-core and per-node pricing, check how replicas, standby nodes, test environments and disaster recovery sites are counted.
• True-ups. Find out whether the vendor can audit usage and bill the difference, how often, and at what rate.
• Uplift cap. Put a maximum renewal increase in the contract itself. A cap in the proposal or an email does not bind anyone.
• Prepayment. If you pay several years up front, check what is refunded if the vendor ends coverage for a technology you depend on.

4. Coverage definitions

"Supported" means whatever the contract says it means. Read the definitions section first.

• Products and versions. Is coverage defined by product name, by version, or by a list that the vendor can change by updating a web page?
• What support includes. Answers to questions, workarounds, bug fixes, security fixes, built and signed packages, or some of those.
• Extensions, plugins and operators. PostgreSQL extensions, RabbitMQ plugins and Kubernetes operators are often excluded unless named.
• Runtimes. Erlang/OTP under RabbitMQ and the JVM under Kafka and ZooKeeper. If they are not named, assume they are not covered.
• Infrastructure. Some contracts cover the software only on certain platforms or only inside the vendor's own distribution.
• Severity definitions. Check who sets the severity of a case, and whether you can raise it.

5. Version coverage when upstream support ends

This is the clause buyers miss most often. Open source projects end support for major versions on a fixed calendar. MySQL 8.0, for example, reached end of life in April 2026 with 8.0.46 as its final release. If your contract covers only versions that upstream still maintains, coverage for that cluster ends on that date, whatever the contract term says.

• Ask for a list of the versions you run with the vendor's own end date for each.
• Ask whether the vendor ships fixes for versions after upstream support ends, and in what form.
• Check whether the contract lets the vendor require an upgrade, and at whose cost.

Managed cloud services handle this differently: Amazon RDS, Azure Database for MySQL and Cloud SQL all moved MySQL 8.0 to paid extended support, billed on top of the instance. If part of your estate is managed, read those terms alongside your support contract.

6. SLAs and credits

• Response or resolution. Most SLAs promise a response, not a fix. Look for fix targets for security vulnerabilities, stated by severity.
• When the clock starts. At public disclosure, when the upstream fix appears, or when you open a ticket. The difference can be weeks.
• Hours. 24/7 for the top severity, business hours for the rest, and whose time zone.
• Credits. How a missed target is measured, how the credit is calculated, whether you must claim it within a deadline, and whether credits are capped.
• Sole remedy. Some contracts make credits your only remedy for a missed SLA. Know whether yours does.

7. Termination and termination assistance

• Termination for convenience. Whether you can end the contract early, and what it costs.
• Termination for cause. Whether repeated SLA failures count as cause.
• Delivered builds. Patched packages and images you have already installed should remain yours to run after the contract ends, without a licence key that expires.
• Handover. A period during which the vendor answers questions from your team or your next vendor, and an export of ticket history and runbooks.
• Data. Whether any of your data, logs or configuration sit in the vendor's systems, and how they are returned or deleted.

8. Security and evidence

• A software bill of materials for each build, and a record of the CVEs fixed in it. SBOMs for end-of-life components explains what to ask for.
• How builds are signed and how you verify them.
• How the vendor notifies you of new vulnerabilities that affect your versions.
• The evidence your auditors expect; the open source audit evidence checklist lists it.

The checklist

Where OSSeva fits

OSSeva covers PostgreSQL, MySQL, MariaDB, Redis, Valkey, RabbitMQ, Kafka, MongoDB, Elasticsearch, ZooKeeper and the Erlang/OTP runtime under one contract with one renewal date. It ships patched, signed builds for versions upstream has dropped, so an end-of-life date does not end your coverage. Pricing is per cluster, not per core, per GB or per node. OSSeva Operate commits to a 15-minute P1 response and patches Critical CVEs (CVSS 9.0 and above) within 48 hours and High within 7 days. The page for procurement teams lists the questions to put to any vendor, OSSeva included; book a discovery call for a quote.

Frequently asked questions

When should we start reviewing a renewal?

At least a month before the notice deadline, not the renewal date. That leaves time to get a competing quote if the renewal price is wrong.

What is a reasonable uplift cap?

One you can budget for. The important part is that a number is written into the contract, so the renewal price is not open-ended.

Are SLA credits worth negotiating?

Less than fix targets are. A credit refunds a small part of the fee; a fix target with a defined clock is what reduces your exposure.

Do we lose patched builds if we leave a vendor?

That depends on the contract. Check that builds already delivered remain yours to run and do not depend on a licence key or a vendor service that stops at termination.

How do we compare an offer with what we pay now?

Add current contracts, any commercial licences and the engineering time spent on patches and vendor tickets. The support cost calculator does the sum with your own numbers, and the RFP template gives you comparable answers from each vendor.