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

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

[Marco Costalba]

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 !

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

[Daniel Barkalow]

On Thu, 27 Dec 2007, Marco Costalba wrote:

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

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*

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

[Abdelrazak Younes]

Daniel Barkalow wrote:
> On Thu, 27 Dec 2007, Marco Costalba wrote:
> 
>> Packaged together with qgit.exe there are the necessary Micorsoft
>> Visual C dll's. Is this a problem for someone?

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

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

Yes, MSVC dlls are redistributable.

> I'd actually be more concerned about whether you can (or should) 
> distribute GPL code compiled with a proprietary compiler;

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.

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

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

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

Well said :-)

Abdel.

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

[Daniel Barkalow]

On Fri, 28 Dec 2007, Abdelrazak Younes wrote:

> Daniel Barkalow wrote:
> > On Thu, 27 Dec 2007, Marco Costalba wrote:
> > 
> > > Packaged together with qgit.exe there are the necessary Micorsoft
> > > Visual C dll's. Is this a problem for someone?
> 
> My two cents below; I hope you don't mind my interference.

Not at all.

> > I'd actually be more concerned about whether you can (or should) distribute
> > GPL code compiled with a proprietary compiler;
> 
> 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.

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.

> > 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.
> 
> This particular tool is free (as in beer) to download and use.

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*

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

[Marco Costalba]

On Dec 28, 2007 1:05 AM, Daniel Barkalow <barkalow@iabervon.org> wrote:
>
> 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).
>

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