Spot the legal question

1890. Lesson identity

Module

4.14 — Legal basics

Lesson

1 — Spot the legal question

Academic type

Concept

Schema type

text

Order

1 of the module

Estimated time

30–40 minutes, including practice

1891. Learning objective

After this lesson, you can classify a production scenario as primarily legal, technical, product-related, or mixed, and state the evidence needed before deciding how to proceed.

1892. Why this matters

Game production regularly combines different kinds of decisions. A missing permission is not solved by writing better code, and a slow asset pipeline is not automatically a legal problem. If you misclassify the question, you may ask the wrong person, give an AI tool the wrong task, or commit to work before a necessary right has been verified. Correct classification creates a useful handoff without pretending that a quick checklist is legal advice.

1893. Prior knowledge

You should be able to map the production scenario before classifying its legal dimension. In particular, you should be able to identify the contributors involved, the assets being created or used, the relevant data flows, any store commitments or platform-facing promises, and the production dependencies that connect these elements. You should also be able to describe the intended player experience and the boundary of a production task. The previous lesson, 4.13 L2 — Write an AI-ready external brief, introduced bounded delegation, explicit constraints, and the project owner's responsibility for integration decisions. No legal training is assumed.

1894. Core concept

A legal question asks whether the project has a right, permission, obligation, restriction, or privacy responsibility that governs a proposed action. It is answered by examining an applicable law, agreement, license, consent record, privacy notice, platform term, or other authoritative source—not by asking whether the action is technically possible or desirable for the product. Common signals include:

• Rights: Who owns or controls the asset, recording, name, likeness, text, or code?
• Licenses: What permission was granted, to whom, for which uses, in which territories, and for how long?
• Privacy: Does the project collect, store, share, or expose personal information, and what obligations govern that activity?
• Terms: Do a platform, service, library, marketplace, or provider impose conditions on use?
• Evidence: What authoritative source demonstrates the relevant permission, restriction, consent, or obligation, and does it cover the intended use?

A technical question concerns whether something can be implemented reliably: for example, whether a file imports correctly or whether a network request fails. A product question concerns what the game should do for its audience and goals: for example, whether a feature improves clarity or belongs in the release scope. One scenario can be mixed. A mixed question must be separated into parts rather than treated as one undifferentiated problem.

This lesson teaches triage, not a legal conclusion. When the consequences are material or the evidence is unclear, escalate the question to an appropriately qualified legal professional.

1895. Mental model

Use the Authority–Implementation–Experience–Evidence check:

Then apply the source test: identify the authoritative source that governs the question, state what part of the source must be checked, and confirm that its scope covers the intended use. A contract, license, consent record, privacy notice, platform term, or provider agreement may answer a legal question. A repository record or technical log can document provenance or implementation behavior, but it does not by itself prove legal permission. A guess, an AI-generated statement, or the fact that an asset is easy to download is not evidence of permission.

1896. Concrete example

A team wants to add a sound file found in an online library to a game prototype.

1. Legal question: What license applies, and does it allow this game use? Is attribution required? Is commercial or redistribution use restricted?
2. Evidence: Record the asset's source page, license text, version or date, author information, and any attribution requirement.
3. Technical question: If use is permitted, does the file import and play in the target build?
4. Product question: If it works, does the sound support the intended tone and feedback of the game?

The technical test does not answer the legal question. The product decision does not create a license. The team can perform the technical and product evaluations while the permission question remains clearly marked for verification.

1897. Common mistake

The common mistake is treating availability as permission. A file that is visible online, included in a tool, or returned by an AI system may still have an owner, a license restriction, an attribution condition, or a privacy implication. Another mistake is labeling every uncertainty “legal.” A broken import is technical; whether the team may use the file is legal. Separate the questions so each one receives the correct evidence and owner.

1898. Guided practice

Classify each scenario as legal, technical, product, or mixed. For every answer, write one sentence explaining the category and one item of evidence or test that would move the decision forward.

1. The team cannot determine whether a purchased music pack permits use in a publicly distributed game.
2. A character's portrait appears blurry after the build process, although the source image is sharp.
3. The team is deciding whether an optional dialogue choice makes the player's objective clearer.
4. A feedback form may store player email addresses, and the team has not decided what information is collected or how it is used.
5. A third-party service's terms may restrict how generated images can be included in the game, and the team also needs to decide whether the images fit the art direction.

For scenario 5, produce two separate statements: one legal question about the service terms and one product question about art direction. Do not resolve either question by guessing.

1899. Validation / evidence

Your work is valid when:

• All five scenarios have a category.
• Each legal or mixed scenario names a specific authority or source to verify.
• Each technical scenario names a reproducible test rather than a permission claim.
• Each product scenario names a player or design criterion.
• Scenario 5 is split into distinct legal and product questions.
• You identify at least one case where the available information is insufficient for a decision and state what evidence is missing.

The evidence is your completed classification table and the short explanations. This demonstrates that you can identify a legal question without presenting a legal conclusion.

1900. Key takeaways

• Legal questions concern rights, permissions, obligations, restrictions, privacy, or agreements that govern a proposed action.
• Technical questions ask whether something can work; product questions ask whether it should be part of the game.
• Mixed scenarios must be decomposed into separate decisions.
• Online availability and AI output are not proof of permission.
• Evidence should identify the authoritative source, applicable scope, conditions, and date where relevant.

1901. Next lesson

Next: 4.14 L2 — Build a review-ready legal inventory. You will turn legal-question triage into a practical record of assets, authoritative sources, permissions, and unresolved checks.

1902. Knowledge check