VRM and Live2D encode different rules for who owns a digital face

What happened

Two file formats let a companion app's visual character move between different pieces of software: VRM, a specification maintained by the VRM Consortium, and Live2D, a commercial rigging tool. The VRM Consortium's own site states that VRM is a cross-platform, glTF-based humanoid avatar format, while Live2D's own site describes software that 'directly animates your original drawings' in two dimensions. Both remain actively maintained, and this description reflects them as retrieved on 16 September 2026.

What the documents show

VRM's own overview states its purpose plainly: 'you can share the same avatar (3D model) data between VRM-compatible applications,' listing live streaming, VR games, and chat as example destinations, and notes an official Unity plugin exists for creators. The specification's metadata documentation lists specific required and optional fields carried inside a VRM file itself, including a required licenseUrl, an avatarPermission field controlling who may perform as the avatar, a commercialUsage field distinguishing personal non-profit, personal profit, and corporate use, and separate boolean flags covering violent, sexual, political, and redistribution permissions. Live2D's homepage, by contrast, describes governing use through separate agreements, a 'Software License Agreement,' a 'Free Material License Agreement,' and others, rather than fields embedded in the character file itself.

The mechanism

The key difference the documents establish is where usage rules live. A VRM file carries its own machine-readable permission fields as part of the asset, so the same file can, in principle, declare its rules to any compliant viewer it is loaded into, independent of which company's app opened it. Live2D instead rigs a two-dimensional illustration and leaves the terms of use in separate license agreements between the parties, outside the asset file, meaning enforcement and permission tracking depend on which agreement governs a particular use rather than on data traveling with the model itself.

What it leaves open

Neither source describes what happens if a viewer simply ignores a VRM file's declared permissions; the specification is descriptive metadata, not an access-control mechanism enforced by any particular software. Nor do the documents reviewed describe an actual case of a user recovering and reusing an avatar after a companion app's shutdown, only the technical capacity for a file to carry that information.

• Does an avatar format carry its own permission data, or rely on separate license agreements to govern reuse?
• What compliant software would actually read and respect a VRM file's declared usage permissions?
• If a companion app shut down, could a user's avatar file be verified to work anywhere else in practice?

A portable file format is a necessary condition for an avatar to outlive one company's app, but the documents here describe that capacity, not a demonstrated instance of it happening.