Hey Phil, I have contacted our legal department for guidance on this specific use case and will update you when I hear back. Thank you for your patience. Justin Terry > -----Original Message----- > From: Philippe Mathieu-Daudé <philmd@redhat.com> > Sent: Friday, September 20, 2019 8:18 AM > To: qemu-devel@nongnu.org; Justin Terry (VM) <juterry@microsoft.com> > Cc: Daniel P . Berrangé <berrange@redhat.com>; Fam Zheng > <fam@euphon.net>; Thomas Huth <thuth@redhat.com>; Paolo Bonzini > <pbonzini@redhat.com>; Alex Bennée <alex.bennee@linaro.org>; Richard > Henderson <rth@twiddle.net>; Eduardo Habkost <ehabkost@redhat.com>; > Stefan Weil <sw@weilnetz.de> > Subject: Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries > > On 9/20/19 1:33 PM, Philippe Mathieu-Daudé wrote: > > Add a job to cross-build QEMU with WHPX enabled. > > > > Since the WHPX is currently broken, include the patch required to have > > successful Shippable build. > > > > I previously included the WHPX headers shared by the Android project, > > and Daniel asked me to check the EULA. While trying to manually > > install the Windows SDK, I noticed the installer fetches archives > > directly, kindly asking where they are stored via the /fwlink API. > > Do the same, fetch the required archives and extract them. No need to > > accept EULA... > > > > Docker build the image first, then build QEMU in a instance of this > > image. The image is internal to Shippable, the instances are not > > reachable and are thrown once the build is finished. What we collect > > from Shippable is the console output of QEMU build process, and if the > > build process succeed or failed. So far we do not redistribute the > > image or built binaries. > > > > Philippe Mathieu-Daudé (3): > > target/i386: Fix broken build with WHPX enabled > > tests/docker: Add fedora-win10sdk-cross image > > .shippable.yml: Build WHPX enabled binaries > > FWIW here is the result of this series: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapp. > shippable.com%2Fgithub%2Fphilmd%2Fqemu%2Fruns%2F516%2F11%2Fcon > sole&data=02%7C01%7Cjuterry%40microsoft.com%7C733a566f3233427 > 8ae6f08d73dddb39f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6 > 37045894733463150&sdata=55URgDII5r74QMUpLOD%2FWT5%2B5jbzyv > nfCSdv%2FNaWDAw%3D&reserved=0 > Duration 17 minutes (1076 seconds) > > 4m49s building the qemu:fedora-win10sdk-cross docker image, 11m10s > building WHPX QEMU.
+launchpad ticket On 9/20/19 6:53 PM, Justin Terry (VM) wrote: > Hey Phil, > > I have contacted our legal department for guidance on this specific use case and will update you when I hear back. Thank you for your patience. > > Justin Terry > >> -----Original Message----- >> From: Philippe Mathieu-Daudé <philmd@redhat.com> >> Sent: Friday, September 20, 2019 8:18 AM >> To: qemu-devel@nongnu.org; Justin Terry (VM) <juterry@microsoft.com> >> Cc: Daniel P . Berrangé <berrange@redhat.com>; Fam Zheng >> <fam@euphon.net>; Thomas Huth <thuth@redhat.com>; Paolo Bonzini >> <pbonzini@redhat.com>; Alex Bennée <alex.bennee@linaro.org>; Richard >> Henderson <rth@twiddle.net>; Eduardo Habkost <ehabkost@redhat.com>; >> Stefan Weil <sw@weilnetz.de> >> Subject: Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries >> >> On 9/20/19 1:33 PM, Philippe Mathieu-Daudé wrote: >>> Add a job to cross-build QEMU with WHPX enabled. >>> >>> Since the WHPX is currently broken, include the patch required to have >>> successful Shippable build. >>> >>> I previously included the WHPX headers shared by the Android project, >>> and Daniel asked me to check the EULA. While trying to manually >>> install the Windows SDK, I noticed the installer fetches archives >>> directly, kindly asking where they are stored via the /fwlink API. >>> Do the same, fetch the required archives and extract them. No need to >>> accept EULA... >>> >>> Docker build the image first, then build QEMU in a instance of this >>> image. The image is internal to Shippable, the instances are not >>> reachable and are thrown once the build is finished. What we collect >>> from Shippable is the console output of QEMU build process, and if the >>> build process succeed or failed. So far we do not redistribute the >>> image or built binaries. >>> >>> Philippe Mathieu-Daudé (3): >>> target/i386: Fix broken build with WHPX enabled >>> tests/docker: Add fedora-win10sdk-cross image >>> .shippable.yml: Build WHPX enabled binaries >> >> FWIW here is the result of this series: >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapp. >> shippable.com%2Fgithub%2Fphilmd%2Fqemu%2Fruns%2F516%2F11%2Fcon >> sole&data=02%7C01%7Cjuterry%40microsoft.com%7C733a566f3233427 >> 8ae6f08d73dddb39f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6 >> 37045894733463150&sdata=55URgDII5r74QMUpLOD%2FWT5%2B5jbzyv >> nfCSdv%2FNaWDAw%3D&reserved=0 >> Duration 17 minutes (1076 seconds) >> >> 4m49s building the qemu:fedora-win10sdk-cross docker image, 11m10s >> building WHPX QEMU.
Hi Justin, Sunil, On 5/20/20 12:26 PM, Philippe Mathieu-Daudé wrote: > +launchpad ticket > > On 9/20/19 6:53 PM, Justin Terry (VM) wrote: >> Hey Phil, >> >> I have contacted our legal department for guidance on this specific >> use case and will update you when I hear back. Thank you for your >> patience. I recently understood legal changes can be very complex, thus it is implicit it can take years before getting updates. Since the project is still actively developed, maybe you could provide a Azure CI job to build a WHPX binary. We don't need to have access to the binary, just to the exit status (success/fail) and build logs. Do you think it is doable? Thanks, Phil. >> >> Justin Terry >> >>> -----Original Message----- >>> From: Philippe Mathieu-Daudé <philmd@redhat.com> >>> Sent: Friday, September 20, 2019 8:18 AM >>> To: qemu-devel@nongnu.org; Justin Terry (VM) <juterry@microsoft.com> >>> Cc: Daniel P . Berrangé <berrange@redhat.com>; Fam Zheng >>> <fam@euphon.net>; Thomas Huth <thuth@redhat.com>; Paolo Bonzini >>> <pbonzini@redhat.com>; Alex Bennée <alex.bennee@linaro.org>; Richard >>> Henderson <rth@twiddle.net>; Eduardo Habkost <ehabkost@redhat.com>; >>> Stefan Weil <sw@weilnetz.de> >>> Subject: Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries >>> >>> On 9/20/19 1:33 PM, Philippe Mathieu-Daudé wrote: >>>> Add a job to cross-build QEMU with WHPX enabled. >>>> >>>> Since the WHPX is currently broken, include the patch required to have >>>> successful Shippable build. >>>> >>>> I previously included the WHPX headers shared by the Android project, >>>> and Daniel asked me to check the EULA. While trying to manually >>>> install the Windows SDK, I noticed the installer fetches archives >>>> directly, kindly asking where they are stored via the /fwlink API. >>>> Do the same, fetch the required archives and extract them. No need to >>>> accept EULA... >>>> >>>> Docker build the image first, then build QEMU in a instance of this >>>> image. The image is internal to Shippable, the instances are not >>>> reachable and are thrown once the build is finished. What we collect >>>> from Shippable is the console output of QEMU build process, and if the >>>> build process succeed or failed. So far we do not redistribute the >>>> image or built binaries. >>>> >>>> Philippe Mathieu-Daudé (3): >>>> target/i386: Fix broken build with WHPX enabled >>>> tests/docker: Add fedora-win10sdk-cross image >>>> .shippable.yml: Build WHPX enabled binaries >>> >>> FWIW here is the result of this series: >>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapp. >>> shippable.com%2Fgithub%2Fphilmd%2Fqemu%2Fruns%2F516%2F11%2Fcon >>> sole&data=02%7C01%7Cjuterry%40microsoft.com%7C733a566f3233427 >>> 8ae6f08d73dddb39f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6 >>> 37045894733463150&sdata=55URgDII5r74QMUpLOD%2FWT5%2B5jbzyv >>> nfCSdv%2FNaWDAw%3D&reserved=0 >>> Duration 17 minutes (1076 seconds) >>> >>> 4m49s building the qemu:fedora-win10sdk-cross docker image, 11m10s >>> building WHPX QEMU. >
> Hi Justin, Sunil, Justin has moved to a different team is no longer working with WHPX. Moving him to bcc. > > On 5/20/20 12:26 PM, Philippe Mathieu-Daudé wrote: > > +launchpad ticket > > > > On 9/20/19 6:53 PM, Justin Terry (VM) wrote: > >> Hey Phil, > >> > >> I have contacted our legal department for guidance on this specific > >> use case and will update you when I hear back. Thank you for your > >> patience. > > I recently understood legal changes can be very complex, thus it is > implicit it can take years before getting updates. > > Since the project is still actively developed, maybe you could provide > a Azure CI job to build a WHPX binary. We don't need to have access to > the binary, just to the exit status (success/fail) and build logs. > > Do you think it is doable? > > Thanks, > > Phil. > The ask generally sounds reasonable. But, can you help me understand the full scope of the ask. Few questions: 1. Stefan has a CI pipeline to build WHPX. What's the benefit of having another CI job, that doesn't export the binary, but, just the status? 2. Which branch is the CI pipeline expected to build? 3. Is the expectation also that it will build WHPX patches that are submitted to the WHPX branch?
Hi Sunil, On 8/1/20 1:31 AM, Sunil Muthuswamy wrote: >> Hi Justin, Sunil, > > Justin has moved to a different team is no longer working with WHPX. Moving him > to bcc. OK. Does that mean you are the new responsible of updating the ticket regarding the WHPX headers and their license? > >> >> On 5/20/20 12:26 PM, Philippe Mathieu-Daudé wrote: >>> +launchpad ticket >>> >>> On 9/20/19 6:53 PM, Justin Terry (VM) wrote: >>>> Hey Phil, >>>> >>>> I have contacted our legal department for guidance on this specific >>>> use case and will update you when I hear back. Thank you for your >>>> patience. >> >> I recently understood legal changes can be very complex, thus it is >> implicit it can take years before getting updates. >> >> Since the project is still actively developed, maybe you could provide >> a Azure CI job to build a WHPX binary. We don't need to have access to >> the binary, just to the exit status (success/fail) and build logs. >> >> Do you think it is doable? >> >> Thanks, >> >> Phil. >> > The ask generally sounds reasonable. But, can you help me understand the full > scope of the ask. Few questions: > 1. Stefan has a CI pipeline to build WHPX. Great! I didn't know Stefan already did it :) Can you share the URL please, so we can integrate it with mainstream CI? > What's the benefit of having another CI > job, that doesn't export the binary, but, just the status? As usual, we do not want to circumvent the license. IANAL but IIUC we can not force a CI job to accept the EULA when installing it, even to test it. So the best we can do is check if the build succeeded (exit status). > 2. Which branch is the CI pipeline expected to build? 'master', to be sure no regressions are introduced. > 3. Is the expectation also that it will build WHPX patches that are submitted to the > WHPX branch? You describe a "downstream CI" testing, which is out of scope of the community public CI. Regards, Phil.
Am 03.08.20 um 12:51 schrieb Philippe Mathieu-Daudé: > Hi Sunil, > > On 8/1/20 1:31 AM, Sunil Muthuswamy wrote: >> The ask generally sounds reasonable. But, can you help me understand the full >> scope of the ask. Few questions: >> 1. Stefan has a CI pipeline to build WHPX. > Great! I didn't know Stefan already did it :) > Can you share the URL please, so we can integrate it with mainstream CI? I am sorry, but I don't have such a CI pipeline. Stefan
Am 03.08.20 um 13:28 schrieb Stefan Weil: > Am 03.08.20 um 12:51 schrieb Philippe Mathieu-Daudé: > >> Hi Sunil, >> >> On 8/1/20 1:31 AM, Sunil Muthuswamy wrote: >>> The ask generally sounds reasonable. But, can you help me understand the full >>> scope of the ask. Few questions: >>> 1. Stefan has a CI pipeline to build WHPX. >> Great! I didn't know Stefan already did it :) >> Can you share the URL please, so we can integrate it with mainstream CI? > > I am sorry, but I don't have such a CI pipeline. > > Stefan We can add a CI pipeline on Microsoft infrastructure by using a GitHub action. Here is an example: https://github.com/stweil/qemu/actions. I just sent a patch which adds the GitHub action for https://github.com/qemu/qemu. Peter, maybe you can add that patch even for 5.1. Kind regards, Stefan
On 03/08/2020 22.25, Stefan Weil wrote: > Am 03.08.20 um 13:28 schrieb Stefan Weil: > >> Am 03.08.20 um 12:51 schrieb Philippe Mathieu-Daudé: >> >>> Hi Sunil, >>> >>> On 8/1/20 1:31 AM, Sunil Muthuswamy wrote: >>>> The ask generally sounds reasonable. But, can you help me understand the full >>>> scope of the ask. Few questions: >>>> 1. Stefan has a CI pipeline to build WHPX. >>> Great! I didn't know Stefan already did it :) >>> Can you share the URL please, so we can integrate it with mainstream CI? >> >> I am sorry, but I don't have such a CI pipeline. >> >> Stefan > > > We can add a CI pipeline on Microsoft infrastructure by using a GitHub > action. Sorry for being ignorant, but how does that solve the legal questions just because it is running on GitHub instead of a different CI? Thomas
Am 04.08.20 um 08:43 schrieb Thomas Huth: > On 03/08/2020 22.25, Stefan Weil wrote: >> We can add a CI pipeline on Microsoft infrastructure by using a GitHub >> action. > Sorry for being ignorant, but how does that solve the legal questions > just because it is running on GitHub instead of a different CI? > > Thomas > Sorry, I though that would be clear by looking at the included shell script. The build does not use the Microsoft SDK. It gets the required header files from Mingw-w64. They added them in git master. See https://github.com/stweil/qemu/blob/master/.github/workflows/build.sh#L50 for code details. It's still shameful that MS is forcing developers to waste time rewriting API headers, just because the MS legal departments are not able to understand the needs of Open Source development. Stefan
On 8/4/20 8:55 AM, Stefan Weil wrote: > Am 04.08.20 um 08:43 schrieb Thomas Huth: > >> On 03/08/2020 22.25, Stefan Weil wrote: >>> We can add a CI pipeline on Microsoft infrastructure by using a GitHub >>> action. >> Sorry for being ignorant, but how does that solve the legal questions >> just because it is running on GitHub instead of a different CI? >> >> Thomas >> > > Sorry, I though that would be clear by looking at the included shell script. > > The build does not use the Microsoft SDK. It gets the required header > files from Mingw-w64. They added them in git master. Oh, so we can do that with GitLab too now, we don't need to rely on the GitHub 'Actions' CI in particular, right? > > See > https://github.com/stweil/qemu/blob/master/.github/workflows/build.sh#L50 > for code details. > > It's still shameful that MS is forcing developers to waste time > rewriting API headers, just because the MS legal departments are not > able to understand the needs of Open Source development. There has be a big switch from Microsoft toward Open Source, I attended some of there talk at the Open Source Summit in 2018. Maybe we simply haven't contacted the right persons to make the changes...? > > Stefan > > >
Am 04.08.20 um 09:23 schrieb Philippe Mathieu-Daudé: > On 8/4/20 8:55 AM, Stefan Weil wrote: >> Am 04.08.20 um 08:43 schrieb Thomas Huth: >> >>> On 03/08/2020 22.25, Stefan Weil wrote: >>>> We can add a CI pipeline on Microsoft infrastructure by using a GitHub >>>> action. >>> Sorry for being ignorant, but how does that solve the legal questions >>> just because it is running on GitHub instead of a different CI? >>> >>> Thomas >>> >> Sorry, I though that would be clear by looking at the included shell script. >> >> The build does not use the Microsoft SDK. It gets the required header >> files from Mingw-w64. They added them in git master. > Oh, so we can do that with GitLab too now, we don't need to rely on the > GitHub 'Actions' CI in particular, right? That's right. The build script was written for Ubuntu, so depending on the distribution used for GitLab CI it will need some modifications. If GitLab already has a recent Mingw-w64, it might be sufficient to fix the case of the header file names. Mingw-w64 uses winhvplatform.h while QEMU expects WinHvPlatform.h and so on. I used symbolic links to add the camel case filenames. >> See >> https://github.com/stweil/qemu/blob/master/.github/workflows/build.sh#L50 >> for code details. >> >> It's still shameful that MS is forcing developers to waste time >> rewriting API headers, just because the MS legal departments are not >> able to understand the needs of Open Source development. > There has be a big switch from Microsoft toward Open Source, I attended > some of there talk at the Open Source Summit in 2018. Maybe we simply > haven't contacted the right persons to make the changes...? Maybe, but it is difficult to find the right person in a large company like MS, and legal departments are often somehow special. And yes, they learned that Open Source can help them for their business, too. Stefan
On 8/4/20 9:42 AM, Stefan Weil wrote: > Am 04.08.20 um 09:23 schrieb Philippe Mathieu-Daudé: > >> On 8/4/20 8:55 AM, Stefan Weil wrote: >>> Am 04.08.20 um 08:43 schrieb Thomas Huth: >>> >>>> On 03/08/2020 22.25, Stefan Weil wrote: >>>>> We can add a CI pipeline on Microsoft infrastructure by using a GitHub >>>>> action. >>>> Sorry for being ignorant, but how does that solve the legal questions >>>> just because it is running on GitHub instead of a different CI? >>>> >>>> Thomas >>>> >>> Sorry, I though that would be clear by looking at the included shell script. >>> >>> The build does not use the Microsoft SDK. It gets the required header >>> files from Mingw-w64. They added them in git master. >> Oh, so we can do that with GitLab too now, we don't need to rely on the >> GitHub 'Actions' CI in particular, right? > > > That's right. The build script was written for Ubuntu, so depending on > the distribution used for GitLab CI it will need some modifications. If > GitLab already has a recent Mingw-w64, it might be sufficient to fix the > case of the header file names. Mingw-w64 uses winhvplatform.h while QEMU > expects WinHvPlatform.h and so on. I used symbolic links to add the > camel case filenames. > > >>> See >>> https://github.com/stweil/qemu/blob/master/.github/workflows/build.sh#L50 >>> for code details. >>> >>> It's still shameful that MS is forcing developers to waste time >>> rewriting API headers, just because the MS legal departments are not >>> able to understand the needs of Open Source development. >> There has be a big switch from Microsoft toward Open Source, I attended >> some of there talk at the Open Source Summit in 2018. Maybe we simply >> haven't contacted the right persons to make the changes...? > > > Maybe, but it is difficult to find the right person in a large company > like MS, and legal departments are often somehow special. Sunil seems quite active with the WHPX development, and the section is listed as "Supported [my Microsoft]" in MAINTAINERS. I'm confident we have someone else able to help use finding the right contacts in the company :) > > And yes, they learned that Open Source can help them for their business, > too. > > Stefan > > >
On 04/08/2020 09.42, Stefan Weil wrote: > Am 04.08.20 um 09:23 schrieb Philippe Mathieu-Daudé: > >> On 8/4/20 8:55 AM, Stefan Weil wrote: >>> Am 04.08.20 um 08:43 schrieb Thomas Huth: >>> >>>> On 03/08/2020 22.25, Stefan Weil wrote: >>>>> We can add a CI pipeline on Microsoft infrastructure by using a GitHub >>>>> action. >>>> Sorry for being ignorant, but how does that solve the legal questions >>>> just because it is running on GitHub instead of a different CI? >>>> >>>> Thomas >>>> >>> Sorry, I though that would be clear by looking at the included shell script. >>> >>> The build does not use the Microsoft SDK. It gets the required header >>> files from Mingw-w64. They added them in git master. Great, thanks for the clarification! >> Oh, so we can do that with GitLab too now, we don't need to rely on the >> GitHub 'Actions' CI in particular, right? > > That's right. The build script was written for Ubuntu, so depending on > the distribution used for GitLab CI it will need some modifications. If > GitLab already has a recent Mingw-w64, it might be sufficient to fix the > case of the header file names. Mingw-w64 uses winhvplatform.h while QEMU > expects WinHvPlatform.h and so on. I used symbolic links to add the > camel case filenames. I'm currently working on a patch series for our gitlab-CI that uses our containers to all possible kinds of cross-compiler builds (basically the ones that we are doing on shippable.com so far), including the 32-bit and 64-bit MinGW cross-compilation jobs. I can have a look whether I can integrate these headers there! Thanks, Thomas
On Tue, Aug 04, 2020 at 10:10:31AM +0200, Thomas Huth wrote: > On 04/08/2020 09.42, Stefan Weil wrote: > > Am 04.08.20 um 09:23 schrieb Philippe Mathieu-Daudé: > > > >> On 8/4/20 8:55 AM, Stefan Weil wrote: > >>> Am 04.08.20 um 08:43 schrieb Thomas Huth: > >>> > >>>> On 03/08/2020 22.25, Stefan Weil wrote: > >>>>> We can add a CI pipeline on Microsoft infrastructure by using a GitHub > >>>>> action. > >>>> Sorry for being ignorant, but how does that solve the legal questions > >>>> just because it is running on GitHub instead of a different CI? > >>>> > >>>> Thomas > >>>> > >>> Sorry, I though that would be clear by looking at the included shell script. > >>> > >>> The build does not use the Microsoft SDK. It gets the required header > >>> files from Mingw-w64. They added them in git master. > > Great, thanks for the clarification! > > >> Oh, so we can do that with GitLab too now, we don't need to rely on the > >> GitHub 'Actions' CI in particular, right? > > > > That's right. The build script was written for Ubuntu, so depending on > > the distribution used for GitLab CI it will need some modifications. If > > GitLab already has a recent Mingw-w64, it might be sufficient to fix the > > case of the header file names. Mingw-w64 uses winhvplatform.h while QEMU > > expects WinHvPlatform.h and so on. I used symbolic links to add the > > camel case filenames. > > I'm currently working on a patch series for our gitlab-CI that uses our > containers to all possible kinds of cross-compiler builds (basically the > ones that we are doing on shippable.com so far), including the 32-bit > and 64-bit MinGW cross-compilation jobs. I can have a look whether I can > integrate these headers there! Fedora rawhide carries mingw64 v7.0.0, which was released in Nov 2019 The WHPX headers were added to mingw64 git a week later, so they're not available in any distro yet. The mingw64 release schedule looks "sporadic" so maybe we can just request a new release to make WPHX stuff available. It'll thus be available for our CI in rawhide/sid shortly thereafter, which will be the best solution to let us do this in GitLab. We certainly don't want to add yet another separate CI system just for WHPX. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
> >> It's still shameful that MS is forcing developers to waste time > >> rewriting API headers, just because the MS legal departments are not > >> able to understand the needs of Open Source development. > > There has be a big switch from Microsoft toward Open Source, I attended > > some of there talk at the Open Source Summit in 2018. Maybe we simply > > haven't contacted the right persons to make the changes...? > > > Maybe, but it is difficult to find the right person in a large company > like MS, and legal departments are often somehow special. > > And yes, they learned that Open Source can help them for their business, > too. > > Stefan Mike Battista is the program manager owner of the SDK license and should be able to take/respond to any feedback about the SDK licensing for open source projects (I have added him here). He has also been added to previous threads about the licensing and is also included in this conversation: https://bugs.launchpad.net/qemu/+bug/1879672 - Sunil
On 8/18/20 11:20 PM, Sunil Muthuswamy wrote: >>>> It's still shameful that MS is forcing developers to waste time >>>> rewriting API headers, just because the MS legal departments are not >>>> able to understand the needs of Open Source development. >>> There has be a big switch from Microsoft toward Open Source, I attended >>> some of there talk at the Open Source Summit in 2018. Maybe we simply >>> haven't contacted the right persons to make the changes...? >> >> >> Maybe, but it is difficult to find the right person in a large company >> like MS, and legal departments are often somehow special. >> >> And yes, they learned that Open Source can help them for their business, >> too. >> >> Stefan > > Mike Battista is the program manager owner of the SDK license and should be > able to take/respond to any feedback about the SDK licensing for open source > projects (I have added him here). He has also been added to previous threads > about the licensing and is also included in this conversation: > https://bugs.launchpad.net/qemu/+bug/1879672 Hi Mike, thanks for helping us with this issue! And thanks a lot Sunil to bring Mike here :) > > - Sunil > >
© 2016 - 2024 Red Hat, Inc.