[Rust-VMM] Licensing Issue in rust-vmm crates

Gerry liuj97 at gmail.com
Tue Jul 5 13:39:08 UTC 2022


I’m OK with changing the license, otherwise qemu can’t make use of the rust-vmm components.

> 2022年7月5日 下午9:37,Andreea Florescu <andreea.florescu15 at gmail.com <mailto:andreea.florescu15 at gmail.com>> 写道:
> 
> Gerry, Rob, Sebastien, what do you think about this?
> I would like to go ahead with the license change to Apache 2.0 OR BSD-3-Clause and it would be great to also get an ACK from you.
> 
> Thanks,
> Andreea
> 
> On Thu, Jun 30, 2022 at 10:01 AM Andreea Florescu <andreea.florescu15 at gmail.com <mailto:andreea.florescu15 at gmail.com>> wrote:
> I just wanted to clarify something as well, I do not feel strongly about changing the license to BSD-3-Clause, we can also use Apache 2.0 OR BSD-3-Clause if that makes sense. My interest is to fix the problem initially reported which significantly limits the usefulness of this project as it cannot be used by projects like QEMU.
> As most contributions are coming from Google (indirectly), Amazon, Intel and Alibaba, it would be really helpful to also get input on updating the license from the folks that are contributing from the respective companies. From the Amazon side of things, we discussed this internally and we're onboard with the change.
> 
> Thanks,
> Andreea
> 
> On Thu, Jun 23, 2022 at 1:48 AM Jeremy Stanley <fungi at yuggoth.org <mailto:fungi at yuggoth.org>> wrote:
> On 2022-06-22 17:30:37 +0100 (+0100), Alberto Faria wrote:
> [...]
> > I may be misunderstanding this, but it sounds like you're assuming
> > that Apache-2.0 is a superset of BSD-3-clause in terms of user
> > obligations. I have no idea if this is actually the case or not, but
> > if it is, then "Apache-2.0 OR BSD-3-clause" == "BSD-3-clause", which
> > in a sense contradicts the wide use of the former in Rust crates.
> [...]
> 
> I'm not a lawyer, but my long-time understanding has been that when
> you distribute software under "license x or license y" that allows
> people who are receiving and possibly redistributing and deriving
> that software to do so based on their choice of either license.
> Blanket statements like this are rarely helpful however when the
> software consists of parts under different licenses, such as
> shipping some files under BSD-3-clause and other files under
> Apache-2.0 as part of the same project. Under those circumstances,
> the sum total of the software is effectively held to the union of
> the requirements for both licenses, but for permissive-style
> licenses like these it's also not expected that the licenses of some
> files impact the licenses of the other files, so long as the chosen
> licenses have compatible terms (permissive-style licenses do not
> require you to distribute derivative works under the same terms).
> 
> The situation changes dramatically when copyleft-style licenses are
> involved, since they often (as is the case with GPL for example)
> convey transitive requirements which forbid additional licensing
> requirements on the complete work and require redistribution under
> the same license instead.
> 
> As for whether Apache-2.0 is a superset of BSD-3-clause, that's
> implied by its ancestry, since the original Apache license was
> effectively a direct copy of BSD-4-clause, and then for Apache-1.1
> the authors dropped the advertising clause that Berkeley had also
> dropped, making it then equivalent to BSD-3-clause. Apache-2.0 is a
> superset of the requirements of Apache-1.1 (and so BSD-3-clause) as
> it merely adds a grant of patent license to the original terms.
> -- 
> Jeremy Stanley
> _______________________________________________
> Rust-vmm mailing list
> Rust-vmm at lists.opendev.org <mailto:Rust-vmm at lists.opendev.org>
> http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm <http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20220705/95d6be7f/attachment.htm>


More information about the Rust-vmm mailing list