Set up build, add basic files

[handrews]

LICENSE is from the JSON Schema spec repo, replacing "JSON Schema Specification Authors" with
"JSON Schema Organization".

CONTRIBUTING.md is a highly condensed adaptation of the file in the JSON Schema spec repo.

BACKGROUND.md is mostly stuff that was in appendixes of an early draft of a proposal that does not need to be part of a standard at all. There's too much of it to put in the README, but I got feedback that the material was very useful for some folks.

Makefile is adapted from the IETF HTTP APIs working group spec repository. The only change is to set the CSS to the style used for published I-Ds. For some reason, that is not the deafult.

The presence of "lib/" is .gitignore is because that is where the Makefile checks out the tools and creates a virtual env.

[gregsdennis]

There's a proposed JSON Path usage for $ref as well: ietf-wg-jsonpath/draft-ietf-jsonpath-base#124. I implemented this as an extension behavior in my library.

Add it in if you like.

[gregsdennis]

Looks good to me. Minor editorial comment.

[jdesrosiers]

This looks mostly fine to me other than a couple corrections I commented on inline. My only concern is the license. Didn't we find that the JSON Schema license was problematic? It would probably be a good idea not to carry that over here. I think something simple like MIT would be a better choice.

[jdesrosiers]

@gregsdennis

There's a proposed JSON Path usage for $ref as well:

That use-case is exactly the kind of thing my vision for a JSON Reference media type is all about. The same idea can be applied to data being validated by JSON Schema, which is what I implemented several years ago and called Hyperjump Validation. Doing something similar with a JSON querying language like JSON Path was another application of the concept that I was thinking about at the time.

[handrews]

@jdesrosiers

[The JSON Path] use-case is exactly the kind of thing my vision for a JSON Reference media type is all about.

Glad @gregsdennis brought it up- if there are any other discussions or uses around that align with what you're doing, please let me know or just open a PR and add them later. I just kind of poked around until I had what felt like "enough" but there wasn't exactly a metric involved.

[handrews]

@jdesrosiers please let me know if this wording feels correct. I am happy to change it further.

Regarding the license, yes but then there was this PR that was recently merged and the license is from there. I did just now copy over the text from the README in that repo that's also part of that PR, which I had not noticed before.

[EDIT: Originally forgot the OAS 3.1 part but fixed just now]

[jdesrosiers]

The changes are fine, just a small typo.

[jdesrosiers]

Regarding the license, yes but then there was this PR that was recently merged and the license is from there.

My understanding was that we can't/shouldn't change the license because people have already been using it under the old license. The change in that PR was ok only because it was fixing an ambiguity, but the preference was to go with something different entirely. Since it's apparently not ok to change the license later, I just don't want us to get locked in to something we don't want to get stuck with. I think we should check with @Relequestual since he was way more involved in the license discussion than I was an probably has an opinion.

[handrews]

@jdesrosiers ah, I did not know that about the license, I wasn't really paying that much attention to it.

Hopefully @Relequestual can weigh in on Monday. I don't have an opinion on what it should be, I'll happily put in whatever is considered appropriate.

[Julian]

Some color on the LICENSE (initially opinionless more or less):

• Yeah, what we have in the spec repository is at least in part because those are the licenses we always have had, and indeed we're not free to change that really (or if we do, that doesn't change that those precise contents are still available historically under the license they were under previously).
• We indeed didn't properly specify a detail of those licenses (which version of them we were using), which the PR that was linked was fixing (in json-schema-org/json-schema-spec@51326f8). Sometimes that can be dicey too in other similar situations but Ben got advice from OpenJS legal saying we're OK there (in particular because essentially we're talking about ambiguity between two fairly similar fairly open licenses anyhow)
• The fact that we dual license the spec repo under either AFL or BSD (3-clause) seems to date back to the beginning of it and even more specifically to something it seems Dojo did, which is something/somewhere Kris Zyp worked at/on at the time. I don't know if this is written down anywhere in history (maybe it is), but my best guess is that the reason for the dual licensing is that the FSF considers AFL to be incompatible with the GPL (see here), and so it was dual licensed BSD so that it could be used alongside GPL code. On the flip side the same wikipedia page lists some reasons some folks prefer AFL (and therefore not single licensed under BSD), though honestly I don't know how "practical" that is -- in the sense that unscientifically I don't see AFL very often, whereas BSD is pretty common in the circles I see (or MIT, which is basically just the BSD 2-clause license with no functional changes)
• Tangentially, finding the above commit (which I should have thought of sooner) honestly probably clarifies the license situation for the spec repo, since it seems clear and/or likely that the intended versions of AFL and BSD are the same ones Dojo was using and specifying elsewhere. But probably we've already beaten that horse enough.

All the above being said...

My opinion probably agrees with the suggestion here, that I'd personally skip dual licensing until/unless someone has a reason to. I'd probably just go with the BSD 3-clause (which is half of what's in that file, and legal from OpenJS claimed was more common than BSD 2-clause at this point EDIT: actually the reason they gave was "because it’s arguably slightly more protective of contributors"), and let someone come along later and ask us to dual license under something else if there's ever a reason it's needed (I can't imagine one). But yeah that allows us to be flexible without needing to worry about putting cats back in bags after.

The only exception would be if large portions of what's here come from previous other repos (like the spec repo), in which case it's already dual licensed because the place it came from was (in which case for our sanity we should probably stick exactly as is).

Hope some of that makes sense (and doesn't involve any armchair lawyering, which I of course am not).

[awwright]

The license should probably continue to say "Authors" or "Contributors" because "JSON Schema Organization" isn't a legal entity for purposes of copyright, and even if a legal entity was named, either the authors would have to transfer their copyright, or that would have to be clear from context (e.g. it was produced as a "work for hire")

[handrews]

@Julian since the specifications here are essentially extracted from the JSON Schema spec repo, it sounds like we should actually just keep the spec repo license after all.

@awwright good catch, I'll make it "specification authors" in general since "JSON Schema Specification Authors" isn't quite right for this repo and we don't yet have a single named specification here.

[Julian]

If that's the case then yeah agreed!

[Relequestual]

Regarding the license, yes but then there was this PR that was recently merged and the license is from there.

My understanding was that we can't/shouldn't change the license because people have already been using it under the old license. The change in that PR was ok only because it was fixing an ambiguity, but the preference was to go with something different entirely. ...

Yup, that's right.

...
The only exception would be if large portions of what's here come from previous other repos (like the spec repo), in which case it's already dual licensed because the place it came from was (in which case for our sanity we should probably stick exactly as is).

Yup. What constitutes "large portions"? That would be a legal question. However, I feel it's fine to find that out if the questions ever arise. The content of the spec has been shuffled around and rewritten so much that I imagine it's very hard in some situations to find the original author.

I feel it makes the most sense to start this repo under a single license such as BSD(three-clause) or MIT. I understand MIT is closer to two-clause BSD. I think I personally prefer three-clause, but I'm not likely to dig into this spec writing much.

[Relequestual]

Looks like this is off to a great start. Made a few comments and suggestions.

[Relequestual]

I'd like to see badges added to the repo readme as per the community repo (https://www.repostatus.org as appropriate). Feel free to cover in this PR or create a new issue.

[handrews]

I chatted with @Relequestual on IM and he told me it's OK to merge this now.

[Relequestual]

I can't signal approval post merge so this will have to do =]