Suppose that I wanted to make a vulkan_sys crate that contained bindings to vulkan for rust. What licensing would be appropriate to use in that case?
#applicable licensing?
noble thicket
noble thicket
I do have some licenses I prefer to conform to rust's licensing open source conventions, however, I want to know if I'm affected by vulkan's licenses in any way.
zenith agate
if you copy paste stuff from lunarg/khronos code those are apache 2
if you copy purely the spec you are fine
zenith agate
the US legal system declared APIs as non copyrightable so legally you are fine
but not a lawyer and this is not legal advice
😛
noble thicket
Fair enough
swift flicker
The right answwr is, that you need to be compliant with their license. If there is none, you have two options, either reach the owner(s) and ask them about the licensing details or simply dont use the code.
Vulkan must be definitely licensed (wiki says Apache, but cant find it on official websites on cell phone). But the situation can be a bit more complicated, as the sdk consists of mutiple modules and these can be licensed differently, but I assume that they are all apache or similar open source friendly licenses or are not included? ButI may be wrong.
swift flicker
I do have some licenses I prefer to conform to rust's licensing open source conv...
You are, as the license tells you, what you cant and what you can do with the resources 🙂
noble thicket
You are, as the license tells you, what you cant and what you can do with the re...
Suppose that I don't use the sdk and instead dynamically link to the shared library directly. Would that change how those licenses affect me?
swift flicker
Still they apply, as the license defines, how you can use the code. Compare it to GPL, even dynamic linking matters and if you link a GPL library dynamically to your code, your code becomes GPL if you distribute the GPL code.
Correct me if I'm wrong, but we have discussed this in work a lot of times and actually GPL triggers, once you distribute the GPL code. So in theory, you can link to it, but if you don't distribute it and let the user download the code himself, you are "safe"? But this is something you don't want to do as you are hiding potential problems etc.
That's where lGPL comes in and allows you to dynamically link an lGPL and not make your code lGPL. So it can be apache, MIT, BSD or even a proprietary license (I guess)
noble thicket
I see. So I need to see what license the binary is under then
smoky junco
That's where lGPL comes in and allows you to dynamically link an lGPL and not ma...
As we are talking about GPL: There are also things released under "GPL with exceptions" such as GCC. Which is somewhere between GPL and LGPL
swift flicker
The binary will most probably be the same license as the headers. The whole package is licensed somehow. I've checked the licenses for Vulkan and as I've expected:
https://vulkan.lunarg.com/license/#/release/record/6020851/linux
For linux there are several licenses used by the SDK which relate to different components part of the SDK
smoky junco
From what I understand: you can use the vulkan.dll without any effect on your code. If you ship the vulkan DLL with your app (e.g. macos/moltenvk) you will need to check the license but afaik you would be fine as long as you attribute it correctly.
swift flicker
And there are also all the copyright holders, which is a nightmare in my opinion. 🙂
noble thicket
It's a good thing I don't intend to ship the binary then.
swift flicker
This is what the Vulkan SDK license says:
Copyright 2016-2023 LunarG Inc.
The Vulkan SDK is comprised of 100% open-source components. The majority of the materials are MIT or Apache 2.0 licenses. The Vulkan SDK licensing registry (found at vulkan.lunarg.com) discloses all components in the SDK and their corresponding open source license. The SDK itself is not licensed because to do so would re-attribute licenses to all the things included in the SDK.
ALL INFORMATION HERE IS PROVIDED "AS IS." LUNARG MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, WITH REGARD TO THIS LIST OR ITS ACCURACY OR COMPLETENESS, OR WITH RESPECT TO ANY RESULTS TO BE OBTAINED FROM USE OR DISTRIBUTION OF THE LIST. BY USING OR DISTRIBUTING THIS LIST, YOU AGREE THAT IN NO EVENT SHALL LUNARG BE HELD LIABLE FOR ANY DAMAGES WHATSOEVER RESULTING FROM ANY USE OR DISTRIBUTION OF THIS LIST, INCLUDING, WITHOUT LIMITATION, ANY SPECIAL, CONSEQUENTIAL, INCIDENTAL OR OTHER DIRECT OR INDIRECT DAMAGES.
swift flicker
The Vulkan SDK licensing registry (found at vulkan.lunarg.com) discloses all components in the SDK and their corresponding open source license. This is important. This should tell you, how the components are licensed
README
The Vulkan SDK is comprised of 100% open source components. The majority of the materials are MIT or Apache 2.0 licenses. This Vulkan SDK license registry discloses all components in the SDK and their corresponding open source license and copyrights.
Using some software engineering techniques, the licenses for binaries are determined by:
Identify all source used to build the binary
Parse the license for each source to determine the collection of licenses contributing to the binary
Other files (that didn't contribute to the binary) are parsed for licenses as well. If the file does not contain a license within the source, they are assigned the license as defined at the parent level of their corresponding github repository.
For those who need to see all the detail on licenses and copyrights for elements in the SDK, a CSV and a TXT file are provided for download.
noble thicket
Yep. I've decided I'd rather not get involved in this mess afterall....
swift flicker
So what are you going to do? 🙂
If you check the csv file, there you can nicely see all the libraries and their license. The vulkan-1.lib is licensed as: "Apache 2.0, Khronos, MIT". So if you link against it, you should be familiar with those licenses and that's all. The Apache and MIT are friendly and Khronos will be the same I guess. 🙂
From the list I see, that lGPL is used only for the tools.
swift flicker
One more remark to the license file. There are resources, which have multiple licenses attached. Not sure how this is meant, but my assumption is, that the point was to tell, which licenses are involved in that particular resource? But from a users perspective this is “irrelevant”, these can be considered as “input” licenses, however, you are interested in outgoing license.
If all the licenses there were outgoing license, it would mean you could select one of them. But as said, I dont think this was the intention
solar mantle
I'm confused. If you don't ship the shared library (DLL or whatever) and just call functions from that, it wouldn't be affected by the license since you are not distributing the source or binaries
I recall going through this with OGRE back when it was GPL, and it was okay to make applications that were dynamically linked as all the code used was your own
and MIT/Apache are pretty permissive, I don't see why there would be a legal issue, but I'm not a lawyer
swift flicker
I fully agree with you, but is this something you really want? You are delagating the responsibility from yourself to someone who uses it.
In my opinion its very damgerous, because you are saying, that your code is permissive, which is partially true. Someone could pack the GPL libraries with good intentions (why not, the code is “MIT”, right?) but suddenly he is screwed. I wouldnt recommend it, although its possible
smoky junco
GPL is 'infectious'. Staticly linking with it makes the final product GPL. Dynamic linking is complicated, it depends if it's a 'derived work' or not. (Unless there's a linking exception. For example libgcc has an exception so you can staticly link to it without requiring every program compiled with GCC to be GPL)
solar mantle
correct, it could be considered a derived work, I forgot about that
noble thicket
I made a rust crate with the whole idea of dynamically linking with vulkan's drivers (.dll/.so), was the original reason I brought up this topic.
https://crates.io/crates/dylink
The problem is that it would still take time to write the structures despite dynamic linking the functions being trivial, which is why I was considering whether it would be worth it or not.
noble thicket
If you check the csv file, there you can nicely see all the libraries and their ...
using the .lib and statically linking isn't good practice anymore anyway.
There's really no point in shipping the code with the drivers since vulkan's driver manufacturers actually install vulkan sanely unlike direct3d from my understanding
noble thicket
I downloaded the runtime components and they seem to be dual licensed under Apache 2.0 and MIT