From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43412) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUhzj-0006dR-Ii for qemu-devel@nongnu.org; Wed, 16 May 2012 13:26:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SUhzh-00043e-Jx for qemu-devel@nongnu.org; Wed, 16 May 2012 13:26:39 -0400 Received: from webmail.storagecraft.com ([199.101.231.144]:51263 helo=STC-EXCH.stc.local) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUhzh-00043H-C0 for qemu-devel@nongnu.org; Wed, 16 May 2012 13:26:37 -0400 Message-ID: <4FB3DE79.9090504@storagecraft.com> Date: Wed, 16 May 2012 11:06:01 -0600 From: Kai Meyer MIME-Version: 1.0 References: <4F4E9E31.50903@storagecraft.com> <4F4F8FCD.7010106@redhat.com> <4F4FD1C9.8050006@storagecraft.com> <4F4FD7C7.7030001@mail.berlios.de> <4F4FD9A6.9060308@mail.berlios.de> <4F4FE4AA.20902@codemonkey.ws> <4F4FE6C6.1070302@storagecraft.com> <4F506E92.9080902@redhat.com> In-Reply-To: <4F506E92.9080902@redhat.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Add support for new image type List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Stefan Weil , qemu-devel@nongnu.org, Anthony Liguori , Nate Bushman On 03/01/2012 11:54 PM, Paolo Bonzini wrote: > > It does not matter whether it is upstream or not. > > When you distribute your modified QEMU binary, anyone who receives it > has the right to ask you for the complete corresponding source code. > > I also suggest that you write a wrapper around your library that exports > the contents as iSCSI or NBD. > > Paolo I simply can't get over how simple it was to integrate our closed-source block-wise access library with qemu, or how many uses there are from other projects like libguestfs that would automatically gain support for our format. Since we last spoke, we've been working on iSCSI, but I've also received some conflicting interpretations on the GPL. As I learn more about the GPL, it is clear that the intent is to help the owners retain as many rights as they choose to retain. In the spirit of pleasing the owners of qemu, I'd like to ask two questions. We are not interested in playing in legal "grey" areas, so unless there is a clear "sure go for it" answer, we're only too happy to comply with your wishes. 1) It's been suggested to me that since we have the rights to distribute our closed source shared library, there is a precedence for being able to distributed a modified version of qemu that does run-time linking against our shared library. The absence or presence of our shared library simply enables or disables support for our file format. We are happy to make available all changes to the qemu source code, but we are not in a position to re-license our shared library's source code to a compatible GPL license. This seems to be in contradiction to Paolo's statement above, so while I can't resist asking if this is possible, I don't have any realistic expectation that this is acceptable. 2) The GPL has provisions for you to create an exception where you have specified a controlled interface. Am I right that qemu has not added this controlled interface exception for file format access? What are your thoughts on adding this exception if it is not present? I would think that "struct BlockDriver" would make an excellent candidate for this. On a personal note, I am an open source enthusiast, so the last thing I would want to do is to help alienate the relationship between qemu and storagecraft. I'm not asking these questions to look for a legal corner to worm my way into, but because I love open source software, and I want to learn how to play nicely. (Plus there's that virtualization "coolness" factor to this solution that I can't resist.)