Someone Else's Textures in Your Project: How Borrowing Works

When you rework someone else's texture, copyright arises for you only in what you added yourself. The source keeps belonging to its own author, however many edits you make. That is what developer communities are really asking about when they go looking for a "safe percentage" of change. No such percentage exists: a court looks at whether the protected creative elements of the source survive in your file. Below is how that gets tested in practice, why three different texture situations behave differently, and what to keep so you can prove your own contribution.

Where the percentage myth comes from

The rule "change it by thirty percent and no one can touch you" has circulated on forums for decades. It has no legal source. No copyright statute counts altered pixels, and no court measures similarity with a ruler.

What gets tested is something else: whether what was protected in the original is still recognisable in the result. A file can be recoloured, flipped, stretched and run through filters and still infringe, if the recognisable composition, drawing and characteristic detail are all still there. The reverse also holds: a modest-looking edit can carry the result past the protected material, when nothing but the idea survives from the source.

What the law says about derivative work

Three jurisdictions converge on one point, and it settles the whole question.

The American wording has the harshest consequences. Copyright in a derivative extends only to the material you contributed and leaves the preexisting material untouched. Even a successful reworking therefore fails to make you the owner of the whole picture that comes out of it: your rights cover your own layer, and underneath it sits someone else's material that you have to be separately entitled to use, under a licence or with the author's permission.

Subsection (a) closes the workaround: where the source was taken unlawfully, protection fails for your part too. Effort invested creates no asset in that case.

The UAE provision arrives at the same place in different words: a derivative work is protected "without prejudice to the protection granted to the original Works from which these Works were derived." Reworking does not displace the original author's rights.

Three situations that keep getting confused

The texture conversation stalls because one question hides three different problems. Their legal answers differ too.

_{A texture from an asset store}

The licence settles this one, and derivative-work analysis barely enters. You obtained the file lawfully, and the scope of your rights sits in the store's agreement.

The key restriction is nearly universal: you may embed the asset in your product, and you may not ship it in a form that lets it be pulled back out. The Unity Asset Store terms say so directly: a product is not "incorporated" into your licensed product if it is designed to allow end users to extract or download assets separately. The TurboSquid licence comes at the same thing from the other side: it requires all reasonable and industry standard measures against other parties gaining access to the models, and requires the models to be held in formats that publicly available software cannot open. Epic's Fab Standard License permits commercial use, modification, and distribution of projects with the assets incorporated.

Two practical traps follow. The first is open asset directories inside the build: a player pulls the texture out of the files, and you have technically breached the extraction restriction. The second is handing the project to a publisher or a buyer: the licence was bought by your company, and whether it travels needs checking before the deal.

_{A texture from someone else's game}

Here derivative-work analysis genuinely applies, and a second layer joins it. Files from another game come out through unpacking its resources, which is a separate breach: the user agreement almost always forbids extracting assets, and circumventing technical protection is prohibited by statute regardless of what you did with the file afterwards.

The situation rarely stops at copyright. A recognisable element of another game may also be a registered design or a trade mark, and reworking the copyright layer leaves the second claim standing.

_{Your own photograph as the source}

You shoot a brick wall, rusted metal, tree bark — and you own the texture that comes out of it. That holds right up until something else lands in the frame. A logo on the wall, a recognisable façade, a protected ornament: each lives by its own rules, and the photographer's copyright does not cover them.

Stock photography adds a third layer: stock licences usually permit use of the image and separately state that no rights in the depicted subjects are granted.

What makes a reworking defensible

Since only your own contribution is protected, the task reduces to making that contribution exist and be provable.

• Creative decisions rather than mechanical operations. Resizing, rotation, a colour-profile change and automatic filters are processing. Your own composition, added elements, a rebuilt arrangement of the material — that is contribution.
• Separability. It helps when your layer can be shown on its own: source, your edits, result. The scope of your rights then reads without expert evidence.
• Work history. Layered project files, intermediate saves, dates. In a dispute these are what answer the question of what the human did.
• Provenance of the source. The store receipt, the licence number, the link to the terms and a copy of them as at the download date. Store terms get rewritten, and two years on the only way to show you complied with the 2026 version is your own copy.

On "I ran it through an AI"

This comes up in the discussions as a solution to the problem. Generative upscaling, redrawing from a reference, style transfer — all of it changes pixels and changes nothing about the legal status of the source. If someone else's file went in without the right to use it, what comes out is still a result derived from someone else's file.

A second problem lands on top of that one, and it concerns your own work. Copyright protects human creative labour. Where the decisions about how the result looks (form, composition, colour) were made by the model, there is almost no human contribution inside those decisions, and little left to protect. In February 2026 the Munich local court heard exactly this kind of dispute: the claimant had produced three logos with a generative model and demanded that the other side stop using them. The court dismissed the claim. Its reasoning ran as follows: protection arises once the person's creative choices dominate the output to the point that the thing as a whole can be regarded as their own original creation; open-ended text prompts fall short of that level, because the machine is the one picking the form. An AI usage assessment is what shows where this has already happened inside a product.

The outcome for a studio is unpleasant: the borrowed layer stayed borrowed, and your own never arrived.

In asset disputes the party that usually loses is the one who cannot show its own work. We regularly see projects where half the textures were made honestly by the team and there is nothing to prove it: files flattened to one layer, no history kept, and the source licences sitting in the mailbox of an artist who left. Inventorying assets before a deal takes weeks; reconstructing them after a buyer asks takes months.
— Futura Digital's assessment

What to do in practice

_{STEP 1 — Tag assets by origin}

Made in-house, bought from a store, taken from open sources, origin unknown. That last category is your exposure, and it is always larger than it looks.

_{STEP 2 — Keep the licence terms as at the download date}

Save a copy of the text; a link alone is not enough. Store terms get rewritten, and a claim will arrive under the version that was in force when you used the asset.

_{STEP 3 — Check that assets cannot be extracted from the build}

The Unity term quoted above turns on how the product is built: the breach is a build designed so that a user can pull the asset out separately. That gets tested against the finished build, not against the licence text.

Engines do pack assets on their own: Unity puts them in containers inside the `*_Data` folder, Unreal in `.pak` archives. There is no open folder of images sitting there — but that is no obstacle either, since standard unpackers open both formats. What to look at is whatever stayed outside the packaging: files shipped alongside the build, directories opened up for modding, web versions serving resources over direct links. Make a release build, open it the way a player would, and see what of the material you bought comes out, and at what effort.

_{STEP 4 — Keep the work history for significant assets}

Layers, intermediate versions, correspondence with the artist. For the key elements of a product this is cheap insurance.

Assets belong to the same chain of rights as code: contracts with artists, assignment of exclusive rights, provable provenance. That chain gets built through IP creator agreements, and an IP rights audit shows what state it is in. A publisher's due diligence asks for exactly these documents, and assembling them retroactively, with the deal already running, almost never works.

The short version

No percentage threshold exists. Rights arise for you in what you added with your own hands; everything else in the file stays with the author of the original. If that original was taken without permission, your part of the work gets no protection either. Of the three typical situations only one is derivative-work analysis; the other two turn on the licence and on the provenance of the file. Mechanical operations and a pass through a generative model change nothing about legal status. A dispute is won by the party that can show what it did itself, and the depth of the edit is secondary. Questions of asset rights and product protection sit within IP and content.