To what extent are interop definitions covered under their original license

Question

I have a project that creates thumbnails for a video file, it is heavily based off interop definitions in directshow.net.

At the moment media browser is GPL so everything is compatible and I'm all good to have cut and pasted this code (since its all attributed properly).

But... I'm looking at including this code in a derivative MIT licensed project. Which leaves me in a bit of a spot.

Directshow.net is licensed under LGPL which means I could depend on that DLL. But ... I can not really include the code under the less restrictive license.

The files in question are interop definitions which can easily/tediously be defined by reading through MSDN and translating stuff to C#, if I did this manually I would most likely arrive at the same code (or something incredibly similar).

Where do I stand here? How do I get this functionality into my MIT licensed project?

Related: http://sourceforge.net/forum/forum.php?thread_id=3040125&forum_id=460697

Answer 1

With LGPL, you only need to share (and cover with LGPL or GPL) source code that's a direct derivative of the library in question -- i.e., changes you may make to that library. Any code that just depends on that library e.g. by linking, but doesn't change it, is not constrained by the LGPL license -- so you can MIT-license it to your heart's content!

Answer 2

Also, interface definitions, sans 'creative' expression (such as descriptive comments) are not subject to copyright, if memory serves. If the only code you're including is such 'boilerplate', then you should be fine.

Of course, I'm not a lawyer, and I can't find the case that set this precedent right now. Perhaps some kind editor feels helpful?

Answer 3

Take all the code and make it into a DLL, and you're fine. Under the terms of the LGPL, you're allowed to link to it as a shared library from any project you want; only the LGPL DLL itself is covered by the licensing requirement. It would have to be LGPL, but the rest of your project wouldn't.

Things get a bit hairier if you want to statically link the library's code into your executable. The point of the LGPL is that the end-user must have the freedom to modify (and particularly to upgrade) the library's functionality on their own initiative. If it's a self-contained DLL, that's simply a matter of swapping one DLL out for another. If you take the code and statically link it, it's not so simple. Then you have two choices:

1. Open-source the entire project, with a license compatible with the LGPL. (This one gets ugly.)
2. Provide the object code (intermediary-stage compilation files that get fed to the linker) to your users so that they can take an updated version of the library and link it in manually. This is sort of an ugly solution, but it's allowed.

Your best bet is to just use a DLL.

Answer 4

It might be best to just avoid legal headaches and re-create the interop definitions. Take a look at the P/Invoke Interop Assistant. Just paste the C++ headers into the tool and it'll give you your bindings. It's still tedious, but much less painful than doing it all by hand.

Answer 5

This is in addition to the interfaces remark: (L)GPL is a license that is invoked on linking (all its wording is about the linking moment), and strictly, when a LGPL header is used, NO LGPL code is actually linked.