[dm-devel] multipath-tools licenses (was Re: [PATCH] multipath-tools: replace FSF address with a www pointer)

[Martin Wilck]

On Fr, 2018-03-23 at 19:28 +0100, Xose Vazquez Perez wrote:
> 
> https://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=blob_plai
> n;f=COPYING;hb=HEAD
> 
>                   GNU *LIBRARY* GENERAL PUBLIC LICENSE
>                         Version 2, June 1991
> 
> aka "Lesser", but rules are the same as in GPL.

Ups, what an embarrassing oversight on my part. I guess my brain just
couldn't believe what my eyes were seeing.

> > 
> https://www.gnu.org/licenses/ is a _generic_ place. There is info
> about
> ALL licences and versions.

That's not obvious to me. In particular the LPGL v2.0 isn't even
mentioned there, only LGPL v2.1, and that's quite at the bottom.

It'd be _far_ more important to agree on consistent licenses throughout
the code. You quoted the file COPYING, but if you look at the actual
source files, the situation is a bit more complicated:

LGPLv2.1:
libmultipath/mpath_cmd.h

GPLv2:
libmultipath/sysfs.c
libmultipath/uevent.c
libmultipath/prioritizers/ontap.c

GPLv2 or later:
25 files under libmultipath and kpartx directories.

GPLv3 or later:
libdmmp

BSD license: 
./third-party/valgrind/drd.h
./third-party/valgrind/valgrind.h

137 files don't have an explicit license header and can thus be assumed
to be covered by the COPYING file (LGPL2.0).

This is a total mess for potential users of our code. Effectively, the
GPL parts of libmultipath would cause all of multipath-tools to be
under GPL rather than LGPLv2.x, because the linking exception of the
LGPL wouldn't apply to them, forbidding linking non-GPL code with
libmultipath. The GPLv2 "or later" gives you the choice, so
libmultipath is effectively under GPLv2 because of sysfs.c and
uevent.c. Furthermore, libmultipath and libdmmp have incompatible
licenses, and "there is no legal way to combine code under GPLv2 with
code under GPLv3 in a single program" (https://www.gnu.org/licenses/rms
-why-gplv3.html).

I believe that various files besides the three above contain code which
has been copied from kernel sources and would thus be under GPLv2 (the
alua code, for example).

Again, IANAL, but this looks like a mess that really ought to be
cleaned up. As long as we don't do that, there's no point in changing
the address headers.

It would make sense to generally agree on a GPL version (2, 2 or later,
3, 3 or later), and apply LGPL to (some of) the libraries and GPL to
the tools.

Martin

-- 
Dr. Martin Wilck <mwilck at suse.com>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)