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.