All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Wilck <mwilck@suse.com>
To: Hannes Reinecke <hare@suse.de>
Cc: device-mapper development <dm-devel@redhat.com>,
	Xose Vazquez Perez <xose.vazquez@gmail.com>,
	fge@redhat.com
Subject: Re: multipath-tools licenses (was Re: [PATCH] multipath-tools: replace FSF address with a www pointer)
Date: Mon, 26 Mar 2018 14:36:28 +0200	[thread overview]
Message-ID: <1522067788.19335.55.camel@suse.com> (raw)
In-Reply-To: <20180326130447.3114ef2f@pentland.suse.de>

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@suse.com>, 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@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

  reply	other threads:[~2018-03-26 12:36 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-10 20:50 [PATCH] multipath-tools: replace FSF address with a www pointer Xose Vazquez Perez
2018-03-19 21:37 ` Martin Wilck
2018-03-23 18:28   ` Xose Vazquez Perez
2018-03-23 20:30     ` multipath-tools licenses (was Re: [PATCH] multipath-tools: replace FSF address with a www pointer) Martin Wilck
2018-03-26 11:04       ` Hannes Reinecke
2018-03-26 12:36         ` Martin Wilck [this message]
2018-03-26 14:02           ` Martin Wilck
2018-03-26 14:15           ` Martin Wilck
2018-03-26 16:07             ` Benjamin Marzinski
2018-03-26 16:16               ` Martin Wilck
2018-03-27 22:24               ` Xose Vazquez Perez
2018-03-28 15:14                 ` Martin Wilck
2018-04-06 16:10                   ` Xose Vazquez Perez
2018-04-06 16:25                     ` Greg KH
2018-04-09  9:01                     ` Martin Wilck
2018-04-10 13:56                       ` Xose Vazquez Perez
2018-03-27 21:42           ` Xose Vazquez Perez
2018-03-27 21:53             ` Martin Wilck
2018-03-26 13:02       ` Xose Vazquez Perez

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=1522067788.19335.55.camel@suse.com \
    --to=mwilck@suse.com \
    --cc=dm-devel@redhat.com \
    --cc=fge@redhat.com \
    --cc=hare@suse.de \
    --cc=xose.vazquez@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.