Clarify NIST license

[mbanck]

I was under the impression that the NIST CODATA is in the public domain, but I could not find any good pointers to that on https://www.nist.gov/srd. The only thing I could find is https://www.nist.gov/srd/public-law which is troublesome and not open data / open source, so if the data used by QCElemental is under that license, it is unclear whether QCElemental could be shipped by Linux distributions like Debian or Red Hat that require Open Source.

The top-level LICENSE file does not seem to cover that so it would be good if that could be clarified.

[loriab]

For the physconst, there's "This dataset is intended for public access and use." from here. But it looks like SRD is under gov't copyright. We could certainly add that language to files in qcel. It looks like NIST is encouraging more API access but that page is only a month old and isn't best suitable for this project. In practice, what qcel does is no different from every quantum chemistry program that grabs from NIST, then stuffs the numbers in a header, not to be changed for the next decade.

Thanks for pointing out the licensing issue. Do you think that the public use statement is enough?

[mbanck]

For the physconst, there's "This dataset is intended for public access and use." from here.

Well, that field can be "public", "restricted public" or "non-public" according to https://www.nist.gov/director/https://project-open-data.cio.gov/v1.1/schema/#accessLevel - I think anything else than "public" would be not enough for any interpretation of Open Data. But just being "public" usually isn't enough either.

But it looks like SRD is under gov't copyright. We could certainly add that language to files in qcel. It looks like NIST is encouraging more API access but that page is only a month old and isn't best suitable for this project. In practice, what qcel does is no different from every quantum chemistry program that grabs from NIST, then stuffs the numbers in a header, not to be changed for the next decade.

Yeah, I understand. This (open data vs. open source) is a recurring issue with Free Software - Physicists think it's crazy to edit the fundamental constants in any way, but Free Software people think you should entirely be able to do so.

Thanks for pointing out the licensing issue. Do you think that the public use statement is enough?

Probably not, as this got flagged by the Debian archive admins when they reviewed qcelemental for archive inclusion. "Public use" is just not enough with respect to the Free Software Definition, which requires you are allowed modify the project and ship that.

Not sure what to do here, is there a solution that does not involve the US government relicensing NIST data, but still makes it possible to build PSI4? Last I checked qcelemental was a required depedency (which is why I packaged it for Debian).

[loriab]

In the concern whether qcel is allowed to use the data as we have? Or whether someone could modify NIST data legally? The latter seems out of the scope of this project. If someone did do it, qcel is positioned to allow it because everything (physconst, covalent radii, vdW radii, except for periodic table but that could be added) is under "contexts", so the new dataset gets a new label and users can access it alongside other versions.

If the concern is the former, that sounds rather harder to solve. But I think one would have to pull most all qc programs, as they've all got this data in a header or scattered somewhere, just more deeply that qcel has.

And yes, qcel is a req'd dependency for psi4 and all qcarchive. have to depart.

[mbanck]

Side question: I guess nist_data/srd121_nist-codata-fundamental-physical-constants-2014-metadata.json is required for license compliance and/or technical reasons?

[mbanck]

As kind of a follow-up to this, we got qcelemental into Debian with just removing raw_data/nist_data/srd121_nist-codata-fundamental-physical-constants-2014-metadata.json from it, under the working theory that this file is not essential for operation.

Still would be good to have this clarified properly, but at least it's not an immediate showstopper for Psi4 in Debian/Ubuntu.

[loriab]

Sorry, I missed your 3 Nov post. Yes, none of raw_data/ are needed for operation. Thanks for finding a way to shepherd the package into Debian.