互操作定义在多大程度上涵盖在其原始许可证下
我有 一个为视频文件创建缩略图的项目，它很大程度上基于 directshow.net 中的互操作定义。
目前媒体浏览器是 GPL，所以一切都是兼容的，我很高兴剪切并粘贴了这段代码（因为它的属性都正确）。
但是......我正在考虑将这段代码包含在一个衍生的麻省理工学院许可项目中。 这让我陷入了困境。
Directshow.net 根据 LGPL 获得许可，这意味着我可以依赖该 DLL。 但是......我不能真正将代码包含在限制较少的许可证下。
有问题的文件是互操作定义，可以通过阅读 MSDN 并将内容翻译为 C# 来轻松/繁琐地定义，如果我手动执行此操作，我很可能会得到相同的代码（或非常相似的代码）。
我站在哪里？ 如何将此功能添加到我的 MIT 许可项目中？
相关：http://sourceforge.net/forum/forum.php？ thread_id=3040125&forum_id=460697
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
此外，如果没记错的话，没有“创意”表达（例如描述性注释）的界面定义不受版权保护。 如果您包含的唯一代码是这样的“样板文件”，那么您应该没问题。
当然，我不是律师，目前还找不到有这样先例的案例。 也许某个好心的编辑觉得有帮助？
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?
这是对接口注释的补充：(L)GPL 是在链接时调用的许可证（其所有措辞都与链接时刻有关），严格来说，当使用 LGPL 标头时，实际上不会链接任何 LGPL 代码。
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.
最好是避免法律问题并重新创建互操作定义。 看一下 P/Invoke Interop Assistant。 只需将 C++ 标头粘贴到该工具中，它就会为您提供绑定。 这仍然很乏味，但比手动完成这一切要痛苦得多。
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.
将所有代码放入 DLL 中，就可以了。 根据 LGPL 的条款，您可以将其作为共享库从任何您想要的项目链接到； 许可要求仅涵盖 LGPL DLL 本身。 它必须是 LGPL，但项目的其余部分则不会。
如果您想静态地将库的代码链接到可执行文件中，事情会变得有点棘手。 LGPL 的要点是最终用户必须能够自由地自行修改（尤其是升级）库的功能。 如果它是一个独立的 DLL，那么只需将一个 DLL 替换为另一个即可。 如果你获取代码并静态链接它，事情就没那么简单了。 那么您有两个选择：
最好的选择是只使用 DLL。
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:
Your best bet is to just use a DLL.
使用 LGPL，您只需要共享（并用 LGPL 或 GPL 覆盖）源代码，该源代码是相关库的直接派生 - 即，您可能对该库进行的更改。 任何仅依赖该库（例如通过链接）但不更改它的代码都不受 LGPL 许可证的约束 - 因此您可以随心所欲地对其进行 MIT 许可！
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!