Open albertofaria opened 2 years ago
Hey, thanks @albertofaria for reporting this. The license should be with OR
specifically for the reason you're mentioning, and that's why we added BSD-3-Clause in the first place.
I am not sure though if there are any problems with just re-license it, or whether we need to go through some kind of process. Are there any implications from a legal side? I am totally supportive or relicensing it, as I think it was just a mistake, @sameo @sboeuf @bonzini @jiangliu what do you think?
Hi, I missed the change in #46. Let's go to the source:
AND
usually means some files are under one license and some files are under another. Full distribution needs to satisfy all the requirements (which means that either they must not conflict, or you have to invoke special clauses like GPL's "mere aggregation" concept).
OR
means dual licensing, and I agree with @andreeaflorescu that the intent was dual licensing and especially compatibility with both crosvm and Firecracker.
I'm not sure what the legal requirements for relicensing are, but obtaining consent from all authors is probably necessary.
It seems some source files are licensed under "Apache-2.0 AND BSD-3-Clause", others under "Apache-2.0", and yet others under "BSD-3-Clause". Here is a list of files per license:
Apache-2.0 AND BSD-3-Clause
src/errno.rs
src/fam.rs
src/linux/eventfd.rs
src/linux/fallocate.rs
src/linux/ioctl.rs
src/linux/poll.rs
src/linux/seek_hole.rs
src/linux/signal.rs
src/linux/timerfd.rs
src/linux/write_zeroes.rs
src/unix/file_traits.rs
src/unix/tempdir.rs
src/unix/terminal.rs
Apache-2.0
src/linux/aio.rs
src/linux/epoll.rs
src/rand.rs
src/syscall.rs
BSD-3-Clause
src/linux/sock_ctrl_msg.rs
src/tempfile.rs
AFAIK, author consent would be necessary in all these cases for switching to "Apache-2.0 OR BSD-3-Clause".
git shortlog -es -- src/
lists the following people as authors of commits that have touched src/
:
Adrian Catangiu <acatan@amazon.com>
Alexandra Iordache <aghecen@amazon.com>
Allison Randal <allison@lohutok.net>
Alyssa Ross <hi@alyssa.is>
Andreea Florescu <fandree@amazon.com>
Connor Kuehl <ckuehl@redhat.com>
Harald Hoyer <harald@redhat.com>
Iulian Barbu <iul@amazon.com>
Iulian-Marian BARBU (78306) <iulian_marian.barbu@stud.acs.upb.ro>
Jacob Hughes <j@jacobhughes.me>
Jing Liu <jing2.liu@linux.intel.com>
Joey Sacchini <joey@sacchini.net>
Kshitij Jain <jkshtj@amazon.com>
Laura Loghin <lauralg@amazon.com>
Liu Jiang <gerry@linux.alibaba.com>
Matt Forrester <github.com@speechmarks.com>
Paolo Bonzini <pbonzini@redhat.com>
Rob Bradford <robert.bradford@intel.com>
Samuel Ortiz <sameo@linux.intel.com>
Serban Iorga <seriorga@amazon.com>
Sergii Glushchenko <gsserge@amazon.com>
karthik nedunchezhiyan <karthik1705.n@gmail.com>
mrxinwang <Henry.Wang@arm.com>
u5surf <u5.horie@gmail.com>
(Using git-blame to consider only currently existing lines leads to the same result: git ls-files -- src/ | xargs -n1 git blame --porcelain -- | grep author-mail | cut -d' ' -f2 | sort | uniq
)
This is 23 people to contact (there are two address for Iulian Barbu). @andreeaflorescu @bonzini @jiangliu @sameo @sboeuf, any thoughts on how practicable this would be? Perhaps code for which consent cannot be obtained could be rewritten/replaced in some way?
On further thought, for files that list corporations as copyright holders, it may be sufficient to get consent from just one person from each company, and from each of the "independent" contributors (although, obviously, I am not a lawyer).
Here is a list of files per copyright holder, in case this turns out to be true:
Alibaba Cloud Computing
src/linux/aio.rs
Amazon.com, Inc. or its affiliates
src/errno.rs
src/fam.rs
src/linux/epoll.rs
src/linux/ioctl.rs
src/linux/signal.rs
src/linux/write_zeroes.rs
src/metric.rs
src/rand.rs
src/syscall.rs
src/unix/terminal.rs
Intel Corporation
src/errno.rs
src/lib.rs
src/linux/eventfd.rs
src/linux/fallocate.rs
src/linux/ioctl.rs
src/linux/poll.rs
src/linux/seek_hole.rs
src/linux/signal.rs
src/linux/timerfd.rs
src/linux/write_zeroes.rs
src/unix/file_traits.rs
src/unix/tempdir.rs
src/unix/terminal.rs
The Chromium OS Authors
src/errno.rs
src/fam.rs
src/linux/eventfd.rs
src/linux/fallocate.rs
src/linux/ioctl.rs
src/linux/poll.rs
src/linux/seek_hole.rs
src/linux/signal.rs
src/linux/sock_ctrl_msg.rs
src/linux/timerfd.rs
src/linux/write_zeroes.rs
src/tempfile.rs
src/unix/file_traits.rs
src/unix/tempdir.rs
src/unix/terminal.rs
The LICENSE-BSD-3-Clause
file also identifies "The Chromium OS Authors" as copyright holders.
Regarding contacting authors to ask for consent, could rust-vmm@lists.opendev.org be CC'd so the community can follow it?
Also, not being a maintainer, I feel it wouldn't be appropriate for me to take the initiative in contacting these authors, but if I can help in any way, please let me know.
@albertofaria thanks a lot for all the effort you've put into this. This is definitely going to help us solving this problem much faster.
On further thought, for files that list corporations as copyright holders, it may be sufficient to get consent from just one person from each company, and from each of the "independent" contributors (although, obviously, I am not a lawyer).
I think it is better indeed to get agreement from one person from the company because otherwise it is going to be very time consuming. From my team we have no problem with changing the license because we all contributed with the idea that the license is with OR
as we discussed during the first rust-vmm meet-up that we had.
Regarding contacting authors to ask for consent, could rust-vmm@lists.opendev.org be CC'd so the community can follow it?
Also, not being a maintainer, I feel it wouldn't be appropriate for me to take the initiative in contacting these authors, but if I can help in any way, please let me know.
I can handle the communication, I'll try to get this done this week.
One question that I have is whether we can have an Apache 2.0 OR BSD-3-clause license when the code that comes from Crosvm is actually BSD-3-Clause only? Does this imply that the whole crate needs to be BSD-3-Clause instead?
@albertofaria : Relicensing of copyrighted work, e.g. OSS, requires the consent from all copyright holders that are involved in the parts that need to be relicensed. The question here is whether all authors are also copyright holders. For coding that is done as part of your work in a company, the copyright normally goes right to the company; the author does not have any rights (with some minor exceptions). So you need to get the consent from a company's representative you is entitled to decide over this matter.
@andreeaflorescu If the original work has been licensed under BSD-3-Clause, you can decide to license modifications thereof under different licenses (including dual-licensing) as long as the license obligations of the orginal license (here BSD-3-Clause) does not cause any conflicts with the new license. For permissive licenses, this is normally not the case.
I think the correct aggregate license for the project is currently BSD-3-Clause AND Apache 2.0.
There are substantial sections copied from crosvm under the BSD-3-Clause. Any substantial changes that we (Intel) would have made would be covered by Apache 2.0.
I can enquire about relicensing those changes under the BSD-3-Clause if the project decides to move to BSD-3-Clause exclusively. I don't see how you can move to BSD-3-Clause OR Apache-2.0 without consent from all parties and in particular "The Chromium OS Authors"
So I think your options are:
I remember there were some offline discussions about licensing in the early stage of rust-vmm project, anyone could recall the detail?
For code contributed by Alibaba, I agree to relicense under "BSD 3 Clause or Apache 2.0".
I am not a lawyer, but essentially getting the copyright holders of the BSD-licensed contributions to make the code optionally available (or even exclusively available) under the Apache License 2.0 means they have to agree to grant patent licenses for anything in their contributions which may be covered by patents they may hold. For most companies that's probably not a problem as they tend to maintain a list of licenses they'll allow their employees to contribute under, but yes it's still not an automatic assumption which can be made.
Another substantive difference is that BSD licenses need to be included in the files they cover (usually embedded in code comments), while the Apache license does not need to be included in each file verbatim and can instead simply be referred to from the file. From a technical standpoint this would probably mean adding a copy of the BSD license to every file which is intended to be distributed under "BSD or Apache" rather than a mere statement to that effect.
Also, it would probably not be a bad idea to consult a lawyer versed in free/libre open source copyright licenses, if there are any concerns that the project contributors may open themselves up to risk in the course of making this change.
I think the correct aggregate license for the project is currently BSD-3-Clause AND Apache 2.0.
There are substantial sections copied from crosvm under the BSD-3-Clause. Any substantial changes that we (Intel) would have made would be covered by Apache 2.0.
I can enquire about relicensing those changes under the BSD-3-Clause if the project decides to move to BSD-3-Clause exclusively. I don't see how you can move to BSD-3-Clause OR Apache-2.0 without consent from all parties and in particular "The Chromium OS Authors"
This is my understanding as well, which is why I was proposing a BSD-3-Clause only license. This shouldn't have a significant impact on product consuming the crates because this is a permissive license and we're already using BSD-3-Clause in the consuming project that I know of.
So I think your options are:
0. Accept the licence is BSD-3-Clause AND Apache-2.0
This is not an option without loosing a significant portion of the community. I think this should be the last resort in case nothing else is possible and we don't reach an agreement.
1. Pursue a relicense to BSD-3-Clause exclusively
This is my preferred option because it looks like it's the most hassle free. I am saying that because the Crosvm code is licensed with BSD-3-Clause and there no changes required from their side.
2. Pursue a relicense to BSD-3-Clause OR Apache 2.0
I think this requires changes in Crosvm, otherwise this also looks like a good option to me.
3. Reimplement the code that is exclusively licensed and place it under the appropriate dual licence.
Does anyone have time for persuing this? This is not only the case for vmm-sys-util. There are other crates that suffer from the same problem.
1. Pursue a relicense to BSD-3-Clause exclusively
This is my preferred option because it looks like it's the most hassle free. I am saying that because the Crosvm code is licensed with BSD-3-Clause and there no changes required from their side.
I think this is the most feasible option and will begin the process to relicense Intel contributions that are not already BSD-3-Clause.
@rbradford just wanted to touch base here. Are you going to open a PR for the license fix in vmm-sys-util, or should someone else take that work?
@rbradford just wanted to touch base here. Are you going to open a PR for the license fix in vmm-sys-util, or should someone else take that work?
I have begun the process to get the appropriate approvals. It may take some time.
@rbradford just wanted to touch base here. Are you going to open a PR for the license fix in vmm-sys-util, or should someone else take that work?
I have begun the process to get the appropriate approvals. It may take some time.
Today I received approval to relicense Intel's past contributions (of non 3rd party code) to BSD-3-Clause on the vmm-sys-util crate and to use BSD-3-Clause for future contributions to this crate. If one of the maintainers would be so kind so as to open a PR I can can approve it.
I've open a PR for updating the license: #167. I'll wait for approvals from all stakeholders before merging it.
vmm-sys-util is currently licensed as "Apache-2.0 AND BSD-3-Clause", as opposed to "Apache-2.0 OR BSD-3-Clause", which appears to be intentional (cf. commit https://github.com/rust-vmm/vmm-sys-util/commit/04c2b8eb3328d15cc068b2f0532e4ad687f7b559).
IIUC, this precludes GPLv2 / GPLv2+ / LGPLv2.1 / LGPLv2.1+ projects from using this crate or any others that depend on it, which seems especially serious since it is a fairly fundamental building block.
Also, it seems there currently exist several crates in the rust-vmm project that depend on vmm-sys-util but are licensed in an (AFAICT) incompatible way. For instance, these dependent crates are "Apache-2.0 OR BSD-3-Clause" (not a comprehensive list):
And these are "Apache-2.0 OR MIT":
Does this warrant any change to how vmm-sys-util is licensed? In particular, would relicensing be a possibility, perhaps as "Apache-2.0 OR BSD-3-Clause"?