Re: Central repo for VirtIO conformance tests?

Hello Michael, thanks for the reply,

On Mon, May 19, 2025 at 10:54=E2=80=AFAM Michael S. Tsirkin <[email protected]=
> wrote:
>
> On Mon, May 19, 2025 at 10:43:33AM +0300, Manos Pitsidianakis wrote:
> > Pinging this thread to ask the OASIS people: Would it be possible to
> > host a software project (this testsuite) under OASIS but with a
> > lighter contribution process? We expect everyone to be contributing to
> > them, from open source/proprietary hypervisor developers, to kernel/OS
> > developers, hobbyists and professionals alike. So I think a low
> > barrier of entry would be reasonable here.
>
> Take a look here pls:
> https://www.oasis-open.org/open-repositories/#licensingRules
>
>
>
> > Seeing as a test suite is essentially tied to the published VIRTIO
> > spec itself it also makes it a good fit semantically. Having a suite
> > with multiple VIRTIO implementations including slim images with Linux
> > would also give a wider frame of reference for downstream consumers of
> > the spec. Currently, the Linux kernel is the de facto (because it's
> > also open source) VIRTIO implementation on the frontend side and
> > oftentimes we end up looking at what Linux does to implement backends.
> >
> > We'd like to potentially:
> >
> > - Expand the array of rootfs images with more Linux userspace tests
> > for more devices
> > - Expand the array of rootfs images with other open source OSes as
> > they gain VIRTIO functionalities
> > - Implement missing VIRTIO spec features in our unikernel test and
> > also exercise realistic but basic VIRTIO command use scenarios for
> > more devices
> > - (This is on my personal wishlist) write a VIRTIO fuzzer framework,
> > similar in spirit to Google's syzkaller project (unsupervised
> > coverage-guided kernel fuzzer)
> > - As a stretch goal, provide a reference test runner framework to run
> > the images with QEMU and rust-vmm vhost-user backends for people to
> > adapt to their setups.
> >
> > PS: The git repositories Alex linked are temporarily inaccessible due
> > to internal unrelated issues, and will be public again.
>
>
> At the moment, from the above link, and if you want it tied to OASIS
> open repositories, it has to be one of:
>
> BSD-3-Clause License (which shall apply if the TC makes no license select=
ion in its approval action); Apache License v 2.0; CC-BY 2.0; CC-BY 4.0; Ec=
lipse Public License v 1.0.

OK that's doable and completely reasonable.

> I am not a lawyer, but can full OS images we licensed under one of
> these? If not, you are better off creating the repository itself outside
> the confines of OASIS.

We'd be hosting essentially build recipes for the images, for tests
where we use other people's code. The build recipes would have the
same license.

If I understand the CLA requirement correctly, even if the
contribution is merged by a maintainer who has signed the CLA, the
original contributor who has no write access to the repository, has to
sign the CLA as well?

> You can still use e.g. virtio-dev mailing list for communication.
>
> > --
> > Manos Pitsidianakis
> > Emulation and Virtualization Engineer at Linaro Ltd
>