License Compliance: How to be a Good Open Source Citizen

By Heather Meeker
Heather MeekerThis is the second half of a two-part series on how start-ups can best use open source software without accidentally getting themselves into a legal bind. The first article in the series can be found here.

As I showed in the previous article, the rules for complying with open source licenses can seem complicated, but you can get most of the way to compliance with some simple guidelines. If you follow these rules you will be on the right track. If you want to do something different than what is outlined below, it may be OK, but you should ask your lawyer.

  • Development Tools. If you are using software for development or testing purposes only, and solely within your company (not to be given to anyone else, such as in a beta test or as part of the distributed SDK or test kit), it’s OK to use software under any open source license. Remember that run-time libraries (like LIBC++) don’t qualify for this rule – they are not just development tools, and are actually a part of your product. You need to consider their license terms separately.
  • SAAS and Cloud Deployment. For server side code in an SAAS or cloud product, the only major open source license you need pay much attention to is Affero GPL. Most open source licenses have no conditions for SAAS use. Remember: SAAS and cloud systems all distribute some software elements — notably Javascript. For those elements, follow the rules below for distributed software. Remember: startup business models can change rapidly, so you may want to operate as if you are distributing your software, even if your company is currently only providing SAAS.
  • Distributed Software. In any distributed software, only use:
    • software under permissive licenses, like MIT, BSD or Apache,
    • GPL software that executes 100% in its own process with no other linked code,
    • LGPL software used only as a dynamically linked library, and
    • other copyleft software (under licenses like Eclipse Public License, Mozilla Public License, or CDDL) for which you have not modified the API.
  • Mobile Apps. This is a special instance of distributed software. In mobile apps, only use software under permissive licenses. It is difficult to abide by the requirements of LGPL or GPL in mobile apps, given the rules of the app stores.
  • Loadable Kernel Modules for Linux. Someday, one of your engineers will come to you and say, “Let’s distribute a proprietary LKM.” That person will have a clever scheme in mind for avoiding GPL. It won’t work. Don’t do it. Everything in the kernel must be GPL.
  • Don’t use code with no license terms. No license terms means no license. If you find code with no license, ask the author to apply a permissive license, like MIT or even CC0 (a public domain dedication).
  • Myths. All of these commonly held beliefs are not true.
    • It is OK to dynamically link to GPL code, but not to statically link to it.
    • It is OK to use a GPL library if it isn’t built in the product, and make customers download it and build the product instead.
    • It is OK to use software on the internet, if there are no licensing terms.
    • Beta tests don’t count as distribution.

Contributions and Releases

Do not sign a contribution license, contribute to an open source project run by someone else, or release your software under an open source license without talking to your lawyer first. Contributing and releasing code may be the right choice for your business, but you need to make the choice wisely. Once you make a contribution or release, the IP rights you had in the software probably will never again be a basis for valuation of your company. Talk to your lawyer first to make sure you understand your choice.

This document is available under the Creative Commons Attribution-NoDerivs Unported 3.0 License

The no-derivs license is applied to avoid inaccuracy and misunderstanding. If you wish to request other terms please contact Heather Meeker, O’Melveny & Myers,

Attribution: Copyright 2014 Heather Meeker