{"thread":{"id":"11408","subject":"[RFC] Distributing Windows binary package compiled with non gpl code","startedAt":"2007-12-27T18:32:09Z","lastAt":"2007-12-28T08:17:30Z","messageCount":5,"participants":["Marco Costalba","Daniel Barkalow","Abdelrazak Younes"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"64124","messageId":"e5bfff550712271032q25d135e7y47d68337e937d401@mail.gmail.com","threadId":"11408","inReplyTo":null,"subject":"[RFC] Distributing Windows binary package compiled with non gpl code","fromName":"Marco Costalba","fromEmail":"mcostalba-re5jqeeqqe8avxtiumwx3w@public.gmane.org","sentAt":"2007-12-27T18:32:09Z","receivedAt":"2007-12-27T18:32:09Z","isPatch":false,"sender":{"key":"mcostalba-re5jqeeqqe8avxtiumwx3w@public.gmane.org","avatar":null},"body":"\nIt seems I have finally worked out a binary installation of qgit under Windows:\n\nhttp://digilander.libero.it/mcostalba/qgit2.1rc1_win.exe\n\n\nIt seems to work with msysgit distribution of git. It DOES NOT work as\nexpected with Cygwin git that IMHO is very broken for qgit. I ended up\ngiving the blame to mingw, but after testing the MSVC compiled qgit\nboth with msysgit and cygwin git I have to say that the problem\n*probably* is not in mingw but in cygwin.\n\nAnyhow the MSVC 2008 compiled qgit seems stable and works as\nadvertised. Now that's the question:\n\nPackaged together with qgit.exe there are the necessary Micorsoft\nVisual C dll's. Is this a problem for someone?\n\nI could try to compile again everything with mingw and test if under\nmsysgit the artifacts that appear with cygwin are fixed, if this\nsucceed I could prepare a binary package built with mingw and\ndistribute this instead, but would be this necessary?\n\n\nqgit is GPL and I for sure want to be stick to GPL, so I don't know if\nthis can be an issue.\n\n\nThanks for help me in clarifing this point\n\nMarco\n\n\nP.S: Just to be fair I have to say that developing under Windows with\nMSVC is much easier, because the debugging tools available with MSVC\n2008 are very advanced and powerful, nothing similar exists _for\nWindow_ in the GPL camp. Indeed MSVC (together with SQL Server) are\n(the only) two good products from MS, so good that even do not seem\nproduced by Microsoft !\n"},{"id":"64126","messageId":"alpine.LNX.1.00.0712271647130.13593@iabervon.org","threadId":"11408","inReplyTo":"e5bfff550712271032q25d135e7y47d68337e937d401@mail.gmail.com","subject":"Re: [RFC] Distributing Windows binary package compiled with non gpl code","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-12-27T22:08:04Z","receivedAt":"2007-12-27T22:08:04Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 27 Dec 2007, Marco Costalba wrote:\n\n> Packaged together with qgit.exe there are the necessary Micorsoft\n> Visual C dll's. Is this a problem for someone?\n\nIt depends on how they're packaged together. If it's possible to unpack \nthem (into a bunch of separate files, where each is either all GPL or no \nGPL), then this is \"mere aggregation\" and perfectly fine (assuming you're \nallowed to distribute the Visual C dlls, of course). IIRC, bundled \nlibraries for Windows programs are stored on the user's disk as separate \nfiles anyway, so this is automatically okay.\n\nI'd actually be more concerned about whether you can (or should) \ndistribute GPL code compiled with a proprietary compiler; people who get \nthe binaries and the source still couldn't edit the source and generate a \ncorresponding binary, because they don't necessarily have the build \nenvironment you used. On the other hand, nothing you could do differently \nwould be any better for anyone with the right to complain, so it shouldn't \nbe an issue in practice. (And a user of qgit for Windows is more likely \nthan usual to have MSVC anyway)\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"64132","messageId":"fl1bcn$k2h$1@ger.gmane.org","threadId":"11408","inReplyTo":"alpine.LNX.1.00.0712271647130.13593@iabervon.org","subject":"Re: [RFC] Distributing Windows binary package compiled with non gpl code","fromName":"Abdelrazak Younes","fromEmail":"younes.a@free.fr","sentAt":"2007-12-27T23:10:08Z","receivedAt":"2007-12-27T23:10:08Z","isPatch":false,"sender":{"key":"younes.a@free.fr","avatar":null},"body":"Daniel Barkalow wrote:\n> On Thu, 27 Dec 2007, Marco Costalba wrote:\n> \n>> Packaged together with qgit.exe there are the necessary Micorsoft\n>> Visual C dll's. Is this a problem for someone?\n\nMy two cents below; I hope you don't mind my interference.\n\n> \n> It depends on how they're packaged together. If it's possible to unpack \n> them (into a bunch of separate files, where each is either all GPL or no \n> GPL), then this is \"mere aggregation\" and perfectly fine (assuming you're \n> allowed to distribute the Visual C dlls, of course). IIRC, bundled \n> libraries for Windows programs are stored on the user's disk as separate \n> files anyway, so this is automatically okay.\n\nYes, MSVC dlls are redistributable.\n\n> I'd actually be more concerned about whether you can (or should) \n> distribute GPL code compiled with a proprietary compiler;\n\nThis is the exact same situation as with other proprietary platforms \n(Solaris, HPUx, etc). You should not make a difference for Windows IMHO. \nBesides, many open source projects have no problem at all with MSVC.\n\n> people who get \n> the binaries and the source still couldn't edit the source and generate a \n> corresponding binary, because they don't necessarily have the build \n> environment you used.\n\nThis particular tool is free (as in beer) to download and use.\n\n> On the other hand, nothing you could do differently \n> would be any better for anyone with the right to complain, so it shouldn't \n> be an issue in practice. (And a user of qgit for Windows is more likely \n> than usual to have MSVC anyway)\n\nWell said :-)\n\nAbdel.\n"},{"id":"64134","messageId":"alpine.LNX.1.00.0712271846380.13593@iabervon.org","threadId":"11408","inReplyTo":"fl1bcn$k2h$1@ger.gmane.org","subject":"Re: [RFC] Distributing Windows binary package compiled with non gpl code","fromName":"Daniel Barkalow","fromEmail":"barkalow-o/mkjedno/bg9huczpvpmw@public.gmane.org","sentAt":"2007-12-28T00:05:00Z","receivedAt":"2007-12-28T00:05:00Z","isPatch":false,"sender":{"key":"barkalow-o/mkjedno/bg9huczpvpmw@public.gmane.org","avatar":null},"body":"\nOn Fri, 28 Dec 2007, Abdelrazak Younes wrote:\n\n> Daniel Barkalow wrote:\n> > On Thu, 27 Dec 2007, Marco Costalba wrote:\n> > \n> > > Packaged together with qgit.exe there are the necessary Micorsoft\n> > > Visual C dll's. Is this a problem for someone?\n> \n> My two cents below; I hope you don't mind my interference.\n\nNot at all.\n\n> > I'd actually be more concerned about whether you can (or should) distribute\n> > GPL code compiled with a proprietary compiler;\n> \n> This is the exact same situation as with other proprietary platforms (Solaris,\n> HPUx, etc). You should not make a difference for Windows IMHO. Besides, many\n> open source projects have no problem at all with MSVC.\n\nThe difference I see is that the project's build system can use the system \ntoolchain without caring whether it's a proprietary one or an open source \none. That is, you can call $CC or $LD based on the interface standard, and \nit doesn't fundamentally matter whether you've got a proprietary compiler \nor not (of course, you'll get a different result, but that's true of \ndifferent compiler versions anyway, and build timestamps and machine and \nuser name will be different, etc). MSVC's build system interface is \nparticular to itself.\n\n> > people who get the binaries and the source still couldn't edit the source\n> > and generate a corresponding binary, because they don't necessarily have the\n> > build environment you used.\n> \n> This particular tool is free (as in beer) to download and use.\n\nIt probably actually falls under the \"system software\" exception, in that \ncase (when distributing source, you have to include everything needed to \nbuild the source, except for normal system software, which you can assume \nthe recipient has).\n\nIn any case, not an actual problem; it's just that distributing \nside-by-side (the original question) is even more clearly not a problem, \nin my opinion.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"64139","messageId":"e5bfff550712280017m6d2b228bne1db05bd54fefd48@mail.gmail.com","threadId":"11408","inReplyTo":"alpine.LNX.1.00.0712271846380.13593@iabervon.org","subject":"Re: [RFC] Distributing Windows binary package compiled with non gpl code","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-12-28T08:17:30Z","receivedAt":"2007-12-28T08:17:30Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On Dec 28, 2007 1:05 AM, Daniel Barkalow <barkalow@iabervon.org> wrote:\n>\n> It probably actually falls under the \"system software\" exception, in that\n> case (when distributing source, you have to include everything needed to\n> build the source, except for normal system software, which you can assume\n> the recipient has).\n>\n\nReading the GPL FAQ at www.gnu.org I have come up with following\nclarifications that IMO apply to this case:\n\n\nhttp://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL\n-------------------------------------------------------------------------------------------------\n\nQ: I'm writing a Windows application with Microsoft Visual C++ (or\nVisual Basic) and I will be releasing it under the GPL. Is dynamically\nlinking my program with the Visual C++ (or Visual Basic) run-time\nlibrary permitted under the GPL?\n\n\nA: The GPL permits this because that run-time library normally\naccompanies the compiler or interpreter you are using. So it falls\nunder the exception in GPL section 3.\n\n   That doesn't mean it is a good idea to write the program so that it\nonly runs on Windows. Doing so results in a program that is free\nsoftware but \"trapped\" (in this case, trapped by Windows instead of by\nJava, but the effect is the same). (Historical note: As of December\n2006 Sun is in the middle of rereleasing its Java platform under GNU\nGPL.)\n\n\n\n\nhttp://www.gnu.org/licenses/gpl-faq.html#GPLCompatInstaller\n-----------------------------------------------------------------------------------------\n\nQ: I would like to bundle GPLed software with some sort of\ninstallation software. Does that installer need to have a\nGPL-compatible license?\n\nA: No. The installer and the files it installs are separate works. As\na result, the terms of the GPL do not apply to the installation\nsoftware.\n\n\n\n\nhttp://www.gnu.org/licenses/gpl-faq.html#NonFreeTools\n--------------------------------------------------------------------------------\n\nQ: Can I release a program under the GPL which I developed using non-free tools?\n\nA: Which programs you used to edit the source code, or to compile it,\nor study it, or record it, usually makes no difference for issues\nconcerning the licensing of that source code.\n\n    However, if you link non-free libraries with the source code, that\nwould be an issue you need to deal with. It does not preclude\nreleasing the source code under the GPL, but if the libraries don't\nfit under the \"system library\" exception, you should affix an explicit\nnotice giving permission to link your program with them. The FSF can\ngive you advice on doing this.\n\n\n\nhttp://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs\n------------------------------------------------------------------------------------------\n\nQ: What legal issues come up if I use GPL-incompatible libraries with\nGPL software?\n\nA: If the libraries that you link with fall within the following\nexception in the GPL:\n\n \"However, as a special exception, the source code distributed need\nnot include anything that is normally distributed (in either source or\nbinary form) with the major components (compiler, kernel, and so on)\nof the operating system on which the executable runs, unless that\ncomponent itself accompanies the executable.\"\n\n    then you don't have to do anything special to use them; the\nrequirement to distribute source code for the whole program does not\ninclude those libraries, even if you distribute a linked executable\ncontaining them. Thus, if the libraries you need come with major parts\nof a proprietary operating system, the GPL says people can link your\nprogram with them without any conditions.\n\n\n\n\n\n\nThe last FAQ is not very clear IMHO because the rule says \"unless that\ncomponent itself accompanies the executable\" (as is the case with my\ndistributed dll) but after the explanation says \"the requirement to\ndistribute source code for the whole program does not include those\nlibraries, even if you distribute a linked executable containing them\"\n\n\nMarco\n"}]}