Re: ddraw.h, dinput.h and dsound.h in Cygwin/MinGW

Danny Smith wrote:
> From: "Peter Ekberg"
> 
>> Danny, Earnie, why doesn't the LGPL qualify in the w32api package?
> 
> I have nothing against the LGPL.

Great (I didn't intend to imply that you did).

>                          I just don't want a precedent for the
> w32api. So far the w32api has been free of any licensing issues.
> Adding a licensing issue opens the door for more "Well, dinput.h is
> LGPL,  why  can't we add lgpl_foo.h and lgpl_foo.def"

In my world there are two scenarios here:

1. The LGPL is not a problem now and then it should not be a problem
   with a future lgpl_foo.h either.
2. The LGPL is a problem now, and then it will certainly be a problem
   with a future lgpl_foo.h as well.

A future lgpl_foo.def is not an issue now (the DirectX .def files are
already in place), so if a future lgpl_foo.def is the real problem,
simply require that specific future file to have a more relaxed
license.

> Anyways, how does L(=Library)GPL work for interfaces into proprietary,
> closed-source libraries?  It doesn't make a lot of sense to me.

Sorry, I don't have any definite answers to this one.

But consider rephrasing the question like this: How does LGPL work
for interfaces into LGPL reimplementations of proprietary closed-
source libraries? View it as interfacing with the Wine versions
of the DirectX libraries. I mean, why wouldn't you want to support
DirectX apps compiled with MinGW running on Wine? This setup
doesn't (necessarily) involve any proprietary closed-source
libraries.

Then, the LGPL header files may or may not work with some random
proprietary closed-source library. When it does happen to work, it
must surely be an extremely unlikely set of coincidences...

(nitpick, L=Library was changed into L=Lesser in v2.1 of the LGPL)

Cheers,
Peter