When I say we can't "redistribute", I mean we can't include any part of the R3D
SDK in the OIIO repository. Nothing they get *from us* (downloading the OIIO
project) can be code or binaries taken from the SDK.
It's fine if the build system, in the process of "installing" the build to the
right directories all within the studio site that is building OIIO, copies
files from one directory to another. If the studio has the SDK on hand to begin
with, they obviously have taken full responsibility for adhering to its
licensing terms.
That language about "non-shared directory" is yet another artifact of how the
license was from a time that the SDK was available under NDA only. I hope they
will rewrite it to clarify, but in my communication with them they have
indicated that all these very draconian interpretations of the license terms
are not what they currently intend or how they interpret it in the world where
it's all freely downloadable from their public web site.
-- lg
> On Jul 26, 2019, at 3:17 PM, Will Rosecrans <[email protected]> wrote:
>
> I definitely can't speak for Larry. That said... I think that trying to set
> the path for the runtime libs from the compile_definitions approach isn't
> great outside of the little sample. It can only work when the binary is run
> on the system where it was built. If making something real that will be
> shipped to another box, the ${RED_RUNTIME_LIBRARIES} will have to be stuffed
> into CMake's installs stuff, so that it can get packaged. I think the
> runtime libs need to match the static library that you link to at build time,
> and I wouldn't expect good results if the end-user had an older/newer R3DSDK
> installed on their machine to try and load from at run time.
>
> As far as I can tell, it actually is fine to redistribute the runtime
> libraries. You just can't redistribute stuff outside that "Redistributable/"
> directory (like the .a static lib, the headers, the documentation, etc.).
> (I'm Not a lawyer, never played one on TV, don't take legal advice from a
> rando on the Internet, etc.) For example, I don't need to download the SDK
> to run a copy of Resolve or Nuke that was built with R3D support. I can just
> install Resolve or Nuke, and they supply the Redistributable libs along with
> their application. It seems analogous to how you can't generally ship MS
> compilers and libs with your app on Windows, but you can ship the MSVCRT DLL
> that is needed at runtime.
>
> The SDK license calls out having a permission to distribute the
> redistributable:
>
> > "... distribute Redistributable Software in original form only, that is
> > installed only in a private (non-shared) directory location that is used
> > only by Your Developer Programs..."
>
> So I think even if libOpenImageIO.so were installed in a shared location like
> /usr/lib, the red libs would have to be in something like
> /usr/lib/OpenImageIO/redstuff.so, so that other apps that use R3D but not the
> system OIIO install wouldn't accidentally pick up runtime libs from a
> different SDK version. The fact that they care where you install it is
> clearly only something that would come up if they do expect you to install it
> in the first place. You can't include any R3D SDK headers in the
> redistributable, so the public header for an OIIO R3D plugin couldn't include
> it or use any types from it, but the implementation .cpp file can depend on
> it, and no apps using OIIO would ever need to see or have the private
> headers. You wouldn't use R3DSDK::Clip in a public header, but rather some
> PIMPL style OIIO::AlexClip which has a mysterious void* field that the
> implementation can cast as a pointer to a Clip. Something like that. It's a
> bit more grody than using an open source library, but I think it's possible
> to do it without too much trouble while staying in the boundaries.
>
> Or just make the R3D plugin a hard opt-in, and only let users use it if they
> have the SDK installed and not worry that it isn't very flexible. Might be
> easiest to start like that, and sort out the technical details, then come
> back later to sort out how best to deal with deployment stuff to make it more
> convenient. But I don't think it's necessary. Maybe after SIGGRAPH season,
> Larry can get an opinion from one of his contacts at R3D. Obviously, their
> opinion would carry a heck of a lot more weight than mine if they think I am
> misunderstanding any of this. :)
>
>
>
> And yeah, if the CMake I started is useful for you, go nuts and throw it in
> whatever you want. It wasn't doing anybody any good just sitting on my hard
> drive. That repo has a BSD license file, but if some other license is more
> convenient for somebody, I can add it.
>
>
> On Fri, Jul 26, 2019 at 1:06 PM Alex Hughes <[email protected]
> <mailto:[email protected]>> wrote:
> That `target_compile_definitions`
> Is a clever way of doing the runtime linking that R3D requires.
>
> Question for LG though...
> Do we want to provide the R3DSDK redistibutables with OIIO, in which case I
> would set the R3DSDK initializer to look relative to itself.
> Another option could be environment variable based so at runtime when the
> R3DSDK needs the path to the libraries, it could pull from the environment.
> The way will was doing it in his demo was using the preprocessor directives
> to define the redist path. Which I think may cause problems because I doubt
> people are compiling against the live libraries in their environment.
> Also, the "add_oiio_plugin" macro doesn't seem to set the passed
> "DEFINITIONS" in a way that would allow the compilation of the plugin to have
> the preprocessor directives applied.
> I played around with modifying the "libOpenImageIO" CMakeLists file and
> added a "target_compile_definitions" call with my required definitions but
> having plugin specific logic in the core lib CMakeLists file doesn't seem
> like the right way to approach this.
>
> So I guess, to simplify the above, the R3DSDK requires runtime linking of the
> sdk and requires a path in there. I am inclined to try to read an environment
> variable and fallback to looking in the same directory for the libraries.
> Does that seem like a good way to do it?
>
> I've got a working R3DInput plugin working I think and am just getting the
> test cases up. But I hopefully will have a PR open soon.
>
> -Alex
>
>
>
> On Fri, Jul 26, 2019 at 5:15 PM Alex Hughes <[email protected]
> <mailto:[email protected]>> wrote:
> Thanks Will,
>
> I would love to include that in my PR if that's ok with you, with credit of
> course.
>
> -Alex
>
> On Fri, Jul 26, 2019 at 8:18 AM Will Rosecrans <[email protected]
> <mailto:[email protected]>> wrote:
> I recently started making a CMake find module for the R3D SDK. It's uhhh...
> not quite production ready, (I think it won't work on a Mac yet, and I
> haven't tested it on Windows) but it might be a handy starting point. Feel
> free to use it or crib from it, etc. It has a trivial example that makes an
> OIIO image buf.
>
> https://github.com/wrosecrans/ImageTypes
> <https://github.com/wrosecrans/ImageTypes>
>
>
>
> On Thu, Jul 25, 2019 at 1:38 PM Alex Hughes <[email protected]
> <mailto:[email protected]>> wrote:
> I could take a look at it since I brought it up.
>
> I've never taken a stab at an OIIO plugin but there are lots of examples and
> the docs seem reasonable.
> I would be tackling it on my own time without company support at this point
> because we don't have an immediate need for it here.
>
> Is the FFMpeg plugin a decent example to base work off of? At least for the
> ImageInput?
>
> -Alex
> _______________________________________________
> Oiio-dev mailing list
> [email protected] <mailto:[email protected]>
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
> _______________________________________________
> Oiio-dev mailing list
> [email protected] <mailto:[email protected]>
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
> _______________________________________________
> Oiio-dev mailing list
> [email protected] <mailto:[email protected]>
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
