[svsm-devel] SVSM Development Call January 8th, 2025

[James Bottomley]

On Tue, 2025-01-07 at 08:26 -0800, Dionna Amalie Glaze wrote:
> On Tue, Jan 7, 2025 at 7:55 AM Jörg Rödel <joro at 8bytes.org> wrote:
> > 
> > Hi,
> > 
> > Happy new year everyone!
> > 
> > Here is the usual call for agenda items for the first SVSM
> > development
> > call in 2025.  Please send me any agenda items you have in mind or
> > raise
> > them in the meeting.
> > 
> > I have one item on the agenda so far:
> > 
> >         * IGVM support for QEMU.
> 
> Regarding this, I'd like to make sure we cover the topic of MSFT
> donating the IGVM spec and implementation to the CCC for appropriate
> open governance.

The spec isn't really separated from the code: it's all one thing.  I
think in principle this document along side code is a good thing and we
want to keep it that way, so you're in effect asking to move this
entire repo:

https://github.com/microsoft/igvm

The IGVM format is designed to be useful beyond simply confidential
computing for multiple different virtual machine images, so even if we
were to move it, I'm not sure the CCC would be the best place to
guarantee that universality.

>  We're institutionally blocked without a significant approval chain
> to provide code to competitor companies.

This sounds a bit like an internal Google problem; I may be able to
help you with this, but I think it's been a while since I engaged
Google legal on open source.  However, the main argument for you to
deploy is that for open source the whole point is to collaborate with
your competitors in the open and you should be empowered to do that.

>  Keeping the tools Coconut-SVSM and Qemu uses under Microsoft is an
> inversion of power, even with the MIT license.

You mean simply by hosting it under our external github account?  It's
where we incubate all our open source projects that accept outside
contributions (and where we hope to openly demonstrate stewardship
worthy of community trust) and I believe Google does something similar.
All corporations tread this fine line: if the project accretes a
vibrant community, we'd likely be happy to move it elsewhere, but we
equally don't want to be accused of simply throwing code over the wall,
which is why we incubate projects to see how they progress.

Regards,

James