Add optional asset.license field

onox commented 7 years ago

The field asset.copyright defines the copyright owner of the content, but it does not say anything about licenses. Some content is licensed under CC or even GPL. If there's no clear indication what the license of the content is, it must be considered to be proprietary. A license field would avoid any possible confusion.

Would it be an idea to specify a list of popular licenses that people can choose from when exporting? The spec should make it clear that the version of the license should be included. For example:

CC-BY-SA-4.0 equals Creative Commons Attribution-ShareAlike 4.0 International License
GPLv2+ equals GNU General Public License version 2 or any later version
GPLv3 equals GNU General Public License version 3

The list should be extended with the other Creative Commons licenses and probably a bunch of other licenses as well. Note that in the case of the GPL, the notice (in source files) sometimes contains "or (at your option) any later version", but sometimes it does not. I've used the + here to make that distinction.

Having a predefined list would make it easy for 3D editing programs to allow the user to choose one of those when exporting the model to glTF.

The field should be optional (in which case the model is proprietary). Perhaps it is a good idea to allow the field to contain a custom / arbitrary license as well (not just one from the predefined list above).

pjcozzi commented 7 years ago

I think its a good idea post 2.0 so we have some time to think through licenses. In the meantime, this could be stored as a property in an application-specific extras object property.

emackey commented 7 years ago

@pjcozzi not sure I agree. Content licenses are quite important to artists and authors. It shouldn't be an enum, since people can put any kind of custom license on any file. It could just be a free-form text string.

lexaknyazev commented 7 years ago

Two more possible issues with such field:

Some parts of an asset could have different licenses. E.g. CC-BY for textures, and CC-BY-ND-SA for final model. Not sure, if it's correct to use one field for everything.
In some cases, free-form text (e.g. full GPL license) could be larger than the rest of glTF JSON. We definitely don't want to feed parsers with that.

In case of "vanilla" glTF encoding (all binary resources in separate files), it should be sufficient to put a LICENCE file in the same directory as JSON and distribute whole package as tar.gz, imho.

On the other hand, it could be reasonable to have machine-readable metadata about asset's copying policy, especially for one-file containers like GLB.

emackey commented 7 years ago

One license field should be enough since glTF supplies only a single copyright field. Multiple copyrights can be listed comma-separated in that field, and multiple licenses can be listed in the license field. The two fields are related, but not the same.
I don't expect people to paste a complete copy of the legal text into the license field. They might put URLs or instructions to get the license there.

Here's an example of how this might work:

"asset" : {
    "copyright" : "Copyright 2017 by Alice Baker.  Textures copyright 2010 by Texture Artists Inc, used with permission.",
    "license" : "Model licensed under CC-BY-ND-SA, see https://creativecommons.org/licenses/by-nc-nd/4.0/.  Textures licensed under CC-BY 4.0, see https://creativecommons.org/licenses/by/4.0/",
    // other fields here...
}

The license(s) just need to be visible to any humans glancing at the top of the decompressed JSON in a text viewer/editor. Like copyright, it doesn't need to be understood by the client software (or at most, advanced clients may have some option to display glTF metadata including copyright and license, but only if that is relevant to the purpose of the client software in some way). It's there to provide guidance on the behavior of humans, not software.

lexaknyazev commented 7 years ago

it doesn't need to be understood by the client software It's there to provide guidance on the behavior of humans

If so, one free-form text field should be fine. I thought of use case like public assets catalog operation, so user could, e.g., easily filter out assets which allow derivatives.

emackey commented 7 years ago

I thought of use case like public assets catalog operation

Yeah I don't think we need to engineer a system for them, they'll need a DB backend or curated metadata of some kind, they can implement that for themselves. I think glTF just needs an optional, free-form text field for people to put notice of license(s) on their work.

pjcozzi commented 7 years ago

@lexaknyazev let's discuss on the call today. I don't think we should make this decision in haste.

onox commented 7 years ago

It shouldn't be an enum, since people can put any kind of custom license on any file. It could just be a free-form text string.

The issue with a free-form text string is that people might forget to specify the exact version or list licenses that do not exist (like CC-BY-ND-SA in your example) (in your example you also point to an URL of a different license, BY-NC-ND).

With an enum you can avoid such problems if the program that exports the .gltf file allows the user to choose from a list (or enter a custom text). An enum is also easily parsed and the non-abbreviated name of the license + URL could be displayed in a program / web page that lists available .gltf files.

In some cases, free-form text (e.g. full GPL license) could be larger than the rest of glTF JSON

The field is not meant to put the whole license in it, just an enum or free-form text that refers to a certain license.

Some parts of an asset could have different licenses. E.g. CC-BY for textures, and CC-BY-ND-SA for final model. Not sure, if it's correct to use one field for everything

That's a good point, perhaps make the field an object with the name of the referenced files as keys?

emackey commented 7 years ago

Maybe we could make it work the way npm's package.json license field works? That is sufficient even for projects that contain a lot of 3rd-party code.

https://docs.npmjs.com/files/package.json#license

RemiArnaud commented 7 years ago

for reference - npm uses https://spdx.org/licenses/https://spdx.org/licenses/ , with the addition of: "SEE LICENSE IN " and "UNLICENSED"

emackey commented 7 years ago

@RemiArnaud Exactly. I think the URL got pasted twice but that's exactly the idea. I'm a bit surprised that glTF 1.0 shipped without a license field, and I think we could catch up by taking some other package management's well-used license field and adding it to 2.0.

onox commented 7 years ago

Maybe we could make it work the way npm's package.json license field works? That is sufficient even for projects that contain a lot of 3rd-party code.

Using the SPDX license expressions would be a great idea. Should there be a license field per file (images, buffers, etc.) or simply go for the (A AND B) syntax?

AurL commented 6 years ago

@pjcozzi we are looking to add model metadata to export glTF from Sketchfab, and we currently target something like this example:

"asset": {
    "extras": {
      "author": {
        "name": "AurL",
        "url": "https://sketchfab.com/waleguene"
      },
      "license": {
        "type": "Creative Commons Attribution",
        "url": "http://creativecommons.org/licenses/by/4.0/"
      },
     "source": "https://sketchfab.com/models/adec10493e06436c967d5797f7085225"
    },
    "generator": "Sketchfab (OSG glTF plugin)",
    "version": "2.0"
  },

I guess that copyright is different from license, and that it doesn't make sense to mix both. According to this thread, there was a tentative to add a license field in the specification but it has been dropped for 2.0. Is there anything new that I could have missed about adding license informations in glTF ? Do you guys have any hint? I would think that a license field could be added in asset, with a schema close to the example above.

If there is nothing new, I guess we will keep this as an extra for now, but we will need to regenerate everything once it's added to the glTF specification.

Thanks

donmccurdy commented 6 years ago

For licenses, it might be nice to use SPDX license IDs to guarantee some consistency across tools. For example "Creative Commons Attribution" would not be uniquely identifiable without the URL, whereas CC-BY-4.0 is unambiguous. These IDs are used by npm's license field.

pjcozzi commented 6 years ago

@AurL no new updates here. You are right that copyright and license would be separate. @donmccurdy's SPDX license IDs has potential. Could be a straightforward extension. @AurL would you want to champion this if we were able to collect use cases?

Speaking of use cases, anyone have them for use or feedback on licenses in glTF?

AurL commented 6 years ago

@pjcozzi we already have usecases on Sketchfab as every single free downloadable model has a license attached to it and Sketchfab licenses for store models.

@donmccurdy 👍 for the consistency, It seems to be the way to go. We are thinking about having these infos, but it's not clear how to specify them:

{
  "license": {
    "identifier": "CC-BY-4.0",
    "name": "Creative Commons Attribution 4.0",
    "url": "https://creativecommons.org/licenses/by/4.0/legalcode"
  }
}

identifier could be required, and may be sufficient, until it comes to custom licenses, where an url would be kind or required in order to get the license details. We were also thinking about adding name that could be a human readable and "ready to display" info but it could give more issues than advantages (non adequation with identifier, non concistency like CC Attribution vs Creative Common Attribution, etc).

Off topic but related, it could be a good opportunity to add an author (optionnal), since it would make sense for all assets.

We would obviously keep the sketchfab related stuff like source and the sketchfab account url in the extra data.

I guess the community will have very interesting feedbacks on this 👍

mramato commented 6 years ago

+1 for a single SPDX license field, they are official and can be validated. It also eliminates the need for a name or url field since having the license ID gets you access to that information as well (though they could still be marked optional for completeness or edge cases).

emackey commented 6 years ago

It also eliminates the need for a name or url field

It's important to remember that content creators (in general, not on a specific site) are free to have their own legal teams invent and apply licenses with any wording they choose. They don't have to select a license from a table of known licenses.

zellski commented 6 years ago

Just to emphasise @AurL's post above — I dragged a glTF export .zip from Sketchfab into the Insimo viewer yesterday and did a double-take of astonished joy when it added an author (with link) widget to the page. It was so painfully, immediately obviously how things should be.

Clearly that info is pulled from the AUTHOR file. Having something like it in .gltf itself would be lovely.

donmccurdy commented 6 years ago

The npm documentation on this is rather quite good, and addresses the case of new licenses:

If you are using a license that hasn't been assigned an SPDX identifier, or if you are using a custom license, use a string value like this one:

{ "license" : "SEE LICENSE IN <filename>" }

[ In our case this could be a URL rather than a filename. And: ]

Finally, if you do not wish to grant others the right to use a private or unpublished package under any terms:

{ "license": "UNLICENSED" }

A similar section describes how to list an author, including any combination of name/email/url: https://docs.npmjs.com/files/package.json#people-fields-author-contributors

zellski commented 6 years ago

From Facebook's end, we likely wouldn't display a model's license or author to end users, but we're pretty keen on it being part of the model definition, and we'd go out of our way to preserve it -- even inside otherwise stripped-down & transformed versions, meant purely for delivery from our backend to clients. I agree that extending this issue to include author information would be practical.

AurL commented 6 years ago

Thanks a lot for your feedbacks. So If I'm correctly following that has been said, with a custom Sketchfab Licence it should give something like:

"asset": {
    "extras": {
      "source": "https://sketchfab.com/models/adec10493e06436c967d5797f7085225"
    },
    "author": "AurlC <mymail@gmail.com> (https://skfb-local.com/waleguene)",
    "generator": "Sketchfab (OSG glTF plugin)",
    "license": "SKETCHFAB EDITORIAL (https://sketchfab.com/licenses)",
    "version": "2.0"
  },

I'm not sure about the shape of the license string, but it follow what is done with author. (And for licenses having an SPDX identifier, license would only contain the ID)

lexaknyazev commented 6 years ago

asset.license field could be introduced only with minor version update (e.g. 2.1). Until then, it should be enclosed in an extension object like this (just an example):

{
  "asset": {
    "extras": {
      "source": "https://sketchfab.com/models/adec10493e06436c967d5797f7085225"
    },
    "author": "AurlC <mymail@gmail.com> (https://skfb-local.com/waleguene)",
    "generator": "Sketchfab (OSG glTF plugin)",
    "extensions": {
      "EXT_asset_license": {
        "license": "SKETCHFAB EDITORIAL (https://sketchfab.com/licenses)"
      }
    },
    "version": "2.0"
  }
}

donmccurdy commented 6 years ago

If we're fairly confident we'll get this into the spec (e.g. 2.1) is it worth muddying the water with an EXT_ extension in the meantime? If it's definitely temporary, the lesser formality of extras seems nice.

lexaknyazev commented 6 years ago

For just one optional string field, extras is perfectly fine as a temporary solution. Choice between an extension and version update probably depends on release timeline and ecosystem adoption.

zellski commented 6 years ago

@AurL & others -- is it accurate to say that that we may be creeping up on an informal standard on this format?

"asset": {
    "extras": {
      "author": "Pär Winzell <zell@alyx.com> (https://alyx.com/zell)",
      "license": "Creative Commons Attribution (http://creativecommons.org/licenses/by/4.0/)",
    },
    "version": "2.0"
  },

AurL commented 6 years ago

@zellski On Sketchfab we want to include these informations as soon as possible so we're currently pushing an update to have this:

"asset": {
    "extras": {
      "author": "AurL (https://sketchfab.com/waleguene)",
      "license": "CC-BY-4.0",
      "source": "https://sketchfab.com/models/e8252dff6bb046038878cf6aba975e83"
    },
    "generator": "Sketchfab-3.1.0,
    "version": "2.0"
  },

I might not be the final format but at least the info will be available. When the specification will be ready to welcome it (including changes), we will follow the update.

Edit: SPDX license ID should be used if available. For custom licences, Name (url) syntax can be used.

onox commented 6 years ago

I'm voting for the SPDX license ID expressions.

donmccurdy commented 6 years ago

A note that came up in #1297, as part of this we may also want to consider either adding an asset.generatorVersion field, an asset.extras.generatorVersion semi-official field, or recommending a particular format for the asset.generator field that includes a version like my-exporter@1.25.0. This is not pressing, but worth considering if we move forward with changes here.

MiiBond commented 6 years ago

Hello. We (Adobe) are looking into adding author/license data to our glTF's exported from Dimension. Ideally, we'd like to define a standard extension rather than just using the extras tag and we'd like to be able to define this metadata per node rather than just globally. The reason for per-node/asset is that users can build scenes out of assets that they've downloaded from Adobe Stock and other places and we want to have the license data travel with the asset.

Before we go ahead and define an extension for this, we'd like to gauge if there is any interest from other parties in aligning this extension with the properties available in the XMP standard? https://www.adobe.com/devnet/xmp.html I see that there was an issue opened last year about this. #1161

We would potentially have use for including other metadata besides just author/license info so adopting an existing metadata spec seems like it might make sense.

robertlong commented 6 years ago

We (Mozilla) are also interested in adding support for author/license data to glTF. We are currently exporting glTF files from Spoke that contain multiple source assets (from Sketchfab, Google Poly, etc.), each of which can have different licenses and author information.

We'd like to see:

Support for defining multiple authors / licenses
Use SPDX identifiers for licenses

It looks like maybe XMP can define that, but this is the first time I'm reading through the spec. There seems to be a lot of video specific metadata and it would need to be converted from XML to JSON. Perhaps you could provide an example of what you are thinking for the extension?

emackey commented 6 years ago

@AurL Would Sketchfab be willing to migrate, if a new metadata extension were published meeting the needs described in the recent comments above?

emilian0 commented 6 years ago

@robertlong , Yes XMP fields will have to be ported to JSON. You can find a list of namespaces and property descriptions here: https://github.com/adobe/xmp-docs/tree/master/XMPNamespaces In particular the dc and xmpRights namespace seems to have almost all that is needed for us: https://github.com/adobe/xmp-docs/blob/master/XMPNamespaces/dc.md https://github.com/adobe/xmp-docs/blob/master/XMPNamespaces/xmpRights.md Xmp and xmpMM are interesting as well The extension Mike and I are thinking about is something along these lines.

{
    "dc:creator": [ "John1", "John2"],
    "dc:contributor" : [ "John"],
    "dc:publisher" : ["Company"],
    "xmpRights:WebStatement": "http://license term",
     ...
}

I didn't find a way to specify licensing via SPDX:ID. Worst case you can probably use xmpRights:WebStatement to point to the SPDX license term.

pjcozzi commented 5 years ago

@donmccurdy any chance you could loop in the Google Poly team here to seek their requirements and feedback?

donmccurdy commented 5 years ago

Before I do, could someone write up a more concrete proposal for what JSON XMP license metadata would look like? I assume we'd keep only a subset of the properties in the "dc" namespace? If so, which properties? Can contributors' and creators' URLs or email addresses be included in some way? I don't see that from the XMP spec.

I'm particularly concerned about the lack of an unambiguous, machine-readable license identifier. Putting SPDX into xmpRights:WebStatement does not seem sufficient.

If we need to add a property or two, does that defeat the purpose of aligning with XMP, or is this still valuable?

emilian0 commented 5 years ago

@donmccurdy regarding adding properties. If we add additional information I don't think that is a problem, perhaps we can add a new namespace. If we work around deficiencies in the specs of current XMP properties by adding new properties that have overlapping semantics we might have issues.

What do you suggest for the license identifier? would SPDX be enough for you? (I am not sure that would be enough for us, it appears to be designed for software licensing rather than media)

I don't think there is a specific field for URLs and emails. Do you think this should be part of the contributor array (contributor would be a dictionary of name, url, email)? Or do you think this should be a separated array: contributor , contributor_urls, contributor_email?

We will review properties & namespace that we are interested in including in the metadata and update the draft.

emilian0 commented 5 years ago

@donmccurdy @pjcozzi @robertlong This proposal includes the entire dc namespace. All properties are optional. If you prefer trimming it down that could also work. Please look at the way contributors or creators names are encoded. Would that work for you? I believe the dc:rights property addresses both your concerns regarding having unambiguous license identifiers (SPDX) and our concern regarding the flexibility of this property. Please let us know what you think.

{
  "KHR_XMP": {
    "dc:contributor" : [ "Creator1Name", "Creator2Email@email.com", "Creator3Name<Email@email.com>"],
    "dc:coverage" : "Bay Area, California, United States",
    "dc:creator" : [ "CreatorName", "CreatorEmail@email.com"],
    "dc:date" : "1997-07-16T19:20:30+01:00",
    "dc:description" : { "en-us: "text"},
    "dc:format" : "model/gltf-binary",
    "dc:identifier" : "urn:stock-id:292930",
    "dc:language" : ["en"],
    "dc:publisher" : ["Company"],
    "dc:relation" : ["https://www.khronos.org/"],
    "dc:rights" : ["BSD-Protection"],
    "dc:source" : "http://related_resource.org/derived_from_this.gltf",
    "dc:subject" : ["architecture"],
    "dc:title" : { "en-us" : "MyModel"},
    "dc:type" : "Physical Object",
  }
}

Property	DCMI definition	Description	Type
`dc:contributor`	An entity responsible for making contributions to the resource.	Can be a Name, an email address, or both in the form `Name<email@email.com>`	Ordered array of text
`dc:coverage`	The spatial or temporal topic of the resource, the spatial applicability of the resource, or the jurisdiction under which the resource is relevant.	Open ended	Text
`dc:creator`	An entity primarily responsible for making the resource	Can be a Name, an email address, or both in the form `Name<email@email.com>`	Ordered array of text
`dc:date`	A point or period of time associated with an event in the life cycle of the resource	date-time specified as ISO 8601	Text ISO 8601
`dc:description`	An account of the resource	Textual descriptions of the content of the resource.	Language Alternative
`dc:format`	The file format, physical medium, or dimensions of the resource.	Prefer using a mediatype when available.	Text mediatype
`dc:identifier`	An unambiguous reference to the resource within a given context	Can be in the form of URN or text.	URN or Text
`dc:language`	A language of the resource	RFC 3066 language code	Array of RFC 3066 codes
`dc:publisher`	An entity responsible for making the resource available	A list of Names or urls.	Unordered array of text
`dc:relation`	A related resource. Recommended best practice is to identify the related resource by means of a string conforming to a formal identification system	A list of URLS	Unordered array of text
`dc:rights`	Information about rights held in and over the resource	We recommend using an SPDX identifier when appropriate, alternative can be a list of informal right statements or URLs	Unordered array of text
`dc:source`	A related resource from which the described resource is derived.	When possible prefer a URL.	Text
`dc:subject`	The topic of the resource	A list of descriptive phrases or keywords that specify the content of the resource (open ended)	Unordered array of text
`dc:title`	A name given to the resource.	Text	Language Alternative
`dc:type`	The nature or genre of the resource	Refer to the DCMITYPE vocabulary when possible	Unordered array of text

references: https://github.com/adobe/xmp-docs/blob/master/XMPNamespaces/dc.md

Note that, in the future, this could be extended with other XMP namespace, such as xmp that provides, for instance, disambiguation between creation and modified dates.

vyv03354 commented 5 years ago

@emilian0

Can dc:identifier be a URL (not a URN) such as "https://sketchfab.com/models/e8252dff6bb046038878cf6aba975e83"?
Shouldn't the Language Alternative list be something like
```
{
"en": "english text",
"fr": "french text",
"x-default": "default text"
}
```
instead of a simple array? Otherwise it will make incompatible changes to the Dublin Core semantics.
IMO dc:rights is too ambiguous to describe license identifier exclusively. Note that glTF already has the asset.copyright property, but OP requested a separate license property. Some licenses (such as CC) require to preserve copyright notice if provided, so I agree with that we need a separate property.

emilian0 commented 5 years ago

Hi @vyv03354, thanks for your feedback, please find my answers below:

I believe you can use URLs instead of URNs. The specs (http://dublincore.org/documents/dces/) says recommended best practice is to identify the resource by means of a string conforming to a formal identification system.. So using URN is just a recommendation. This said I believe you want to use dc:source to store that url. "dc:source" : "https://sketchfab.com/models/e8252dff6bb046038878cf6aba975e83".
Yes, thanks for pointing that out, I will fix the proposal above.
"IMO dc:rights is too ambiguous to describe license identifier exclusively." => I agree. I believe we want to fit 3 classes of licensing metadata: open ended copyright notice, url, machine-readable identifier. My understanding is that you are suggesting to have separated properties for that (rather than fitting everything in the dc:rights field), correct?

andreasplesch commented 5 years ago

Would a KHR_XMP extension object be designed to apply for all, the gltf asset, the gltf scene or scenes, and used resources such as textures or meshes which have their own sources needing acknowledgment ?

emilian0 commented 5 years ago

@andreasplesch . Yes, that is what we are proposing. Do you agree?

andreasplesch commented 5 years ago

Yes, that would be best, in order to avoid rediscussing metadata for textures. It just was not clear from the discussion sofar as it started out with asset.

donmccurdy commented 5 years ago

We mention "per-node" above – if multiple textures attached to the same mesh might have different attribution, we'd need some additional attachment points. Perhaps something like:

{
  extensions: { KHR_XMP: {
    entries: [ ... ]
  } },
  nodes: [
    { mesh: 0, extensions: {KHR_XMP: {index: 0}}},
    ...
  ],
  images: [
    {uri: 'baseColor.png', extensions: {KHR_XMP: {index: 1}}},
    ...
  ]
}

andreasplesch commented 5 years ago

Yes, per node is mentioned.

I looked up the COLLADA metadata capabilities in https://www.khronos.org/files/collada_spec_1_5.pdf for a more domain specific attempt. examples here:

<COLLADA>
 <asset>
   <created>2005-06-27T21:00:00Z</created>
   <keywords>COLLADA interchange</keywords>
   <modified>2005-06-27T21:00:00Z</modified>
   <unit name="nautical_league" meter="5556.0" />
   <up_axis>Z_UP</up_axis>
 </asset>
</COLLADA>

<asset>
 <contributor>
   <author>Bob the Artist</author>
   <author_email>bob@bobartist.com</author_email>
   <author_website>http://www.bobartist.com</author_website>
   <authoring_tool>Super3DmodelMaker3000</authoring_tool>
   <comments>This is a big Tank</comments>
   <copyright>Bob's game shack: all rights reserved</copyright>
   <source_data>c:/models/tank.s3d</source_data>
 </contributor>
</asset>

Not sure if there is something for textures. It does seem best to align with a larger effort such as XMP.

It might be better to keep things flat, eg. to avoid referencing into an array of sets of metadata. I think it would be rare that it is necessary to reference the same set twice.

emilian0 commented 5 years ago

Added #1553 pull request.Please let me know what you think. Thanks.

emilian0 commented 5 years ago

Hi @AurL would this work for you?

"asset": {
    extensions : {"KHR_XMP": {
      "dc:creator": ["AurL (https://sketchfab.com/waleguene)"],
      "gltf:spdx": "CC-BY-4.0",
      "dc:identifier": "https://sketchfab.com/models/e8252dff6bb046038878cf6aba975e83"
    }},
    "generator": "Sketchfab-3.1.0,
    "version": "2.0"
  },

vyv03354 commented 5 years ago

Is it correct to use dc:source here? Per the spec,

The described resource may be derived from the related resource in whole or in part. Recommended best practice is to identify the related resource by means of a string conforming to a formal identification system.

So I thought dc:source will point an original work from a derivative work. This is the reason why I asked whether URLs are usable for dc:identifier. Note that dc:source has exact the same description as dc:identifier about an identification system: by means of a string conforming to a formal identification system.

emilian0 commented 5 years ago

@vyv03354 I believe you are right, I am going to fix my comment above. Thank you!

emackey commented 3 years ago

This conversation moved to KHR_xmp and is now being updated to KHR_xmp_json_ld. Closing this old issue.

onox commented 3 years ago

@emackey This whole XMP extension doesn't address what this issue asked for: a simple field to specify a SPDX expression.

KhronosGroup / glTF

Add optional asset.license field #839