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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2018-03-26 at 13:04 +0200, Hannes Reinecke wrote:
> On Fri, 23 Mar 2018 21:30:17 +0100
> 
> > 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.
> > 
> 
> Well, as I'm the one responsible for adding 'sysfs.c' and 'uevent.c'
> to
> multipath-tools I should allowed to change the license there, right?

I guess so.

> If so I'm happy to change them to LPGL to make things easier.

That'd be helpful, but not sufficient, because there's a couple of
other files under "GPLv2 or later" left, and because the GPLv2/v3
problem for libdmpp remains.

It'd be a good idea to upgrade generally from "Library GPL v2" at least
to LGPLv2.1. That shouldn't be a problem, as the only major
differerence between LGPLv2 and LGPLv2.1 is the addition of §6b in the
latter, allowing the use of "a suitable shared library mechanism for
linking with the library".

According to https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility
, LGPLv2.1 is compatible with GPLv3, although the "combination is under
GPLv3".

The key question is whether we need *L*GPL at all. We only do if we
want to allow prioprietary code to link with our code. Because
libmultipath is no "library" intended for general use, rather a set of
common code between multipath and multipathd, I don't see a strong case
for *L*GPL for it. The parts of the code that might be interesting for
external parties to use are libmpathcmd, libmpathpersist, and libdmmp,
where the GPLv3 of the latter explicity forbids use by proprietary
code. libmpathcmd doesn't need to link libmultipath, but
libmpathpersist in its current form does.

I vote to change libmpathcmd and libmpathpersist to "LGPLv2.1 or
later", and everything else to "GPLv2 or later" (*). But I own just a
marginal portion of the code, so that's for others to decide.

Cheers,
Martin

(*) Caveat: code which has been copied from kernel sources (list.h?,
alua code?, ... ?) would be under "GPLv2 only", and changing that would
require consent of the original copyright holders, which might be
difficult to obtain.

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

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel




[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux