Hi, I am faced with a dilemma. A bunch of users are asking me to activate the OptiX renderer for Blender. Unlike CUDA, OptiX requires some non-free include files during build[1]. The idea is to fetch the headers, that are provided by NVidia with wget in order to avoid packaging them up in the source rpm. I understand, that this is a problem, but is there any chance to get this going. E.g. using the download service, but not packaging it later on. If I look at builds like gradle or rancher-desktop, they all end up fetching huge amounts of binaries from some web resources. Here; we're talking about a few header files, that we just should avoid to redistribute. Here's my current state of affairs[2]. Cheers, Pete -- Life without chameleons is possible, but pointless. [1] https://devtalk.blender.org/t/blender-2-8-cycles-optix-packaging/12533/14 [2] https://build.opensuse.org/package/show/home:frispete:blender/blender-310
Am 16.03.22 um 22:47 schrieb Hans-Peter Jansen:
Unlike CUDA, OptiX requires some non-free include files during build[1]. The idea is to fetch the headers, that are provided by NVidia with wget in order to avoid packaging them up in the source rpm.
I was under the impression that OBS builds don't have network access, but maybe that changed?
I understand, that this is a problem, but is there any chance to get this going. E.g. using the download service, but not packaging it later on.
IANAL, but I don't think so. Including the headers makes blender a derivative work, and the US Supreme Court couldn't muster the courage to declare APIs as non-copyrightable. [1,2] (Here in Europe we see things a bit different, but that doesn't count.)
If I look at builds like gradle or rancher-desktop, they all end up fetching huge amounts of binaries from some web resources.
I don't see the gradle build fetching anything, maybe you could point me to the relevant lines? Rancher Desktop seems not to be in Factory (unless I've missed it) and so it can do what it wants. Your best chances are probably to get this into some add-on repository like Packman. Or perhaps it's Ok for non-oss, but I'm not sure what the rules are for this. But we likely still want an OptiX-free blender in Factory as oss. Best regards, Aaron [1] <https://www.supremecourt.gov/opinions/20pdf/18-956_new_o7jp.pdf> [2] <https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc.#Decision>
On Donnerstag, 17. März 2022 10:25:20 CET Jan Engelhardt wrote:
On Thursday 2022-03-17 01:29, Aaron Puchert wrote:
IANAL, but I don't think so. Including the headers makes blender a derivative work, and the US Supreme Court couldn't muster the courage to declare APIs as non-copyrightable.
Libraries can be used to a degree without headers.
How do you call a function when you do not know the parameters and its return codes? Using a library without "its" headers only works when the library implements a public, well known interface, where you can replace the headers with compatible ones or create the headers yourself from a public specification. The NVidia OptiX headers are completely proprietary, all documentation comes with the same unfriendly license. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
On Thursday 2022-03-17 16:04, Stefan Brüns wrote:
On Donnerstag, 17. März 2022 10:25:20 CET Jan Engelhardt wrote:
On Thursday 2022-03-17 01:29, Aaron Puchert wrote:
IANAL, but I don't think so. Including the headers makes blender a derivative work, and the US Supreme Court couldn't muster the courage to declare APIs as non-copyrightable.
Libraries can be used to a degree without headers.
How do you call a function when you do not know the parameters and its return codes? Using a library without "its" headers only works when the library implements a public, well known interface
You need to have "some idea" of how the library behaves to make sensible use of it, that much is obvious. And the knowledge can be gained (with sufficient time investment) from just the library. People have reverse engineered much more complicated code than shared libraries (which have a fair block of self-description owing to the shared nature).
participants (4)
-
Aaron Puchert -
Hans-Peter Jansen -
Jan Engelhardt -
Stefan Brüns