Extend the specification to define a license property, so that IP considerations are unambiguous, and it is addressed consistently.

[ericjohnson-tibco]

Since the intent of schemas is to be widely used and shared, they should probably include standard license information.

Two forms come to mind:

"$spdx_license_identifier" : "MIT",

"$license_text" : [
"Copyright ... some Co.\n",
"This file is covered by our license ...\n",
"Please note the following rules...\n",
" blah, blah, blah\n",
]

[handrews]

@ericjohnson-tibco interesting idea. The bar for a new core keyword ($-prefix) is very high, but legal requirements are the sort of thing with strong interoperability requirements. Arguably only the core vocabulary offers that.

I would prefer $license as an object which can have sub-keys. We avoid that in general (e.g. contentMediaType, contentEncoding instead of a content object), but licensing is very much its own thing.

Note that with draft 2019-09's vocabulary feature you could create a licensing vocabulary to try this out and try to get other implementations to adopt it. Which would give us more information about whether this is really needed in core.

[Relequestual]

With no feedback on thoughts since Oct, I'm removing this issue from draft-09 milestone.
Any resolution would likely be to write a seperate vocabulary.
Happy to help explain how to do that if it's something you want to investigate.

[awlayton]

I might be interested in try to make a vocabulary to add this to my schemata. How can I got about it in a way that it might actually be accepted eventually?

[awwright]

I don't think this makes sense.

There is nothing about this that is specific to JSON Schema, and any solution we come up with, I think you should be able to use to describe other documents, too. I think data like this is better expressed with something more standard, like the rel=license link relation. Or perhaps a JSON Schema defines a keyword equivalent to an HTML meta tag.

Also I think licensing is a legal concept, and technical standards do not set the law. And in the US, APIs and data are not necessarily copyrightable. The contents of a book might be copyrighted; but the fact the book is divided into chapters and each chapter has one heading and 0+ paragraphs and so on—this is just expressing a fact about how books are written; likewise, JSON Schema is merely expressing facts about how JSON documents are formed. So I think the presence of a "license" property could be misleading.

[karenetheridge]

I think some purely informational (non-validating) keywords for documenting schema ownership and attribution could be useful - e.g. $author, $contact_info, $licence etc. At present all this information needs to be stuffed into $comment (and that keyword is explicitly permitted to be stripped during publishing, whereas we shouldn't be stripping attribution data).

[Relequestual]

I've seen a number of meta-data keywords or indeed an object, record things like copyright and provenance.
These are fine things to have in a schema file!
@awwright whether or not a schema can be copyrightable is not something I can be sure of, but if people want to use permissive licences to avoid potential issues, then why not? Code files often have their own copyright at the top, and schemas are a kind of code, maybe?

I might be interested in try to make a vocabulary to add this to my schemata. How can I go about it in a way that it might actually be accepted eventually? - @awlayton

First, you need to define the additional keywords you want to add, what they mean, and what they represent.
Once you document that, you can then write a schema for it.
Once you have a schema for it, you add to your documentation, the vocabulary URI and, and create a new meta-schema which includes that vocabulary.

Those last steps, we can help with!

How can I go about it in a way that it might actually be accepted eventually?

I'm not sure exactly what you mean by this. If you create a vocabulary, YOU have created it. It's your thing you provide tooling for or convince other people is worth using. As an org, we may curate a list of published vocabularies, but we're not going to look after or promote them. The main reason for vocabularies is to allow extensions to be written by OTHER people.

There's an example at the bottom of the core spec for how to write a new meta-schema with a new vocabulary.

Come by our slack if you want help or have questions.

As an aside, I've migrated this issue to the vocabularies repo. We haven't updated it in a while, but it allows others to find others interested in a specific aspect... hopefully. We haven't formally worked out what to do with it yet, other than move issues here which don't fit in core or validation.