[RFC] Distributing Windows binary package compiled with non gpl code

It seems I have finally worked out a binary installation of qgit under Windows:

http://digilander.libero.it/mcostalba/qgit2.1rc1_win.exe

It seems to work with msysgit distribution of git. It DOES NOT work as expected with Cygwin git that IMHO is very broken for qgit. I ended up giving the blame to mingw, but after testing the MSVC compiled qgit both with msysgit and cygwin git I have to say that the problem *probably* is not in mingw but in cygwin.

Anyhow the MSVC 2008 compiled qgit seems stable and works as advertised. Now that's the question:

Packaged together with qgit.exe there are the necessary Micorsoft Visual C dll's. Is this a problem for someone?

I could try to compile again everything with mingw and test if under msysgit the artifacts that appear with cygwin are fixed, if this succeed I could prepare a binary package built with mingw and distribute this instead, but would be this necessary?

qgit is GPL and I for sure want to be stick to GPL, so I don't know if this can be an issue.

Thanks for help me in clarifing this point

Marco

P.S: Just to be fair I have to say that developing under Windows with MSVC is much easier, because the debugging tools available with MSVC 2008 are very advanced and powerful, nothing similar exists _for Window_ in the GPL camp. Indeed MSVC (together with SQL Server) are (the only) two good products from MS, so good that even do not seem produced by Microsoft !

On Thu, 27 Dec 2007, Marco Costalba wrote:

It depends on how they're packaged together. If it's possible to unpack them (into a bunch of separate files, where each is either all GPL or no GPL), then this is "mere aggregation" and perfectly fine (assuming you're allowed to distribute the Visual C dlls, of course). IIRC, bundled libraries for Windows programs are stored on the user's disk as separate files anyway, so this is automatically okay.

I'd actually be more concerned about whether you can (or should) distribute GPL code compiled with a proprietary compiler; people who get the binaries and the source still couldn't edit the source and generate a corresponding binary, because they don't necessarily have the build environment you used. On the other hand, nothing you could do differently would be any better for anyone with the right to complain, so it shouldn't be an issue in practice. (And a user of qgit for Windows is more likely than usual to have MSVC anyway)

	-Daniel
*This .sig left intentionally blank*

Daniel Barkalow wrote:

My two cents below; I hope you don't mind my interference.

Yes, MSVC dlls are redistributable.

This is the exact same situation as with other proprietary platforms (Solaris, HPUx, etc). You should not make a difference for Windows IMHO. Besides, many open source projects have no problem at all with MSVC.

This particular tool is free (as in beer) to download and use.

Well said :-)

Abdel.

On Fri, 28 Dec 2007, Abdelrazak Younes wrote:

Not at all.

The difference I see is that the project's build system can use the system toolchain without caring whether it's a proprietary one or an open source one. That is, you can call $CC or $LD based on the interface standard, and it doesn't fundamentally matter whether you've got a proprietary compiler or not (of course, you'll get a different result, but that's true of different compiler versions anyway, and build timestamps and machine and user name will be different, etc). MSVC's build system interface is particular to itself.

It probably actually falls under the "system software" exception, in that case (when distributing source, you have to include everything needed to build the source, except for normal system software, which you can assume the recipient has).

In any case, not an actual problem; it's just that distributing side-by-side (the original question) is even more clearly not a problem, in my opinion.

	-Daniel
*This .sig left intentionally blank*

On Dec 28, 2007 1:05 AM, Daniel Barkalow <barkalow@iabervon.org> wrote:

Reading the GPL FAQ at www.gnu.org I have come up with following clarifications that IMO apply to this case:

http://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL -------------------------------------------------------------------------------------------------

Q: I'm writing a Windows application with Microsoft Visual C++ (or
Visual Basic) and I will be releasing it under the GPL. Is dynamically
linking my program with the Visual C++ (or Visual Basic) run-time
library permitted under the GPL?

A: The GPL permits this because that run-time library normally
accompanies the compiler or interpreter you are using. So it falls
under the exception in GPL section 3.

   That doesn't mean it is a good idea to write the program so that it
only runs on Windows. Doing so results in a program that is free
software but "trapped" (in this case, trapped by Windows instead of by
Java, but the effect is the same). (Historical note: As of December
2006 Sun is in the middle of rereleasing its Java platform under GNU
GPL.)

http://www.gnu.org/licenses/gpl-faq.html#GPLCompatInstaller -----------------------------------------------------------------------------------------

Q: I would like to bundle GPLed software with some sort of
installation software. Does that installer need to have a
GPL-compatible license?

A: No. The installer and the files it installs are separate works. As
a result, the terms of the GPL do not apply to the installation
software.

http://www.gnu.org/licenses/gpl-faq.html#NonFreeTools --------------------------------------------------------------------------------

Q: Can I release a program under the GPL which I developed using non-free tools?

A: Which programs you used to edit the source code, or to compile it,
or study it, or record it, usually makes no difference for issues
concerning the licensing of that source code.

    However, if you link non-free libraries with the source code, that
would be an issue you need to deal with. It does not preclude
releasing the source code under the GPL, but if the libraries don't
fit under the "system library" exception, you should affix an explicit
notice giving permission to link your program with them. The FSF can
give you advice on doing this.

http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs ------------------------------------------------------------------------------------------

Q: What legal issues come up if I use GPL-incompatible libraries with
GPL software?

A: If the libraries that you link with fall within the following
exception in the GPL:

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

    then you don't have to do anything special to use them; the
requirement to distribute source code for the whole program does not
include those libraries, even if you distribute a linked executable
containing them. Thus, if the libraries you need come with major parts
of a proprietary operating system, the GPL says people can link your
program with them without any conditions.

The last FAQ is not very clear IMHO because the rule says "unless that component itself accompanies the executable" (as is the case with my distributed dll) but after the explanation says "the requirement to distribute source code for the whole program does not include those libraries, even if you distribute a linked executable containing them"

Marco