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 13:20:54 -0600	[thread overview]
Message-ID: <4FB3FE16.3000608@storagecraft.com> (raw)
In-Reply-To: <4FB3E86B.7020206@redhat.com>

On 05/16/2012 11:48 AM, Paolo Bonzini wrote:
> Il 16/05/2012 19:06, Kai Meyer ha scritto:
>> 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.
> That's really getting into grey areas.  IANAL, so I cannot answer this
> question.
>
> But as an aside, the GPL _does_ give you rights to distribute any
> modification you make to QEMU.  The right questions to ask are:
>
> 1) a practical question: would the QEMU community accept that
> contribution?  The answer here is "most likely not".
>
> 2) a legal question (i.e. the question that a court would answer): what
> are the rights of the _recipients_ of your version (and especially of
> the copyright holders of QEMU)?  Do they have rights to ask you for the
> source code to the shared library, and to receive it under the GPL?
> Again I cannot answer here (and I couldn't even if I were a lawyer).
>
> (Remember that however what we proposed was not just relicensing your
> library source code, but alternatively to rewrite it from scratch with
> no particular attention to performance.  That would be a completely
> different story, probably also for your lawyers.  You could also share
> any internal spec you have and hire someone to write the QEMU interface
> for you, basically a form of clean-room reverse engineering).
>
>> 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.
> This would have to be applied to all files (not just block/*.c say) and
> agreed upon by all QEMU copyright holders.  The second condition is
> quite obvious, the first I'll spend a few more words on.
>
> The first condition is because the code overall can be distributed as
> long as it fulfills all existing licenses.  QEMU right now has files
> under BSD, GPLv2, GPLv2-or-later, LGPLv2.1-or-later and perhaps some
> more licenses.  You can take code from individual files (or complete
> files) and reuse it under the license indicated in the header of that
> file.  However, you can only distribute QEMU as a whole under the
> intersection of those licenses, which is GPLv2.  If you add another
> license to the mix ("GPL+controlled interface") for block/*.c, QEMU as a
> whole could still only be distributed under GPLv2.
>
>> 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.)
> Sure, personally I appreciate your honesty even though I disagree with
> your goal. :)
>
> Paolo
I want to respect the lines that the GPL draws, and this helps clarify 
for me where some of those lines are. To help me better understand, what 
would be the terminology used for the explanation between what I would 
call "source code" licensing, and "project" licensing? Also, where in 
the code (or rather what file) can I see this distinction? It seems like 
something critical to be aware of, and I'd like to avoid missing 
something like this in the future as I give advice on what software we 
can use.

Thanks for being patient with me.

If you would help clarify a separate point, I would be grateful. As I 
understand it, I am able to modify qemu for my own purposes (like 
testing the filesystem integrity inside a backup image by using 
guestmount to mount it). How much of that work (source code, principles, 
explanations, ect) can I share, and with whom can I share it with? For 
instance, would qemu be opposed to a StorageCraft wiki article on "How 
to add support for our Backup Images to qemu"? And would it make a 
difference if it was a publicly accessible wiki vs a private wiki? I am 
interested in respecting the spirit and purpose of the GPL license for 
the qemu project. The header file for our image library is open, and we 
encourage our customers to do interesting things with the library. It is 
unfortunate for this project (and any other GPL project we may 
encounter) that the library itself can't be opened.

-Kai Meyer

  parent reply	other threads:[~2012-05-16 19:21 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
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 [this message]
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=4FB3FE16.3000608@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).