|
OK, I got it. Will think how to resolve this. On Wednesday, September 28, 2011 06:10:19 PM Daniel P. Berrange wrote: > On Wed, Sep 28, 2011 at 06:01:24PM +0400, Dmitry Mishin wrote: > > On Wednesday, September 28, 2011 05:34:47 PM Daniel Veillard wrote: > > [...] > > > > > > +int psbmApiInit(struct psbm_driver *driver) > > > > +{ > > > > + const char *libname = "libprl_sdk.so"; > > > > + void *handle = NULL; > > > > + PRL_RESULT res; > > > > > > > That I dislike, sorry this must not be dlopen'ed in at runtime, > > > > > > but checked in at configure time and properly linked in. Also > > > means that proper dependancies and packaging have to be in place. > > > > I exactly want to avoid dependencies. > > > > Library can be used both remotely (for example, on Fedora host) and > > locally (on PSBM host). And if in the local case we can create special > > libvirt rpm with enabled PSBM support and integrate it to distribution, > > in remote case we force user to download not only Parallels SDK rpm > > (which will hardly be included to Fedora due to proprietary license), > > but also fixed libvirt package instead of already installed one. Is it > > preferable way from your point of view? > > > > > > + handle = dlopen(libname, RTLD_LAZY); > > > > + if (!handle) { > > > > + psbmError(VIR_ERR_INTERNAL_ERROR, > > > > + _("Failed to load SDK library %s %s"), libname, > > > > dlerror()); + return VIR_ERR_INTERNAL_ERROR; > > > > + } > > > > > > > So what is that SDK library, how is it distributed and what is the > > > > > > licencing for it ? As much as I like adding a driver, I would like to > > > make sure the deployement is clean and there is no licencing issues. > > > > > > Any pointers ? All I found was > > > http://www.parallels.com/ptn/download/sdk/ > > > > > > and it's quite silent on code availability and Licence for the > > > libraries. > > > > It has a proprietary license and not open sourced now. Is it a problem? > > If the license is not LGPLv2+ compatible, then it can't be used > by libvirt, regardless of whether it is directly linked, or > dlopened. In other words using 'dlopen' doesn't magically solve > the license compatibility problem. > > Daniel -- Thanks, Dmitry. |
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list