Fix missing DGG license

[aaronfranke]

This PR takes out a part of #237, just the fixes for the DGG license.

The Darmstadt Graphics Group GmbH legal mark license was missing validation in the PHP script. This caused the PHP script to produce invalid license text in the .reuse/dep5 file. This PR adds a case for this license, similar to the existing code for Cesium, Khronos, and UX3D. I also ran the PHP script locally.

[javagl]

This looks "OK" for me insofar that it follows the pattern of other licenses. But I'm starting to question that pattern in #253 (somewhat unrelated to this PR, and probably to be dicussed independently)

[javagl]

As discussed in #253 : The values of the link and text fields at https://github.com/KhronosGroup/glTF-Sample-Assets/pull/248/files#diff-09506a581239de149cd51038a4ec19738712ea024006cb0d91a6e070f3246d63R194 probably don't make sense. I don't have a clear idea about how to resolve this. We could

1. merge this PR, and then resolve #253 "holistically" by fixing these links and texts for all licenses in the LICENSES folder
2. solve #253 and include the addition of the DGG license there
3. update this PR to include fixes for #253 (even though some details may still TBD)

No strong preference, just laying out options.

[aaronfranke]

@javagl I don't feel, let's say, legally qualified to fix licensing-related code beyond simple fixes like this PR, so I won't do option 3 myself. If the license stuff needs restructuring, that should be done by someone who knows this area best.

[echadwick-dgg3d]

These seem like GitHub formatting issues to me. It seems like treating the DGG company logo as a trademark is the right way to go here.

Content submitters like myself will need clear guidance on whatever the desired metadata formatting should be, once these issues are resolved. In the past, I just copied existing repo files, editing them to reflect the new content. So we should make sure existing repo files are properly formatted, and create clear submission guidelines.

[javagl]

I just copied existing repo files, editing them to reflect the new content.

same here, and that may not be ideal, particularly in "non-standard-(license)-cases".

So we should make sure existing repo files are properly formatted, and create clear submission guidelines.

Yes, the submission guidelines have to be clarified - and this includes some aspects of the workflow. I started to ~"fix a few things" in #254 , but will have to read some of the metadata handling code more thoroughly. (Currently, low priority on my side, but will try to make some progress some time, and in the meantime, everybody can chime in...)

---

EDIT: Didn't mean to close...