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 ?
相关问题
- CALayer - backgroundColor flipped?
- Core Data lightweight migration crashes after App
- How can I implement password recovery in an iPhone
- how do you prevent page scroll in textarea on mobi
- Custom UITableview cell accessibility not working
相关文章
- Could I create “Call” button in HTML 5 IPhone appl
- Unable to process app at this time due to a genera
- How do you detect key up / key down events from a
- “Storyboard.storyboard” could not be opened
- Open iOS 11 Files app via URL Scheme or some other
- Can keyboard of type UIKeyboardTypeNamePhonePad be
- How do I set compatible devices to only ARKit comp
- Can not export audiofiles via “open in:” from Voic
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.
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.
(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.
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.
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.
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