Spark the innovation within you.

When was the last time you did something new?

engineering

Linting licenses

share

Dependencies are at the core of programming. In iOS, we often use Cocoapods to manage dependencies in our projects. But if we are not careful, we can add a dependency that is not free to use, and expose our company to legal issues later. That’s why it’s really important to verify the LICENSE files of each dependency before adding it. But we all know that humans make mistakes, so in this article, we’ll cover how to automate the process of verifying each dependency. Note: If you want to know more about the different kinds of licenses, go check https://choosealicense.com/.

Listing the licenses

First of all, if you want to quickly see the state of the licenses in your project, I created a gem called ADLicenselint that lists the licenses for each pod in your Podfile.

To use it, install the gem and run ad_licenselint in the directory that contains the Podfile.

Note: by default the gem prints the dependencies that have licenses not free to use, but you can print the whole list with the --all option:

You can check all the other options on the github page directly.

Under the hood, the gem uses the plists generated by Cocoapods during the pod install. The plists are located here: Pods/Target\ Support\ Files/Pods-MyApp/Pods-MyApp-acknowledgements.plist.

Here is an example of one entry in the plist for the pod Alamofire:

The gem simply parses this file and extracts the informations for each pod. By default, the licenses automatically validated are MITApacheApache 2.0 and BSD. Every license that is not included in this list will be considered unsafe.

Using it with fastlane

Along with the gem, you can find a fastlane plugin that can be used in your Fastfile.

First add the plugin to your Pluginfile:

Then call the ad_licenselint action with your parameters:

The summary is a string and can be printed as is, whereas the report hash has the following structure:

Automation

Once we have access to the license linter in our lanes, we can imagine some nice use cases.

Pull request comment

Let’s say you want to post an automatic message to your pull request if you detect that a pod with a commercial license has been used.

For instance, let’s add ObjectivePGP (with a commercial license) and update ADUtils (with a MIT license) in our Podfile.

Once the pull request is pushed to Github, here is an example of an automatically posted message:

With this warning, the developer can check if he really wants to use this dependency or not.

The code to automatically post this message in a pull request can be found here. In this case we use the formatted report summary available in lane_context[:AD_LICENSE_LINT_SUMMARY] after we called ad_licenselint.

Note: what is interesting here is to use the gem cocoapods-core to get the list of updated pods for a branch. This library is useful if you want to manipulate the Podfile and Podfile.lock backing models.

The following snippet shows an example of what you can do with the library:

Pull request review

You could also imagine posting a review directly to the Podfile in the pull request.

For instance if we add the same pod ObjectivePGP, we can create this automatic review:

The code to automatically post this review in a pull request can be found here. This example uses the report summary hash available in lane_context[:AD_LICENSE_LINT_REPORT] after we called ad_licenselint.

Note: to interact with the Github api, we use the octokit gem that is really simple to use:

Conclusion

The earlier you know a dependency is not compatible with your project, the earlier you can reject it and search for another alternative. The best option is always to go to the Github page of the pod and check the LICENSE file, but ADLicenselint has been developed to act as an extra safeguard.

The fastlane plugin along with the gem should give you all the tools you need to use it in your workflow if you want to automate the linting process.