Chapter 2 of 9 · 4 checks · 3 min
Licensing
Buyers of code need to know exactly what they may do with it. Write the licence before your first sale.
Write a short licence that says what buyers may and may not doMust
Why it matters and how to check
A clear licence prevents most disputes. Cover in plain language: whether the buyer may use the product in personal projects, client projects or commercial products; how many projects, people or seats; whether they may modify it; and that they may not resell or redistribute the product itself, for example as another template.
Show the licence on the product page before purchase and include it in the download as a
LICENSEfile. Check that a buyer reading only the product page could answer "can I use this for a client?".Do
- Show the licence on the product page before purchase
- Include a LICENSE file in the download
Avoid
- Selling code with no licence and no stated terms
Offer clear licence tiers if different buyers need different rightsShould
Why it matters and how to check
Many developer products sell more than one licence: a personal or single-project licence, a team or multi-seat licence, and sometimes an extended licence for use in products that are themselves sold. Tiers let individuals pay less while businesses pay for the rights they need.
Keep the number of tiers small and describe each in one line. Check that the differences between tiers are about rights or seats, not hidden features buyers only discover after purchase.
Do
- Describe each tier in one plain line
Avoid
- So many tiers that buyers cannot tell which they need
Decide deliberately between an open source and a commercial licenceShould
Why it matters and how to check
If you publish code publicly without any licence, GitHub's documentation notes that default copyright applies and others may not reproduce, distribute or create derivative works from it. If you publish under an open source licence, buyers and non-buyers alike get the rights that licence grants.
Some developers sell a paid version alongside a free open source core, or sell support and extras for open source code. Choose on purpose: check that the licence on your public repository matches what you intend to sell, and do not put the paid product in a public repository by accident.
Do
- Keep the paid product in a private repository or delivery system
Avoid
- Pushing paid code to a public repository with an open source licence
Use licence keys for software that should be limited to a number of activationsNice to have
Why it matters and how to check
For plugins, desktop apps or paid libraries, licence keys let you limit how many sites or devices a purchase covers. Lemon Squeezy, for example, can generate a unique key for each purchase, with an activation limit and an optional expiry set per product or variant, and provides a licence API to activate and validate keys.
Keep the check simple and fail gracefully: a buyer whose network is down should not lose access to what they paid for. Check the full flow with a test purchase: key delivered, activation works, deactivation frees the slot.
Do
- Test activation and deactivation with a test purchase
Avoid
- Licence checks that break the product when offline