Freelance Contract & Legal Vocabulary for IT

MSA (Master Services Agreement): the umbrella contract that governs all future work between two parties. Covers: legal terms (IP, confidentiality, liability), payment terms, dispute resolution, termination. Signed once; remains in effect for all subsequent projects. SOW (Statement of Work): a project-specific document executed under the MSA. Covers: project description, deliverables, timeline, pricing, acceptance criteria. Each new project has a new SOW; the MSA doesn't need to be re-signed. Related documents: NDA (Non-Disclosure Agreement) — protects confidential information shared during discussions. Often signed before the MSA. Change Order — a written amendment to a SOW for scope changes, additional work, or price adjustments. Must be signed by both parties before work begins. Work Order — similar to SOW; the term varies by industry/region. Contract structure vocabulary: Recitals — the "whereas" clauses at the start of a contract describing context. Whereas — introductory clause. Notwithstanding — a common legal term meaning "despite" or "regardless of." Hereinafter referred to as — how parties are named in the contract for subsequent references. In conversation: "The MSA negotiation is the hard part — once that's done, adding new projects is just a one-page SOW that takes an hour to write."

IP assignment: a contract clause transferring ownership of intellectual property created during the engagement from the freelancer to the client. Without an assignment clause, IP ownership defaults depend on jurisdiction — in many countries, the creator retains copyright unless explicitly transferred. Work-for-hire: a legal doctrine (US) where work created within the scope of employment or as a specifically ordered/commissioned work becomes the property of the employer/commissioning party. Freelancers should specify whether the engagement is work-for-hire. Carve-out: explicitly excluding specified pre-existing items from the IP assignment. Critical for: utility libraries you've built over years, frameworks you use across clients, open-source tools you contribute to. IP vocabulary: Pre-existing IP — code, tools, or materials the freelancer created before the engagement. Must be listed (even roughly) in the contract. Background IP — same as pre-existing IP; used in UK/EU contexts. Foreground IP — new IP created during the engagement; typically assigned to the client. Moral rights — in many jurisdictions, the right to be identified as the author and to object to derogatory treatment; can't be assigned (only waived in some jurisdictions). License-back — the client assigns IP to them but licenses it back to you for use in other projects. In conversation: "I always list my pre-existing libraries in the contract schedule — if I don't carve them out explicitly, I could be handing over my entire open-source toolkit."

Retainer: a recurring fee the client pays to reserve the consultant's availability for a defined amount of work per period. Types: Time-based retainer — client pays for X hours/month; unused hours may or may not roll over. Project retainer — ongoing relationship with priority access; not tied to specific hours. Engagement retainer — a fixed monthly fee for advisory availability. Payment vocabulary: Net-30 — payment due 30 days after invoice date. Net-15, net-60 are variations. Due on receipt — payment due immediately upon invoicing. Milestone payment — payment tied to completion of a defined project milestone. Reduces risk for both parties. Fixed-price contract — total price agreed upfront regardless of hours worked. Risk to consultant if scope is unclear. Time-and-materials (T&M) — pay for actual hours worked at agreed hourly rate. Risk to client if project expands. Blended rate — a single hourly rate for mixed-skill project teams instead of individual rates per role. Late payment clause — specifies interest charged on overdue invoices. Prompt payment discount — discount offered if paid within a shorter window (e.g., 2/10 net-30: 2% discount if paid in 10 days). In conversation: "After getting paid 90 days late twice, I moved to milestone payments — I only do the next phase of work after the previous invoice clears."

Scope creep: the gradual expansion of project scope beyond what was agreed in the SOW — often through informal requests, assumptions, or "while you're at it" additions. Scope creep erodes profitability on fixed-price contracts and strains relationships when the client expected more than the consultant planned to deliver. Change order: a formal written amendment to the SOW. Elements: description of additional work, revised deliverables, price for the change, timeline impact, updated total project cost. Must be signed before additional work begins. Scope management vocabulary: In-scope — explicitly included in the SOW. Out-of-scope — explicitly excluded. Acceptance criteria — specific, measurable conditions that determine when a deliverable is complete. Clear acceptance criteria prevent disputes about whether work is "done." Gold-plating — the consultant adding unrequested features beyond the SOW. Also a form of scope change (time spent). Deliverable — a specific, tangible output defined in the SOW (e.g., "deployed API with documentation," not "good backend"). Definition of Done — the mutual agreement of what completed work looks like. In conversation: "I never start out-of-scope work without a signed change order — even for small requests. Once you do it informally once, every request becomes just a small thing.

Liability cap: a contract clause limiting the maximum amount one party can claim from the other in damages. Standard approach: cap at the fees paid for the project (or a multiple thereof — 1× or 2× fees). Without a cap: a bug in your code could theoretically expose you to the client's entire business losses — existentially dangerous for a solo consultant. Contract risk vocabulary: Consequential damages (indirect damages) — losses beyond the direct contract value: lost profits, lost customers, reputational harm. Typically excluded from liability by both parties. Direct damages — direct financial loss caused by the breach. More likely to be covered. Indemnification — one party agrees to defend and compensate the other for third-party claims arising from a specified breach. Example: "I indemnify you against any IP infringement claims if I used someone else's code in my deliverables." Mutual indemnification — both parties indemnify each other for their respective breaches. Force majeure — neither party is liable for delays caused by events beyond their control (pandemic, natural disaster, government action). Cure period — if a party breaches, they have X days to fix it before the other party can terminate. Governing law — which country/state's laws apply to disputes. Arbitration — disputes resolved by an arbitrator (faster and cheaper than court). In conversation: "I always cap liability at my project fees — if I wrote a bug that cost the client $10M in losses, I shouldn't owe more than the $50K they paid me."

'API response schema' describes the *structure* of the data being sent back from the server – essentially, how the data is formatted. Options A and D are about UI/UX or bugs, respectively; option B is a legal agreement, not a technical specification. The correct answer focuses on the technical definition of the data itself.

'SOW' stands for 'Statement of Work,' a crucial document in freelance contracts. It clearly defines the specific tasks, deliverables, and associated costs for a particular project or change. Options A, C, and D have completely different meanings and are not relevant to this scenario.

'Consequential damages' (also known as indirect losses) are extremely difficult to prove in court. They often involve complex calculations and require demonstrating a direct causal link between the freelancer's work and the loss. Excluding this clause significantly reduces the freelancer's potential liability and financial risk – that's why it is so important.

The API response is providing feedback on a payment operation. The `status` field indicates success, and the other fields (transaction ID, amount, currency) detail the details of the successful transaction. Option A describes an error; options C and D are not typical responses from a payment gateway.

'SOW' stands for 'Statement of Work', a core document outlining the project's scope and deliverables. In this PR context, it specifies the requirements that Lisa's code changes are designed to fulfill – in this case, implementing the user authentication flow as defined in the SOW.