json-schema-spec
json-schema-spec copied to clipboard
json-schema-org
Schemas and other data are public domain
- does the filename UNLICENSE have any special meaning in that it is not a LICENSE?
- I would put this file in the root of the repository, rather than in meta/, as the main schema file is in the root as
schema.json. It will also be much more visible there to casual browsers of the repo.
does the filename UNLICENSE have any special meaning in that it is not a LICENSE?
I think the name is to emphasize that, to the extent it is acting as a license, that it's not intending to be one. I've found that GitHub recognizes the filename. But it doesn't matter either way.
I would put this file in the root of the repository
To me, I would read this, and it would imply it's authoritative for all the content in the entire repository, but this isn't correct.
To me, I would read this, and it would imply it's authoritative for all the content in the entire repository, but this isn't correct.
The file should either say explicitly which files it applies to, or be rewritten so it does apply to all files.
I feel that if the file is not in the root it will not be seen, and certainly not be understood to apply to /schema.json.
I think this is fine, but let's add it to the agenda for our upcoming Open Community Working Meeting call (for which I have yet to create an issue... on it now and will update).
I'm not keen on the file name. It just, is odd. Interesting that GitHub recognise it.
I see you're using the "unlicense" license, which is OSI regonised and approved, as opposed to some statements about public domain.
@karenetheridge do you use schemas in the output directory too?
If so, we will need the licence and readme there also.
The file should either say explicitly which files it applies to, or be rewritten so it does apply to all files.
It's uncommon to modify the actual contents of the license file, and probably discouraged for possible legal complications that none of us can foresee. I think it's best if README.md describe which files are provided under which license. We can then include the text of each license to remove any remaining ambiguity.
I feel that if the file is not in the root it will not be seen, and certainly not be understood to apply to /schema.json.
I think it can be buried somewhat if that helps clarify its scope; it's more important that we be unambiguous. We can also specify: "As attached in the meta/UNLICENSE file in this repository." (Or "As attached in LICENSE.Unlicense", or whatever the filename is.)
I think it's best if README.md describe which files are provided under which license
Yup, it can't hurt to be explicit :)
I think it can be buried somewhat if that helps clarify its scope
Yes, but part of my point was that burying a licence file in meta/ would be wrong if we intend it to apply to /schema.json as well.
@karenetheridge do you use schemas in the output directory too?
I would assume that all the schema files would apply under the same licence.
Perhaps we should move them all to a common subdirectory. Then there can be a LICENSE file in that subdirectory, along with a README that clearly states that the licence is intended to apply to those files.
The draft-next branch has been merged and is now closed. The merge target for this PR has been changed to main. Here are the recommended steps to get your branch reabsed properly.
- Make sure your remote for the
json-schema-org/json-schema-specrepo is up-to-date. (Example:git fetch upstream). - Rebase your commits onto
main. (Example:git rebase --onto upstream/main abcd123~1(replaceabcd123with the commit hash of the first commit in your PR)). - Force push the rebased branch to your fork. (Example:
git push --force origin my-branch).
@awwright @Julian is this an alternative to #1255 or is it complementary? Austin, can you rebase/recreate/whatever this onto main so the diff is readable without having to dig out the individual commit?
This one was before we got guidance from OpenJS legal. It's still possibly relevant though if we want an even more liberal licence for the schemas than for the rest of the repo.
I just looked at this again. This bit causes me concern:
Anyone is free to copy, modify, publish, use, compile, sell, or distribute this software
How would we feel if someone took the main metaschema, modified it (say to change the semantics for a keyword they didn't like), and then published it in their implementation without changing the $id? That would cause confusion among any who used that implementation, and surely is something we would ask the author to stop doing. Can we avoid that by spelling out that the files can be redistributed but not altered?
That's how open source works; nothing stops someone from doing that - but in practice, who would actually care about the knockoff?
Can we avoid that by spelling out that the files can be redistributed but not altered?
I think one of the Creative Commons variations might do that.
who would actually care about the knockoff?
If the knockoff is an implementation like ajv (which already does some roguish things), the impact could be significant.
If the knockoff is an implementation like ajv (which already does some roguish things), the impact could be significant.
That's a good point. We should probably be better about defining what it means to claim you implement JSON Schema. Which is not a spec thing, but is a thing the JSON Schema Org should think about. At this point, what AJV implements by default (without having to reconfigure it) is not JSON Schema despite the claims, and it's a problem.
If a deviation is sufficiently useful that it gains adoption, then perhaps that’s a strong signal that the spec should incorporate it.
@ljharb not if the deviations results in a constant stream of people showing up asking us why their schema that ought to work doesn't work. AJV is one implementation, no matter how popular. We don't get people showing up in the slack asking for more implementations to act like it, but we do get a lot of people who are confused and annoyed.
We've adopted quite a few innovations from the community, including AJV (which played a large role in the adoption of if/then/else). But those adoptions are due to broader demand beyond any one implementation.
(Any language or license that limits peoples' ability to create derivative works from official metaschemas is going to cause issues for people creating metaschemas we do want them to create, i.e. ones where they do indeed change $id and add stuff, or modify stuff, or use what we produce as a baseline, etc. So I too would oppose any restrictions there personally, for whatever my vote counts.)
@Julian the language would be tied to the $id value. Other people shouldn't publish json-schema.org identifiers.
I still think such a thing would cause issues personally. Any custom language typically does for e.g. corporate users.
Any custom language
- That's overly vague, let's talk about specifics
- There are many licenses covering many usage patterns, it need not be "custom" (we shouldn't be writing custom legal language without a lawyer)
The things to consider are:
- Can you use a
json-schema.org-identified schema (JSOIS) in a for-profit application? Yes - Can you redistribute an unmodified JSOIS in a for-profit application? Yes
- Can you create a derivation of a JSOIS that does not use
json-schema.orgin its$idand do anything you want with it? Yes - Can you non-functionally modify (e.g. minify or otherwise reformat) a JSOIS and use/redistribute it just as the original? Yes
- Can you functionally modify a JSOIS and re-publish it with the same
$id? No - Can you create a new schema with a
json-schema.org$idand publish it? No
I've shared my opinion. Feel free to have your own or disregard mine, but I stand by what I said.
EDIT: by which I mean any such language that would limit someone's use of $id is what I mean by custom, even if written by a lawyer.
I'd be interested in hearing from any FOSS compliance people on whether the approach I sketched out would cause any problems.
I'm not dead set on these restrictions, but it's worth considering, and perhaps checking to see if the OpenJS Foundation has any resources or advice to consider.
Yep that definitely seems reasonable to me too. (Obviously they will ask about what license the existing ones are under, which I'd suspect would be presumed to be BSD like the documents).
On Sun, 28 Aug 2022 20:46:38 -0700, Karen Etheridge wrote:
Anyone is free to copy, modify, publish, use, compile, sell, or distribute this software
How would we feel if someone took the main metaschema, modified it (say to change the semantics for a keyword they didn't like), and then published it in their implementation without changing the
$id? That would cause confusion among any who used that implementation, and surely is something we would ask the author to stop doing. Can we avoid that by spelling out that the files can be redistributed but not altered?
If the license forbids modification, the software would fail any FLOSS definition, from the Debian Free Software Guidelines to OSI's Open Source Definition, etc.
For Debian that would mean that we can't include it in Debian "main" (i.e. the "proper" Debian archive), we would have to put it into the "non-free" archive area (which is not enabled by default and not available for other packages etc.).
Cheers, gregor, Debian Perl Group member
--
.''. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 . ' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe -
