Debian Bug report logs - #545574
lintian: Check for discrepancies in LGPL licensing

Reply or subscribe to this bug.

Display info messages

Message #5 received at [email protected] (full text, mbox, reply):

From: Mathew Eis <[email protected]>

To: [email protected]

Subject: lintian: Check for discrepancies in LGPL licensing

Date: Tue, 8 Sep 2009 00:43:16 -0700

Package: lintian
Version: 2.2.14
Severity: wishlist

It would be useful to have lintian check for discrepancies in LGPL
licensing; in particular check for the use of the non-existent
licenses "Lesser GPL v2" and "Library GPL v2.1".

See the following attached e-mail for a example case.

On Tue, Jul 28, 2009 at 3:29 AM, Adriaan de Groot<[email protected]> wrote:
> Hi Daniel, Mathew,
>
> The confusion seems to be the following:
> - LGPL v. 2.1 is the *Lesser* GPL
> - LGPL v. 2 is the *Library* GPL
>
>
> You can find the texts of these licenses at
> - http://www.gnu.org/licenses/lgpl-2.1.html
> - http://www.gnu.org/licenses/old-licenses/library.html
>
>
> In general, writing "Library GPL v. 2.1" is accepted to mean "Lesser GPL v.
> 2.1". I don't know if there's a consensus on other label+version mix-ups. So
> if your program license headers refer to a version that technically does not
> exist (i.e. Lesser GPL v. 2), as Daniel points out in icns_family.c, there is
> technically a problem, but in practice there is not.
>
> It *is* in the interest of the copyright holders to have consistent licensing
> across the entire library, so it would be good to pick one (either Library v.
> 2 or Lesser v. 2.1) and write that in the headers. If the library portion of
> lcns is intended to be under the Lesser General Public License v. 2.1 (or, at
> your option, any later version) -- and Mathew indicates this in his message --
> it would be best to write that in the headers. That means changing the version
> number in files referring to Lesser to version 2.1, and changing files still
> licensed under the Library General Public License v. 2 (or, at your option,
> any later version) to fall under the Lesser GPL v. 2.1 (or, at your option,
> any later version).
>
> Having one single consistent license text makes things a lot easier both for
> tools, lawyers and others to decide what's going on. Hence the suggestion to
> fix it, but it's not a high priority.
>
> I would suggest the following course of action (not legal advice, just best
> practices):
>
> - ping the developer list saying "The intention is to license under Lesser GPL
> v. 2.1, but the wording is sometimes messy, like 'Library GPL v. 2.1' or
> 'Lesser GPL v. 2'. We should make this text consistent."
> - wait a week or so for anyone to come forward saying they really really meant
> licensing under Library GPL v.2 or later and refuse to re-license.
> - then update the license headers.
>
> Since the intention is clear and the LGPL v. 2.1 is written as a clarification
> of terminology (and adds one clause related to linking) and drop-in successor
> to the LGPL v. 2, this is a straightforward change. Not something to do during
> otherwise hectic development, but good for a quiet time or during freeze
> before a release (and CIA suggests that icns development is pretty quiet).
>
>
> [ade], hoping he didn't make any mistakes in {Lesser,Library} v. {2,2.1}
>
> --
>  []   Adriaan de Groot
> [][][] Freedom Task Force, Free Software Foundation Europe
>  ||   http://blogs.fsfe.org/adridg/
>
> Free Software Foundation Europe e.V. is a German Verein registered at
> the Registergericht Hamburg (VR 17030). Its president is Karsten
> Gerloff. For more information on FSFE, see http://fsfe.org.
>

---------- Forwarded message ----------
From: Mathew Eis <[email protected]>
Date: Mon, Jul 27, 2009 at 3:18 AM
Subject: Re: Inconsistency in License of files in libicns
To: [email protected]
Cc: [email protected]


Hello Daniel,

Thank you for contacting me.

Unfortunately, I am a little confused by the nature of this e-mail,
with the following link being the basis of our licensing for the
library portion of libicns (largely the files that you note to be in
error):

http://www.gnu.org/licenses/lgpl-2.1.html

The above clearly is the Lesser General Public License version 2.1 as
published by GNU themselves, under which the library portion of
libicns is intended to be published. I am a little confused as to why
you say that "there is no Lesser General Public License version 2.1"

Please let me know if there is something which I am misunderstanding,
as I would most certainly be interested in addressing any licensing
issues that libicns may have.

Sincerely,

-Mathew Eis

On Sat, Jul 25, 2009 at 9:41 PM, D M German<[email protected]> wrote:
>
> Dear Mathew,
>
> I am a researcher doing analysis of licenses in Free and Open source
> software, particularly those in Debian.
>
> In recent weeks we have discovered a minor inconsistency in many
> projects and it is present in some of the libicns files authored by
> you.
>
> I have been contacting developers in several FOSS projects to try to
> address it.
>
> This is the license statement from file ./src/icns_family.c
>
>  This library is free software; you can redistribute it and/or 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.
>
>
> As you might know, there is no Lesser General Public License version
> 2.1. its predecessor is the Library General Public License version 2.
>
> Several files in libicns contains the proper reference to the Library
> GPL v2 (or any later version):
>
> ./icnsutils/png2icns.c
> ./icnsutils/icns2png.c
> ./icnsutils/icontainer2icns-v2.c
> ./icnsutils/icontainer2icns.c
>
> But the following files contain the error above:
>
> ./src/icns_debug.c
> ./src/icns_element.c
> ./src/icns_family.c
> ./src/icns_image.c
> ./src/icns_io.c
> ./src/icns_jp2.c
> ./src/icns_rle24.c
> ./src/icns_utils.c
>
> I have asked members of the Freedom Task Force of the Free Software
> Foundation Europe (http://www.fsfe.org/projects/ftf/ftf.en.html, of
> which I am also a member) and they concur that it is in the best
> interest of the copyright owners to fix this issue (even though is
> minor).
>
> thank you,
>
> --daniel
>
> --
> --
> Daniel M. German
> http://turingmachine.org/
> http://silvernegative.com/
> dmg (at) uvic (dot) ca
> replace (at) with @ and (dot) with .
>

Send a report that this bug log contains spam.