[libvirt] [PATCH 1/1] [RFC] Parallels Server Bare Metal driver stub

[Dmitry Mishin]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20110928/df08fcd1/attachment-0001.htm>