[prev in list] [next in list] [prev in thread] [next in thread]
List: libvir-list
Subject: Re: Libvirt Rust bindings could use some work
From: Neal Gompa <ngompa13 () gmail ! com>
Date: 2022-02-28 12:08:22
Message-ID: CAEg-Je_qEr_8gDo3EzGS_LGZOKMLUtVHy2Dj1g3GKc3qsu6W7A () mail ! gmail ! com
[Download RAW message or body]
On Mon, Feb 21, 2022 at 11:53 AM Wim de With <wf@dewith.io> 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
> >
> > For Rust we should aim for whatever is most appropriate - MIT or BSD
> > or Apache - I'm not familiar with which is dominant in the Rust world.
>
> Apache and MIT or even dual licensing of both are the most common.
> The official API guidelines recommend dual licensing under Apache and
> MIT.
>
I would prefer we didn't repeat that dumb advice in libvirt-rs. Just
go with Apache-2.0 if we want a permissively licensed crate. I would
suggest MPL-2.0 for libvirt-rs, though. That allows proprietary
linking but maintains that each file that makes up the crate *must*
remain FOSS, and is compatible with GNU licenses. It's static-link
compatible copyleft, basically.
--
真実はいつも一つ!/ Always, there's only one truth!
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic