License for language bindings

Some time ago I created SDL bindings for the D language. The project
required that I translate the C headers to D modules. In D, modules are
compiled into object code and linked into the application statically. There
is a big debate right now between me and the users of the bindings about
licensing.

My understanding is that the D modules I created constitute a modification
of the SDL source and therefore must be released under the LGPL (as per
sections 2a and 2c of the LGPL). I can’t see how this could be otherwise, as
all of the macros had to be rewritten as D functions (D has no
preprocessor). My users contend that the D modules are an original work and,
since the project actually loads the SDL shared library dynamically through
libdl on Linux and LoadLibrary on Windows, it qualifies as a “work that uses
the library”. According to them, I can satisfy the license requirements in
the same manner as any application with uses SDL.

This is an important distinction. If I am right and my bindings have to be
LGPL, then this will affect the licensing of any application that uses the
bindings. Since the D modules are compiled directly into object files and
linked into the application, then such applications would be considered a
derivative and not a “work that uses the library” according to section 5 of
the LGPL. If my users are right, then I am free to release my bindings under
any license I choose as long as I adhere to the the requirements laid out in
section 6b of the LGPL (as most normal SDL apps do).

So, are my D modules considered a modification of SDL or a “work that uses
the library”? I really just can’t see how the latter can be the case, though
I really hope I’m wrong. I would love to release the bindings under a
different license. Any opinions appreciated.

Some time ago I created SDL bindings for the D language. The project
required that I translate the C headers to D modules. In D, modules are
compiled into object code and linked into the application statically. There
is a big debate right now between me and the users of the bindings about
licensing.

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.

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

Although Sam is right, as I understand it anyway, the bindings are
created by you and if you want to licence them under the LGPL and
enforce it that’s up to you :slight_smile:

sparkesOn 4/20/06, Sam Lantinga wrote:

Some time ago I created SDL bindings for the D language. The project
required that I translate the C headers to D modules. In D, modules are
compiled into object code and linked into the application statically. There
is a big debate right now between me and the users of the bindings about
licensing.

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.


Steve ‘sparkes’ Parkes - tshirts http://nerd.ws - code http://zx-81.com
Autistic LUG http://autisticlug.org - blog http://sp.arkes.co.uk

Thanks for the clarification. My users will be happy to hear that you share
their view.On 4/21/06, Sam Lantinga wrote:

Some time ago I created SDL bindings for the D language. The project
required that I translate the C headers to D modules. In D, modules are
compiled into object code and linked into the application statically.
There
is a big debate right now between me and the users of the bindings about
licensing.

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.