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.