On Wed, 2005-01-12 at 10:41 -0500, John Ehresman wrote: > Tor Lillqvist wrote: > > Also, as the MSVCR7*.DLL are not part of the operating system like > > MSVCRT.DLL, it's against the (L)GPL to distribute (L)GPL software that > > would use MSVCR7*.DLL. (I am not a lawyer, but this seems to be the > > common interpretation of the situation.) Thus, now and in the > > foreseeable future, (L)GPL software for Windows should continue to use > > MSVCRT.DLL. The actual language of the operating system exception in the GPL is: : 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 components (compiler, kernel, and so on) : of the operating system on which the executable runs, unless that : component itself accompanies the executable. Which might possibly provide an out for MSVCR7*.DLL ... since they accompany the (most commonly used) compiler. I suspect what was being thought of was static linking to libraries provided with the compiler, but it could conceivably be stretched to cover this as well. > IANAL, but isn't the situation different w/ GPL v the LGPL? LGPL allows > linking with non-opensource components. It's not a clear issue, but the language in section 5 of the LGPL is specifically about "A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it". My interpretation is that the provisions for distributing a LGPL library linked against a proprietary library are pretty much identical to those for distributing a GPL application linked against a proprietary library. My personal, non-legal, non-binding, opinion is that I wouldn't be comfortable distributing a version of GTK+ modified to depend upon a proprietary library unless that proprietary library is covered by the GPL system exception. If no modification to GTK+ is necessary, and the library being linked to is simply a reimplementation of an existing API, I'm a lot more comfortable with it, even though that probably doesn't affect the legal situation. Microsoft redistributables such as GDI+ are probably close enough to being part of the operating system to pass the GPL system exception, even if they weren't distributed with the particular version that the user is rnuning on. > > I strongly advice people who might still insist on building GLib, GTK+ > > etc themselves with MSVC 7.* and to use MSVCR7*.DLL to use different > > names for their DLLs, to avoid confusion. The "standard" DLL names > > that a mingw build produces should be used only for DLLs that use > > MSVCRT.DLL. Otherwise there will be no end of confusion if and when > > there starts to appear various distributions of GTK+ etc built to use > > different C runtimes but using the same DLL names. > > Yes, the names should be changed. Note that this situation is almost > certainly going to become more common as more software will be built > using MSVC 7+. I wonder if we need a "GTK+ Win32 binary API test app" ... some standard .exe to download from gtk.org to check your library build. Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part