licensing – Choosing the right license for an open-source Objective-C project to avoid problems with the App Store?


In connection with the upcoming attestation of an iOS application in the App Store, I thought about

какую лицензию выставить простому open-source проекту, расположенному на Github-е?

Due to ignorance, I imagine that I need some kind of the simplest, most free license:

  • I am not responsible to anyone for my code
  • Nobody is responsible to me for my code, its modification and use;)
  • Due to the simplicity of the project and its specificity, it is ridiculous to talk about any "commercial purposes" and so on.

If there are several such simple licenses, I will be glad to see a description of their differences. Any further clarification about licensing simple and unambiguous open-source code on github is also welcome.


Yes, I know there are sites like .

But it would be convenient for me, say, to see answers like "I already have n projects on my github – and I use such and such licenses" before starting to delve into all this number.

In other words, find out what specific simple licenses people are successfully using for their projects (examples are welcome) so that these projects are approved by the App Store.


I figured out what licenses are and, more precisely, which license I should choose.

Judging by the fact that not a single detailed meaningful answer appears, I conclude that I must write the answer to this topic myself. And I will definitely do this after the project as part of the application appears on the App Store.


Finally, we got around to writing an answer on the licensing topic.

1.5 years have passed since the creation of this topic, and although during this time I personally have never had to face the problems of licensing my own or using someone else's code, it seems to me that the minimum concept of licensing is necessary for any developer. I will try to note a few points that I consider to be key for myself:

The lack of a license for the project is bad

This thing may not be obvious at all, but a project that does not contain a license is maximally protected: all rights belong to the author, and you cannot use it in any way. Dot.

No license

That is, if you use a project without a license, you expose yourself to risks of uncertain size and quality, which are proportional to the "seriousness" of the project and coincidence. If you publish somewhere, such as on Github, your own framework-library project without a license, you are putting someone else at risk.

In one of the articles, the links to which I give below, there is advice (I quote freely): "if you notice that there is no license in a certain project on Github, create a pull request and offer the author some free license like Apache License v2. If he's out of his mind, he'll think, if not, then at least you tried. "

The algorithm for parsing licenses, which is used in the AppStore review process, is not harsh, but it should not be neglected anyway

Now, having a little more knowledge about licensing, I understand that Apple either does not see many flaws in licensing, or "deliberately" ignores.

For example, in one of my applications, I included several times a very heavily modified version of the third-party library, which is distributed under the Apache License v2. According to this license, I had to document all my changes in the headers of the modified files. Of course, I didn’t do it out of ignorance. Obviously, no one paid attention to this, and I have never heard from colleagues so far that they are faced with Apple's attention to such minor flaws.

Common sense and the lack of information about the opposite make us think that the AppStore is missing applications with much gross violations of licensing, and that it most likely depends on how big the fish is: the amount of money tied to the application, the size of the target audience, etc. etc.

Despite the lack of apparent strictness on the part of Apple, now I quite strictly follow the license rules that are specified in third-party projects and now I automatically always pay attention to which license is in front of me, whether it has any special additions, edits, etc. etc.

The need for a license file in the project (and in the source files of the project)

For example, if your project is using an MIT license, then simply stating “this project is using an MIT license” will not be enough.

Here is an excerpt from the MIT License :

The above copyright notice and these terms and conditions must be included in all copies or significant portions of this Software.

Therefore, in the case of MIT, a file with a LICENSE license must be present in the root of the project, and it is highly desirable to have the license text in the header of each source code file, Example: Alamofire .

In the case of the Apache License 2.0, a license file is also required, but there is no need to include the text of the license itself in the source code files, just a link to the license will be enough, Example: Realm .

Choosing a license

The MIT License is the most common license for iOS / OSX projects on Github. If there is no desire at all to understand licensing, you can absolutely safely choose it and consider that the issue has been resolved, but it is better to know at least about the following types of licenses:

Apache License 2.0 and BSD 2-clause “Simplified” License .

Good to know that GPL licenses are not compatible with the AppStore: Is it possible to have GPL software in the Mac App Store?

iOS / OSX dynamic frameworks / CocoaPods / Carthage

The licensing issue is perhaps becoming a bit more acute due to the fact that with the advent of iOS dynamic frameworks, more and more iOS developers are now starting to use CocoaPods with the use_frameworks! option use_frameworks! , many are switching to Carthage, and some are switching to manual frameworks altogether. All three of these methods assume that there are many folders with the .framework extension that lie inside the application archive, separately from it, which automatically hints at the need for LICENSE files in the folders of these frameworks.

A good example would be a Realm database that supports all of the distributions listed and contains a compound license file in its Realm.framework / Resources . By the way, there are very interesting lines in this license, according to which, if I understand correctly, a Realm user cannot be in the countries of Cuba, Iran, North Korea, Sudan, or Syria:


You understand that the Software may contain cryptographic functions that may be
subject to export restrictions, and you represent and warrant that you are not
located in a country that is subject to United States export restriction or embargo,
including Cuba, Iran, North Korea, Sudan, or Syria, and that you are not on the
Department of Commerce list of Denied Persons, Unverified Parties, or affiliated
with a Restricted Entity.

(now I can very easily imagine myself as a citizen of Iran who, regarding this license, will write a letter to the Realm developers asking them to clarify this point).


In addition to the service for choosing a license, which @aknew recommended: Software Licenses in Plain English , there is another one, also interesting: Choosing an OSS license doesn't need to be scary .

And here are two articles that I highly recommend everyone who is interested in this topic to read:

Github needs to take open source seriously

Using CocoaPods Without Going to Court

Scroll to Top