💼 Lesson 6.2: Scope, Intellectual Property & Who Owns the Code

Writing a Scope That Actually Prevents Disputes

In Lesson 6.1 you learned that the scope clause is your best defense against scope creep — the slow, unpaid expansion of a project past what was originally agreed. This section shows you how to actually write one well. We'll also build on this in Lesson 7.2, where we cover managing scope changes during a live project.

Why vague scope is the #1 source of freelance disputes

Consider two versions of the same line item on a proposal:

Vague: "Build a website for the bakery, including an online ordering system."

Precise: "Build a 6-page responsive website (Home, Menu, About, Locations, Order Online, Contact) using [stack]. The Order Online page integrates with [named ordering platform] via their embeddable widget — full custom checkout/payment processing is not included. Client supplies all menu content, photography, and copy in final form before development begins. Includes one round of design revisions and one round of development revisions."

The vague version invites a dispute the moment the client imagines "online ordering system" means a fully custom cart with inventory management, while you imagined a simple embedded widget. The precise version leaves almost no room for disagreement about what's included — and just as importantly, it's explicit about what's not included and what the client is responsible for providing.

A scope statement outline you can reuse

SCOPE OF WORK / STATEMENT OF WORK — OUTLINE
=============================================
1. PROJECT OVERVIEW
   - One or two sentences: what is being built and why

2. DELIVERABLES (be specific — list every page/feature/screen)
   - Deliverable 1: ...
   - Deliverable 2: ...

3. TECHNOLOGY / APPROACH
   - Stack, platforms, or tools to be used
   - Any third-party services/APIs involved and who pays for their fees

4. EXPLICIT EXCLUSIONS
   - What is NOT included (be as specific as the inclusions)

5. CLIENT RESPONSIBILITIES
   - Content, assets, credentials, and approvals the client must provide,
     and by when (delays here shift the timeline — reference your
     Timeline clause)

6. REVISIONS
   - Number of included rounds per deliverable; cost of extra rounds

7. ACCEPTANCE CRITERIA
   - What "done" and "approved" mean for each deliverable
   - How many business days the client has to review before it's
     considered accepted

8. ASSUMPTIONS
   - Anything you're assuming to be true when pricing this (e.g.,
     "assumes existing hosting account with admin access provided")

Notice that a scope statement is a bit more detailed than the "Scope & deliverables" clause you'd put directly in a contract — many freelancers write the full scope statement as an attached exhibit or appendix to the main contract (often called "Exhibit A" or "Statement of Work"), so the contract itself stays clean and the scope can be updated per-project without rewriting the whole agreement.

Who Owns the Code? IP Basics for Freelancers

"Intellectual property" (IP) refers to creations of the mind that the law treats as ownable — for freelance work of any kind, that's mainly copyright (which protects the actual code, text, images, video, illustrations, and other creative expression you create, not just software). Understanding a few basic IP concepts will help you negotiate ownership terms confidently instead of guessing, whether you're a developer, a designer, or a video editor.

The default rule: the creator owns it, until they don't

In general US copyright law, the person who creates the work — the code, the design file, the video edit — owns the copyright in it by default — even if someone else paid for it — unless one of two things happens: (1) it qualifies as "work made for hire," or (2) the creator explicitly assigns (transfers) the rights to someone else. This surprises a lot of new freelancers, who assume paying for work automatically means owning it. It doesn't, automatically — the contract has to say so.

The more common (and reliable) approach: assignment on payment

Most freelance services contracts, rather than relying on "work made for hire" language, use a straightforward assignment clause: the freelancer agrees to transfer ("assign") ownership of the deliverable to the client, explicitly upon full payment. This is both simpler and gives you leverage: until the client has paid in full, you retain ownership, which is a meaningful incentive for a slow-paying client to finish paying.

SAMPLE IP / OWNERSHIP CLAUSE (illustrative — have counsel review before use)
============================================================================
"Upon receipt of full and final payment for the Deliverables described in
this Agreement, Freelancer assigns to Client all right, title, and interest
in and to the Deliverables, including all associated intellectual property
rights, EXCLUDING:
  (a) any pre-existing tools, libraries, frameworks, code snippets, design
      systems, templates, presets, or similar assets owned by Freelancer
      prior to this Agreement or developed for general reuse across
      multiple clients ("Freelancer Background IP"), which Freelancer
      licenses to Client on a non-exclusive, perpetual basis solely as
      incorporated into the Deliverables; and
  (b) any third-party software, open-source components, fonts, stock
      assets (images, footage, music), or APIs incorporated into the
      Deliverables, which remain subject to their own applicable licenses.

Until full and final payment is received, all rights in the Deliverables
remain with Freelancer. Freelancer retains the right to display and
describe the Deliverables in Freelancer's portfolio, case studies, and
promotional materials, excluding any confidential or proprietary Client
information."

Licensing instead of assigning

Sometimes, instead of a full ownership transfer, you and a client agree to a license instead — the client gets the right to use the work (often broadly, e.g., "worldwide, perpetual, exclusive") without you fully transferring ownership. This is less common for custom one-off client deliverables (clients usually expect to own what they paid for outright), but it's the standard model for things like a premium WordPress theme, a plugin, a SaaS product, a stock footage/music pack, or a design template you built and are licensing to multiple customers rather than building bespoke for one client. Know which model you're in before you negotiate — "who owns it" and "who can use it" are different questions.

Open Source, Third-Party Assets & License Compliance

Almost no project is built from 100% original material. Developers pull in open-source libraries, frameworks, fonts, and third-party APIs; designers and media pros pull in stock images, footage, music, fonts, and icon sets. Each of these comes with its own license, and as the freelancer, part of your professional responsibility — no matter your discipline — is respecting those licenses and flagging any that could affect the client.

Open-source licenses at a high level

Third-party assets: fonts, images, APIs

The same logic applies beyond code:

• Fonts — many are free for personal use but require a paid license for commercial/client work, or restrict web-embedding vs. desktop use. Check before shipping a client site with a font you found "for free" online.
• Stock images/icons/footage/music — "royalty-free" is not the same as "free" — most stock licenses still require purchase and have usage limits (e.g., print run caps, no resale, no broadcast use, no trademark use). Free stock sites vary widely in their actual terms — read them.
• Third-party APIs and plugins — check the provider's terms of service for usage limits, attribution requirements, and — importantly — who's responsible for the ongoing fees or rate limits going forward (this belongs in your scope's exclusions too).

Best practice: keep a simple running list, per project, of every non-original component you used and its license — a few lines in a README or a project doc. This takes minutes, and it means you can answer a client's (or your own future) question about licensing instantly instead of having to reconstruct it later.

Protecting Your Own Reusable Work & Portfolio Rights

You bring more to every project than what's unique to that client: a developer's utility functions, boilerplate setups, and internal tools; a designer's component/design system, icon set, or starter templates; a video editor's LUTs, motion-graphics templates, and preset transitions — plus everyone's general approach and know-how. If your contract assigns "everything" to the client with no carve-out, you could technically be giving away rights to work you'll want to reuse on the very next project.

Carve-outs for your own tools

This is why the sample clause in Section 2 included a "Freelancer Background IP" carve-out — it explicitly keeps your pre-existing and general-purpose reusable work (code, design systems, templates, presets, and the like) as yours, while granting the client a license to use it as incorporated into their specific deliverable. This is standard, fair, and something most reasonable clients will accept without pushback once it's explained: you're not asking to withhold anything unique to their project, just to keep ownership of your own general-purpose building blocks.

Your right to show work in your portfolio

Don't overlook this — it's easy to forget until you're trying to build a portfolio and realize you never secured the right to show anything you made. Include an explicit clause (as in the sample above) reserving your right to display the work — screenshots, a link, a brief case-study description, a reel clip — in your portfolio and marketing, while still respecting the client's confidential business information (e.g., you can show the finished UI or final video, but maybe not a client's internal admin dashboard with real customer data visible, unreleased footage, or specific business metrics they'd rather keep private). If a client needs the work to stay fully confidential (common for internal tools, pre-launch products, or unreleased campaigns), negotiate this upfront — e.g., a delayed portfolio right ("may be shown after public launch") is a reasonable compromise.

NDAs and confidentiality, revisited

Recall from Lesson 6.1 that confidentiality clauses/NDAs typically run both directions. From an IP standpoint, this matters because it protects you too — your reusable tools, pricing, and internal processes are exactly the kind of information you'd want covered by a mutual (not one-sided) confidentiality clause.

Fair IP terms aren't about taking more for yourself — they're about making sure ownership matches reality: the client owns what's unique to their project, and you keep what's genuinely yours across every project.

📋 Templates & Examples

1. PROJECT OVERVIEW
   A 5-page marketing website for a local physical-therapy clinic to
   generate appointment-booking leads.

2. DELIVERABLES
   - Home, Services, About, Testimonials, Contact pages
   - Mobile-responsive layout, contact form emailing to one address
   - Basic on-page SEO (titles, meta descriptions, alt text)

3. TECHNOLOGY / APPROACH
   - Static site (HTML/CSS/JS), deployed to Netlify
   - Contact form via a third-party form-handling service (client pays
     any service fees above the free tier)

4. EXPLICIT EXCLUSIONS
   - No CMS/blog functionality
   - No ongoing hosting/maintenance after 30-day warranty window
   - No paid advertising setup or copywriting beyond light editing

5. CLIENT RESPONSIBILITIES
   - Final copy and photography provided within 5 business days of
     contract signing
   - One designated point of contact for approvals

6. REVISIONS
   - 2 rounds of design revisions, 1 round of development revisions
     included; additional rounds billed at $75/hour

7. ACCEPTANCE CRITERIA
   - Client has 5 business days to review each milestone; no response
     within that window counts as approved

8. ASSUMPTIONS
   - Client already owns their domain name and will provide DNS access

1. PROJECT OVERVIEW
   A full brand identity package for a local physical-therapy clinic
   (name already set), to use across signage, print, and web.

2. DELIVERABLES
   - Primary logo + 1 secondary/icon mark, 2 color variations
   - One-page brand style guide (colors, type, logo usage rules)
   - Exported files: PNG, SVG, PDF (print-ready)

3. TOOLS / APPROACH
   - Designed in Adobe Illustrator; source .ai files included per
     Section 4's ownership terms
   - Font selection uses commercially-licensed webfonts (client pays
     any licensing fees above what's already covered)

4. EXPLICIT EXCLUSIONS
   - No business card, signage, or vehicle wrap design
   - No trademark search or registration
   - No motion/animated logo version

5. CLIENT RESPONSIBILITIES
   - Completed brand questionnaire and any existing brand assets
     provided within 5 business days of contract signing

6. REVISIONS
   - 3 rounds of concept revisions included; additional rounds
     billed at $75/hour

7. ACCEPTANCE CRITERIA
   - Client has 5 business days to review each round; no response
     within that window counts as approved

8. ASSUMPTIONS
   - Client has secured rights to the business name being used

Best Practices & Common Mistakes

✅ Do's

• Tie IP transfer to full payment. It's fair, standard, and gives you real leverage if a client stalls on the final invoice.
• Write scope exclusions as carefully as inclusions. Vague inclusions with no exclusions are the #1 driver of scope-creep arguments.
• Log every third-party license you use, per project. A two-minute habit that saves hours of reconstruction later.

❌ Don'ts

• Don't sign an "all rights, no carve-out" IP clause without reading it — you could be giving away rights to your own general-purpose tools, templates, or presets.
• Don't assume "royalty-free" means "free" for stock assets — read the actual license terms before shipping.
• Don't forget to reserve your portfolio rights — it's much harder to negotiate after the project is finished and delivered.

📓 Work Journal

📝 Summary

🎉 What You've Accomplished

You now understand the IP fundamentals that most new freelancers never learn until a dispute forces them to — and you've drafted a real scope statement and IP plan you can adapt for actual client work.

❓ Common Questions at This Stage

🔭 Looking Ahead

Next, in Lesson 6.3: Liability, Insurance & Protecting Yourself, we'll cover how to limit your financial exposure if something in your delivered work goes wrong, and what kinds of insurance freelancers might consider.

📚 Additional Resources

• choosealicense.com: Plain-English Guide to Open-Source Licenses
• U.S. Copyright Office: Works Made for Hire (Circular 9)