An important part of keeping costs down for your Android app development is to reuse code – including your own as well as open source code.
Welcome back to part two of three in this article series about understanding and working with licenses for both code and image assets for your Android apps.
Also be sure to check out part 1, which explains various types of image licenses you may come across.
This article is about licenses for code. There are so many licenses available for code that it can get to be very confusing.
Public Domain, Closed source, and Open Source
This is a can of worms in itself, but a quick definition before we go on.
Public Domain refers to software (or anything else) that is free from copyright or any other kind of protection. It’s freely available to the public.
It is likely that any public domain software was explicitly gifted to the world by the author, because:
- Copyright laws offer long periods of protection
- Closed source software from defunct companies rarely sees the light of day
- You’ll likely want to reuse software that is relatively new
Most software in the world is closed source – millions of lines of code that nobody will see except for the developers at the company that owns the code. Not really of much importance to us here, except that:
- You might pay to use closed source libraries in your software, which will be subject to the licensing terms of the offering company.
- You want to ensure that your own closed source code stays that way, and that you don’t inadvertently obligate yourself to showing it to the world.
That second point bears more discussion – and we’ll get back to it in a minute.
Open Source is the most common code you’ll come across, but it comes in a countless number of flavors – different licenses that have specific restrictions.
To simplify the open source world, several organizations have created boilerplate licenses that anyone can apply to their code. These licenses make it very easy to recognize major differences between what is allowed, if you know what they mean.
It would be impractical for me to list all of the licenses that you might come across, but the Open Source Initiative maintains a list of open source licenses that you may want to check out.
A few software licenses that I have come across recently:
- Apache Software License, 2.0 – This is the preferred license for the Android project, and you’ll find not only much of the source of Android in this license, you’ll find popular shared projects (such as Google’s DashboardLayout from the iosched 2011 project) under this license as well. This license is fairly easy to comply with – you often just need to include the license notice with any Apache code that you use.
- Android Individual Contributor License Agreement – This is based on the Apache license grants, and retains many rights for the contributor while allowing the code to be used in derivative works of the Android project.
- GNU General Public License(GPL) – Some code (particularly updates to the Linux kernel) are under the GNU license, due to the code that was being modified. An important distinction of the GNU license is that code based on GPL code must be also released under the same license. As there are several distinct versions of the GPL, it is important to do the research to understand each license that you come across.
There are dozens of other licenses in the wild, and there isn’t any way around it – you’ll need to research each one you use to understand the implications of using that code.
Here’s one older, but well written guide to open source licenses from Smashing Magazine.
Considerations for including open source code
A decision for what types of licensed code to use for your projects should involve both your business needs and your philosophy on software. Many people believe that software should all be free, but your business needs may differ.
DO
- Research the license of code BEFORE you put it into your project. After you release it, it is too late to take it back – even if you remove the offending code in future releases.
- Understand compliance issues with GPL, as described here.
- Understand how to be compliant with the Apache 2.0 license
- Isolate open source code into library projects (by license type), to simplify compliance
- Include copies of the license and other required items with every distribution of your software
Do NOT
- Include GNU (or similar) open source code in modules that you don’t want to release the source code for. You will be responsible for releasing any source code that is commingled with that open source code.
- Assume that nobody will notice – several products have been shown to have blatantly violated the terms of the GPL. Those companies are now facing lawsuits and their reputations are suffering. You don’t want to build your business on shaky ground.
- Include open source code in your working project with the assumption that you will fix things up before releasing – it is easy to forget those details.
Onwards to inexpensive, high quality Android apps
Hopefully you’re a little better prepared to safely and correctly use open source code in your next Android app. If you have experiences or advice with working with open source code, please share them in the comments section below or send me an email.
In the next part of this series, I’ll cover a few resources that have been helpful to me in finding code and image assets to use in my Android apps.
If you can’t wait for more, be sure to browse for other articles on:
- Android App Markets – where to distribute or sell your Android apps for maximum exposure
- Android Ad Revenue – maximize your ad revenue with these articles on ad networks and how to get the best out of them for your apps