Re: [Mingw-users] Success building GCC 4.5.2 using only the msvcr100.dll runtime

[Charles W. <cwi...@us...>]

On 5/15/2011 2:54 PM, Khalid wrote:
> My understanding (and do feel free to correct me) is if one considers MinGW's
> current act of distributing the shared libraries (libgcc_s_dw2-1.dll, and
> libstdc++-6.dll that rely on the msvcrt.dll) NOT a violation of Microsoft's
> EULA, then how can distributing JUST the SAME shared libraries (albeit ones that
> rely on "MSVCR{7,8,9,10}x.DLL") be any different? MinGW is not actually
> distributing the runtimes in either case.

I believe the distinction has to do with

1) whether we're talking about the GPLv2 or the GPLv3, and
2) whether the DLL is "part of the operating system" -- in the legal
sense, which is more than just "hey, it was installed on my computer by
default".

This all hinges on whether we, as a distributor, are required to provide
source code for a specific DLL.  Obviously in the case of these MS
runtimes, we do NOT have the source code -- so we cannot distribute
source we don't have.  If other license language REQUIRES us to
distribute it, as a consequence of distributing our product (e.g. your
libstdc++-6.dll, or some .exe), then...since we can't comply with that
requirement, we therefore cannot distribute the product.

First principle: if you ship an exe, and that exe is GPL, then you must
provide source code not just for it, but also for every DLL it links
directly against (dlopen()/LoadLibrary() is a murky area).  Obviously
this is impossible for operating system libraries -- whether that
operating system is Solaris or Irix or Windows.

So, second principle: both the GPLv2 and GPLv3 have "exceptions" to this
rule. With the GPLv2, the exception is if the DLL in question is "part
of the operating system".   So, if the dll IS "part of the operating
system" then we don't have to distribute its source code, and we are
then able to comply with the GPLv2 requirements for our application.
Thus, we can distribute the exe with an easy conscience.

msvcrt.dll is "part of the operating system", and has been declared so
by Microsoft themselves (link?).  We have generally asserted that the
various msvcr##.dll runtimes are NOT -- and this appears to be the
position of both MS themselves, and of the FSF, which explains why the
exception language was revised for:


With the GPLv3 the exception is if the DLL in question is a "System
Library" -- which the GPLv3 explicitly defines (emphasis added):

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

Under this definition, the msvcr##.dll runtimes are "System Libraries"
and thus, fall under the exception -- but only for (L)GPLv3 software,
NOT (L)GPLv2!

> Remember we are setting the GPL concerns aside of the sake of the argument.

No, we're not doing that.  gcc ITSELF is under the GPL -- that's the
point.  libstdc++6.dll ITSELF is under the GPL (with certain
exceptions).  Ditto libgcc_s-dw2-1.dll.  That's kindof the whole point
here: CAN we distribute the following:

	gcc.exe
	libgcc_s-dw2-1.dll
	libstdc++6.dll

binaries, if they are directly linked to an element -- msvcr*100.dll --
for which we do not have access to the source code?  The answer appears
to be:

1) NO, if the GPLv2 is used, since msvcr##.dll is not a "part of the
operating system"
2) YES, if the GPLv3 is used, since msvcr##.dll is a "System Library"



Then, there's the DEEPER question about our end users -- who are
software developers, using our gcc: they are going to WANT to ship to
THEIR users WORKING software.

Which means, like "professional" software built using Visual Studio and
packaged via the MS installer, they will want to include redist.exe in
their installer.  That way, their end users will have a point-n-click
"professional" way of installing WORKING software.

But to do so, if they use our (mingw.org) compiler, would be a violation
of the redist.exe EULA -- since that only allows redistribution if they
had a valid Visual Studio license (not Express), AND maybe even if the
software product was itself actually BUILT with Visual Studio (not sure
about that part; **maybe** you could buy a VS license simply to have the
right to distribute redist.exe for software you built using this special
gcc.  But -- even if it were legal to do so -- why would you?  As much
of a free-software and gcc fan as I am, I'd have a hard time selling
this to Corporate management..."why not just use the compiler we paid
for?" ).


An enterprising scum sucker might be able to make the argument that we
were *encouraging* our users to do this, simply by providing a compiler
that required the msvcr##.dll runtime instead of the msvcrt.dll one.
Napster, anyone?

> Consider this situation. If Python (which seems to own a proper VS license)
> installs MSVCR90.DLL in some developer's computer then why should the same
> developer not link her code and shared libraries with the same runtime to ensure
> proper functioning of her work? If she is not redistributing the runtime herself
> and it is there already installed (or will be installed somewhere else) then how
> does that violate the Microsoft EULA? 

Ah, but you are missing the crucial difference: software for a
interpreter ALWAYS requires that interpreter.  SO, the windows port of
hg requires the user (separately?) d/l and install python -- and it's
the python guys who are on the hook for making sure the necessary ms
runtime DLLs are installed.  And, as you have posited, they have a
license for redist.exe so they're covered.  The hg folks don't even need
to worry about it.

We, on the other hand, ship a *compiler* for *binary* products. (And
you're even suggesting that the compiler ITSELF might depend on
msvcr##.dll for execution).  Now, under the GPLv3, but not GPLv2, this
appears to be ok -- so long as we do NOT ship redist.exe ourselves.

But that means (a) our stuff is broken OOB unless the user takes a
second step, and (b) anything they build is ALSO broken OOB unless THEIR
users take a second step, OR unless our users violate the redist.exe
EULA and ship it with their product to their users.  And, also arguably
-- by some dishonest hack of a scum sucking legal beagle -- we'd be
implicitly encouraging that latter behavior.

> It seems to me (and I could be mistaken) that the GPL could be the only obstacle
> here. And some would say that this is truly the sad thing.

No, it's not the GPL's "fault".  It's the fact that you want to use a
proprietary runtime library with free-as-in-speech software, or you want
to encourage our compiler's users to ship software to THEIR users that
requires a proprietary runtime library.

The GPL was not written to make it easy to do that.  It was written to
promote the spread of Free (as in speech) software.  If that's a
problem, then perhaps you should avoid software licensed under it.  Of
course, that's a LOT of software, including gcc (which just goes to show
the licensing strategy has been VERY effective in achieving its goal!)

Since mingw.org's entire purpose is to provide a port of the GPLed gcc
compiler for windows...maybe you should look at other compilers instead?
 There are "open source" compilers out there that support windows and
aren't GPL, after all...google is your friend.

Aside: In real life, I'm not as much of a GPL fanatic as the above
implies, BUT...mingw.org is nothing if not a win32 port of gcc, and gcc
IS gpl, so...

--
Chuck