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