Ask a room of engineers how they pick tools and you will hear about features, community and documentation. Ask who read the licence or subscription terms first and hands stay down. That gap is where a handful of persistent myths live. They sound sensible, they are repeated in team chats, and each one has caused real bills, awkward audits or painful migrations. Here are six of them, with the practical correction for each. The common thread is simple: the headline is the sales pitch, and the small print is the contract.
Myth 1: “The free tier is free forever”
Free tiers are real and useful, but “free” describes today’s offer, not a guarantee. Terms commonly allow the provider to change limits, remove features or end the tier with notice. Some free plans also restrict commercial use, cap users or delete inactive accounts.
What to do: Find the clause on changes to the service and the one on account inactivity. If your project would be hard to move, treat the free tier as a trial, and note what the paid price would be.
Myth 2: “Open source means no obligations”
Open source software is free to use in the sense of cost and access, but it comes with a licence, and licences differ. Some are permissive and ask mainly for attribution. Others expect you to share modifications under the same terms in certain situations. Newer “source-available” licences look open but restrict what you may do commercially.
What to do: Keep a simple list of the licences in your stack. When a licence name is unfamiliar, read its summary page and ask someone qualified about your specific use before you build a product on it.
Myth 3: “We can cancel anytime”
Sales teams love this phrase. The contract often says something more specific: cancel anytime, effective at the end of the current term; or cancel with thirty days’ notice; or cancel through a form that is only available in a settings page few people visit. Annual plans may be non-refundable even if you stop using the service in month two.
What to do: Locate the renewal clause. Write down the notice period, the required method, and the date. Put a reminder in the calendar the day you sign.
Myth 4: “Support is included”
Support can mean a community forum, an email address with a five-day target, or a phone line with a named engineer. The words are the same on the pricing page; the commitments are not. Response times often apply only to certain severity levels or paid tiers.
What to do: Read the support schedule. Look for response targets, hours of coverage, and whether an outage counts as top severity. If you rely on the tool for production, check what the remedy is when targets are missed.
Myth 5: “Our data is ours, so we can leave easily”
In principle, customers own their data. In practice, getting it out can be slow, partial or priced. Exports may exclude configuration, history or logs. Some providers delete data soon after the account closes; others keep it far longer than customers expect.
What to do: Look for the export and deletion clauses. Test an export early, while you still have bargaining power, and check what format you get.
Myth 6: “Everyone clicks accept, so the terms must be standard”
Standard-looking does not mean identical. Two similar services can differ sharply on liability caps, price-change rights and audit permissions. Popularity says little about how a clause will treat a small team.
What to do: Compare the three clauses that cost real money: renewal, price changes and liability. Ten minutes is usually enough to spot a standout.
A quick reading routine
- Open the terms and the pricing page side by side.
- Search for renew, terminate, fee, change, retain and liable.
- Read the paragraph around each match, and write one line on each.
- List anything you do not understand and ask the provider to explain it in writing.
- Store the answers with the terms.
Teams that run change programmes will recognise the pattern. A new tool is introduced with enthusiasm, and the commercial details go unexamined until something breaks. The write-up on steering people through change in a DevOps adoption touches on why small habits like this matter more than any single tool decision.
Glossary words to look up before signing
If any of these terms appear and you are unsure, pause. You can find friendly explanations in a long list of beginner DevOps vocabulary, and for the contractual words, ask the provider or a professional:
- Sublicensing and seat, which affect who may use the software.
- Indemnity, which covers who pays when something goes wrong.
- Audit rights, which let a vendor check your usage.
- Termination for convenience, which says who can walk away and when.
When to bring in a lawyer
This article is general information, not advice about your agreements. For large contracts, unusual licences or anything involving personal data, speak to a qualified lawyer. Readers in India can look through WakilSahab, a website offering a directory of lawyers by practice area alongside legal news, forum discussions and blog articles. Use it to begin your search, then agree the work and the fee with the lawyer yourself.
The practical takeaway
Each myth survives because checking it takes effort and believing it takes none. Replace belief with a short routine, and you will be wrong less often. Before your next tool goes into production, spend the time to read what it says about renewal, price changes, data export and liability. It rarely takes longer than the meeting where the tool was chosen, and it can save far more than that meeting cost.