Using CocoaPods Without Going to Court
CocoaPods makes it dead easy to pitch code into your app from many authors under many licenses. But beware: thanks to CocoaPods, you can also get yourself into license trouble faster than ever before!
You see, every CocoaPod is distributed under the terms of a software license. The license makes demands of you. In return, you get to use the software. But if you don’t meet the license’s demands, you lose the right to use that software. Then you’ll have to delete the pod and do something else. Otherwise, you face:
Having your app rejected.
Heading to court.
Before we get started, let’s be clear: this isn’t legal advice. Go see a legal professional if you’re in a license-related pickle. If you’re worried for no good reason and it’s impacting your quality of life, see a psychiatrist instead.
Not Just a Cocoa Problem
Even if you’re not a CocoaHead, this still applies to you. Just replace CocoaPods with gems/modules/packages/what-have-you, and hum loudly when we discuss the App Store. Those of us in Cocoaland are just glad we finally get the chance to infringe at the speed of light, too.
Different licenses might be popular in your world. Check out tl;drLegal for the gist, then dig into the license text itself for a delicious meal of legal spaghetti. Additionally, many license authors also publish a FAQ. This can help a lot with understanding and applying the license.
No License, No Go
If there is no license, the default license applies: The author has exclusive right to the work, and you can’t use it. Period.
Apple’s done us no favor by including an exclusive copyright statement in new file boilerplate. Many projects do not take care to amend this boilerplate text in the individual source files, which can be unsettling. When in doubt, check the README, LICENSE, or COPYING file to see if some other license governs. If you can’t find one, delete the code from your app with prejudice.
Whenever you copy in a component’s source code, be sure to preserve its license statement. CocoaPods does this right, but if you’re adding a third-party component by hand, take care.
Academic Licenses: Notice & Terms
The most common demand a license makes is to include the copyright notice and license terms in your app. The MIT license puts it like so:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
You should assume that every pod makes this minimal demand. CocoaPods does, and it will help you meet it by pasting all your pods’ licenses into a single, large acknowledgements file. This file comes in two flavors:
Markdown for display in your app
Plist for inclusion in a Settings bundle
Displaying this information makes it easy for users to see which components you used. It also gives the authors credit. That said, just including the notice and terms in your app bundle might be enough. Every copy of your app will then include them.
Most so-called academic licenses make no substantive demand beyond this. Common academic licenses include:
On top of the usual notice and terms rigmarole, the Apache license adds, “You must cause any modified files to carry prominent notices stating that You changed the files.”
Source control makes it easy to check whether you’ve modified an Apache-licensed file. If you did, stick a comment right after the Apache license boilerplate, something like, “MODIFIED (YEAR) BY (NAME). Modifications licensed under (LICENSE).” Prominent notice given; problem solved.
There’s one more thing: If the library includes a NOTICE text file, then you need to include that in your app bundle alongside the usual notice and terms. If there is no NOTICE file, you get to skip a good block of legalese; count yourself lucky!
Since our sole option is statically linking to others’ code, using LGPL’d software requires offering to make the object files for our app available to users on request. The intention is that they can swap in their own version of the LGPL’d code we’re using, link all the object files together, and run the software.
I recommend you steer clear of using any LGPL-licensed software in a close-sourced app.
The GPL is the GNU General Public License.
You can’t use code licensed under any version of the GPL in any app distributed in the App Store. The GPL forbids adding any terms and conditions above those of the GPL. The App Store’s Terms of Service add additional terms and conditions, so no GPL code can legally be in the App Store. This has already caused Apple to yank the VLC media player app and an iPhone port of GNU Go from the App Store.
If you’re not headed to the App Store, feel free to pull in a GPL library. Just remember that you’ll have to GPL-license your code, then, too.
Will It Blend?
Some licenses are incompatible with other licenses. That sometimes means you can’t use code under those licenses simultaneously in your app. That’s not an issue with most common licenses today, barring the GPL variants, so you likely needn’t worry about it. Much.
There’s no substitute for reading the licenses of the code you use and making sure you understand them. Do your due diligence a few times, and you’ll have the interactions between common licenses down pat.
If you don’t comply with a library’s license terms, you’re violating the law.
Use BSD- or MIT-licensed code with abandon. Just ensure that the license and copyright notice ends up in your final app bundle.
Use Apache 2.0-licensed code freely. Add its copyright notice and license to your app bundle as with BSD- and MIT-licensed code. Be sure to copy in the full text of the license in its multi-page glory.
If you change any of the Apache-licensed files, you need to add a prominent notice to that effect. Nothing says prominent like using caps lock.
If there’s a NOTICE file, copy it into your app bundle, and consider providing it somewhere the user can view it. Off in the Settings app is a good place.
Skip LGPL- and GPL-licensed code, unless you like headaches or getting your app yanked from the App Store.