KhronosGroup / OpenGL-Registry

OpenGL, OpenGL ES, and OpenGL ES-SC API and Extension Registry
677 stars 274 forks source link

Include complete license text #628

Closed ghost closed 1 month ago

ghost commented 1 month ago

DISCLAIMER: I'm not a lawyer, nor is this legal advice. Follow at your own risk.

Using the SPDX license identifier alone is an insufficient replacement for the actual license text. I've discussed this here, here's the TL;DR: The original license text of the API headers appear to have been replaced with the SPDX ID within this commit about three years ago, quote from the commit description:

@pdaniell-nv recommend approving ASAP. This has benefits downstream when doing REUSE license checking in repositories which host these files.

REUSE requires that all licenses are placed in their own dedicated folder, which hasn't been done. This repository isn't considered REUSE-compliant and follows bad licensing terms.

I'm a fan of the licensing practice used in FreeBSD (take a look at cat.c). Blender, on the other hand, has all the licenses in doc/licenses and provides the SPDX ID and copyright text at the top of each file.

And what about the extensions and specs? Are they proprietary, or not owned by Khronos?

I'd love to see these changes be made, as many loaders (Glad, GLEW, gl3w, etc.) download the headers from this repository and this could be problematic.

oddhack commented 1 month ago

We cannot say what the licenses on all the extensions are. It is literally impossible, many of the companies have been out of business for decades. REUSE compatibility is worth doing and I'll take a look at that, but most vendor extensions are just going to be under a placeholder "LicenseRef-Unknown" to pacify REUSE.

We are not going to start injecting full MIT or Apache 2.0 whatever licenses in the headers, and Khronos does have an IP lawyer whom such matters have been discussed with.

ghost commented 1 month ago

We cannot say what the licenses on all the extensions are. It is literally impossible, many of the companies have been out of business for decades.

Yeah, I can see what you mean. Some SGI extensions date back to the 90s.

We are not going to start injecting full MIT or Apache 2.0 whatever licenses in the headers

Ha, the Apache license might just be longer than the header itself! However the MIT license isn't very long, sparing trouble for the loaders I mentioned... but very well then.

Khronos does have an IP lawyer whom such matters have been discussed with.

I'm glad to hear that a real lawyer is going to take action.

REUSE compatibility is worth doing and I'll take a look at that

Thank you for your consideration!

oddhack commented 1 month ago

It's good to know that a real lawyer is going to take action.

More that the real lawyer has long since signed off on using SPDX identifiers, so there won't be any action other than to minimally REUSE-ify the repo. Whenever you remove a file with just a copyright and SPDX ID from a repository, you'll have to carry the actual license terms with it - the advantage of the standard IDs is that this is not hard to sort out.

ghost commented 1 month ago

Whenever you remove a file with just a copyright and SPDX ID from a repository, you'll have to carry the actual license terms with it - the advantage of the standard IDs is that this is not hard to sort out.

I can see why it's worth the minor complications, many large projects are resorting to SPDX for the same reason.

Vulkan-Docs appears to be doing this right; licenses appear to be in LICENSES/, the LICENSE.adoc makes it clear that each ID corresponds to a specific license, and COPYING.adoc defines the specific license of each directory... though there appears to be one minor slip-off on that repo...

The license template hasn't been modified to state the copyright years and copyright holders, and I believe that that error has made it's way to chrome://credits as I've stated on the forums. Search for "vulkan". I believe that this happened because reuse download --all downloads them as-is, without informing.

ghost commented 1 month ago

It's been a week and no updates. This is urgent.

oddhack commented 1 month ago

Closing, since this user has deleted their account. In principle this is a moderately useful thing to do but it's not a high priority for Khronos, as people have been using these headers without trouble for decades.