Let’s talk about ownership
4th March 2011 · 0 Comments
As a mobile application developer, one of the first discussions we have with prospective customers is about who needs to own the intellectual property rights of the code. The discussion about intellectual property can be confusing even for the smartest of us (and we’re pretty smart). Not only are there different types of intellectual property that can be created with every project, but there are numerous factors that determine who owns each intellectual property right created.
A common practice of application developers is to use open source code–and why not? It’s there, it’s readily available, easy to plug in, and it saves development hours, right? That may be okay if you’re building a short term campaign, but if your purpose is to build a business app that is going to make you lots of money that open source code may have financial and legal ramifications if you don’t follow the right path to ensure proper licensing.
The rise of the open source community has spawned a wealth of options for businesses looking to build quality software without the big expensive price tag. Development houses can plug in ready-made code instead of building their own, which in the end can save time and money. But there are considerations to be made when looking at incorporating open source code into your application that should be addressed before any work is done on the project. Addressing the needs of the business around ownership and property should be done upfront to avoid assumptions which can leave you not owning anything.
What is open source?
Open source refers to any piece of software code that has been shared with the development community to use without expectation of financial compensation. This “free” code is maintained and built on by the open source community and often represents a collaborative effort to create software across many developers that is constantly updated and improved.
Knowing your ingredients
Building a software application is a lot like buying a burrito for lunch at a gas station (stick with us here). Some people are in a hurry and just want something that fulfills their needs, and they don’t care what’s inside the burrito. They need it cheap and fast and don’t want to worry about the consequences. Others may read the ingredients but not understand what they really mean, and so are still making an uninformed decision about their lunch choices. Still others will read the ingredients, understand them, and decide whether or not to buy the burrito based on the information they’ve carefully weighed and considered.
When deciding whether or not to use open source code in your application, you should know your ingredients, what they mean for your product, and what the long term impacts are for the business. The decision of whether or not to use open source code in your application should be a discussion with your vendor at the very beginning of the project, before the scope of the work is even discussed.
Types of licenses
Most open source work is governed and protected by open source licenses that dictate how that code can be copied, distributed, modified, and sold. There are several licenses associated with open source work, and the rights they grant can vary. You not only need to know whether or not open source code is used in your application, you also need to know what licenses are associated with that code.
GNU General Public License (GPL): GPLs are the most common type of open source license, and have been around the longest. It grants the user the right to copy and distribute the software wherever they want and in as many places as they want, but requires that any other code used in conjunction with the GPL code also be licensed under the GPL. This gets tricky with paid and proprietary software applications.
BSD License: The BSD license grants the same rights to copying and distributing software as the GPL, but with more freedom for distribution practices. As long as notice of the license and warranty information is included in the software, you can use the code however you see fit. The main thing to note for BSD licenses is their clause about endorsements – users can’t take the names of contributors to the code and imply an endorsement for derivative works without express permissions.
MIT License: This is the shortest and least restrictive of the three major licenses. It provides all the same rights as the GPLs and BSD licenses, but does not contain any restrictions around distribution or copying. As long as notice of the license is included in the software, users are free to copy, distribute, modify, and sell the software.
For more information on the types of licenses associated with open source software and their terms, check out the list of approved licenses for the Open Source Initiative.
When discussing your project with your vendor it’s important to ask the right questions about the code used in your application. Asking the right questions up front so that you’re armed with the proper knowledge about the make-up of your project can save you a world of headaches down the road. Below is a list of helpful questions to ask when talking to your vendor, and your answers should help steer your conversation with them about using open source code in your application.
What you should ask yourself:
Do I plan on reselling this application?
If your answer is yes, then you definitely need to be aware of any open source code in your application. This often means you’ll need to include a notice of licenses and code used in the application. Also, some open source code can place restrictions on redistribution, so if you’re using open source make sure the license reflects your future plans.
Does this code need to be unique?
It might seem like a weird question, but it’s important to know why you might want to use unique code. If you’re selling an application that is dependent on a novel concept, using someone else’s code to build the majority of that application could get you in trouble later on. For example, if you plan to patent part of the process you don’t want to impede that process with open source licenses.
Is it worth the extra expense?
Proprietary code is more expensive to develop, so you need to weigh the option of using open source for cheaper, faster development against the need to own the source code. Custom programming in some cases is just expensive, but in other situations it can create more value in the product.
What you should ask your vendor:
Who will own the rights to the source code for my project?
Even if you’re not using open source, many development houses will own their code by default unless you specifically ask about intellectual property rights. This can create huge problems down the road if you want to make modifications (especially with another vendor) or if the software becomes valuable later on. If the vendor owns the software they can license it to others to use at a much lower price than what you paid to develop the product.
Will you use open source code or libraries in my application?
Some development houses operate on a don’t ask, don’t tell policy about where the code comes from. We always have this discussion first with our clients, before we even discuss features of the application. This is a must if you have plans to own the intellectual property of the entire application.
If open source is being used in the application, which licenses apply to the source?
Different licenses have different terms, some of which are more restrictive than others (see above for more details).
Have the proper licensing terms been included in the code, if applicable?
Many of the licenses need to be included as part of the code to indicate where the code came from and under what agreement you’re using it.
Another place to address licensing is in the contract. Language like work for hire, transferability, non-exclusive and non-transferrable all point to decisions about ownership.
John Curtis is the President and CEO of Quotient Integrated Solutions, Inc., in Austin and has more than 10 years of leadership experience in architecting technology solutions and developing intellectual property for companies such as Motorola, Dow Chemical, Exxon, Aetna, and more. Contact him at 512-646-4902 or http://Quotient.net
Special thanks to Darin Siefkes, Attorney at Law, http:// dsaustinlaw.com