或者，您可以在其他更宽松的许可证（例如 Apache 2 许可证、Microsoft 公共许可证或 MIT X11 许可证）下寻找该库的替代实现。
In Short/TL;DR:
The LGPL and application stores have a few incompatibilities which means that you do not have the rights to distribute LGPL code on DRM-enabled AppStores or locked devices.
It is best if you look for alternative implementations of the library under other laxer licenses like the Apache 2 License, the Microsoft Public License or the MIT X11 License.
Longer:
The LGPL states:
It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute.
The rights for statically linking LGPL code with proprietary code comes from section 6 of the LGPL. In addition to the rights granted that section deals with the requirements on your part towards downstream recipients of your code.
You should read this section in detail.
Conflicts between Pay-for-Development and the LGPL
Application Stores that require users to pay to enter the program and obtain key certificates, provisioning profiles and tools to deploy to the device are in direct contradiction with the LGPL.
The LGPL requires that the end user is able to fetch your object files plus the open source library (plus tools, see the section below) and produce some code that works. There is no room for having the downstream recipient have to enter a separate agreement with Apple, Microsoft, Amazon or Google to be able to deploy a working version of the code on his own hardware.
In particular this section is relevant:
You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License.
You do not need to give users the right to republish your application on an AppStore, but you need to give users the right to deploy your app with the modified version of the LGPL code on their own devices, so any developer program or device that requires extra payments to deploy is in conflict with the LGPL.
Distribution of Object Files
You must ensure that the terms of the resulting executable allow the recipient to make changes to the LGPL code and produce a new working bits of code out of it. This in practice means that you need to distribute the object files of your program so that a third party can relink your application with a modified version of the library, possible to fix bugs, improve it in some way, or provide their own features.
You could get away with this by posting the object files in your web site and providing a project so third parties can relink the application. Not doing so revokes your license to the LGPL.
Rights for Reverse Engineering
This is another requirement from Section 6.
This might be in direct conflict with the terms of various application stores, but you need to check the exact terms with the application store you are using (Apple, Amazon, Android or other third parties).
Notice and Advertisements
As part of the requirements for LGPL code, the application that is shipped to the downstream user must ship with the LGPL license and point to this license on any places of the application that display any copyright notices. Some application stores post this on the application store site, while others might have the copyright information on the executable itself.
Distribution of the Modified LGPL code
This is very easy to abide by, you just need to distribute the copy of the LGPL code on your web site (there are some extra details about this on the license about the length of time you need to keep the code available).
Requirements that you can not fulfill
One of the major problems with the LGPL and using static libraries in applications that are distributed through application stores is the requirement that you distribute the tools and scripts that are necessary for an end-user to rebuild the software.
For some embedded system scenarios, you would require the embedded system vendor to disclose his developer tools and APIs to any end users and this might not be possible. It is not clear if something like the iPhone or Windows SDKs can be freely redistributed to fulfill the obligations in this case, you might want to discuss with your lawyers and find out how comfortable you are with the exposure of the requirements.
What you can do
If you absolutely need to use some LGPL code in an appstore or an embedded system, you can always reach out to the original authors of the code and ask them to grant you a license to the code under different terms.
Alternatively, you can look for alternative implementations of the library under other laxer licenses like the Apache 2 License, the Microsoft Public License or the MIT X11 License.
0) 根据本许可证的条款传达最小对应源代码，并以适合的形式并根据条款传达相应的应用程序代码允许用户按照 GNU GPL 第 6 节指定的用于传达相应源代码的方式，将应用程序与链接版本的修改版本重新组合或重新链接，以生成修改的组合作品。
Regarding the LGPL, I believe that St3fan is incorrect, but Louis Gerbarg is correct: it is possible to use LGPL libraries in closed-source iPhone apps, but with restrictions.
So as Louis Gerbarg mentioned, if you use an LGPL library, you are allowed to keep your application closed-source as long as you make freely available the object (e.g. *.o) files that are needed for your customers to take your application and link it.
Detailed requirements on your app imposed by the LGPL license of the library:
d) Do one of the following:
0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
Apple App Store 与 FSF 的 Copyleft 理念不兼容，该理念存在于 GPL 和 LGPL 以及 Affero GPL 的所有版本中。 Apple App Store 不允许用户获取自由软件、对其进行修改，然后在自己的设备上自由运行。 他们要求你使用 DRM、每年支付 100 美元、同意他们的附加条款等等。这里有一篇很好的文章：http://michelf.com/weblog/2011/gpl-ios-app-store/
在 App Store 之外分发适用于 iOS 的 GPL/LGPL 软件是完全合法的，问题出在Apple App Store上。 所以我建议游说苹果改变他们的限制。 Mac OS X 和 iOS 甚至从根本上依赖 GPL/LGPL 软件（例如 gcc 等），因此 Apple 享受着自由，但同时又剥夺了用户同样的自由。
至于 App Store 兼容的许可证，您需要使用非常宽松的许可证，例如 BSD、MIT、Apache 或公共领域。
The Apple App Store is incompatible with the FSF's copyleft idea which is present in all versions of both the GPL and LGPL, and also the Affero GPL. The Apple App Store does not let users take Free Software, modify it, then run it on their own devices freely. They require you to use DRM, pay $100 a year, to agree to their additional terms, etc. There is a pretty good write up of this here: http://michelf.com/weblog/2011/gpl-ios-app-store/
It is completely legal to distribute GPL/LGPL software for iOS outside of the App Store, the problem lies with the Apple App Store. So I recommend lobbying Apple to change their restrictions. Mac OS X and iOS even fundamentally rely on GPL/LGPL software (e.g. gcc and many more), so Apple is enjoying the freedom yet it is denying its users the same freedom.
As for licenses that the App Store is compatible with, you will need to go with the very permissive licenses like BSD, MIT, Apache, or public domain.
I don't think LGPL will work for iPhone applications.
The problem is that the iPhone runtime does not allow you to bundle shared libraries (or frameworks) with your app. Only single binary applications are allowed. The LGPL is based on the assumption that you bundle a shared library with an application. Direct linking is still forbidden.
This is not legal advice, I am not a lawyer, but it sounds like you need a library with a BSD or Apache license. That would be the case if you were developing a proprietary desktop program that used an open source library. I don't know if Apple has any further restrictions for iPhone apps.
Static object file linking may address the question of how to allow an app which uses LGPL licensed code to be made available without distributing the non-LGPL'd portions of its source code.
But it seems like LGPL, as a variant on GPL, imposes a larger insurmountable problem for iPhone app development in that the development tools needed to create and distribute any iPhone app are only available under terms from Apple that are incompatible with GPL. ie. There is a $100/year fee, and there are numerous terms and conditions on the use of those tools that are not part of the GPL license. The terms of the license for Apple's iPhone developer tools seem to be incompatible with the spirit of and perhaps also the letter of GPL.
If you're not releasing your source code, you can't use any strict copyleft license. You can't use any GPLv3-based license in any case, since the iPhone distribution conflicts with the no-Tivoization clause.
If you're using LGPLv2, you'll have to provide your program in linkable format, which may or may not be acceptable (at least it's not source code), and this is likely to be something you don't want to deal with, unless the library offers a lot of benefit.
If there's one copyright holder on the library, you can always see if you can get a license exception.
You won't have any problem with the typical BSD/MIT/Boost/whatever permissive licenses. There are a lot of Open Source/Free Software licenses out there, and for the rest you'll have to read them and see.
When I try to port Fuego onto iPhone, I asked a similar question on the fuego mailing list. So far, my understanding is "LGPL is not compatible with AppStore". A previous question also receives an answer as: no.
The folks who maintain that the App Store terms of service are problematic, in particular the $100 yearly Apple Dev program fee, are wrong. That $100 is not even close to a showstopper. It is typical of developers that they spend so much time worrying about these type of things ;0) Lawyers have been stick-handling around contract provisions for thousands of years and these are hardly worth losing any sleep over.
Prerequisite: Provide the object files and a basic project file from a web location accessible via a link in the app.
Option 1, for cowboys: Jailbreaking is officially legal (and free). That alone voids any concerns over compatibility between LGPL and the App Store terms. Where does the LPGL specify a particular distribution channel? Nowhere. You want to upgrade a statically linked library in an app you downloaded via the app store? Suck it up, alpha dev and jailbreak your phone! Just because Apple is a bully in the playground doesn't force you stay on their merry-go-round. Enterprising developers can thereby receive valuable bragging rights at the next meetup. Plus the fact that you jailbroke your phone in order to upgrade an LPGL library gives you access to the keg room in Richard Stallman's basement!
Option 2 for getting around it legally, and in good faith: Section 1 of LGPL v2.1 (and section 4 of the GPL v3) allows developer to charge a fee for the physical act of copying the library. This provides a mechanism for the developer to re-assign that fee towards the $99 Apple Dev subscription fee.
What about the 100 device limit? End users who wish to upgrade their binary are upgrading a commercial application, so the app developer's own license terms come into play. It is trivial to add a 100 device limit to a custom license agreement. How many people own more than 100 iOS devices? Even Jobs didn't own that many! It's hardly an unreasonable limit. Given that there's no requirement that an end-user be allowed to release their own modified version of the original commercial app into the wild, there will be no basis for complaints when it fails to load on the device of the modifier's 101st friend.
There is no requirement in the LGPL that the end user has to have a comfy, risk-free, or even obvious choice. They just have to have a choice, and there's 2 perfectly good ones.
发布评论
评论（10）
简而言之/TL;DR：
LGPL 和应用程序商店存在一些不兼容性，这意味着您无权在启用 DRM 的 AppStore 或锁定设备上分发 LGPL 代码。
最好是在其他更宽松的许可证（例如 Apache 2 许可证、Microsoft 公共许可证或 MIT X11 许可证）下寻找该库的替代实现。
更长：
LGPL 规定：
将 LGPL 代码与专有代码静态链接的权利来自 LGPL 第 6 节。 除了授予的权利之外，该部分还涉及您对代码下游接收者的要求。
您应该详细阅读本节。
付费开发与 LGPL
应用程序商店之间的冲突要求用户付费才能进入程序并获取密钥证书、配置文件和部署到设备的工具，这与 LGPL 直接矛盾。
LGPL 要求最终用户能够获取您的目标文件和开源库（以及工具，请参阅下面的部分）并生成一些有效的代码。 下游接收者没有必要与苹果、微软、亚马逊或谷歌签订单独的协议，才能在自己的硬件上部署代码的工作版本。
本节尤其相关：
您不需要授予用户在 AppStore 上重新发布您的应用程序的权利，但您需要授予用户在自己的设备上使用 LGPL 代码的修改版本部署您的应用程序的权利，因此任何需要的开发者程序或设备额外支付的部署费用与 LGPL 相冲突。
目标文件的分发
您必须确保生成的可执行文件的条款允许接收者对 LGPL 代码进行更改并从中生成新的工作代码位。 这实际上意味着您需要分发程序的目标文件，以便第三方可以将您的应用程序与库的修改版本重新链接，可以修复错误，以某种方式改进它，或者提供自己的功能。
您可以通过在您的网站上发布目标文件并提供一个项目以便第三方可以重新链接该应用程序来解决此问题。 如果不这样做，您的 LGPL 许可证就会被撤销。
逆向工程的权利
这是第 6 节的另一项要求。
这可能与各个应用程序商店的条款直接冲突，但您需要检查您正在使用的应用程序商店（Apple、Amazon、Android 或其他第三方）的确切条款。派对）。
声明和广告
作为 LGPL 代码要求的一部分，发送给下游用户的应用程序必须附带 LGPL 许可证，并在应用程序中显示任何版权声明的任何位置指向此许可证。 一些应用程序商店将其发布在应用程序商店网站上，而其他应用程序商店可能拥有可执行文件本身的版权信息。
修改后的 LGPL 代码的分发
这很容易遵守，您只需在您的网站上分发 LGPL 代码的副本（许可证上有一些关于您需要保留该代码的时间长度的额外详细信息）可用代码）。
您无法满足的要求
LGPL 以及在通过应用程序商店分发的应用程序中使用静态库的主要问题之一是要求您分发最终用户重建软件所需的工具和脚本。
对于某些嵌入式系统场景，您可能要求嵌入式系统供应商向任何最终用户公开其开发人员工具和 API，但这可能是不可能的。 目前尚不清楚 iPhone 或 Windows SDK 之类的东西是否可以自由重新分发来履行本案中的义务，您可能需要与您的律师讨论并了解您对暴露这些要求的接受程度。
您可以做什么
如果您确实需要在应用程序商店或嵌入式系统中使用某些 LGPL 代码，您可以随时联系该代码的原始作者，并要求他们根据不同的条款授予您该代码的许可。
或者，您可以在其他更宽松的许可证（例如 Apache 2 许可证、Microsoft 公共许可证或 MIT X11 许可证）下寻找该库的替代实现。
In Short/TL;DR:
The LGPL and application stores have a few incompatibilities which means that you do not have the rights to distribute LGPL code on DRM-enabled AppStores or locked devices.
It is best if you look for alternative implementations of the library under other laxer licenses like the Apache 2 License, the Microsoft Public License or the MIT X11 License.
Longer:
The LGPL states:
The rights for statically linking LGPL code with proprietary code comes from section 6 of the LGPL. In addition to the rights granted that section deals with the requirements on your part towards downstream recipients of your code.
You should read this section in detail.
Conflicts between Pay-for-Development and the LGPL
Application Stores that require users to pay to enter the program and obtain key certificates, provisioning profiles and tools to deploy to the device are in direct contradiction with the LGPL.
The LGPL requires that the end user is able to fetch your object files plus the open source library (plus tools, see the section below) and produce some code that works. There is no room for having the downstream recipient have to enter a separate agreement with Apple, Microsoft, Amazon or Google to be able to deploy a working version of the code on his own hardware.
In particular this section is relevant:
You do not need to give users the right to republish your application on an AppStore, but you need to give users the right to deploy your app with the modified version of the LGPL code on their own devices, so any developer program or device that requires extra payments to deploy is in conflict with the LGPL.
Distribution of Object Files
You must ensure that the terms of the resulting executable allow the recipient to make changes to the LGPL code and produce a new working bits of code out of it. This in practice means that you need to distribute the object files of your program so that a third party can relink your application with a modified version of the library, possible to fix bugs, improve it in some way, or provide their own features.
You could get away with this by posting the object files in your web site and providing a project so third parties can relink the application. Not doing so revokes your license to the LGPL.
Rights for Reverse Engineering
This is another requirement from Section 6.
This might be in direct conflict with the terms of various application stores, but you need to check the exact terms with the application store you are using (Apple, Amazon, Android or other third parties).
Notice and Advertisements
As part of the requirements for LGPL code, the application that is shipped to the downstream user must ship with the LGPL license and point to this license on any places of the application that display any copyright notices. Some application stores post this on the application store site, while others might have the copyright information on the executable itself.
Distribution of the Modified LGPL code
This is very easy to abide by, you just need to distribute the copy of the LGPL code on your web site (there are some extra details about this on the license about the length of time you need to keep the code available).
Requirements that you can not fulfill
One of the major problems with the LGPL and using static libraries in applications that are distributed through application stores is the requirement that you distribute the tools and scripts that are necessary for an end-user to rebuild the software.
For some embedded system scenarios, you would require the embedded system vendor to disclose his developer tools and APIs to any end users and this might not be possible. It is not clear if something like the iPhone or Windows SDKs can be freely redistributed to fulfill the obligations in this case, you might want to discuss with your lawyers and find out how comfortable you are with the exposure of the requirements.
What you can do
If you absolutely need to use some LGPL code in an appstore or an embedded system, you can always reach out to the original authors of the code and ask them to grant you a license to the code under different terms.
Alternatively, you can look for alternative implementations of the library under other laxer licenses like the Apache 2 License, the Microsoft Public License or the MIT X11 License.
关于 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) 根据本许可证的条款传达最小对应源代码，并以适合的形式并根据条款传达相应的应用程序代码允许用户按照 GNU GPL 第 6 节指定的用于传达相应源代码的方式，将应用程序与链接版本的修改版本重新组合或重新链接，以生成修改的组合作品。
Regarding the LGPL, I believe that St3fan is incorrect, but Louis Gerbarg is correct: it is possible to use LGPL libraries in closed-source iPhone apps, but with restrictions.
If you take a look at http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License, you can read "Alternatively, a statically linked library is allowed if either source code or linkable object files are provided."
So as Louis Gerbarg mentioned, if you use an LGPL library, you are allowed to keep your application closed-source as long as you make freely available the object (e.g. *.o) files that are needed for your customers to take your application and link it.
I go in depth into the subject of iPhone and LGPL compatibility here.
Detailed requirements on your app imposed by the LGPL license of the library:
d) Do one of the following:
0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
Apple App Store 与 FSF 的 Copyleft 理念不兼容，该理念存在于 GPL 和 LGPL 以及 Affero GPL 的所有版本中。 Apple App Store 不允许用户获取自由软件、对其进行修改，然后在自己的设备上自由运行。 他们要求你使用 DRM、每年支付 100 美元、同意他们的附加条款等等。这里有一篇很好的文章：http://michelf.com/weblog/2011/gpl-ios-app-store/
在 App Store 之外分发适用于 iOS 的 GPL/LGPL 软件是完全合法的，问题出在Apple App Store上。 所以我建议游说苹果改变他们的限制。 Mac OS X 和 iOS 甚至从根本上依赖 GPL/LGPL 软件（例如 gcc 等），因此 Apple 享受着自由，但同时又剥夺了用户同样的自由。
至于 App Store 兼容的许可证，您需要使用非常宽松的许可证，例如 BSD、MIT、Apache 或公共领域。
The Apple App Store is incompatible with the FSF's copyleft idea which is present in all versions of both the GPL and LGPL, and also the Affero GPL. The Apple App Store does not let users take Free Software, modify it, then run it on their own devices freely. They require you to use DRM, pay $100 a year, to agree to their additional terms, etc. There is a pretty good write up of this here: http://michelf.com/weblog/2011/gpl-ios-app-store/
It is completely legal to distribute GPL/LGPL software for iOS outside of the App Store, the problem lies with the Apple App Store. So I recommend lobbying Apple to change their restrictions. Mac OS X and iOS even fundamentally rely on GPL/LGPL software (e.g. gcc and many more), so Apple is enjoying the freedom yet it is denying its users the same freedom.
As for licenses that the App Store is compatible with, you will need to go with the very permissive licenses like BSD, MIT, Apache, or public domain.
我认为 LGPL 不适用于 iPhone 应用程序。
问题是 iPhone 运行时不允许您将共享库（或框架）与您的应用程序捆绑在一起。 仅允许单个二进制应用程序。 LGPL 基于将共享库与应用程序捆绑在一起的假设。 直接链接仍然被禁止。
I don't think LGPL will work for iPhone applications.
The problem is that the iPhone runtime does not allow you to bundle shared libraries (or frameworks) with your app. Only single binary applications are allowed. The LGPL is based on the assumption that you bundle a shared library with an application. Direct linking is still forbidden.
这不是法律建议，我不是律师，但听起来您需要一个具有 BSD 或 Apache 许可证的库。 如果您正在开发使用开源库的专有桌面程序，就会出现这种情况。 我不知道苹果是否对iPhone应用程序有进一步的限制。
This is not legal advice, I am not a lawyer, but it sounds like you need a library with a BSD or Apache license. That would be the case if you were developing a proprietary desktop program that used an open source library. I don't know if Apple has any further restrictions for iPhone apps.
（我不是律师。）
静态目标文件链接可能会解决如何允许使用 LGPL 许可代码的应用程序在不分发其源代码的非 LGPL 部分的情况下可用的问题。
但似乎 LGPL 作为 GPL 的变体，给 iPhone 应用程序开发带来了一个更大的难以克服的问题，因为创建和分发任何 iPhone 应用程序所需的开发工具只能根据与 GPL 不兼容的 Apple 条款提供。 IE。 每年需要支付 100 美元的费用，并且使用这些工具有许多条款和条件，这些条款和条件不属于 GPL 许可证的一部分。 Apple iPhone 开发者工具的许可条款似乎与 GPL 的精神甚至文字不相容。
(I am not a lawyer.)
Static object file linking may address the question of how to allow an app which uses LGPL licensed code to be made available without distributing the non-LGPL'd portions of its source code.
But it seems like LGPL, as a variant on GPL, imposes a larger insurmountable problem for iPhone app development in that the development tools needed to create and distribute any iPhone app are only available under terms from Apple that are incompatible with GPL. ie. There is a $100/year fee, and there are numerous terms and conditions on the use of those tools that are not part of the GPL license. The terms of the license for Apple's iPhone developer tools seem to be incompatible with the spirit of and perhaps also the letter of GPL.
如果您不发布源代码，则无法使用任何严格的 Copyleft 许可证。 在任何情况下都不能使用任何基于 GPLv3 的许可证，因为 iPhone 分发与 no-Tivoization 条款相冲突。
如果您使用 LGPLv2，则必须以可链接格式提供程序，这可能会也可能不会被接受（至少它不是源代码），并且这可能是您不想处理的事情，除非图书馆提供很多好处。
如果该库只有一位版权所有者，您可以随时查看是否可以获得许可例外。
对于典型的 BSD/MIT/Boost/任何宽松的许可证，您不会有任何问题。 有很多开源/自由软件许可证，其余的您必须阅读它们并查看。
If you're not releasing your source code, you can't use any strict copyleft license. You can't use any GPLv3-based license in any case, since the iPhone distribution conflicts with the no-Tivoization clause.
If you're using LGPLv2, you'll have to provide your program in linkable format, which may or may not be acceptable (at least it's not source code), and this is likely to be something you don't want to deal with, unless the library offers a lot of benefit.
If there's one copyright holder on the library, you can always see if you can get a license exception.
You won't have any problem with the typical BSD/MIT/Boost/whatever permissive licenses. There are a lot of Open Source/Free Software licenses out there, and for the rest you'll have to read them and see.
当我尝试将 Fuego 移植到 iPhone 上时，我在 < a href="http://sourceforge.net/mailarchive/forum.php?forum_name=fuego-devel" rel="nofollow noreferrer">fuego 邮件列表。 到目前为止，我的理解是“LGPL 与 AppStore 不兼容”。 以前的 问题也得到的答案是：不。
When I try to port Fuego onto iPhone, I asked a similar question on the fuego mailing list. So far, my understanding is "LGPL is not compatible with AppStore". A previous question also receives an answer as: no.
Wunderradio 就是一个很好的例子。 他们使用 ffmpeg 和其他 LGPLv2 许可的框架，并在其网站上提供 .o 文件。
奇怪的是，他们还为其应用程序提供了完整的源代码。
http://wunderradio.com/code.html
A good example is Wunderradio. They use ffmpeg and other LGPLv2 licensed frameworks, and provide the .o files on their website.
Strangely, they also provide full source code for their app.
http://wunderradio.com/code.html
那些认为 App Store 服务条款有问题的人，尤其是每年 100 美元的 Apple Dev 计划费用，是错误的。 这 100 美元还远远不够。 开发商的典型特征是，他们花费大量时间担心此类事情；0) 数千年来，律师一直在围绕合同条款进行严格处理，而这些几乎不值得失眠。
先决条件：
从可通过应用程序中的链接访问的 Web 位置提供目标文件和基本项目文件。
选项 1，针对牛仔：
越狱是正式合法的（并且免费）。 仅此一点就消除了对 LGPL 和 App Store 条款之间兼容性的任何担忧。 LPGL 在哪里指定特定的分销渠道？ 无处。 您想升级通过应用程序商店下载的应用程序中的静态链接库吗？ 忍住吧，阿尔法开发者，越狱你的手机！ 仅仅因为苹果是操场上的恶霸，并不能强迫你留在他们的旋转木马上。 因此，有进取心的开发人员可以在下次聚会上获得宝贵的吹嘘权利。 另外，您为了升级 LPGL 库而越狱手机的事实使您可以访问理查德·斯托曼地下室的小桶室！
合法且善意地规避此问题的选项 2：
LGPL v2.1 第 1 节（以及 GPL v3 第 4 节）允许开发人员对复制库的物理行为收取费用。 这为开发者提供了一种机制，可以将该费用重新分配到 99 美元的 Apple Dev 订阅费中。
100 台设备的限制怎么样？ 希望升级二进制文件的最终用户正在升级商业应用程序，因此应用程序开发人员自己的许可条款将发挥作用。 在自定义许可协议中添加 100 台设备的限制非常简单。 有多少人拥有超过 100 台 iOS 设备？ 就连乔布斯也没有拥有那么多！ 这并不是一个不合理的限制。 鉴于没有要求最终用户被允许将他们自己的原始商业应用程序的修改版本发布到野外，当它无法在修改者的第 101 位朋友的设备上加载时，就没有投诉的依据。
LGPL 中没有要求最终用户必须有一个舒适的、无风险的、甚至是显而易见的选择。 他们只需要有一个选择，而且有两个非常好的选择。
The folks who maintain that the App Store terms of service are problematic, in particular the $100 yearly Apple Dev program fee, are wrong. That $100 is not even close to a showstopper. It is typical of developers that they spend so much time worrying about these type of things ;0) Lawyers have been stick-handling around contract provisions for thousands of years and these are hardly worth losing any sleep over.
Prerequisite:
Provide the object files and a basic project file from a web location accessible via a link in the app.
Option 1, for cowboys:
Jailbreaking is officially legal (and free). That alone voids any concerns over compatibility between LGPL and the App Store terms. Where does the LPGL specify a particular distribution channel? Nowhere. You want to upgrade a statically linked library in an app you downloaded via the app store? Suck it up, alpha dev and jailbreak your phone! Just because Apple is a bully in the playground doesn't force you stay on their merry-go-round. Enterprising developers can thereby receive valuable bragging rights at the next meetup. Plus the fact that you jailbroke your phone in order to upgrade an LPGL library gives you access to the keg room in Richard Stallman's basement!
Option 2 for getting around it legally, and in good faith:
Section 1 of LGPL v2.1 (and section 4 of the GPL v3) allows developer to charge a fee for the physical act of copying the library. This provides a mechanism for the developer to re-assign that fee towards the $99 Apple Dev subscription fee.
What about the 100 device limit? End users who wish to upgrade their binary are upgrading a commercial application, so the app developer's own license terms come into play. It is trivial to add a 100 device limit to a custom license agreement. How many people own more than 100 iOS devices? Even Jobs didn't own that many! It's hardly an unreasonable limit. Given that there's no requirement that an end-user be allowed to release their own modified version of the original commercial app into the wild, there will be no basis for complaints when it fails to load on the device of the modifier's 101st friend.
There is no requirement in the LGPL that the end user has to have a comfy, risk-free, or even obvious choice. They just have to have a choice, and there's 2 perfectly good ones.