qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kai Meyer <kai.meyer@storagecraft.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Stefan Weil <weil@mail.berlios.de>,
	qemu-devel@nongnu.org, Anthony Liguori <anthony@codemonkey.ws>,
	Nate Bushman <Nate.Bushman@storagecraft.com>
Subject: Re: [Qemu-devel] Add support for new image type
Date: Wed, 16 May 2012 11:06:01 -0600	[thread overview]
Message-ID: <4FB3DE79.9090504@storagecraft.com> (raw)
In-Reply-To: <4F506E92.9080902@redhat.com>

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.)

  parent reply	other threads:[~2012-05-16 17:26 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-29 21:52 [Qemu-devel] Add support for new image type Kai Meyer
2012-03-01  0:16 ` Brian Jackson
2012-03-01 15:03 ` Kevin Wolf
2012-03-01 19:45   ` Kai Meyer
2012-03-01 20:10     ` Stefan Weil
2012-03-01 20:18       ` Stefan Weil
2012-03-01 20:31         ` Kai Meyer
2012-03-01 21:05         ` Anthony Liguori
2012-03-01 21:14           ` Kai Meyer
2012-03-02  6:54             ` Paolo Bonzini
2012-03-02 18:38               ` Kai Meyer
2012-03-05  9:14                 ` Paolo Bonzini
2012-03-05 12:14                 ` Stefan Hajnoczi
2012-05-16 17:06               ` Kai Meyer [this message]
2012-05-16 17:48                 ` Paolo Bonzini
2012-05-16 18:21                   ` Anthony Liguori
2012-05-16 18:56                     ` Kai Meyer
2012-05-16 19:20                   ` Kai Meyer
2012-05-17  9:10                     ` Artyom Tarasenko
2012-05-17  9:41                       ` Paolo Bonzini
2012-05-17 11:03                         ` Artyom Tarasenko
2012-05-17 17:53                         ` Kai Meyer
2012-05-17 19:43                           ` Paolo Bonzini
2012-05-17 20:18                             ` Kai Meyer
2012-03-01 20:26       ` Kai Meyer
2012-03-01 20:38         ` Paolo Bonzini
2012-03-01 20:53         ` Stefan Weil
2012-03-01 21:02     ` Anthony Liguori
2012-03-08 15:17     ` Kevin Wolf
2012-03-08 17:16       ` Nate Bushman
2012-03-09  9:23         ` Kevin Wolf
2012-03-09 10:28           ` Paolo Bonzini
2012-03-09 11:26             ` Kevin Wolf
2012-03-10 16:54             ` Nate Bushman
2012-03-10 16:53           ` Nate Bushman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FB3DE79.9090504@storagecraft.com \
    --to=kai.meyer@storagecraft.com \
    --cc=Nate.Bushman@storagecraft.com \
    --cc=anthony@codemonkey.ws \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=weil@mail.berlios.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).