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

"Peter Ekberg" <[email protected]> Thu, 30 Sep 2004 14:16:14 +0200
Newsgroups gmane.comp.emulators.wine.license
Message-ID <[email protected]>
Earnie Boyd wrote:
> Peter Ekberg wrote:
>> There is a world of difference between the GPL and the LGPL.
>
> Only for the use of the binary form.  For the source it is
> exactly as if it were GPL.

True, but why is this an issue? See below.

>> With the LGPL you differentiate between works that /use/ and
>> works /based/ on the LGPL code. Applications/libraries compiled
>> against w32api is /using/ it, they're not /based/ on it. And
>> because the content of the header files in question fall into
>> this category listed in the LGPL: "numerical parameters, data
>> structure layouts and accessors, and small macros and small
>> inline functions (ten lines or less in length)", these
>> apps/libs that are /using/ the headers are "unrestricted,
>> regardless of whether it is legally a derivative work"
> 
> If this were true then why do the libstdc++ maintainers need
> to put in a specific wording to modify the LGPL to allow my
> use in proprietary software?

I don't know for sure, but a quick check reveals that the stl
headers are packed with inline template functions larger than
the mentioned 10 lines. Their FAQ also indicates that this is
the reason for their "runtime exception."

>          Headers are source, and including those headers in
> my source are considered a modified work based on the original.

Well, yes if by including them, you mean copying them into your
source (so yes, the w32api itself will be a derivative work
based on Wine). But NO, if you by including them mean to #include
them.

>  Note the L in the LGPL was changed from Library to Lesser
> for a reason.

And the reason has nothing to do with how similar the LGPL
is to the GPL. The primary reason for the name change was
that authors of new libraries should not mistakenly think
that they should use the LGPL rather than the GPL, just
because the old _name_ of the license seemed to fit better.

>> Works /based/ on the w32api will be as you say, infected. But
>> the remedy for those works is simple enough, they only need to
>> remove the LGPL files in question before they make a public release.
> 
> The Cygwin project, which is where this discussion
> originated, would not be able to use the w32api library package
> without such modification because the Cygwin project would require
> copyright ownership of the L/GPL headers before it could use the
> package.  That is the reason the  Cygwin package chose to use
> Newlib instead of GNU version of the C runtime.

I'm sorry, I don't grasp what is so special about the w32api?
Please inform me. I mean, the Cygwin project surely does not have
copyright ownership of everything under L/GPL it distributes.
When I read http://www.redhat.com/software/cygwin/ I can't see
how these DirectX headers affect any of the promises. But that
page does not provide the finer details of the contract, so
again, please enlighten me.

> The MinGW project would not be able to distribute the w32api library
> without such modification because we publish that proprietary source
> will not be infected with the copyleft L/GPL.

I see this in the MinGW FAQ: "The copyright agreement states no
restrictions are placed on programs or object files compiled
with the library." This will not change, apps/libs that #include
these LGPL DirectX headers do not inherit the LGPL license.

Cheers,
Peter