Re: [Qemu-devel] [PATCH V9 01/14] block: move bdrv_snapshot_find() to block/snapshot.c

[Kevin Wolf]

Am 14.03.2013 um 13:10 hat Markus Armbruster geschrieben:
> Kevin Wolf <address@hidden> 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