哪些开源许可与苹果iPhone及其官方App Store兼容？
我正在写一个iPhone应用程序，我想使用第三方库的部分function。 我打算通过App Store销售它，我的代码不会公开。 哪些开放源代码许可允许衍生作品并在苹果自己的条件下发布？
简称/ TL; DR：
LGPL和应用程序商店有一些不兼容性，这意味着您无权在启用DRM的AppStores或locking的设备上分发LGPL代码。
最好的方法是在Apache 2许可证，Microsoft公共许可证或MIT X11许可证等其他许可证许可证下查找库的其他实现。
更长：
LGPL指出：
这种需求可能会违反通常不伴随操作系统的其他专有库的许可限制。 这样的矛盾意味着你不能在你分发的可执行文件中同时使用它们和库。
将LGPL代码与专有代码静态链接的权利来自LGPL的第6节。 除了授予该部分的权利之外，还要处理您的代码对下游收件人的要求。
您应该详细阅读本节。
付费开发与LGPL之间的冲突
应用程序需要用户付费才能进入程序并获得重要证书，configuration文件和部署到设备的工具的存储与LGPL直接相冲突。
LGPL要求最终用户能够获取你的目标文件加上开放源代码库（加上工具，见下面的部分），并产生一些可行的代码。 下游收件人不得不与苹果，微软，亚马逊或谷歌签订单独的协议，以便能够在自己的硬件上部署代码的工作版本。
特别是这一节是相关的：
您不得对收件人行使本协议授予的权利施加任何进一步的限制。 您对使用本许可证强制执行第三方的合规性不承担责任。
您不需要授予用户在AppStore上重新发布您的应用程序的权利，但您需要让用户有权在自己的设备上使用LGPL代码的修改版本来部署您的应用程序，因此任何需要的开发人员程序或设备额外支付部署与LGPL冲突。
对象文件的分发
您必须确保生成的可执行文件的条款允许收件人更改LGPL代码，并从中生成新的工作代码。 这实际上意味着您需要分发程序的目标文件，以便第三方可以使用该库的修改版本来重新链接您的应用程序，可以修复错误，以某种方式改进错误，或者提供自己的function。
您可以通过在您的网站上发布目标文件并提供一个项目来避免这种情况，因此第三方可以重新链接应用程序。 不这样做会撤销LGPL的许可证。
逆向工程的权利
这是第6节的另一个要求。
这可能与各种应用程序商店的条款直接冲突，但您需要检查您正在使用的应用程序商店（Apple，Amazon，Android或其他第三方）的确切条款。
通知和广告
作为LGPL代码要求的一部分，发送给下游用户的应用程序必须随附LGPL许可证，并在显示任何版权声明的应用程序的任何地方指向此许可证。 一些应用程序商店将其发布在应用程序商店网站上，而其他应用程序商店可能拥有可执行文件本身的版权信息
修改的LGPL代码的分配
这是非常容易遵守的，你只需要在你的网站上分发LGPL代码的副本（在许可证上有一些额外的细节需要保持代码的可用时间）。
你不能满足的要求
LGPL的主要问题之一是在通过应用程序商店分发的应用程序中使用静态库时，需要分发最终用户重build软件所需的工具和脚本。
对于某些embedded式系统场景，您需要embedded式系统供应商向任何最终用户披露他的开发人员工具和API，这可能是不可能的。 目前还不清楚像iPhone或Windows SDK这样的东西可以自由地重新分配，以履行这种情况下的义务，你可能想与你的律师讨论，并找出你是多么舒服的暴露的要求。
你可以做什么
如果您绝对需要在app store或embedded式系统中使用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和LGPL兼容性的主题。
图书馆的LGPL许可证对您的应用程序的详细要求：
d）执行以下操作之一：
0）根据本许可协议条款和相应的应用代码，以适当的forms传送最小对应源代码，并允许用户将应用程序与链接版本的修改版本重新组合或重新链接，以生成修改组合工作，按照GNU GPL第6节规定的方式传输相应的源文件。
我不认为LGPL将适用于iPhone应用程序。
问题是iPhone运行时不允许你将共享库（或框架）与你的应用程序捆绑在一起。 只允许单个二进制应用程序。 LGPL基于假设您将共享库与应用程序捆绑在一起。 直接链接仍然被禁止。
苹果应用程序商店与GPL和LGPL的所有版本以及Affero GPL都存在FSF的copyleft想法不兼容。 Apple App Store不允许用户使用自由软件，修改它，然后在自己的设备上自由运行。 他们要求你使用DRM，每年支付100美元，以同意他们的附加条款等。这里有一个很好的写作： http : //michelf.com/weblog/2011/gpl-ios-app-商店/
在App Store之外分发iOS的GPL / LGPL软件是完全合法的，问题在于苹果App Store。 所以我build议游说苹果改变他们的限制。 Mac OS X和iOS甚至从根本上依赖于GPL / LGPL软件（例如gcc等等），因此苹果正在享受自由，但它却剥夺了用户同样的自由。
对于App Store兼容的许可证，您需要使用BSD，MIT，Apache或公共领域的许可许可证。
这不是法律意见，我不是律师，但听起来你需要一个BSD或Apache许可证的图书馆。 如果您正在开发使用开源库的专有桌面程序，情况就是这样。 我不知道苹果是否有进一步限制iPhone应用程序。
（我不是律师）
静态目标文件链接可以解决如何允许使用LGPL许可代码的应用程序可用而不分发其源代码的非LGPL部分的问题。
但似乎LGPL作为GPL的一个变体，对于iPhone应用程序开发来说是一个更大的不可逾越的问题，因为创build和发布任何iPhone应用程序所需的开发工具只能在苹果与GPL不兼容的条款下提供。 即。 年费为100美元，使用这些不属于GPL许可证的工具有许多条款和条件。 苹果的iPhone开发工具的许可条款似乎与GPL的精神，也许也是信件不相容。
如果你没有发布你的源代码，你不能使用任何严格的copyleft许可证。 在任何情况下，您都不能使用任何基于GPLv3的许可证，因为iPhone发行版与免提条款相冲突。
如果你使用的是LGPLv2，你必须提供可链接格式的程序，可能或不可以接受（至less不是源代码），这可能是你不想处理的东西，除非图书馆提供很多好处。
如果图书馆有一个版权所有者，您可以随时查看是否可以获得许可证例外。
典型的BSD / MIT / Boost /许可许可证不会有任何问题。 有许多开源/自由软件许可证，其余的你必须阅读和看看。
当我尝试将Fuego移植到iPhone上时 ，我在fuego邮件列表上提出了类似的问题。 到目前为止，我的理解是“LGPL与AppStore 不兼容”。 前面的问题也得到答案：不。
Wunderradio就是一个很好的例子。 他们使用ffmpeg和其他LGPLv2许可的框架，并在其网站上提供.o文件。
奇怪的是，他们也提供了完整的应用程序源代码。
那些认为App Store服务条款有问题的人，特别是每年100美元的Apple Dev计划费是错误的。 那100美元甚至没有接近顶尖人物。 他们花这么多时间担心这类事情是典型的开发者; 0）律师几千年来一直坚持合同条款，这些都不值得失眠。
先决条件：从可通过应用程序中的链接访问的Web位置提供对象文件和基本项目文件。
选项1，牛仔：越狱是官方合法的（免费）。 LGPL与App Store条款之间的兼容性无关。 LPGL在哪里指定特定的分销渠道？ 无处。 您想要通过应用程序商店下载的应用程序中的静态链接库升级？ 吸取它，alpha开发和越狱你的手机！ 仅仅因为苹果是操场上的恶霸并不会迫使你留在他们的旋转木马上。 有创意的开发者可以在下次聚会中获得有价值的吹牛权利。 再加上事实，你越狱你的手机，以升级一个LPGL库让您访问理查德斯托曼的地下室小桶房间！
备选scheme2是为了合法地解决这个问题，诚实信用：LGPL v2.1（和GPL v3第4节）的第1部分允许开发人员对复制图书馆的实际行为收取费用。 这为开发人员提供了一个机制，将这笔费用重新分配给99美元的Apple Dev订阅费用。
100设备限制怎么样？ 希望升级二进制文件的最终用户正在升级商业应用程序，所以应用程序开发人员自己的许可证条款将发挥作用。 为自定义许可协议添加100个设备限制是微不足道的。 有多less人拥有超过100个iOS设备？ 即使乔布斯也没有那么多！ 这不是一个不合理的限制。 鉴于没有要求允许最终用户将自己的原始商业应用程序的修改版本发布到野外，当无法在修改器的第101个朋友的设备上加载时，将没有投诉的基础。
LGPL没有要求最终用户必须有一个舒适，无风险，甚至是明显的select。 他们只需要有一个select，而且有两个非常好的select。
