When you decide to create a mobile app for your business, it can be hard to understand where the code is coming from and who owns what part of it.
Your business needs to ensure your proprietary ideas are secure and wholly your own, but if you are unsure how code ownership works, understanding who owns your business' proprietary ideas may not be as straightforward as it seems. This overview will guide you through the ins and outs of code ownership and help your business determine if owning code is necessary for you.
There is also a lot more to the intellectual property of a company than the bits and bytes of source code and the mobile app it drives.
How does code ownership work?
Code ownership has evolved over the years. Back in the 1970s, most applications were written from scratch, so code ownership was a lot more straightforward. Today things are a bit more complicated since most things are the work of much larger teams and may incorporate open source, 3rd party libraries and generally get quite large. The basic principle is the same: when someone writes some code, as with any other creative endeavor, the author is the initial owner of the creation. In a business context the code typically becomes the property of the business through the contracted agreement with their employee, contractor, or development company that writes the code.
To create an app today, only part of your app's functionality is written from scratch. The rest is built on what already exists. Black Duck's 2025 Open Source Security and Risk Analysis, which audited 965 commercial codebases, found that on average 70% of the code had open source origins. The complete final project includes code written in house, APIs available via the mobile operating system, open source components, commercial libraries, and, in a growing number of cases, cloud services. Looking at the ways you can use code you did not write gives a clearer picture of code ownership.
3 ways to manage ownership of code that you did not directly write
Open-source code
Open source code products give you permission to use, modify, and redistribute the code that you have access to. This is the primary way people gain access to reuse other developers' code in their projects, and the adaptability of open source code creates greater collaboration between developers.
While there are many variations to open source, these are the two primary approaches:
Very few restrictions: MIT, Apache, or similar licenses allow others to use the code with few limits beyond keeping the original copyright and license notices. The resulting product can be used for any commercial purpose.
More restrictions: Licenses that allow usage of the code but put some limits on what you can do. The best example is the GPL license, known as the viral license, which requires that derivative works you distribute be released under the same license, with their source code.
While the original author is the copyright holder and owner of the code, open source licenses allow others to utilize the code for free. The benefit of open source code is helping to provide the building blocks for others to create bigger and better solutions within a community to have better coding solutions in the future.
Visible source
Unlike open source code, most commercial creators do not want to provide their work to others. However there may be some commercial benefit from allowing others to review and audit the code. Visible source code is a compromise: specific parties can look at the code but cannot use it or disclose it. This can help ensure that there are no security exploits or other issues with the code while still maintaining its value. This approach also allows collaboration between companies to build tightly integrated systems or services. In this case, the owner retains control over the code.
Source code escrow
If you are using a commercial system or managed platform, which is a service that runs pre-existing app code on your behalf, and the provider goes out of business, what happens to the code? This question could be an important one for your business continuity or for critical systems viability.
In those situations, source code escrow is the answer. Source code escrow is a fail-safe that offers your business a way to move forward without the original developer. It is a legal agreement which guarantees your business use of the existing code if something happens to the developer or service provider so that you can continue maintaining the code they developed for you. Ownership of the code would still belong to the original entity, or their survivor, but you would retain the right to use the code to operate your business. This type of agreement can happen between your company and a company which makes code specifically for your use or with an app company that provides the same code framework to many companies, in which case multiple clients are all receiving the source code to continue their operations.
Source code escrow is a great way to ensure continuity, particularly when working with smaller service providers.
Who owns the code when you use a managed platform?
Running your app on a managed platform means a provider builds and operates it so you do not need to hire developers or carry the engineering, which is a popular way to lower the barrier to entry on mobile apps. But when someone else writes and runs the code, you also usually won't own it. That is a real tradeoff: you get speed and someone else carries the maintenance, and in exchange the platform owner keeps the code.
However, not owning the code doesn't mean you don't own a stake in your app. On a platform like our Managed Apps, Fluxweave owns the software, and you own your data, your customer relationships, and your brand. The risk with any platform is dependence: if the provider goes away, a configuration without a platform does not run. Ask what happens to your data and users in that case, and whether an escrow arrangement or an export is available. We lay out who owns what on our pricing page.
Is it important to have ownership of your app's code?
Nobody owns every line of their app's code, because so much of it comes from open source and libraries. The real question is whether you own the code written for you, and both answers can be right. If the software itself is part of what makes your business valuable, or you want the freedom to take it to another team later, have it built and make sure the contract gives you the code and the IP. If what you need is a working app and you would rather not carry the engineering, a managed platform can be the better fit, as long as your data, your customer relationships, and your brand stay yours. Trust and intellectual property are the two main factors in deciding which path fits your business.
In some situations, such as working on a top secret government project or developing a new highly secure payment system, having the business or government directly own the code is the best choice. On the other side, even large companies rely on platforms they don't own. Netflix moved its streaming service onto Amazon Web Services, finishing in 2016, rather than keep running its own data centers. Delivering high quality video is part of its business, but its brand, its content, and its apps are what it chose to own. Netflix trusts AWS to keep running the infrastructure while Netflix keeps its own intellectual property.
Another important consideration is that without constant maintenance and upkeep freshly written code, like fresh produce, will start to rot. The tools, languages and libraries used to create code are constantly moving. Even if an app is perfectly bug free and fully supporting every possible feature it will require modifications and upgrades to keep it running on the latest platforms.
What should you focus on owning?
Code ownership isn't as straightforward as someone learning to code and sitting down to type. The prevalence of open-source code and walled garden platforms has created a highly collaborative environment where developers are constantly working to improve others' work. With most of the code in apps today coming from open source and other shared sources, nobody owns every line. What you can decide is who owns the code written for you.
Whichever path you choose, protect the power of your idea, your brand, your data, and your customer relationships. If you build, make sure the contract gives you the code and the IP (when we build for you, you own it; see pricing and engagement). If you use a managed platform, make sure your data, your customer relationships, and your brand stay yours, and know what happens if the platform goes away.