I'm writing an iPhone app, and I would like to use a 3rd party library for part of its functionality. I intend on selling it through the App Store and my code will not be open sourced. Which open source licenses allow to make derivate works and publish them under apple's own conditions ?
Which open source licenses are compatible with the Apple's iPhone and its official App Store ? [closed]
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.
What if the software you want to link to the LGPL is GPL? There would be no problems there, right? –
Phonon
replying to myself: fsf.org/blogs/licensing/… , meh! what a trap –
Phonon
@Coloratura The makers of Sparrow acknowledged the inclusion of LGPL libraries, and put up this web page, which they must believed removed any legal obstacles. sprw.me/lgpl.php Is this sufficient in your opinion? –
Markettamarkey
Regarding the $99 Apple Developer fee: "There is no room for having the downstream recipient have to enter a separate agreement with Apple". Q: Is there a room to enter a separate agreement to buy a compiler or a computer or pay for internet connection? These are all necessary for the user to be able to relink the code. How are these different from the Apple Developer fee? –
Dwelling
This might have changed. Apple recently removed the need for an developer program to deploy to devices, so anyone should be able to relink without fee. This would imply it now is in fact compatible with the LGPL. –
Si
great answer! my understanding is that the portion of the application's code under the LGPL license must be open to all, including buyer of your software. You don't need to open source your own written portion of the application. Therefore it is best to either dynamically link or find a laxer license, am I correct? –
Antho
I was thinking of the term "distribution". Am I right to think that for apps on appstore, it's actually Apple that is distributing it, and thus eventually apple that is violating the terms? IDK... –
Berryman
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.
There are a number of apps currently using LGPL libraries (ffmpeg, among others) on the app store now. Regardless of legality, people are doing it. –
Hogshead
Apple won't care (it's not their job to police this), but the developers of ffmpeg can assert their rights at any time. It's a risk. –
Turpeth
The developers of ffmpeg don't consider use on iPhone to be a violation of the license. –
Entrust
That Wikipedia quote ends with [citation needed]. If you google that quote, all links point to the Wikipedia article. I don't mean to be negative, but I read through the LGPL 2.1 and AFAIK things are not that black and white; but I can't wait to be proven wrong. Are you basing this answer solely on that quote? –
Hue
The important thing is how the copyright holders of any LGPL (or GPL even) code you want to use interpret the licnese, because it is they who would be able to have your app pulled (or worse). How anybody else interprets it is fairly irrelevant. So, if you are pondering using LGPL or even GPL code in an app, you need to hope the code has a single or small set of copyright owners, and just ask them nicely. –
Campion
Even high profile apps use LGPL and make loads of money with it, and it seems to be ok - like Sparrow for iOS. sprw.me/lgpl.php –
Amputee
@steipete, and all of you who do, are at the mercy of the copyright holders of the LGPL licensed holders' work. I personally believe many chose LGPL without a very thorough understand of how it works, or, alternatively, back in a day before the iOS App Store was relevant (to them). Back in the classic Windows desktop and normal Unix/Linux days, pre-appstore, LGPL was almost as liberal as X11 or MIT license, if you didn't intend to change the library itself, only use it. So I think a lot of LGPL library authors are OK with with its use on iOS. But they should state that exception. (As some do.) –
Davie
Appears your blog went down. Can you update it? –
Sb
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 recommend lobbying Apple to change restrictions because it can't. Apple needs to pay salaries to software reviewers and traffic costs of app downloads—even for free apps. $100/year is quite reasonable. Instead, you should lobby the library authors to change licensing from LGPL to something that doesn't require free unrestricted modifiability of end software by users. For example, a year ago cocos2d moved from LGPL to MIT license. –
Cockalorum
I think you are mistakenly equating to things that do not belong together. Apple has many lots of money over the past decades selling software without DRM. The App Store and its DRM requirement is new. Also, there are many companies and people that make money selling GPL software. RedHat, Digium (Asterisk), Cygnus Solutions, MySQL, etc. –
State
Also, Apple now sells more music without DRM than with. –
State
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.
Direct linking is not forbidden by the LGPL. The license explicitly allows static (direct) linking; you just have to make object files available in that case. –
Transparent
@JosephH: It also has to be possible for the end user to replace the library with a modified version. That seems to be impossible on an iPhone. –
Lighting
@Lighting : It might be possible for an end user to buy a new Mac and purchase a $99 developer license from Apple, which would enable the use of all the tools required to build and install from object files onto an iPhone. –
Nollie
@hotpaw2: So you are saying he has to purchase an additional license to be able to use his LGPL rights? I don't think the LGPL allows for that. –
Lighting
@Lighting The LGPL does allow for that - on other platforms there is no free compiler, it is a perfectly acceptable that a user who does not possess a compiler or other necessary tools is unable to compile a replacement binary. You are partly right though; the appstore T&Cs are incompatible with the LGPL - many authors of LGPL software (with the FSF being a notable exception) view this only as a technical violation of the license, and allow usage of the LGPL libraries on the iphone. (This relates to LGPLv2; LGPLv3 may be slightly different.) –
Transparent
Remember that the LGPL was written way back in 1991 when it certainly was not the rule that compilers are free, as people seem to think is the rule today, if Linux and other FLOSS operating systems is what you work on. Back then compilers for what was then normal desktop systems were seldom free. –
Campion
@Campion it was written by the people who made the free GCC compiler, with an agenda to spread it. –
Davie
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 will impose additionally restrictions. Since the phone does not support dynamic linking, and the LGPL requires you be able to substituted in modified copies of the code you will need to provide a partially built copy of the app someone can use to relink against modified version of the lib. –
Diatomic
Thanks for the clarification, I removed the suggestion to try LGPL from my answer. –
Decorum
(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.
One thing to remember in all this: it is totally legal and clear to make an GPL/LGPL app for iOS and distribute it outside of the App Store. It is the App Store that is the issue. –
State
static linking is specifically not allowed (it is dynamic linking that is a workaround, but you cannot dynamically link in an iOS app), see multinc.com/2009/08/24/… –
Conchitaconchobar
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.
Except the use can not relink the program if it's distributed through the App Store. So LGPLv2 is OK, but only if you distributed the app outside of the app store. (In practice that means through a jail-break channel, so, in practice, that means "no".) –
Davie
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.
Apparently, it is. But they closed that loophole in v3. –
Amputee
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.
An example is not an argument. We can all provide examples for all possible permutations of (mis)use of licensed software. –
Davie
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.
You are deep into liberal interpretation here. All of these hurdles can just as well be interpreted as unjustifiable hurdles, by the authors of the LGPL library. –
Davie
You are evaluating the terms of the GPL without considering the downstream implications. You are treating "the developer" as a single person. But in fact there are at least 3 basic roles in the FOSS process. Initial originator of software (A). The person who gets the software from A and passes it along (B) and the person who ultimately gets it and wants to do something with it. To use GPL code with Apple, all three would need to pay the license fee. So there is no "the developer" who matches your description. –
Moose
© 2022 - 2024 — McMap. All rights reserved.