简而言之/tl;dr:

lgpl和应用程序存储有一些不兼容性,这意味着您无权在启用drm的应用程序存储或锁定的设备上分发lgpl代码。

最好是在其他较宽松的许可证(如apache 2许可证、microsoft公共许可证或mit x11许可证)下寻找库的替代实现。

比较长的:

lgpl声明:

这一要求可能与许可证相矛盾 其他通常不受限制的专有库 随操作系统一起使用。这种矛盾意味着你不能 在可执行文件中同时使用它们和库 分发。

将lgpl代码与专有代码静态链接的权利来自lgpl的第6节。除了授予的权限之外,该部分还处理对代码下游接收者的需求。

你应该详细阅读这一节。

发展性薪酬与lgpl之间的冲突

需要用户付费才能进入程序并获得密钥证书的应用程序存储、配置配置文件和部署到设备的工具与lgpl直接矛盾。

lgpl要求最终用户能够获取您的对象文件和开放源代码库(以及工具,请参阅下面的一节)并生成一些有效的代码。没有任何余地让下游的接受者必须与苹果、微软、亚马逊或谷歌签订单独的协议,才能在自己的硬件上部署工作版本的代码。

本节特别涉及:

你不能再强加 受方行使本协议授予权利的限制。 您不负责强制第三方遵守 这个执照。

您不需要授予用户在AppStore上重新发布应用程序的权限,但您需要授予用户在其自己的设备上部署应用程序的权限(使用修改后的LGPL代码版本),因此任何需要额外付款才能部署的开发程序或设备都与H LGPL。

对象文件的分发

您必须确保生成的可执行文件的条款允许接收者对lgpl代码进行更改,并从中生成新的工作代码位。实际上,这意味着您需要分发程序的对象文件,以便第三方可以使用库的修改版本重新链接您的应用程序,可以修复错误,以某种方式改进它,或提供它们自己的功能。

您可以通过将对象文件发布到您的网站并提供一个项目,以便第三方可以重新链接应用程序来解决这个问题。不这样做会吊销您的lgpl许可证。

逆向工程的权利

这是第6节的另一个要求。

这可能与各种应用程序商店的条款直接冲突,但您需要与正在使用的应用程序商店(苹果、亚马逊、安卓或其他第三方)核对确切的条款。

通知和广告

作为lgpl代码要求的一部分,发送给下游用户的应用程序必须附带lgpl许可证,并在显示任何版权声明的应用程序的任何位置指向该许可证。一些应用程序存储会将此发布到应用程序存储网站上,而其他应用程序存储可能拥有可执行文件本身的版权信息。

改进的lgpl码的分布

这很容易遵守,您只需要在您的网站上分发lgpl代码的副本(许可证上有一些关于保持代码可用的时间长度的额外细节)。

你不能满足的要求

lgpl和在通过应用程序存储区分发的应用程序中使用静态库的一个主要问题是,需要分发最终用户重建软件所需的工具和脚本。

对于某些嵌入式系统场景,您将要求嵌入式系统供应商向任何最终用户公开其开发工具和api,这可能是不可能的。目前尚不清楚,iphone或windowssdk这样的东西是否可以自由重新分配,以履行本案中的义务,您可能希望与律师讨论,了解您对披露这些要求有多满意。

你能做什么

如果您绝对需要在appstore或嵌入式系统中使用一些lgpl代码,您可以随时联系代码的原始作者,让他们根据不同的条款授予您代码许可证。

或者,您可以在其他更宽松的许可证(如apache 2许可证、microsoft公共许可证或mit x11许可证)下寻找库的替代实现。

关于lgpl,我认为st3fan是不正确的,但是louis gerbarg是正确的:可以在封闭源代码的iphone应用程序中使用lgpl库,但是有限制。

如果你看看 http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License ,您可以阅读“或者,如果提供了源代码或可链接对象文件,则允许静态链接库。”

因此,正如louis gerbarg所提到的,如果您使用lgpl库,只要您免费提供客户获取应用程序并链接它所需的对象(例如.*o)文件,就可以保持应用程序的封闭源代码。

我深入研究了 iPhone and LGPL compatibility here .

库的lgpl许可证对应用程序的详细要求:

d)执行下列操作之一:

0)根据本许可证的条款,以适合用户使用链接版本的修改版本重新组合或重新链接应用程序以生成修改后的组合作品的形式,并在允许用户使用链接版本的修改版本重新组合或重新链接应用程序的条款下,传送最小的对应源代码和相应的应用程序代码,以gnu gpl第6节规定的方式传输相应的源。

我认为lgpl不适用于iphone应用程序。

问题是,iphone运行时不允许您将共享库(或框架)与应用程序捆绑在一起。只允许使用单个二进制应用程序。lgpl基于将共享库与应用程序捆绑在一起的假设。仍然禁止直接连接。

苹果应用商店与fsf的copyleft理念不兼容,这一理念存在于gpl和lgpl以及affero gpl的所有版本中。苹果应用商店不允许用户获取免费软件,修改它,然后在自己的设备上自由运行。他们要求你使用DRM,每年支付100美元,同意他们的附加条款,等等。这里有一个很好的描述: http://michelf.com/weblog/2011/gpl-ios-app-store/

在app store之外发布用于ios的gpl/lgpl软件是完全合法的,问题在于apple app store。所以我建议游说苹果改变他们的限制。MacOSX和iOS甚至从根本上依赖于GPL/LGPL软件(如GCC等),因此苹果享受着自由,但它拒绝给用户同样的自由。

至于app store兼容的许可证,您需要使用非常许可的许可证,如bsd、mit、apache或public domain。

这不是法律建议,我不是律师,但听起来你需要一个有bsd或apache许可证的库。如果您正在开发使用开放源代码库的专有桌面程序,则会出现这种情况。我不知道苹果是否对iphone应用有进一步的限制。

(我不是律师。)

静态对象文件链接可以解决如何允许使用lgpl许可代码的应用程序在不分发其源代码的非lgpl部分的情况下可用的问题。

不过,lgpl作为gpl的一个变体,似乎给iphone应用程序的开发带来了一个更大的不可克服的问题,即创建和发布任何iphone应用程序所需的开发工具只能在苹果提供的与gpl不兼容的条款下才能使用。也就是说,有一个100美元/年的费用,并有许多条款和条件,这些工具的使用不属于GPL许可证的一部分。苹果iphone开发工具的许可条款似乎与gpl的精神,或许也与gpl的文字格格不入。

如果不发布源代码,就不能使用任何严格的copyleft许可证。在任何情况下都不能使用任何基于gplv3的许可证,因为iphone发行版与no tivoization子句冲突。

如果您使用的是lgplv2,则必须以可链接的格式提供程序,这种格式可能是可以接受的,也可能是不可接受的(至少它不是源代码),而且这很可能是您不想处理的,除非库提供了很多好处。

如果库中有一个版权所有者,则始终可以查看是否可以获得许可例外。

典型的bsd/mit/boost/whatever许可证不会有任何问题。有很多开源/免费软件许可证,剩下的你必须阅读并查看。

当我试图 port Fuego onto iPhone ,我问了一个类似的问题 fuego mailing list . 到目前为止,我的理解是“lgpl是 不 与AppStore兼容”。以前的 question 也会得到一个答案:不。

一个很好的例子就是WunderRadio。他们使用ffmpeg和其他lgplv2许可的框架,并在他们的网站上提供.o文件。

奇怪的是,他们还为他们的应用程序提供了完整的源代码。

http://wunderradio.com/code.html

那些坚持认为应用商店的服务条款有问题的人,尤其是每年100美元的苹果开发程序费用,是错误的。那100美元甚至还不足以成为一个卖座的人。这是典型的开发人员,他们花这么多时间担心这些事情;律师们几千年来一直在处理合同条款,这些都不值得再睡一觉。

先决条件: 从可通过应用程序中的链接访问的Web位置提供对象文件和基本项目文件。

选项1,牛仔: 越狱是合法的(而且是免费的)。仅此一点就消除了对lgpl和app store术语之间兼容性的任何担忧。lpgl在哪里指定特定的分销渠道?无处可去。是否要升级通过应用商店下载的应用中的静态链接库?把它吸起来,阿尔法·德夫,把你的手机给越狱了!仅仅因为苹果是操场上的恶霸,并不会强迫你呆在他们的旋转木马上。因此,有进取心的开发人员可以在下次会议上获得宝贵的吹牛权。再加上你为了升级lpgl库而越狱,这让你可以进入理查德史泰尔曼地下室的酒桶室!

选择2:合法和真诚地绕过它: lgpl v2.1的第1节(以及gpl v3的第4节)允许开发人员对复制库的物理行为收取费用。这为开发人员提供了一种机制,可以将该费用重新分配给99美元的apple dev订阅费。

100个设备的限制是多少?希望升级二进制文件的最终用户正在升级商业应用程序,因此应用程序开发人员自己的许可条款将发挥作用。在自定义许可协议中添加100个设备的限制是很简单的。有多少人拥有超过100台iOS设备?就连乔布斯也没有那么多!这几乎不是一个不合理的限制。考虑到没有要求终端用户可以发布他们自己修改过的原始商业应用程序版本,当它无法加载到修改者的第101个朋友的设备上时,就没有理由抱怨了。

lgpl中没有要求最终用户必须有一个舒适、无风险甚至显而易见的选择。他们只有一个选择,有两个非常好的选择。