| Message ID | 20180310205002.3318-1-xose.vazquez@gmail.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | christophe varoqui |
| Headers | show |
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
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
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
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 -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
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.
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 -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
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
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
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) -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
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
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 -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
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
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> -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
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 -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
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
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. -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
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
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(-)