[rtmpdump] Link OpenSSL statically for Win32

[David Woodhouse]

On Mon, 2010-04-19 at 22:21 +0930, Stef wrote:
> On 19/04/2010 8:53 PM, David Woodhouse wrote:
> > On Mon, 2010-04-19 at 20:15 +0930, Stef wrote:
> >    
> >> Unfortunately, "hashswf.c" and "rtmp.c"  in the "librtmp" use the
> >> OpenSSL stuff too, don't they?  So that puts a damper on anything
> >> using the librtmp library as well unless it's built to use the dynamic
> >> DLL.
> >>      
> > Those files are licensed under LGPL, not GPL. So there is no problem
> > with linking to OpenSSL.
> >
> > But still, as I said, they can be built to use GnuTLS instead of
> > OpenSSL. And then _even_ the GPL-licensed tools like rtmpdump can be
> > statically linked quite happily.
> >
> >    
> Agreed.
> 
> Howard should put a note in the README/COPYING pointing out the issue 
> with distributing Windows (Mac too?) versions of rtmpdump and 
> static-built OpenSSL.  E.g: It can only be re-distributed as long as the 
> executable is built to use the OpenSSL dynamic-link-libs (personal use 
> is fine with static-built OpenSSL) or GnuTLS (static or dynamic).

That might be wise. Would you care to suggest that again, in 'diff -up'
form?

It isn't really an issue on Mac -- there's a dynamic OpenSSL library on
Mac OS as part of the default install, so you can just ship rtmpdump
linked against that and everybody's happy.
  
> Either that or drop OpenSSL entirely and just use GnuTLS exclusively.

There are people who will still want to use OpenSSL for their local
builds. Didn't somebody say only last night that it was easier to build
OpenSSL on Windows than it is to build GnuTLS?

(Although if we can ship fully-functional binaries for the majority of
Windows users, perhaps that becomes less of an issue?)

-- 
dwmw2