On Mon, Feb 21, 2022 at 11:53 AM Wim de With wrote:
>
> > Since the intent of libvirt using LGPL was explicitly to allow non-GPL
> > compatible applications to use libvirt, it is a mistake to be using
> > a license that breaks this ability for Rust.
> >
> > In Golang we've used MIT license
> >
>
On Mon, Feb 21, 2022 at 05:28:24PM +0100, Wim de With wrote:
> On Mon, Feb 21, 2022 at 10:21:32AM -0500, Andrea Bolognani wrote:
> > We are aware of the issues with the current API of libvirt-rs, but
> > unfortunately nobody has been able to dedicate time to addressing
> > them. Any contributions
On Mon, Feb 21, 2022 at 10:21:32AM -0500, Andrea Bolognani wrote:
> On Fri, Feb 18, 2022 at 10:28:29AM +0100, Wim de With wrote:
> > Hello,
> >
> > I was reading the Rust bindings for libvirt and I noticed that they are
> > not very idiomatic. A couple of examples:
> >
> > 1. It is conventional to
On Mon, Feb 21, 2022 at 04:30:28PM +0100, Ján Tomko wrote:
> On a Monday in 2022, Andrea Bolognani wrote:
> > On Fri, Feb 18, 2022 at 10:28:29AM +0100, Wim de With wrote:
> > Licensing is a pretty fun minefield :)
> >
> > For example, even though libvirt-rs itself would be statically linked
> >
On a Monday in 2022, Andrea Bolognani wrote:
On Fri, Feb 18, 2022 at 10:28:29AM +0100, Wim de With wrote:
Licensing is a pretty fun minefield :)
For example, even though libvirt-rs itself would be statically linked
into any application that uses it, by virtue of it being a wrapper
around the C
On Fri, Feb 18, 2022 at 10:28:29AM +0100, Wim de With wrote:
> Hello,
>
> I was reading the Rust bindings for libvirt and I noticed that they are
> not very idiomatic. A couple of examples:
>
> 1. It is conventional to have a *-sys crate containing only the C
> interface and the linking
