On Fri, 08 Jul 2011 15:39:22 -0400, Johannes Pfau <spam@example.com> wrote:

> Andrej Mitrovic wrote:
>> What's the license on the bindings?
>
> Have not thought about that yet, but I think I'll use the boost
> license. (I'm not sure if that's possible, as
> cairo is LGPL, maybe I'll have to release the binding part at least as
> LGPL, as that's based on the cairo headers? Stupid licensing stuff... )
>

I'm not a lawyer, but I think LGPL just covers the library code, not the bindings, as long as the link is dynamic.  In other words, LGPL specifically allows dynamically linking with any license, as long as the library remains LGPL.

For reference, the C standard library (which phobos uses extensively) is LGPL on Linux (glibc).

-Steve

Steven Schveighoffer wrote:
>On Fri, 08 Jul 2011 15:39:22 -0400, Johannes Pfau <spam@example.com> wrote:
>
>> Andrej Mitrovic wrote:
>>> What's the license on the bindings?
>>
>> Have not thought about that yet, but I think I'll use the boost
>> license. (I'm not sure if that's possible, as
>> cairo is LGPL, maybe I'll have to release the binding part at least
>> as LGPL, as that's based on the cairo headers? Stupid licensing
>> stuff... )
>>
>
>I'm not a lawyer, but I think LGPL just covers the library code, not the bindings, as long as the link is dynamic.  In other words, LGPL specifically allows dynamically linking with any license, as long as the library remains LGPL.
>
>For reference, the C standard library (which phobos uses extensively)
>is LGPL on Linux (glibc).
>
>-Steve

True, but in this case the bindings were translated from the cairo c headers. I wasn't sure if the bindings could be considered a derivate work. But looking at the LGPL license:
------------------------
  3. Object Code Incorporating Material from Library Header Files.

  The object code form of an Application may incorporate material from
a header file that is part of the Library.  You may convey such object
code under terms of your choice, provided that, if the incorporated
material is not limited to numerical parameters, data structure
layouts and accessors, or small macros, inline functions and templates
(ten or fewer lines in length), you do both of the following:

   a) Give prominent notice with each copy of the object code that the
   Library is used in it and that the Library and its use are
   covered by this License.

   b) Accompany the object code with a copy of the GNU GPL and this
   license document.
------------------------
Seems like (simple) header files can be used without restrictions. Looking at other cairo bindings luacairo is public domain, so I think I'll just release the everything under the boost license.

-- 
Johannes Pfau

The existing D1 bindings are BSD. Boost would be great, although you seem to have already put the LGPL clause in some of your translated header files.

As I understand it, LGPL comes into play if you want to link statically, alter the source of the library, or distribute the DLLs. AFAIK only if your bindings are GPL/LGPL *and* you distribute the source code then you can distribute the DLLs (libcairo-2.dll and its dependencies libpng14-14.dll and zlib1.dll). Otherwise the user would have to download them (from http://www.gtk.org/download/index.php), or maybe an application installer could do this automatically for its dependencies.

I'm not a lawyer though.

Using std.c.windows.windows is going to be problematic because the WindowsAPI bindings have a void* handle typedef, and std.c.windows.windows has the same typedef.

If your library has this function:
foo(HDC hdc) { }

I can't use it from my code if I use the WindowsAPI bindings:

import win32.windef;
import win32.winuser;

{
   HDc hdc;
   foo(hdc);  // compile error
}

See:

test.d(21): Error: function test.Foo (HANDLE hdc) is not callable
using argument types (HANDLE)
test.d(21): Error: cannot implicitly convert expression (hdc) of type
HANDLE to HANDLE

Personally I wish we got totally rid of std.c.windows.windows and the ancient DLLs distributed with DMD.

That was referring to this module: https://github.com/jpf91/cairoD/blob/master/src/cairo/win32.d

On Fri, 08 Jul 2011 16:02:39 -0400, Johannes Pfau <spam@example.com> wrote:

> Steven Schveighoffer wrote:
>> On Fri, 08 Jul 2011 15:39:22 -0400, Johannes Pfau <spam@example.com>
>> wrote:
>>
>>> Andrej Mitrovic wrote:
>>>> What's the license on the bindings?
>>>
>>> Have not thought about that yet, but I think I'll use the boost
>>> license. (I'm not sure if that's possible, as
>>> cairo is LGPL, maybe I'll have to release the binding part at least
>>> as LGPL, as that's based on the cairo headers? Stupid licensing
>>> stuff... )
>>>
>>
>> I'm not a lawyer, but I think LGPL just covers the library code, not
>> the bindings, as long as the link is dynamic.  In other words, LGPL
>> specifically allows dynamically linking with any license, as long as
>> the library remains LGPL.
>>
>> For reference, the C standard library (which phobos uses extensively)
>> is LGPL on Linux (glibc).
>>
>> -Steve
>
> True, but in this case the bindings were translated from the cairo c
> headers. I wasn't sure if the bindings could be considered a derivate
> work.

Well, if we look at this logically -- if the C headers contain so much code that using them would require releasing your software under LGPL, then why even use LGPL?  The only point for using LGPL is to allow other licensed code to use your library, yet still have your library be under the GPL.  If linking a C application using the C headers doesn't require GPL'ing your code (or LGPL'ing), then I can't see how a translation of them would require it.

But almost certainly a translation of the headers is a derived work, so the bindings themselves should have the same license as the headers (LGPL).  I think this should cause no problems with linking proprietary code.  I don't think it would qualify as a phobos module though.

-Steve

> But looking at the LGPL license:
> ------------------------
>   3. Object Code Incorporating Material from Library Header Files.
>
>   The object code form of an Application may incorporate material from
> a header file that is part of the Library.  You may convey such object
> code under terms of your choice, provided that, if the incorporated
> material is not limited to numerical parameters, data structure
> layouts and accessors, or small macros, inline functions and templates
> (ten or fewer lines in length), you do both of the following:
>
>    a) Give prominent notice with each copy of the object code that the
>    Library is used in it and that the Library and its use are
>    covered by this License.
>
>    b) Accompany the object code with a copy of the GNU GPL and this
>    license document.
> ------------------------
> Seems like (simple) header files can be used without restrictions.
> Looking at other cairo bindings luacairo is public domain, so I think
> I'll just release the everything under the boost license.

On 7/8/11, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>  I think this should cause no problems with linking proprietary
> code.  I don't think it would qualify as a phobos module though.

That doesn't make sense to me. If the .d files are LGPL'ed you can't import them to your D projects without the license going viral on all of your files and making them all LGPL. And the fact that D has no real concept of headers probably makes licensing more muddy.

Maybe it's best to ask the Cairo folks if it's ok to translate the C headers to D without having to use LGPL on the .d files.

On 2011-07-08 13:42, Andrej Mitrovic wrote:
> Using std.c.windows.windows is going to be problematic because the WindowsAPI bindings have a void* handle typedef, and std.c.windows.windows has the same typedef.
> 
> If your library has this function:
> foo(HDC hdc) { }
> 
> I can't use it from my code if I use the WindowsAPI bindings:
> 
> import win32.windef;
> import win32.winuser;
> 
> {
> HDc hdc;
> foo(hdc); // compile error
> }
> 
> See:
> 
> test.d(21): Error: function test.Foo (HANDLE hdc) is not callable
> using argument types (HANDLE)
> test.d(21): Error: cannot implicitly convert expression (hdc) of type
> HANDLE to HANDLE
> 
> Personally I wish we got totally rid of std.c.windows.windows and the ancient DLLs distributed with DMD.

The situation betwen druntime and Phobos with regards to Windows-specific stuff definitely needs to be ironed out. The two conflict and at least some of the Phobos stuff for Windows isn't even under Boost. So, there's work to be done there. However, I don't believe that any Phobos developers are focusing on Windows-specific stuff like this at this point. So, if the situation is going to improve, someone is likely going to have to step up and do the work and then submit it for review. Otherwise, it's not likely to improve much anytime soon. Various pull requests from folks outside of the Phobos dev team have certainly helped, so progress is better than it was, but someone is probably going to have to take it upon themselves to sort it all out and propose and implement an appropriate solution for it to get fully fixed.

- Jonathan M Davis

On 7/9/2011 5:43 AM, Steven Schveighoffer wrote:
> On Fri, 08 Jul 2011 16:02:39 -0400, Johannes Pfau <spam@example.com> wrote:
>
>> Steven Schveighoffer wrote:
>>> On Fri, 08 Jul 2011 15:39:22 -0400, Johannes Pfau <spam@example.com>
>>> wrote:
>>>
>>>> Andrej Mitrovic wrote:
>>>>> What's the license on the bindings?
>>>>
>>>> Have not thought about that yet, but I think I'll use the boost
>>>> license. (I'm not sure if that's possible, as
>>>> cairo is LGPL, maybe I'll have to release the binding part at least
>>>> as LGPL, as that's based on the cairo headers? Stupid licensing
>>>> stuff... )
>>>>
>>>
>>> I'm not a lawyer, but I think LGPL just covers the library code, not
>>> the bindings, as long as the link is dynamic. In other words, LGPL
>>> specifically allows dynamically linking with any license, as long as
>>> the library remains LGPL.
>>>
>>> For reference, the C standard library (which phobos uses extensively)
>>> is LGPL on Linux (glibc).
>>>
>>> -Steve
>>
>> True, but in this case the bindings were translated from the cairo c
>> headers. I wasn't sure if the bindings could be considered a derivate
>> work.
>
> Well, if we look at this logically -- if the C headers contain so much
> code that using them would require releasing your software under LGPL,
> then why even use LGPL? The only point for using LGPL is to allow other
> licensed code to use your library, yet still have your library be under
> the GPL. If linking a C application using the C headers doesn't require
> GPL'ing your code (or LGPL'ing), then I can't see how a translation of
> them would require it.
>
> But almost certainly a translation of the headers is a derived work, so
> the bindings themselves should have the same license as the headers
> (LGPL). I think this should cause no problems with linking proprietary
> code. I don't think it would qualify as a phobos module though.
>

A few years back I was concerned about this same issue with my SDL bindings in Derelict. SDL was licensed under the LGPL. So I posted a question to the SDL mailing list. The maintainer, Sam Lantinga, answered thus:

"The API is not copyrighted, only the SDL implementation is.  I would consider this a work that uses the library, rather than a derivative work.  You'll notice that using inline functions in LGPL headers, which technically places code from those headers in your object code, also does not change your work into a derivative work - it remains a work that uses the library."

That reinforced my own understanding. So for years now the license for Derelict's bindings has usually been different from the C libraries. That's especially true for Derelict 2, which is licensed under Boost.

Realistically, I'd like to release Derelict with no license at all. I'm not sure exactly what it is I'm licensing. The lion's share of original code in the project is in the utility package. The bindings themselves generally have very little non-interface code, just what's required to implement the loader. But I've learned that people get nervous when there's no license attached to a library. So Boost it is.

Andrej Mitrovic wrote:
>Using std.c.windows.windows is going to be problematic because the WindowsAPI bindings have a void* handle typedef, and std.c.windows.windows has the same typedef.
>
>If your library has this function:
>foo(HDC hdc) { }
>
>I can't use it from my code if I use the WindowsAPI bindings:
>
>import win32.windef;
>import win32.winuser;
>
>{
>   HDc hdc;
>   foo(hdc);  // compile error
>}
>
>See:
>
>test.d(21): Error: function test.Foo (HANDLE hdc) is not callable
>using argument types (HANDLE)
>test.d(21): Error: cannot implicitly convert expression (hdc) of type
>HANDLE to HANDLE
>
>Personally I wish we got totally rid of std.c.windows.windows and the ancient DLLs distributed with DMD.

Ok, would something like this work? (for cairo.c.win32)
-------------------------------
//Use Andrej Mitrovic's API from
//https://github.com/AndrejMitrovic/DWindowsProgramming/tree/master/win32
version(EXT_WIN32_BINDINGS)
{
    import win32.windef;
    import win32.wingdi;
}
else
{
    import core.sys.windows.windows;
    pragma(msg, "cairo.c.win32: LOGFONTW should move to druntime");
    enum size_t LF_FACESIZE = 32;
    struct LOGFONTW
    {
        LONG lfHeight;
        LONG lfWidth;
        LONG lfEscapement;
        LONG lfOrientation;
        LONG lfWeight;
        BYTE lfItalic;
        BYTE lfUnderline;
        BYTE lfStrikeOut;
        BYTE lfCharSet;
        BYTE lfOutPrecision;
        BYTE lfClipPrecision;
        BYTE lfQuality;
        BYTE lfPitchAndFamily;
        WCHAR[LF_FACESIZE] lfFaceName;
    }
}
-------------------------------
I guess win32.windef and win32.wingdi contain all needed types?

Regarding the LGPL clause in the bindings, that's a leftover from the cairo c headers. Even if that counted as releasing the sources as LGPL I could still relicense them as long as I'm the only contributor. I'll just ask on the cairo mailing list, that seems to be the best solution.

-- 
Johannes Pfau