On Wed, May 16, 2012 at 9:20 PM, Kai Meyer <kai.me...@storagecraft.com> 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 system. -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu