Re: [Mingw-users] Re: License, -mno-cygwin

[Ikm <ik...@on...>]

Friday, May 18, 2001, 12:47:52 AM, you wrote:

Hope you don't mind if I respond...

DD> The topic over in cygwin-land was that the C++ libraries gcc uses
DD> (libgcc, libstdc++) may be used in 100% proprietary programs, provided
DD> those programs were compiled and linked with gcc.  This is an
DD> exception to the LGPL that libgcc and libstdc++ allow.  That exception
DD> may make your entire thread moot, if the libraries in question are
DD> libgcc and/or libstdc++.

If these libraries are distributed with such an exception, it sure may.

>> LGPL> A program that contains no derivative of any portion of the
>> LGPL> Library, but is designed to work with the Library by being compiled or
>> LGPL> linked with it, is called a "work that uses the Library".  Such a
>> LGPL> work, in isolation, is not a derivative work of the Library, and
>> LGPL> therefore falls outside the scope of this License.
>> LGPL> However, linking a "work that uses the Library" with the Library
>> LGPL> creates an executable that is a derivative of the Library (because it
>> LGPL> contains portions of the Library), rather than a "work that uses the
>> LGPL> library".  The executable is therefore covered by this License.
>> LGPL> Section 6 states terms for distribution of such executables.
>> 
>> It says that our program is our program, but only without the library
>> it uses. But if it is linked *statically*, it is a derivative (it
>> contains pieces of code from the library). However, if we link
>> dynamically, our program doesn't contain them (it only contains
>> references to them). We shouldn't forget, however, that our program,
>> either linked statically or dynamically, also uses material from
>> library's header file:

DD> One of the keys of the GPL (I do not refer to the LGPL here) is that
DD> it deals with "works" and not "files".  The LGPL clause above uses the
DD> phrase "creates an executable" in such a way that *I* interpret the
DD> "program" in the first half to mean something that is *not* the final
DD> executable.

It isn't a straightforward interpretation. License states about an
"executable" containing parts of the "library". Executable that uses
dll doesn't contain them, only headers' info (and such fact doesn't
put any restrictions as long as that headers are plain enough).

DD>   I do not believe the FSF intended for dynamic linking to
DD> be considered different from static linking, but that is a gray area
DD> they are working on clarifying in the next rev of the [L]GPL.

But as far as I can understand they are implicitly considered different
in the current version of the license.

DD> IMHO, an executable that requires a DLL to run is not considered a
DD> separate work from that dll, regardless of how many individual files
DD> are involved.

Such executable is a separate work. But it doesn't really work. But still it is
a separate work ;)

Ok, if to talk seriously, here, the same piece:

>> LGPL> A program that contains no derivative of any portion of the
>> LGPL> Library, but is designed to work with the Library by being compiled or
>> LGPL> linked with it, is called a "work that uses the Library".  Such a
>> LGPL> work, in isolation, is not a derivative work of the Library, and
>> LGPL> therefore falls outside the scope of this License.

 (***)

License says it *is* a separate work. Even if .dll is required in
order to execute. (Program is designed to work with the Library by
being linked with it. Dynamic linking is still just linking. The only
difference that it is physically done by user's system, not by vendor,
who only puts refs needed to perform it)

DD>   One may argue that "linking" is the process of
DD> resolving symbol references, and linking against a DLL certainly does
DD> that, even though the files aren't merged at that time.

But such linking is always done by the end-user (every time he runs the program).
Imagine vedor distributing separate executable under it's own license,
and also distributing required LGPL libraries under LGPL on the same distribution
medium. I think such behaviour doesn't violate anything.

DD> IMHO an executable that will run without that dll, but may use that
DD> dll if it is present, would be a separate work.

Refer to the piece (***) above.

>> So, when we make a decision about the way of linking, the answer is:
>> we should link dynamically.

DD> Well, technical and support issues may be a more important issue than
DD> legal issues sometimes, especially when the user has two different
DD> versions of the same dll on their system.

Ah, of course. To resolve such conflict, for instance, we can give choice to
install required dlls to the program's destination folder only (rather
than to win\system).
Or we can link statically. But it is still pain.

>> LGPL clearly states that end-user *must* have the ability to modify
>> the library and use our program with the modified version. If we link
>> statically, we will have to provide all the stuff needed to relink (at
>> least all our .o files and scripts), that's painful.

DD> Or at least one big .o of everything but the library, perhaps even
DD> with resolved symbols stripped, ready for that one final link step.
DD> For all intents and purposes, that one big .o is as proprietary as a
DD> proprietary executable gets.  Note: Cabletron ships their Spectrum
DD> product this way! (not because of the gpl, but for technical reasons).

But when we link dynamically, we don't have to waste time doing it.

Of course, all this isn't necessarily relevant in case of libs that
are not purely LGPLed. For instance, if libstdc++ and others really
give such a nice linking exception mentioned at the top of the letter,
it is much easier just to link against them statically.

-- 
Konstantin Isakov