Binary package includes Microsoft binaries

[datallah]

Unless you have some sort of special permission from Microsoft, it's almost certainly not OK to distribute dbghelp.dll and symsrv.dll.

Additionally, using the versions of these not distributed with the system I think is somewhat problematic from a licensing perspective. It's theoretically fine for drmingw itself since it's LGPL, but it means that drmingw/exchndl.dll becomes GPL-incompatible.

[White-Tiger]

non of your points are actually valid...

About distributing them: https://msdn.microsoft.com/en-us/library/windows/desktop/ms679294%28v=vs.85%29.aspx
It makes it quite clear that it is allowed..

And I guess that the GPL question is also invalid.. You can freely use GPL dynamic link libraries, you just can't statically link them. Besides GPL allows you to use non-GPL code IIRC (would be quite stupid if it did not)
Hell, you can even use GPL dlls in non-GPL programs^^ A DLL is never directly part of a program. You can update it, you can replace it, but the program will still work. I wouldn't even consider a statically linked library to be part of a program... ok it's directly build into one binary / program... no easy way to remove, modify, update it... (yet not impossible). And yes.. some compilers might optimize unused functions out of it... but the source wasn't modified though ;)

Also, you don't need to redistribute those dll files.. just omit them and hope that your users got a recent enough version installed...

[datallah]

It looks like you're right about the redistribution of those DLLs (which solves the most significant concern). In that case, I guess all that's missing is is to make it clear what the origin and licensing of those libraries is.

You're not right about the GPL situation though (you may be confusing the LGPL and the GPL). You can neither dynamically link to a GPL library from incompatible code, nor can you dynamically link to an incompatibly licensed library from GPL code - see the GPL FAQ on the matter.

I can dynamically link to the the system dbghelp.dll from GPL code, and thats fine. If the end user ends up deciding to use a non-system version of dbghelp.dll, that's not a problem either (as long as they don't distribute the combination). The problem arises if I link against dbghelp.dll from GPL code and then distribute the non-system version along with with my GPL binary.

So as long as it's clear what the distributed dbghelp.dll and symsrv.dll are and that they're not covered by the same licensing as the rest of the binaries, and they're not necessary for drmingw itself to function, I think the problem goes away.

[jrfonseca]

@White-Tiger, thanks for your reply. It save me a lot of work.

@datallah,

Unless you have some sort of special permission from Microsoft, it's almost certainly not OK to distribute dbghelp.dll and symsrv.dll.

Like it is said on the link that @White-Tiger provided:

"The most current versions of DbgHelp.dll, SymSrv.dll, and SrcSrv.dll are available as a part of the Debugging Tools For Windows package. The redistribution policies for these included DLLs were specifically designed to make it as easy as possible for people to include these files in their own packages and releases."

I honestly can't understand how you could make such a blanket statement like you did. Microsoft makes a lot of closed yet redistributable software.

Furthermore, @datallah , a word of advice for the future: this sort of statements shouldn't be made in public. Thankfully in this case I'm pretty sure I'm in the clear. But legality is not always black and white, and by publicly raising uncertainty about an open-source project legality you can raise the stakes, hence make a huge disservice to project. This sort of matters should always, always, be raised through private e-mails.

Additionally, using the versions of these not distributed with the system I think is somewhat problematic from a licensing perspective. It's theoretically fine for drmingw itself since it's LGPL, but it means that drmingw/exchndl.dll becomes GPL-incompatible.

That depends on whether dbghelp.dll is considered a "system library", or whether Debugging Tools For Windows is a "major component" -- http://www.gnu.org/licenses/gpl-faq.en.html#SystemLibraryException

People can argue either way. Personally I think that dbghelp.dll/symsrv.dll qualifies as a system libraries, be it under GPLv2 or GPLv3, regardless the .dll are pre-installed in the system, or come from Debugging Tools For Windows package. But until the matter is put before a court and a judge decides, nobody can be sure. And I think hell will freeze (or more realistically, the software in question will become obsolete) before anybody will take such a silly matter to court.

So I see no problem in GPL programs to ship these DLLs neither.

To be extra sure, a GPL program author could explicitly state that they consider DbgHelp a system library. Or they could state they don't, and provide an exception http://www.gnu.org/licenses/gpl-faq.en.html#GPLIncompatibleLibs

Of course, GPL programs are welcome to not ship DbgHelp/SymSrv too, as @White-Tiger said. The drawback here is that it will fail to work on older Windows, or not pick up PDB symbols from Microsoft symbol store.

GPL programs are also welcome to not to use DrMingw/ExcHndl/MgwHelp at all. After all, I did my part by making DrMingw/ExcHndl/MgwHelp in a license that can be used by any program, even closed-source ones. I can't help if people use other licenses that are so restrictive that they can't use key third-party components. I don't force anybody to depend on ExcHndl. It's those who do want to depend on ExcHndl/MgwHelp that must make sure they can.

Furthermore, it's arguable whether a program can ever "depends" or be a "derived work" from a JIT debugger like ExcHndl, since it should be able to run fine without it, without any loss of functionality.

Another solution would be for ExcHndl to invoke DrMingw.exe / catchsegv.exe to write the crash report from an outside separate process, so that DbgHelp is never loaded on the main program. This is actually almost trivial to implement, as DrMingw.exe/catchsegv.exe already have all the code to do this. (And in fact, I think some other similar JIT debuggers do similar things.)

[jrfonseca]

So as long as it's clear what the distributed dbghelp.dll and symsrv.dll are and that they're not covered by the same licensing as the rest of the binaries, and they're not necessary for drmingw itself to function, I think the problem goes away.

https://github.com/jrfonseca/drmingw/blob/master/README.md#about has always explicitly mentioned that DbgHelp is used , with a link to the exact same URL that @White-Tiger provided.

From my POV this is more than adequately documented.

I'm closing this issue, and restoring the original title, to make it easier to find for future reference.

[datallah]

It wasn't my intention to ruffle any feathers, just to file a quick ticket get the issue resolved. In retrospect, it would have likely been better to bring up the concern about the redistribution privately - sorry about that.

I guess, while it is clear that DbgHelp is used by the code based on the documentation, it wasn't clear to me that there were differently licensed things was actually distributed alongside the LGPL DLLs. Perhaps I'm overlooking something that makes this clear.

As a longtime user of exchndl, I'm happy with the licensing and all the hard work that's gone into it, please don't misinterpret this as a complaint.

As far as the GPL goes, as you mentioned, it is something of a contentious issue to draw the boundaries of what a "System Library" is, something that certainly is not worth us getting into the details on. Clearly, this isn't directly a problem for the drmingw project, nor should you feel like you have to make that decision.

Would you consider adding a "LICENSE-dbghelp.txt" or something of that nature containing the license.txt from the Debugging Tools for Windows to the binary release?
I think that would help remove any potential confusion or question as to what the licensing of those libraries is.

Thanks and again, apologies for any unnecessary stress.

[jrfonseca]

I still believe the current documentation is adequate.

The licenses included in the DrMingw binaries are there for compliance reasons, not documentation.

To the best of my knowledge, the closest description of how Microsoft intends DbgHelp and SymSrv to be redistributed is https://msdn.microsoft.com/en-us/library/windows/desktop/ms679294.aspx which says

The redistribution policies for these included DLLs were specifically designed to make it as easy as possible for people to include these files in their own packages and releases.

and https://msdn.microsoft.com/en-us/library/windows/desktop/ff805116.aspx which says

When using DbgHelp, the best strategy is to install a copy of the library from the Debugging Tools For Windows package in the application directory logically adjacent to the software that calls it. If Symbol Server and Source Server are also needed, then both SymSrv.dll and SrcSrv.dll must be installed in the same directory as DbgHelp.dll, as DbgHelp will only call these DLLs if they share the same directory with it. (Note that DbgHelp will not call these two DLLs from the standard search path.) This helps prevent the usage of mismatched DLLs; likewise, it also improves security overall."

I see many other open- and closed-source projects abiding by these guidelines.

And the instructions I have on the README echo Microsoft's guidelines, so if an user copies DbgHelp.dll and SymSrv.dll together with ExcHndl.dll and MgwHelp.dll into their application directory they will still be following the guidelines.

So in short, I'm perfectly satisfied with the current state of affairs. If somebody is not, and they want all the fine-print, they are welcome to hire a lawyer, or try to get clarification from Microsoft for the exact terms, or simply not redistribute DbgHelp.dll and SymSrv.dll, and rely on the system's pre-installed version...