[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Add support for new image type

From: Artyom Tarasenko
Subject: Re: [Qemu-devel] Add support for new image type
Date: Thu, 17 May 2012 11:10:17 +0200

On Wed, May 16, 2012 at 9:20 PM, Kai Meyer <address@hidden> wrote:
> 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?

With source code that's easy - if you  distribute qemu you have to
distribute its source code.

> 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?

With wiki documentation which is not derived from other sources (like
QEMU wiki or QEMU itself) you can do whatever you like.

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

IANAL but I think you can have 3 more options:

- you can take an older qemu version. Prior to to release 1.0 qemu
claimed to have LGPL 2 license.
LGPL would allow linking qemu with your library. There is one caveat
though: I don't know how legal this
LGPL label was, because also back at that time there were files under GPL.
On the other hand there was a already a precedence of using a
proprietary library, called FMOD.

- you probably can distribute your library and instructions how to
incorporate it in qemu. Then you are not violating GPL,
but your customers would be: the modified version is not
distributable. Check this with your lawyer.

- the cleanest way. You can fork qemu and remove all GPL code. The
heart of qemu - TCG is licensed under BSD license. A lot of code is
licensed under BSD and LGPL, so maybe if you don't need the whole
functionality of qemu, you can live with the BSD/LGPL subset. Who
knows, you even may find people interested in non-GPL version of qemu.
For example in FreeBSD community, they are trying to build a GNU-less

Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

reply via email to

[Prev in Thread] Current Thread [Next in Thread]