explicit licence needed in schema files and all repositories

[karenetheridge]

I sent a request to the debian-perl folks to package my implementation for Debian. They are concerned that I bundle the metaschema files but there is no associated licence; additionally the tests bundle the test files from JSON-Schema-Test-Suite and there is no licence there either.

I would suggest:

• adding a licence in a $comment field in the metaschemas,
• add a LICENCE file in every repository (github will link to this when it exists, for extra visiblity).

cc @Relequestual

[karenetheridge]

this can help - https://choosealicense.com/licenses/ and https://choosealicense.com/appendix/

[karenetheridge]

It would also be useful to add a paragraph somewhere giving explicit guidance regarding the use of metaschemas, test files etc and what limitations, if any, are imparted on any software that uses these resources (e.g. what licences those works can or cannot use).

[karenetheridge]

Note that for some packagers, the mere mention of the licence type/name is not enough - the full licence itself must be included in a LICENSE file.

[gregsdennis]

Why do we need the license in every file? That seems excessive. (I suppose it depends on the license we choose.)

[karenetheridge]

A single LICENSE file in the repository is likely sufficient (which would be included when the metaschemas are bundled elsewhere), but a comment in the metaschemas can't hurt, and is more clear.

[gregsdennis]

😏 Do we need to add a $license keyword to the meta vocab?

[awwright]

As far as my contributions go, the meta-schemas are public domain, and need neither a license nor attribution.

The idea that code is unusable unless it contains a license is a faulty assumption on their part (code can be public domain, and copyrighted code can be licensed separately from what it says), but to that end, there's https://unlicense.org/

I think putting that in a file next to the meta-schemas should be sufficient.

Also, I tend to doubt that most schemas have enough creative content to be copyrightable to begin with. At least in the US, objective facts & data generated by computer programs are generally not copyrightable, and outside the US, it doesn't make sense to me to cater to every broken copyright regime out there.

[gregoa]

Hi,

one member of the Debian Perl Group who started with these questions here :)

What we need are the typical permissions of FLOSS (use, modify, distribute, etc.) for us as a project and for our users. That's typically covered in a license. It's not important how this is declared (LICENSE file, in a README, in each file, …) as long as it's clear and conistent.

(If code is put into the public domain that's also fine, I'll just note that the concept of public domain doesn't exist in most jurisdictions, so everyone outside a few countries can't reliniquish all their rights and use the public domain conecpt.)

I note that README.md already mentions a License, it says The source material in this repository is licensed under the AFL or BSD license., which was a bit unclear to us at first sight:

• BSD: Which BSD version? With or without the The Regents of the University of California clause (probably not …)?
• AFL: Is this the Academic Free License 3.0?
• What das AFL or BSD mean? Both for all files, or some with AFL and some with BSD?

The easiest way forward for us would be if you could expand this section of the README.md to say something like:

The source material in this repository is licensed under the following licenses, at your choice:

<full text of chosen BSD variant>

<full text of AFL variant>

Cheers, gregor

[karenetheridge]

It would appear that the packaging of my implementation on Debian is blocked until I can provide a licence with the schema files that I bundle: https://salsa.debian.org/perl-team/modules/packages/libjson-schema-modern-perl/-/commit/2bffdfbd291a9bbf19a21d55019754f58c070dd3

[awwright]

As a general principle, we should be using language that's clear and precise, so I filed #1173 to try to resolve this.

I would also like to mention, as a widespread legal principle, contracts may be read favorably by the person receiving the text (the "construction against the drafter" principle, related to the "rule of lenity"); I don't want to spread the misconception that an unclear license actually poses a challenge. I'm unaware of any cases where someone seemed to receive a license, but had legal troubles because a jurisdiction doesn't recognize public domain, or because our license text happens to mention the University of California; our intent has been sufficiently stated. The "not all jurisdictions recognize public domain" seems to me like a boogeyman invented by lawyers to keep themselves employed, every court on Earth should have no difficulty understanding this means irrevocable permission to use the content.

[gregoa]

Thanks for the PR in #1173; that should be enough to make it clear that the schemas (which @karenetheridge includes in JSON-Schema-Modern) are released under the terms of meta/UNLICENSE which in my understanding is a perfectly fine free license.

[Relequestual]

😏 Do we need to add a $license keyword to the meta vocab?

I'm in favour of a new governance and providence vocabulary, but haven't had the time to make them. I feel like we could add it regardless.

@karenetheridge Re the test suite, is this not enough? https://github.com/json-schema-org/JSON-Schema-Test-Suite/blob/master/LICENSE

We are planning to discuss the licence specifically for the spec repo meta-schemas.

[Relequestual]

We discussed this on OCWM call https://github.com/json-schema-org/community/issues/133

Rather than relicencing, we woundered if it was preferable to add the licenses already mentioned to a licence file. Basec on the above, it looks like that would be enough. We just need to pick which AFL and BSD licence to include.

It looks like originally it said the code in the repo was covered under AFL or BSD, however it was actually MIT in the code comments 🤷‍♂️.

It was then changed to "source material".

If you consider JSON Schema files such as the meta-schemas to be "code", then it would be covered under that. But we still don't know WHICH versions of those licences.

The list of contributors for the current meta-schemas is small, and we could feasibly contact all 6 of them, but @handrews seems to be unreachable (or at least not responding, which is fine if you're reading this Henry! Keep well buddy).

Let me ask on the OpenJSF Slack what people think of this. I wonder if the licence line is even valid without specifying which they relate to.

Edit: I've now asked. (Link to join the OpenJSF Slack)

[Relequestual]

Related: https://github.com/json-schema-org/json-schema-spec/issues/532

[Relequestual]

Sorry it has taken so long to get an update on this. My email got lost in the ether.

I had a breif chat with Brian from the OpenJS Foundation, and he is now waiting for a response from legal council. I'll update as soon as I hear anything.

[Relequestual]

Response from OpenJS Foundation is as follows:

I connected with counsel on this. Here’s the recommendation.

“I suggest adding a license file that makes clear that the applicable licenses is AFL or either BSD license (2-clause or 3-clause) makes sense, notwithstanding the historical ambiguity. It’s difficult to imagine how a contributor who intended to license their contribution under the BSD 2-clause would be harmed by redistribution of the component under the BSD 3-clause, or vice versa, so I think it’s extremely unlikely that an early contributor who later disagrees would assert their rights in a way that would be detrimental.

If you’re trying to choose between the BSD 3-clause and BSD 2-clause, I would suggest going with the BSD 3-clause license, because it’s arguably slightly more protective of contributors.”

So from this perspective, I’d recommend opening a PR to push a LICENSE file with the text of BSD 3-clause first, and AFL second. I’d also update the README and any other appropriate places in the documentation. If you want to add SPDX short-form IDs that would be cool and in line with best practices, but not required. In the PR, I would recommend something like the following: “Historically JSON Schema has declared that contributions are licensed BSD or AFL, without specifying the version of BSD. We’ve been asked to specify a version for work elsewhere in the ecosystem, and OpenJS Foundation counsel recommended BSD 3-clause as the most common choice. This PR adds a license file to make this explicit.”

I would request reviews from the top contributors (if you are in contact with them), and leave it open for a few weeks for comment.

Legal’s assessment is that this should be relatively noncontroversial.

So it seems like our course of action is as follows. Create PRs (maybe one) containing:

• [x] Add LICENSE file to make clear that the applicable licenses (to meta-schemas and any other code in the repo) is AFL or BSD (3-clause)
• [x] Update README to reflect formal license acceptance
• [ ] Add SPDX short code IDs (optional)

This is open for anyone, although @karenetheridge may beat everyone else to it.