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

[DJ D. <dj...@de...>]

Earnie wrote to me:
> Speaking of this, there has been clatter on the MinGW list about this
> very issue.  Paul Sokolovsky has created libstdc++.dll and libgcc.dll
> and as a result of need to distribute those dll's and of course the
> source to build those dll's.   So recommendations about using the static
> versions of those libraries were made just to avoid having to distribute
> those DLL's with source.  I was wondering if you might respond to the
> attached mail?

Sure.  Note that I didn't go read the original thread.  I will respond
with my opinions only to the specific points given below.

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

> 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:

One of the keys of the GPL (I do not refer to the LGPL here) is that
it deals with "works" and not "files".  The LGPL clause above uses the
phrase "creates an executable" in such a way that *I* interpret the
"program" in the first half to mean something that is *not* the final
executable.  I do not believe the FSF intended for dynamic linking to
be considered different from static linking, but that is a gray area
they are working on clarifying in the next rev of the [L]GPL.

IMHO, an executable that requires a DLL to run is not considered a
separate work from that dll, regardless of how many individual files
are involved.  One may argue that "linking" is the process of
resolving symbol references, and linking against a DLL certainly does
that, even though the files aren't merged at that time.

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

> LGPL> If such an object file uses only numerical parameters, data
> LGPL> structure layouts and accessors, and small macros and small inline
> LGPL> functions (ten lines or less in length), then the use of the object
> LGPL> file is unrestricted, regardless of whether it is legally a derivative
> LGPL> work.  (Executables containing this object code plus portions of the
> LGPL> Library will still fall under Section 6.)
> 
> So if headers are plain enough (it is almost always true, possible
> exception is STL, for example), our program, when linked dynamically,
> is still our program, there are no problems with licensing. But when
> linked statically, it always falls under the terms of Section 6.

Yeah, complex headers are another gray area.  STL is definitely
complex.

> Hmm, that's interesting. As we can see, any statically linked program
> falls under the terms of this section. But the question is: does
> dynamically linked program fall under them too?

See above for my take on that.

> LGPL> In addition, mere aggregation of another work not based on the Library
> LGPL> with the Library (or with a work based on the Library) on a volume of
> LGPL> a storage or distribution medium does not bring the other work under
> LGPL> the scope of this License.
> 
> Let's say that we can make an installer that
> 1) installs our program
> 2) gives a choice to install needed libraries' binaries and sources
> (default is to install bins and not to install srcs)
> 
> Now
> 1) our program doesn't fall under the scope of the LGPL
> 2) our distribution doesn't violate LGPL

Any distro that includes sufficient source is OK with the LGPL anyway,
regardless of what the user chooses to install or to not install.  It
is only when the *distributor* keeps the source from the user that the
LGPL is violated.  The user *always* has the freedom to choose what
they want to do or not do with it, but it must be *their* choice.

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

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

> Any statically linked program will fall
> under the terms of section 6. It is quite restrictive, for instance:
> 
> (from section 6)
> LGPL> Accompany the work with the complete corresponding
> LGPL> machine-readable source code for the Library including whatever
> LGPL> changes were used in the work (which must be distributed under
> LGPL> Sections 1 and 2 above); and,

This shouldn't be a problem anyway.

> 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.

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

> So just giving an URL won't work. If we distribute our program on a
> CD-ROM, source code must be available from the same CD-ROM, and so
> on.

Yup.  There are lots of good reasons why, too.