Am 14.03.2013 um 13:10 hat Markus Armbruster geschrieben: > Kevin Wolf <kw...@redhat.com> writes: > > But you have to do it right. This specific patch would introduce a > > copyright violation. It's really not that hard to conform to the terms > > of the MIT license, but that doesn't mean that you can ignore it. There > > is exactly one requirement and it reads like this: > > > > The above copyright notice and this permission notice shall be > > included in all copies or substantial portions of the Software. > > That's why I pointed to resources and examples on how to do it properly. > > > (I'm still waiting for a patch to blockdev.c, for which you did it > > wrong, by the way) > > Oops, that one fell through the cracks. Patch coming.
Thanks. > >> Of course, the stronger license still has to be compatible with GPLv2, > >> so we can accept the result into QEMU. > >> > >> If a subsystem has additional requirements on licenses, its maintainers > >> will explain them to you. For what it's worth, substantial parts of the > >> block layer are already GPLv2+. > > > > What parts exactly? As long as there are plans for a libqblock and as > > long as it doesn't seem completely impossible to have it under LGPL, I > > will ask to use either MIT or LGPL for block layer code (this doesn't > > apply to qemu-only code that isn't used in the tools - in this sense, > > things like blockdev.c are not part of the block layer) > > $ git-grep -lw GPL block block* > block-migration.c > block/blkverify.c > block/gluster.c > block/linux-aio.c > block/raw-aio.h > block/rbd.c > block/sheepdog.c > blockdev-nbd.c > blockdev.c Luckily, none of these are really critical for a libqblock library, even though they would be nice to have. If we can't license such a library as LGPL, we would lose the most important potential user, which is libvirt. In which case I probably wouldn't want to bother with providing a library at all. Kevin
