[PATCH] multipath-tools: replace FSF address with a www pointer

[PATCH] multipath-tools: replace FSF address with a www pointer

[Xose Vazquez Perez]

Less prone to future modifications, and new FSF licences
point exactly to this url: <http://www.gnu.org/licenses/>.

First clean up was done in 5619a39c433ac3d10a88079593cec1aa6472cbeb

Cc: Martin Wilck <mwilck@suse.com>
Cc: Christophe Varoqui <christophe.varoqui@opensvc.com>
Cc: device-mapper development <dm-devel@redhat.com>
Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
---
 libmultipath/dm-generic.c   | 4 +---
 libmultipath/dm-generic.h   | 4 +---
 libmultipath/foreign.c      | 4 +---
 libmultipath/foreign.h      | 4 +---
 libmultipath/foreign/nvme.c | 4 +---
 libmultipath/generic.c      | 4 +---
 libmultipath/generic.h      | 4 +---
 7 files changed, 7 insertions(+), 21 deletions(-)

diff --git a/libmultipath/dm-generic.c b/libmultipath/dm-generic.c
index bdc9ca0..d752991 100644
--- a/libmultipath/dm-generic.c
+++ b/libmultipath/dm-generic.c
@@ -12,9 +12,7 @@
   GNU General Public License for more details.
 
   You should have received a copy of the GNU General Public License
-  along with this program; if not, write to the Free Software
-  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301,
-  USA.
+  along with this program.  If not, see <https://www.gnu.org/licenses/>.
  */
 
 #include <stdint.h>
diff --git a/libmultipath/dm-generic.h b/libmultipath/dm-generic.h
index 5d59724..986429f 100644
--- a/libmultipath/dm-generic.h
+++ b/libmultipath/dm-generic.h
@@ -12,9 +12,7 @@
   GNU General Public License for more details.
 
   You should have received a copy of the GNU General Public License
-  along with this program; if not, write to the Free Software
-  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301,
-  USA.
+  along with this program.  If not, see <https://www.gnu.org/licenses/>.
  */
 #ifndef _DM_GENERIC_H
 #define _DM_GENERIC_H
diff --git a/libmultipath/foreign.c b/libmultipath/foreign.c
index 7217184..80b399b 100644
--- a/libmultipath/foreign.c
+++ b/libmultipath/foreign.c
@@ -12,9 +12,7 @@
   GNU General Public License for more details.
 
   You should have received a copy of the GNU General Public License
-  along with this program; if not, write to the Free Software
-  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301,
-  USA.
+  along with this program.  If not, see <https://www.gnu.org/licenses/>.
 */
 
 #include <sys/sysmacros.h>
diff --git a/libmultipath/foreign.h b/libmultipath/foreign.h
index 973f368..697f12f 100644
--- a/libmultipath/foreign.h
+++ b/libmultipath/foreign.h
@@ -12,9 +12,7 @@
   GNU General Public License for more details.
 
   You should have received a copy of the GNU General Public License
-  along with this program; if not, write to the Free Software
-  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301,
-  USA.
+  along with this program.  If not, see <https://www.gnu.org/licenses/>.
 */
 #ifndef _FOREIGN_H
 #define _FOREIGN_H
diff --git a/libmultipath/foreign/nvme.c b/libmultipath/foreign/nvme.c
index 235f75d..280b6bd 100644
--- a/libmultipath/foreign/nvme.c
+++ b/libmultipath/foreign/nvme.c
@@ -12,9 +12,7 @@
   GNU General Public License for more details.
 
   You should have received a copy of the GNU General Public License
-  along with this program; if not, write to the Free Software
-  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301,
-  USA.
+  along with this program.  If not, see <https://www.gnu.org/licenses/>.
 */
 
 #include <sys/sysmacros.h>
diff --git a/libmultipath/generic.c b/libmultipath/generic.c
index 6f7a2cd..0d1e632 100644
--- a/libmultipath/generic.c
+++ b/libmultipath/generic.c
@@ -12,9 +12,7 @@
   GNU General Public License for more details.
 
   You should have received a copy of the GNU General Public License
-  along with this program; if not, write to the Free Software
-  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301,
-  USA.
+  along with this program.  If not, see <https://www.gnu.org/licenses/>.
  */
 
 
diff --git a/libmultipath/generic.h b/libmultipath/generic.h
index 7f7fe66..6346ffe 100644
--- a/libmultipath/generic.h
+++ b/libmultipath/generic.h
@@ -12,9 +12,7 @@
   GNU General Public License for more details.
 
   You should have received a copy of the GNU General Public License
-  along with this program; if not, write to the Free Software
-  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301,
-  USA.
+  along with this program.  If not, see <https://www.gnu.org/licenses/>.
  */
 #ifndef _GENERIC_H
 #define _GENERIC_H
-- 
2.14.3

Re: [PATCH] multipath-tools: replace FSF address with a www pointer

[Martin Wilck]

On Sat, 2018-03-10 at 21:50 +0100, Xose Vazquez Perez wrote:
> Less prone to future modifications, and new FSF licences
> point exactly to this url: <http://www.gnu.org/licenses/>.
> 
> First clean up was done in 5619a39c433ac3d10a88079593cec1aa6472cbeb
> 
> Cc: Martin Wilck <mwilck@suse.com>
> Cc: Christophe Varoqui <christophe.varoqui@opensvc.com>
> Cc: device-mapper development <dm-devel@redhat.com>
> Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>

IANAL, but AFAICS multipath-tools comes under GPLv2, and the GPLv2
still contains the original paragraph with the address. 

https://www.gnu.org/licenses/old-licenses/gpl-2.0.html#howto

Replacing this by the text from GPLv3, and using the "/licenses/" link,
which points to a page mostly devoted to GPLv3, might cause people to
think we're using GPLv3. I'm in favor of keeping the GPLv2 wording.

Martin

-- 
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

Re: [PATCH] multipath-tools: replace FSF address with a www pointer

[Xose Vazquez Perez]

On 03/19/2018 10:37 PM, Martin Wilck wrote:

> On Sat, 2018-03-10 at 21:50 +0100, Xose Vazquez Perez wrote:
>> Less prone to future modifications, and new FSF licences
>> point exactly to this url: <http://www.gnu.org/licenses/>.
>>
>> First clean up was done in 5619a39c433ac3d10a88079593cec1aa6472cbeb
>>
>> Cc: Martin Wilck <mwilck@suse.com>
>> Cc: Christophe Varoqui <christophe.varoqui@opensvc.com>
>> Cc: device-mapper development <dm-devel@redhat.com>
>> Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>

> IANAL, but AFAICS multipath-tools comes under GPLv2, and the GPLv2


https://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=blob_plain;f=COPYING;hb=HEAD

                  GNU *LIBRARY* GENERAL PUBLIC LICENSE
                        Version 2, June 1991

aka "Lesser", but rules are the same as in GPL.

> still contains the original paragraph with the address. 
> https://www.gnu.org/licenses/old-licenses/gpl-2.0.html#howto


from https://www.gnu.org/licenses/gpl-howto.html :
"[...]
    Foobar is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.

    Foobar is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with Foobar.  If not, see <http://www.gnu.org/licenses/>.

To use a different set of GPL versions, you would modify the end of the first
long paragraph. For instance, to license under version 2 or later, you would
replace “3” with “2”.
[...]"

Anyway, that text is a "licence notice" and is not "part of the licence":

> Replacing this by the text from GPLv3, and using the "/licenses/" link,
> which points to a page mostly devoted to GPLv3, might cause people to
> think we're using GPLv3. I'm in favor of keeping the GPLv2 wording.


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


It would be nice to start using SPDX tags ( https://spdx.org/ ),
at least for new files, instead of full GPL/LGPL notices:
https://photos.app.goo.gl/Rrin0LlobTFYYciQ2


BTW: LFC191 Compliance Basics for Developers course is FREE
     https://training.linuxfoundation.org/linux-courses/open-source-compliance-courses/compliance-basics-for-developers

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

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

[Hannes Reinecke]

On Fri, 23 Mar 2018 21:30:17 +0100
Martin Wilck <mwilck@suse.com> wrote:

> 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.
> 
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?

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

Cheers,

Hannes

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

[Martin Wilck]

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

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

[Xose Vazquez Perez]

On 03/23/2018 09:30 PM, Martin Wilck wrote:

> [...]
> 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.
> [...]

Already discussed, but without a real conclusion: https://marc.info/?t=146961656800001

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

[Martin Wilck]

On Mon, 2018-03-26 at 14:36 +0200, Martin Wilck wrote:
> On Mon, 2018-03-26 at 13:04 +0200, Hannes Reinecke wrote:
> > 
> > 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.

Well - AFAICS the initial versions of these files were basically copied
 from udev. That means we can't simply change their license unless Kay
Sievers agrees.

Martin

-- 
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

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

[Martin Wilck]

On Mon, 2018-03-26 at 14:36 +0200, Martin Wilck wrote:
> 
> 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 just realized that libdmmp doesn't link to libmultipath, either, just
libmpathcmd. So there's _no_ linking problem here, and _no_ legal
problem distributing libdmmp and libmultipath together. I'm sorry for
distributing FUD.

Soooo, it's actually not so bad, after all, except that we (and
external parties) have to realize that the COPYING file doesn't apply
to libmultipath as a whole, just to those files that don't carry an
explicit copyright notice, and that means very little. Because of the
issues raised earlier, libmultipath.so and libmpathpersist.so are
effectively under "GPLv2 only" license, and neither under any *L*GPL
variant, nor under a "version $x or later" variant.

The COPYING file is therefore rather misleading.

Martin

-- 
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

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

[Benjamin Marzinski]

On Mon, Mar 26, 2018 at 04:15:19PM +0200, Martin Wilck wrote:
> On Mon, 2018-03-26 at 14:36 +0200, Martin Wilck wrote:
> > 
> > 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 just realized that libdmmp doesn't link to libmultipath, either, just
> libmpathcmd. So there's _no_ linking problem here, and _no_ legal
> problem distributing libdmmp and libmultipath together. I'm sorry for
> distributing FUD.
> 
> Soooo, it's actually not so bad, after all, except that we (and
> external parties) have to realize that the COPYING file doesn't apply
> to libmultipath as a whole, just to those files that don't carry an
> explicit copyright notice, and that means very little. Because of the
> issues raised earlier, libmultipath.so and libmpathpersist.so are
> effectively under "GPLv2 only" license, and neither under any *L*GPL
> variant, nor under a "version $x or later" variant.
> 
> The COPYING file is therefore rather misleading.

It was always my intention that libmpathcmd was LGPL. It doesn't link to
any other multipath code, and as you point out, mpath_cmd.h has a LGPL
header.

All of the code that I have contributed to libmpathpersist, I am happy
to release under LGPL, but that doesn't amount to much.

I agree that libmultipath should not be LPGL'ed. I don't think anyone
should even be distributing .h files for it.  I certainly don't ever
worry about maintaining a consistent API in it, so nothing outside of
the multipath tools code base should ever rely on it.

As for what, if anything, to do with the libdmmp license, I belive that
it pretty much entirely up to Gris.

If we can limit the project to two (or if necessary 3) licenses, we can
just include all the license files, and explain what applies to what
in the README.  I haven't really looked at how other projects that have
multiple licenses for parts of their code do things, so perhaps there is
a more standard way.

-Ben

> 
> Martin
> 
> -- 
> 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)

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

[Martin Wilck]

On Mon, 2018-03-26 at 11:07 -0500, Benjamin Marzinski wrote:
> 
> All of the code that I have contributed to libmpathpersist, I am
> happy
> to release under LGPL, but that doesn't amount to much.

As long as libmpathpersist links to libmultipath, that wouldn't change
a thing for external users. If the intention is to make libmpathpersist
usable by proprietary code, you'd need to decouple it from libmultipath
by using cli commands. If there's no such intention, all we need to do
is clarify the license situation.

Regards
Martin

-- 
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

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

[Xose Vazquez Perez]

On 03/26/2018 02:36 PM, Martin Wilck wrote:

> 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".

Yes, LGPLv2.1 is LGPLv2.0 plus §6b:
---cut----
    b) Use a suitable shared library mechanism for linking with the
    Library.  A suitable mechanism is one that (1) uses at run time a
    copy of the library already present on the user's computer system,
    rather than copying library functions into the executable, and (2)
    will operate properly with a modified version of the library, if
    the user installs one, as long as the modified version is
    interface-compatible with the version that the work was made with.
---end---


https://www.gnu.org/licenses/old-licenses/lgpl-2.0.txt
https://www.gnu.org/licenses/old-licenses/lgpl-2.1.txt


--- lgpl-2.0.txt	2010-03-25 18:29:55.000000000 +0100
+++ lgpl-2.1.txt	2010-03-24 00:34:05.000000000 +0100
@@ -1,13 +1,14 @@
-                  GNU LIBRARY GENERAL PUBLIC LICENSE
-                       Version 2, June 1991
+                  GNU LESSER GENERAL PUBLIC LICENSE
+                       Version 2.1, February 1999

- Copyright (C) 1991 Free Software Foundation, Inc.
+ Copyright (C) 1991, 1999 Free Software Foundation, Inc.
  51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
  Everyone is permitted to copy and distribute verbatim copies
  of this license document, but changing it is not allowed.

-[This is the first released version of the library GPL.  It is
- numbered 2 because it goes with version 2 of the ordinary GPL.]
+[This is the first released version of the Lesser GPL.  It also counts
+ as the successor of the GNU Library Public License, version 2, hence
+ the version number 2.1.]

                             Preamble

@@ -16,97 +17,109 @@ freedom to share and change it.  By cont
 Licenses are intended to guarantee your freedom to share and change
 free software--to make sure the software is free for all its users.

-  This license, the Library General Public License, applies to some
-specially designated Free Software Foundation software, and to any
-other libraries whose authors decide to use it.  You can use it for
-your libraries, too.
-
-  When we speak of free software, we are referring to freedom, not
-price.  Our General Public Licenses are designed to make sure that you
-have the freedom to distribute copies of free software (and charge for
-this service if you wish), that you receive source code or can get it
-if you want it, that you can change the software or use pieces of it
-in new free programs; and that you know you can do these things.
+  This license, the Lesser General Public License, applies to some
+specially designated software packages--typically libraries--of the
+Free Software Foundation and other authors who decide to use it.  You
+can use it too, but we suggest you first think carefully about whether
+this license or the ordinary General Public License is the better
+strategy to use in any particular case, based on the explanations below.
+
+  When we speak of free software, we are referring to freedom of use,
+not price.  Our General Public Licenses are designed to make sure that
+you have the freedom to distribute copies of free software (and charge
+for this service if you wish); that you receive source code or can get
+it if you want it; that you can change the software and use pieces of
+it in new free programs; and that you are informed that you can do
+these things.

   To protect your rights, we need to make restrictions that forbid
-anyone to deny you these rights or to ask you to surrender the rights.
-These restrictions translate to certain responsibilities for you if
-you distribute copies of the library, or if you modify it.
+distributors to deny you these rights or to ask you to surrender these
+rights.  These restrictions translate to certain responsibilities for
+you if you distribute copies of the library or if you modify it.

   For example, if you distribute copies of the library, whether gratis
 or for a fee, you must give the recipients all the rights that we gave
 you.  You must make sure that they, too, receive or can get the source
-code.  If you link a program with the library, you must provide
-complete object files to the recipients so that they can relink them
-with the library, after making changes to the library and recompiling
+code.  If you link other code with the library, you must provide
+complete object files to the recipients, so that they can relink them
+with the library after making changes to the library and recompiling
 it.  And you must show them these terms so they know their rights.

-  Our method of protecting your rights has two steps: (1) copyright
-the library, and (2) offer you this license which gives you legal
+  We protect your rights with a two-step method: (1) we copyright the
+library, and (2) we offer you this license, which gives you legal
 permission to copy, distribute and/or modify the library.

-  Also, for each distributor's protection, we want to make certain
-that everyone understands that there is no warranty for this free
-library.  If the library is modified by someone else and passed on, we
-want its recipients to know that what they have is not the original
-version, so that any problems introduced by others will not reflect on
-the original authors' reputations.
+  To protect each distributor, we want to make it very clear that
+there is no warranty for the free library.  Also, if the library is
+modified by someone else and passed on, the recipients should know
+that what they have is not the original version, so that the original
+author's reputation will not be affected by problems that might be
+introduced by others.
 \f
-  Finally, any free program is threatened constantly by software
-patents.  We wish to avoid the danger that companies distributing free
-software will individually obtain patent licenses, thus in effect
-transforming the program into proprietary software.  To prevent this,
-we have made it clear that any patent must be licensed for everyone's
-free use or not licensed at all.
-
-  Most GNU software, including some libraries, is covered by the ordinary
-GNU General Public License, which was designed for utility programs.  This
-license, the GNU Library General Public License, applies to certain
-designated libraries.  This license is quite different from the ordinary
-one; be sure to read it in full, and don't assume that anything in it is
-the same as in the ordinary license.
-
-  The reason we have a separate public license for some libraries is that
-they blur the distinction we usually make between modifying or adding to a
-program and simply using it.  Linking a program with a library, without
-changing the library, is in some sense simply using the library, and is
-analogous to running a utility program or application program.  However, in
-a textual and legal sense, the linked executable is a combined work, a
-derivative of the original library, and the ordinary General Public License
-treats it as such.
-
-  Because of this blurred distinction, using the ordinary General
-Public License for libraries did not effectively promote software
-sharing, because most developers did not use the libraries.  We
-concluded that weaker conditions might promote sharing better.
-
-  However, unrestricted linking of non-free programs would deprive the
-users of those programs of all benefit from the free status of the
-libraries themselves.  This Library General Public License is intended to
-permit developers of non-free programs to use free libraries, while
-preserving your freedom as a user of such programs to change the free
-libraries that are incorporated in them.  (We have not seen how to achieve
-this as regards changes in header files, but we have achieved it as regards
-changes in the actual functions of the Library.)  The hope is that this
-will lead to faster development of free libraries.
+  Finally, software patents pose a constant threat to the existence of
+any free program.  We wish to make sure that a company cannot
+effectively restrict the users of a free program by obtaining a
+restrictive license from a patent holder.  Therefore, we insist that
+any patent license obtained for a version of the library must be
+consistent with the full freedom of use specified in this license.
+
+  Most GNU software, including some libraries, is covered by the
+ordinary GNU General Public License.  This license, the GNU Lesser
+General Public License, applies to certain designated libraries, and
+is quite different from the ordinary General Public License.  We use
+this license for certain libraries in order to permit linking those
+libraries into non-free programs.
+
+  When a program is linked with a library, whether statically or using
+a shared library, the combination of the two is legally speaking a
+combined work, a derivative of the original library.  The ordinary
+General Public License therefore permits such linking only if the
+entire combination fits its criteria of freedom.  The Lesser General
+Public License permits more lax criteria for linking other code with
+the library.
+
+  We call this license the "Lesser" General Public License because it
+does Less to protect the user's freedom than the ordinary General
+Public License.  It also provides other free software developers Less
+of an advantage over competing non-free programs.  These disadvantages
+are the reason we use the ordinary General Public License for many
+libraries.  However, the Lesser license provides advantages in certain
+special circumstances.
+
+  For example, on rare occasions, there may be a special need to
+encourage the widest possible use of a certain library, so that it becomes
+a de-facto standard.  To achieve this, non-free programs must be
+allowed to use the library.  A more frequent case is that a free
+library does the same job as widely used non-free libraries.  In this
+case, there is little to gain by limiting the free library to free
+software only, so we use the Lesser General Public License.
+
+  In other cases, permission to use a particular library in non-free
+programs enables a greater number of people to use a large body of
+free software.  For example, permission to use the GNU C Library in
+non-free programs enables many more people to use the whole GNU
+operating system, as well as its variant, the GNU/Linux operating
+system.
+
+  Although the Lesser General Public License is Less protective of the
+users' freedom, it does ensure that the user of a program that is
+linked with the Library has the freedom and the wherewithal to run
+that program using a modified version of the Library.

   The precise terms and conditions for copying, distribution and
 modification follow.  Pay close attention to the difference between a
 "work based on the library" and a "work that uses the library".  The
-former contains code derived from the library, while the latter only
-works together with the library.
-
-  Note that it is possible for a library to be covered by the ordinary
-General Public License rather than by this special one.
+former contains code derived from the library, whereas the latter must
+be combined with the library in order to run.
 \f
-                  GNU LIBRARY GENERAL PUBLIC LICENSE
+                  GNU LESSER GENERAL PUBLIC LICENSE
    TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION

-  0. This License Agreement applies to any software library which
-contains a notice placed by the copyright holder or other authorized
-party saying it may be distributed under the terms of this Library
-General Public License (also called "this License").  Each licensee is
-addressed as "you".
+  0. This License Agreement applies to any software library or other
+program which contains a notice placed by the copyright holder or
+other authorized party saying it may be distributed under the terms of
+this Lesser General Public License (also called "this License").
+Each licensee is addressed as "you".

   A "library" means a collection of software functions and/or data
 prepared so as to be conveniently linked with application programs
@@ -133,7 +146,7 @@ such a program is covered only if its co
 on the Library (independent of the use of the Library in a tool for
 writing it).  Whether that is true depends on what the Library does
 and what the program that uses the Library does.
-
+
   1. You may copy and distribute verbatim copies of the Library's
 complete source code as you receive it, in any medium, provided that
 you conspicuously and appropriately publish on each copy an
@@ -255,7 +268,7 @@ distribute the object code for the work
 Any executables containing that work also fall under Section 6,
 whether or not they are linked directly with the Library itself.
 \f
-  6. As an exception to the Sections above, you may also compile or
+  6. As an exception to the Sections above, you may also combine or
 link a "work that uses the Library" with the Library to produce a
 work containing portions of the Library, and distribute that work
 under terms of your choice, provided that the terms permit
@@ -282,23 +295,31 @@ of these things:
     Library will not necessarily be able to recompile the application
     to use the modified definitions.)

-    b) Accompany the work with a written offer, valid for at
+    b) Use a suitable shared library mechanism for linking with the
+    Library.  A suitable mechanism is one that (1) uses at run time a
+    copy of the library already present on the user's computer system,
+    rather than copying library functions into the executable, and (2)
+    will operate properly with a modified version of the library, if
+    the user installs one, as long as the modified version is
+    interface-compatible with the version that the work was made with.
+
+    c) Accompany the work with a written offer, valid for at
     least three years, to give the same user the materials
     specified in Subsection 6a, above, for a charge no more
     than the cost of performing this distribution.

-    c) If distribution of the work is made by offering access to copy
+    d) If distribution of the work is made by offering access to copy
     from a designated place, offer equivalent access to copy the above
     specified materials from the same place.

-    d) Verify that the user has already received a copy of these
+    e) Verify that the user has already received a copy of these
     materials or that you have already sent this user a copy.

   For an executable, the required form of the "work that uses the
 Library" must include any data and utility programs needed for
 reproducing the executable from it.  However, as a special exception,
-the source code distributed need not include anything that is normally
-distributed (in either source or binary form) with the major
+the materials to be distributed need not include anything that is
+normally distributed (in either source or binary form) with the major
 components (compiler, kernel, and so on) of the operating system on
 which the executable runs, unless that component itself accompanies
 the executable.
@@ -347,7 +368,7 @@ Library), the recipient automatically re
 original licensor to copy, distribute, link with or modify the Library
 subject to these terms and conditions.  You may not impose any further
 restrictions on the recipients' exercise of the rights granted herein.
-You are not responsible for enforcing compliance by third parties to
+You are not responsible for enforcing compliance by third parties with
 this License.
 \f
   11. If, as a consequence of a court judgment or allegation of patent
@@ -390,7 +411,7 @@ excluded.  In such case, this License in
 written in the body of this License.

   13. The Free Software Foundation may publish revised and/or new
-versions of the Library General Public License from time to time.
+versions of the Lesser General Public License from time to time.
 Such new versions will be similar in spirit to the present version,
 but may differ in detail to address new problems or concerns.

@@ -453,16 +474,16 @@ convey the exclusion of warranty; and ea
     Copyright (C) <year>  <name of author>

     This library is free software; you can redistribute it and/or
-    modify it under the terms of the GNU Library General Public
+    modify it under the terms of the GNU Lesser General Public
     License as published by the Free Software Foundation; either
-    version 2 of the License, or (at your option) any later version.
+    version 2.1 of the License, or (at your option) any later version.

     This library is distributed in the hope that it will be useful,
     but WITHOUT ANY WARRANTY; without even the implied warranty of
     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-    Library General Public License for more details.
+    Lesser General Public License for more details.

-    You should have received a copy of the GNU Library General Public
+    You should have received a copy of the GNU Lesser General Public
     License along with this library; if not, write to the Free Software
     Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA

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

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

[Martin Wilck]

On Tue, 2018-03-27 at 23:42 +0200, Xose Vazquez Perez wrote:
> On 03/26/2018 02:36 PM, Martin Wilck wrote:
> 
> > 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".
> 
> Yes, LGPLv2.1 is LGPLv2.0 plus §6b:

Thanks for confirming. I used "wdiff" for comparing the two texts, that
makes it even easier to verify that the differences are few.

Martin

-- 
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

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

[Xose Vazquez Perez]

On 03/26/2018 06:07 PM, Benjamin Marzinski wrote:

> If we can limit the project to two (or if necessary 3) licenses, we can
> just include all the license files, and explain what applies to what
> in the README.  I haven't really looked at how other projects that have
> multiple licenses for parts of their code do things, so perhaps there is
> a more standard way.

Multiple licences, for modules, are accepted in the Linux kernel:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/module.h#n171

And the SPDX License Identifier is being used:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/license-rules.rst

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

[Martin Wilck]

On Wed, 2018-03-28 at 00:24 +0200, Xose Vazquez Perez wrote:
> On 03/26/2018 06:07 PM, Benjamin Marzinski wrote:
> 
> > If we can limit the project to two (or if necessary 3) licenses, we
> > can
> > just include all the license files, and explain what applies to
> > what
> > in the README.  I haven't really looked at how other projects that
> > have
> > multiple licenses for parts of their code do things, so perhaps
> > there is
> > a more standard way.
> 
> Multiple licences, for modules, are accepted in the Linux kernel:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tr
> ee/include/linux/module.h#n171

Multiple licenses are acceptable for multipath-tools, too. Yet we need
to understand, and clearly communicate, which license applies to which
source file, and what that means for the binaries and libraries that
are part of the package. And, needless to say, reducing the number of
licenses and getting rid of the obsolete LGPL-2.0 would simplify
matters significantly, both for us and other parties.

> And the SPDX License Identifier is being used:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tr
> ee/Documentation/process/license-rules.rst

Yeah, it's probably a good idea to do that. I'm not sure if it should
replace the boilerplate license header or just be added on top of it.
Either way, when we do this, we should make sure that we understand
which license covers the individual files, in particular those that
currently have no license header. We're assuming that these are covered
by COPYING, but is that actually true for all 130+ files?

This shouldn't be taken too lightly. Assume you add an "LGPL-2.1" SPDX
header to some file. Company X links to the file in it's proprietary
product. Later, company Y finds some of its own GPL-2.0 licensed code
in the same file and sues X over 100 million for GPL breakage. Now X
claims the money back from the person who inserted the misleading
license header in the file ...

That sounds paranoid and exaggerated, but I've heard exactly arguments
like this in discussions about proprietary software using FLOSS. It's
the kind of thing Black Duck and similar companies make money with.

Regards
Martin

-- 
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

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

[Xose Vazquez Perez]

On 03/28/2018 05:14 PM, Martin Wilck wrote:

> On Wed, 2018-03-28 at 00:24 +0200, Xose Vazquez Perez wrote:

> Multiple licenses are acceptable for multipath-tools, too. Yet we need
> to understand, and clearly communicate, which license applies to which
> source file, and what that means for the binaries and libraries that
> are part of the package. And, needless to say, reducing the number of
> licenses and getting rid of the obsolete LGPL-2.0 would simplify
> matters significantly, both for us and other parties.

It would be nice to have the old cvs repo, from 2003-09-18 multipath-0.0.1 to
2005-05-23 multipath-tools-0.4.5, online. Or converted to git.

>> And the SPDX License Identifier is being used:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tr
>> ee/Documentation/process/license-rules.rst
> 
> Yeah, it's probably a good idea to do that. I'm not sure if it should
> replace the boilerplate license header or just be added on top of it.
> Either way, when we do this, we should make sure that we understand
> which license covers the individual files, in particular those that
> currently have no license header. We're assuming that these are covered
> by COPYING, but is that actually true for all 130+ files?
> 
> This shouldn't be taken too lightly. Assume you add an "LGPL-2.1" SPDX
> header to some file. Company X links to the file in it's proprietary
> product. Later, company Y finds some of its own GPL-2.0 licensed code
> in the same file and sues X over 100 million for GPL breakage. Now X
> claims the money back from the person who inserted the misleading
> license header in the file ...
> 
> That sounds paranoid and exaggerated, but I've heard exactly arguments
> like this in discussions about proprietary software using FLOSS. It's
> the kind of thing Black Duck and similar companies make money with.


Kernel guys are replacing boiler plate text with a SPDX tag.
I suppose, by advice and with assistance of the lawyers of The Linux Foundation.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b24413180f5600bcb3bb70fbed5cf186b60864bd
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a04c7278d3042cb30c8a66197d900209a4f2417c


This template could be good enough and neat for multipath-tools:
// SPDX-License-Identifier: <licence(s)>
// File-Originally-From: <project name and <url>>
// <a copyright indicator> <year(s) applicable>, <copyright holder(s)>.
// Author(s): <Name and <e-mail>>
//	      ...

e.g.

// SPDX-License-Identifier: GPL-2.0-or-later
// File-Originally-From: linux-tool <http://linux-tool.org>
// Copyright 1999, 2001-2018, Foo Corp.
// Author(s): Bar <bar@foo.org>

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

[Greg KH]

On Fri, Apr 06, 2018 at 06:10:48PM +0200, Xose Vazquez Perez wrote:
> On 03/28/2018 05:14 PM, Martin Wilck wrote:
> 
> > On Wed, 2018-03-28 at 00:24 +0200, Xose Vazquez Perez wrote:
> 
> > Multiple licenses are acceptable for multipath-tools, too. Yet we need
> > to understand, and clearly communicate, which license applies to which
> > source file, and what that means for the binaries and libraries that
> > are part of the package. And, needless to say, reducing the number of
> > licenses and getting rid of the obsolete LGPL-2.0 would simplify
> > matters significantly, both for us and other parties.
> 
> It would be nice to have the old cvs repo, from 2003-09-18 multipath-0.0.1 to
> 2005-05-23 multipath-tools-0.4.5, online. Or converted to git.
> 
> >> And the SPDX License Identifier is being used:
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tr
> >> ee/Documentation/process/license-rules.rst
> > 
> > Yeah, it's probably a good idea to do that. I'm not sure if it should
> > replace the boilerplate license header or just be added on top of it.
> > Either way, when we do this, we should make sure that we understand
> > which license covers the individual files, in particular those that
> > currently have no license header. We're assuming that these are covered
> > by COPYING, but is that actually true for all 130+ files?
> > 
> > This shouldn't be taken too lightly. Assume you add an "LGPL-2.1" SPDX
> > header to some file. Company X links to the file in it's proprietary
> > product. Later, company Y finds some of its own GPL-2.0 licensed code
> > in the same file and sues X over 100 million for GPL breakage. Now X
> > claims the money back from the person who inserted the misleading
> > license header in the file ...
> > 
> > That sounds paranoid and exaggerated, but I've heard exactly arguments
> > like this in discussions about proprietary software using FLOSS. It's
> > the kind of thing Black Duck and similar companies make money with.
> 
> 
> Kernel guys are replacing boiler plate text with a SPDX tag.
> I suppose, by advice and with assistance of the lawyers of The Linux Foundation.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b24413180f5600bcb3bb70fbed5cf186b60864bd
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a04c7278d3042cb30c8a66197d900209a4f2417c

Not just the LF lawyers, but the lawyers from almost all major Linux
copyright holders (Intel, Google, Red Hat, IBM, and so on...)

Here's the rules for how we structure the tags and why:
	https://www.kernel.org/doc/html/latest/process/license-rules.html

If you are going to use SPDX for your tools (and you should!), you might
want to look at the REUSE Initiative:
	https://reuse.software/

That provides a great framework for how you should probably tag things
in your codebase.

Hope this helps,

greg k-h

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

[Martin Wilck]

On Fri, 2018-04-06 at 18:10 +0200, Xose Vazquez Perez wrote:
> 
> It would be nice to have the old cvs repo, from 2003-09-18 multipath-
> 0.0.1 to
> 2005-05-23 multipath-tools-0.4.5, online. Or converted to git.

Found this:

https://web.archive.org/web/20050413224017/http://christophe.varoqui.fr
ee.fr/multipath-tools/

It covers 0.1.0-0.4.4.

Martin

-- 
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

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

[Xose Vazquez Perez]

On 04/09/2018 11:01 AM, Martin Wilck wrote:
> On Fri, 2018-04-06 at 18:10 +0200, Xose Vazquez Perez wrote:
>>
>> It would be nice to have the old cvs repo, from 2003-09-18 multipath-
>> 0.0.1 to
>> 2005-05-23 multipath-tools-0.4.5, online. Or converted to git.
> 
> Found this:
> 
> https://web.archive.org/web/20050413224017/http://christophe.varoqui.free.fr/multipath-tools/
> 
> It covers 0.1.0-0.4.4.

tar files, there is no cvs history.