From: Paolo Bonzini <pbonzini@redhat.com>
To: Artyom Tarasenko <atar4qemu@gmail.com>
Cc: Stefan Weil <weil@mail.berlios.de>,
Kai Meyer <kai.meyer@storagecraft.com>,
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: Thu, 17 May 2012 11:41:44 +0200 [thread overview]
Message-ID: <4FB4C7D8.4010609@redhat.com> (raw)
In-Reply-To: <CACXAS8C-=zZ6uH7jXyKWbOQktFzPxiLC+dcZd+Tsn+DoQFEeDw@mail.gmail.com>
Il 17/05/2012 11:10, Artyom Tarasenko ha scritto:
> 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.
Roughly speaking, each file has its own license. So you can take for
example vl.c or tcg/* and use it in a proprietary program, because those
are under a non-copyleft license. You cannot do the same for
event_notifier.c, because it is released under GPLv2 or later.
For the project to be distributable at all, there has to be a license
that is compatible with all the others: such a license has to allow all
restrictions imposed by the other licenses used in the project, and all
other licenses have to allow all restrictions imposed by such a license.
For QEMU this license is the GPLv2.
>> 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?
Principles, explanations can be shared with whoever you want, however
you want. Patches are more of a grey area and I suggest you consult a
(good) lawyer.
Remember that the GPL only becomes relevant once you start distributing
code. As long as you share the changes within your company for example
you are safe. Here is what the GPL FAQ says:
Is making and using multiple copies within one organization or
company “distribution”? (#InternalDistribution)
No, in that case the organization is just making the copies for
itself. As a consequence, a company or other organization can
develop a modified version and install that version through its own
facilities, without giving the staff permission to release that
modified version to outsiders.
However, when the organization transfers copies to other
organizations or individuals, that is distribution. In particular,
providing copies to contractors for use off-site is distribution.
What you suggested with run-time linking sounds like you are adding a
functionality that is totally useless to the general public. Those
people who are able to combine it with the shared library could use it
as in the above answer without distributing the result.
Morally it's wrong, but a copyright holder cannot stop you on moral
grounds. Legally, you should consult a lawyer. Practically:
- if you go with iSCSI or something like that you would provide the same
functionality to your customers, keep clear from legal grey areas, and
the QEMU community probably could not care less.
- if you go with a clean reimplementation under the GPL you would
provide the same functionality to your customers, keep clear from legal
grey areas, contribute to QEMU positively, and perhaps get some
advertising for your product.
Paolo
next prev parent reply other threads:[~2012-05-17 9:42 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
2012-05-17 9:10 ` Artyom Tarasenko
2012-05-17 9:41 ` Paolo Bonzini [this message]
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=4FB4C7D8.4010609@redhat.com \
--to=pbonzini@redhat.com \
--cc=Nate.Bushman@storagecraft.com \
--cc=anthony@codemonkey.ws \
--cc=atar4qemu@gmail.com \
--cc=kai.meyer@storagecraft.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).