glTF is an open standard. It is not withheld by patents or license fees, you are free to implement it.

The specification is under CC-BY-4.0. This is the key insight: Documents have copyright. When I tell you that the specification is under CC-BY-4.0, I'm talking about all the documents that describe it. If you distribute any part of those documents, you need to attribute it. But you do not need to distribute the specification to implement it. KhronosGroup also has scripts and tools on the glTF specification repository which are under Apache License 2.0, you don't need those either.

By the way, the glTF format is also ratified as ISO/IEC 12113:2022, you can buy the standard from ISO (it cost 0, but you have to register), and you would be getting the standard under ISO Customer License Agreement, which is completely different, but equally irrelevant for your case.

If you implement the specification own your own, you are the author of that code, and as author you can reserve all rights over it.

Remember that trademarks covers the the use of the names or brands. If you do not include the names of glTF or Khronos Group in your game, you need to worry it is not in a way that might cause people to think you or your game is in someway affiliated with them.

Meanwhile, copyright covers the expression of ideas, not the ideas themselves. If you implement the glTF specification, it is your own expression of their ideas, and thus, it is at least in principle free of their copyright. In practice it might not be, depending if took somebody else implementation and modified, then we need to consider the copyright of that somebody else.

Finally, the scorch over earth (this opinion is my own) known as software patents could extend to alternative implementations, but being glTF an open standard, there are no software patents that you need to worry about.

For example there is an extension for Unity that loads glTF in runtime developed under the Khronos Group umbrella under MIT license: https://github.com/KhronosGroup/UnityGLTF

Another example that comes to mind is that Godot has custom code (development independently) to read and write glTF (useful for the few of us who want to use Godot to make 3D tools) and it is also under MIT.

These examples aren't the only options. Meanwhile they evidence that code that use glTF can be under other licenses unrelated to the license of the specification.

VRoid uses the vrm file extension. The files are glTF with some custom extra stuff. So you can take a vrm, change the extension, and import it to Blender using glTF import. This is OK.

In practice glTF an other similar standards are good as exchange formats (they are good to allow software to interoperate, such as Blender and your game engine).

However, glTF, obj, and similar formats are not the best for runtime... For runtime you want a format that closely resembles how you layout memory for the GPU, so you need minimum processing from reading the file to using it, which is going to a binary format tailored for your shaders.

Because of that, game engines often import the glTF but store it in a custom format, which is what actually gets deployed on release. Which means: games made with most engines can use glTF during their development but do not actually ship code to load glTF. This is the usual way it works, although there are exceptions.

As per the names, the closer to official names is the rigify naming convention, which is not protected in anyway (if it were, then making models with bones with those names would be legal a concern, regardless of format). Yet, you don't have to use those names if you do not want to: rename the bones, or make your own rig. In fact making your own rig is not unusual for game development studios.

Although using a well known format is good if you are making is a tool

If you are making a tool (e.g. your want to make it easy for others to mod your game), then it makes sense to use a well known format and to mention it. In doing so, you would allow your tool to interoperate with other software that uses the well known format, and users won't be confused about it.

I believe you should not feature the glTF or KhronosGroup names prominently, as to not create - a legal basis for a lawsuit about potential - user confusion regarding your product being associated with them. But, presumably there would be mention of it in documentation and import options.

Addendum: Yes KhronosGroup want you to use the glTF logo as to signify compatibility. Make sure to follow their guidelines if you are doing that: https://www.khronos.org/legal/trademarks/

glTF is an open standard. It is not withheld by patents or license fees; you are free to implement it. In Khronos's own words:

Any developer or company can freely download the available Khronos API Specifications and implement and ship products using the specification completely free of charge, royalty or licensing.

The specification is under CC-BY-4.0. This is the key insight: Documents have copyright. When I tell you that the specification is under CC-BY-4.0, I'm talking about all the documents that describe it. If you distribute any part of those documents, you need to attribute it. But you do not need to distribute the specification to implement it. The Khronos Group also has scripts and tools on the glTF specification repository which are under Apache License 2.0; you don't need those either.

By the way, the glTF format is also ratified as ISO/IEC 12113:2022. You can buy the standard from ISO (it costs nothing, but you have to register), and you would be getting the standard under the ISO Customer License Agreement, which is completely different, but equally irrelevant for your case.

If you implement the specification on your own, you are the author of that code, and as author you can reserve all rights over it.

Remember that trademarks cover the the use of the names or brands. If you do not include the names of glTF or Khronos Group in your game, you do not need to worry. The trademark just protects them from uses of their names/brands in a way that might cause people to think you or your game is in some way affiliated with them.

Meanwhile, copyright covers the expression of ideas, not the ideas themselves. If you implement the glTF specification, it is your own expression of their ideas, and thus, it is at least in principle free of their copyright. In practice it might not be: for example, if you took somebody else's implementation and modified it, then we need to consider the copyright of that implementor.

Finally, the scourge over the Earth (this opinion is my own) known as software patents could extend to alternative implementations, but with glTF being an open standard, there are no software patents that you need to worry about.

For example there is an extension for Unity that loads glTF in runtime developed under the Khronos Group umbrella under an MIT license: https://github.com/KhronosGroup/UnityGLTF

Another example that comes to mind is that Godot has custom code (developed independently) to read and write glTF (useful for the few of us who want to use Godot to make 3D tools) and it is also under an MIT license.

These examples aren't the only options. Meanwhile, they demonstrate that code that uses glTF can be under other licenses unrelated to the license of the specification.

VRoid uses the vrm file extension. The files are glTF with some custom extra stuff. So you can take a vrm file, change the extension, and import it to Blender using glTF import. This is OK.

In practice, glTF and other similar standards are good as exchange formats (they are good to allow software to interoperate, such as Blender and your game engine).

However, glTF, obj, and similar formats are not the best for runtime... For runtime, you want a format that closely resembles how you lay out memory for the GPU, so you need minimum processing from reading the file to using it, which is going to mean using a binary format tailored for your shaders.

Because of that, game engines often import the glTF but store it in a custom format, which is what actually gets deployed on release. That means: games made with most engines can use glTF during their development but do not actually ship code to load glTF. This is the usual way it works, although there are exceptions.

As per the names, the closest thing to "official" names is the Rigify naming convention, which is not protected in any way (if it were, then making models with bones with those names would be a legal concern, regardless of format). Yet, you don't have to use those names if you do not want to: rename the bones, or make your own rig. In fact, making your own rig is not unusual for game development studios.

Although using a well known format is good if what you are making is a tool

If you are making a tool (e.g. you want to make it easy for others to mod your game), then it makes sense to use a well known format and to mention it. In doing so, you would allow your tool to interoperate with other software that uses the well known format, and users won't be confused about it.

I believe you should not feature the glTF or Khronos Group names prominently, as to not create a legal basis for a lawsuit about potential user confusion regarding your product being associated with them. But, presumably there would be mention of it in documentation and import options.

Addendum: Yes Khronos Group want you to use the glTF logo as to signify compatibility. Make sure to register as a File Format Adopter and follow their guidelines if you are doing that.

Let me tell you what is cool: include a credits sequence and there properly attribute the people who contributed to the game, including any assets you used under a free license, regardless if the attribution is required or not. You can even tell those artists and creators that your game used their assets over social media, which might turn into positive for marketing the game.

Addendum: Yes KhronosGroup want you to use the glTF logo as to signify compatibility. Make sure to follow their guidelines if you are doing that: https://www.khronos.org/legal/trademarks/

Let me tell you what is cool: include a credits sequence and there properly attribute the people who contributed to the game, including but not limited to any assets you used under a free license, regardless if the attribution is required or not. You can even tell those artists and creators that your game used their assets over social media, which might turn into positive for marketing the game.