Why software licences show up in an art pipeline
Game and VFX projects absorb a surprising amount of code that never came from your programmers: a HLSL/GLSL shader pack off GitHub, a free Unity editor extension, a Blender add-on baked into your export pipeline, an open-source importer, a compression library vendored into a tool. Each of those is governed not by a marketplace EULA but by an open-source software licence, and that licence binds you the moment you distribute the thing it is attached to. The two families that matter are permissive (MIT, Apache 2.0, BSD, zlib) and copyleft (GPL, LGPL, AGPL).
| Licence | Family | Ship in a closed game? | Main obligation |
|---|---|---|---|
| MIT / BSD / zlib | Permissive | Yes | Preserve copyright + licence notice |
| Apache 2.0 | Permissive | Yes | Notice + carry any NOTICE file; patent grant |
| LGPL | Weak copyleft | Usually, if dynamically linked | Allow relinking; publish changes to the library |
| GPL | Strong copyleft | High risk | Combined work must be GPL + source offered |
| AGPL | Network copyleft | High risk | GPL terms extended to network/served use |
The permissive notice requirement
MIT and BSD ask for almost nothing - but they do ask for one thing that studios routinely miss: you must preserve the copyright notice and licence text and distribute them with the product. It does not have to be on the credits screen; a bundled licences.txt, an in-game acknowledgements page or a NOTICE file in the install directory all satisfy it. Apache 2.0 adds a wrinkle: if the upstream project ships a NOTICE file, you must carry its contents forward, and Apache also comes with an explicit patent grant that terminates if you sue the authors over patents. None of this is onerous - it just has to actually happen, and it has to happen for every permissive component, not just the famous ones.
GPL copyleft: the one to keep out of the build
The GPL is designed to spread. If you combine GPL-licensed code with your own - link it, statically or (per the FSF's position) even dynamically in many cases - the resulting work can be required to be licensed under the GPL as a whole, with corresponding source made available to your users. For a proprietary game or a client deliverable that is usually a dealbreaker, which is why many studios simply ban GPL and AGPL code from shipping builds and reach for an MIT/Apache/BSD equivalent or a commercial licence instead. LGPL is the softer cousin: it generally lets you use the library in a closed product provided it is dynamically linked and users can relink an updated version, but it still obliges you to publish any changes you make to the library itself. The safe habit is to know which of your code-bearing assets are copyleft before the build locks, not after a publisher's scanner flags them.
Keep a NOTICE / attribution trail
Whatever the licence, the operational answer is the same: maintain a single, exportable list of every third-party software component, its licence, its version and its notice text. That list is what feeds your in-product acknowledgements page, and it is what a publisher's or acquirer's due-diligence questionnaire is really asking for when it says "list your open-source dependencies." Building it once and updating it as components arrive is trivial; reconstructing it from a locked build is a forensic exercise.
How the register handles code-bearing assets
Asset Licence Register treats a shader, plugin or tool exactly like a model: it carries MIT / Apache / GPL as built-in licence types with SPDX identifiers. Tag a component MIT or Apache and it raises the notice-required flag until you record where the notice lives; tag it GPL and it raises a copyleft-risk flag so a shipping decision is a conscious one, not an accident. Everything then rolls up into the same manifest and CREDITS export as the rest of your assets - one due-diligence answer covering art and code together.