规避针对Debian或Ubuntu的非病毒许可库的GPL包装 [英] Circumventing GPL Packaging of Non-Virally-Licensed Libraries for Debian or Ubuntu
问题描述
我想在我的应用程序中使用某些库，这些库具有与封闭源分发兼容的许可证，例如LGPL和BSD。但是，在我使用的Linux发行版Ubuntu上，版权文件将这些库的打包标记为受GPL保护。我想避免使用GPL许可证。这样的库的一个示例是 libpng 。所以，我有三组问题：
什么包装？可以从原始LGPL库中构建的共享库中提取该共享库，以删除GPL保护吗？
是否存在存储库或其他获得非GPL打包的方式与我的软件包管理系统兼容的这些库的版本？自己构建库是我的最后选择。
包装是指脚本和元数据的集合，这些脚本和元数据采用了原始资源压缩文件，然后将其转换为.deb。如果通过 apt-get source somepackage 获取debian源代码，则可以在 debian / 目录下找到它。
要获得明确的答案，您可能应该联系律师。我不是一个人，这也不是法律建议-但是，说像GPL这样的病毒许可仅限于版权法允许它们影响的范围。具体来说，只有当您的代码是相关GPL代码的衍生产品时，它们才会真正影响您。您的代码可能是所讨论的实际库的派生作品，但是很难说您的代码是打包脚本的派生作品。毕竟，如果代码是基于Red Hat构建的，那么您的代码就可以正常工作，对吧？
虽然与debian打包脚本的情况不完全相同，但您可能发现有趣的是，阅读有关Linux和二进制内核模块的讨论；衍生作品的概念在那里也很突出。
I want to use certain libraries in my application which have licenses that are compatible with closed-source distribution, such as LGPL and BSD. However, on the Linux distribution I use, Ubuntu, the "packaging" of these libraries is marked by the copyright file as being GPL-protected. I want to avoid GPL licenses. One example of such a library is libpng. So, I have three sets of questions:
The packaging does indeed mean that I'd have to open the source to my app if I were to distribute the package with it, right?
What is the packaging? Can the shared object built from the original LGPL library be extracted from it so as to remove the GPL protection?
Are there repositories or other ways of getting non-GPL-packaged versions of these libraries that are compatible with my package management system? Building the libraries myself is my last resort.
The packaging refers to that collection of scripts and metadata that take a the raw source tarball and turn it into a .deb. If you obtain the debian source code via apt-get source somepackage, you can find this under the debian/ directory.
For a definitive answer, you should probably contact an attorney; I am not one, and this is not legal advice - that said, however, 'viral' licenses such as the GPL are limited to what copyright law allows them to affect. Specifically, they can only really affect you if your code is a derivative work of the GPL'd code in question. Your code may be a derivative work of the actual library in question, but it would be hard to argue that your code is a derivative work of the packaging scripts; after all, your code would work just fine if built on, say, Red Hat, right?
While it's not exactly the same situation as with debian packaging scripts, you might find it interesting to read this discussion of Linux and binary kernel modules; the concept of derivative works is prominent there as well.
这篇关于规避针对Debian或Ubuntu的非病毒许可库的GPL包装的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
