Re: LGPL v3 compatibilty (original) (raw)

On Mon, Jul 02, 2007 at 07:52:03PM +0200, Francesco Poli wrote:

On Mon, 2 Jul 2007 12:31:13 -0400 Anthony Towns wrote: [...]

Note that if we do stick to the view we've taken up until now, when we have a LGPLv3 only glibc in the archive, we'll no longer be able to distribute GPLv2-only compiled executables. Unless the GPLv2-only work copyright holder(s) add(s) a special exception, similar to the one needed to link with the OpenSSL library, right?

Well, that's always an option, but where the gpl v2 app can get an exception added, it can also be relicensed under gpl v3 too. Presumably we have a few gpl v2 apps where thast's not going to be an option.

On the other hand, supposing we find a different view that allows GPLv2 apps to make use of the system library exception to link to a hypothetical LGPLv3 glibc. Then we'll have decided there's /a/ way of distributing a library in Debian ("anything that is normally distributed with the major components of the operating system") and an executable that links to that library in Debian, without "that component [the library] itself accompan[ying] the executable". Some possible ways to draw that line might be:

- as long as the executable only uses bog standard functions from the
  library (eg, ANSI C standard functions, but not GNU extensions) 
  it's okay

- as long as the lib is priority: standard or higher, and the executable
  is optional or extra, it's ok

- as long as the lib is in main, and the executable isn't in main, it's
  ok

- as long as the lib and the executable is in different .debs, it's ok

- that clause doesn't hold any meaning or validity at all anymore, so
  it's ok in all circumstances, as long as the library is in main

I would expect the first interpretation there isn't actually useful, but all the others that I can come up with would not only allow GPLv2 apps to use an LGPLv3 glibc, it'd also allow them to link to a CDDL'ed libc (OpenSolaris), a GPLv3'ed libgnutls, or OpenSSL...

If we can avoid the "accompanying the executable" clause in some way as Nexenta have done, with the FSF's apparent blessing, and interpret "normally distributed with the major components of the operating system" to cover everything in main, that means we can use the system library exemption in the GPLv2 to link GPLv2 software to any DFSG-free library. [0]

For GPLv3, the same argument is easier, in that the "accompanying the executable" clause disappears, but also harder because the other text changes a bit. We'd need for the random non-GPLv3 compatible library to be a "System Library" as defined by:

] The "System Libraries" of an executable work include anything, other than ] the work as a whole, that (a) is included in the normal form of packaging ] a Major Component, but which is not part of that Major Component, and (b) ] serves only to enable use of the work with that Major Component, or to ] implement a Standard Interface for which an implementation is available ] to the public in source code form. A "Major Component", in this context, ] means a major essential component (kernel, window system, and so on) of ] the specific operating system (if any) on which the executable work runs, ] or a compiler used to produce the work, or an object code interpreter ] used to run it.

So for libssl to be covered in the "System Libraries" of a GPLv3ed executable work, "it" needs to:

1) be other than the work as a whole
2) be included in the nromal form of packaging a Major Component
3) not be that Major Component
4a) serve only to enable use of the work with that Major Component; or
4b) implement a Standard Interface for which there is an open source
    implementation

If we define "it" as openssl.h, and the Major Component as libssl, then (1), (2), (3), and (4b) seem satisfied to me, with (4a) satisfied as well, unless I'm misunderstanding that subclause.

For libssl to be a Major Component, then libssl has to be:

1a) as major and essential a component of Debian as a window system; or
1b) a compiler used to produce the work; or
1c) an object code interpreter used to run the work

(1b) and (1c) aren't satisfied, but (1a) is, afaics -- libssl is far more major and essential than X on Debian, afaics.

I would expect (1a) to be satisfied for a lot of significant libraries in Debian, such as anything of standard priority or higher, but not all libraries in optional or extra.

Cheers, aj

[0] That would only work for us because we're making a "universal" operating system. It would be difficult to make quite the same argument for Ubuntu, because libraries in universe are distributed separately from the "major components" of the operating system (ie, Ubuntu's main component).

Attachment:signature.asc
Description: Digital signature

Reply to: