Open Source Libraries: Legal Requirements Every Dev Must Know

Building an app that uses open source code is something most developers do without thinking twice about the legal side of things, and honestly that makes sense because you're trying to ship a product and solve problems for users. The only issue is that every open source library comes with a licence attached, and ignoring those legal requirements can expose your business to lawsuits, force you to open source your proprietary code, or even lead to your app being pulled from the store... I've seen all three scenarios play out over the years, and none of them are situations you want to find yourself in after spending months building something.

Open source doesn't mean free of legal obligations, it means free to use under specific conditions that you're legally bound to follow

The mobile app industry relies heavily on open source libraries because they save development time and money, but most developers I work with don't fully understand what they're agreeing to when they install a package. Back in 2018 I worked with a fintech client who discovered during their Series A funding due diligence that they'd been using GPL-licensed code in their proprietary app for eighteen months, which meant they were technically required to release their entire codebase as open source. We had to rip out that library and rebuild the functionality from scratch, which delayed their funding round by three months and cost them about 85 grand in development time and legal fees.

What Are Open Source Libraries

Open source libraries are collections of pre-written code that developers can use in their projects without building everything from scratch, and they cover pretty much anything you can think of from handling network requests to processing images to managing database connections. When I started building apps a decade ago, the open source ecosystem was much smaller, but now there are millions of libraries available across different package managers like npm for JavaScript, CocoaPods for iOS, and Maven for Android... the growth has been massive.

These libraries save time.

Instead of spending two weeks building a custom image caching system, you can install a well-tested library that handles it in an afternoon. For a typical e-commerce app I built last year, we used about thirty different open source libraries for things like payment processing, analytics, crash reporting, and UI components. Without those libraries, the project would have taken four months instead of six weeks, and the client would have spent an extra sixty thousand pounds on development costs. When building complex functionality like IoT integration in mobile apps, relying on proven open source components becomes even more critical for project success.

The thing people often miss is that free to use doesn't mean you can do whatever you want with the code. Each library comes with a software licence that sets out specific terms for how you can use, modify, and distribute that code. Some licences are permissive and let you do almost anything, whilst others are restrictive and require you to share your own code under the same licence if you use theirs. Understanding these differences matters because choosing the wrong library can create legal problems that are expensive and time-consuming to fix.

• Permissive licences like MIT and Apache 2.0 let you use the code in commercial projects with minimal restrictions
• Copyleft licences like GPL require you to release your code under the same licence if you distribute it
• Weak copyleft licences like LGPL allow linking to libraries without sharing your code but modifications to the library must be shared
• Public domain options like Unlicense have no restrictions at all but offer no warranty or liability protection

Understanding Software Licences

Software licences are legal documents that grant you permission to use someone else's code under certain conditions, and breaking those conditions can result in copyright infringement claims that cost serious money to defend against. I've probably reviewed hundreds of open source licences at this point, and whilst they can seem overwhelming at first, most fall into a few categories that are easier to understand once you know what to look for.

The MIT licence is probably the most common permissive licence I see in mobile development, and it's lovely and simple... you can use the code for anything including commercial projects, you can modify it, you can distribute it, and your only real obligation is to include the original licence and copyright notice somewhere in your app. We use MIT-licensed libraries all the time at Glance because they don't create any complications for our clients who want to keep their code proprietary. A healthcare app we built used fifteen MIT-licensed libraries for things like JSON parsing, image loading, and date handling, and compliance was straightforward.

Apache 2.0 is similar to MIT but includes explicit patent grants, which means contributors promise not to sue you for patent infringement if you use their code. This matters more than you might think because software patents are a minefield, and having that protection built into the licence gives you legal cover. I tend to prefer Apache-licensed libraries when they're available because of this extra protection, and most big tech companies do the same for their open source projects.

Keep a spreadsheet of every open source library you use, its licence type, and where you've included the required attributions... this takes five minutes per project but saves hours during audits or due diligence

GPL licences are where things get complicated because they're copyleft licences, which means if you use GPL code in your app and distribute that app, you're legally required to release your entire app's source code under GPL too. This is fine for open source projects but disastrous for commercial apps where your code is your competitive advantage. I always avoid GPL-licensed libraries for client work unless the client specifically wants to release their code as open source, which happens rarely. The one exception is when you're using GPL software as a separate service rather than linking it into your app, but even then you need to be careful about how the integration works.

Common Legal Pitfalls for Developers

The biggest mistake I see developers make is simply not checking licences before using libraries, and I get why it happens because you're focused on solving a technical problem and the licence feels like boring paperwork. A client came to me in 2019 with an education app they'd built themselves, and they were about to sign a distribution deal with a large publisher when their lawyers discovered they'd used AGPL-licensed code. The AGPL is particularly strict and requires you to share your source code even if you're just providing the software as a service, which their platform model relied on... they ended up walking away from a 200k deal because replacing the code would have meant rebuilding half the app.

Another common problem is mixing incompatible licences in the same project without realising it. Some licence combinations just don't work together legally... for example, you can't combine GPL code with proprietary code in a way that creates a single distributed work, and you can't take MIT-licensed code and re-licence it under a different licence without permission. I worked with a developer who'd taken an MIT-licensed library, modified it, and then tried to release his version under a proprietary licence without including the original MIT licence notice. That's copyright infringement, and whilst he fixed it quickly once I pointed it out, if the original author had noticed first he could have faced a lawsuit. These kinds of issues can be caught early with proper code quality tools and development processes.

Dependencies of dependencies create another layer of complexity that catches people out. When you install a library, it often pulls in other libraries that it depends on, and those dependencies might have different licences than the main library you wanted. I've seen projects where the main library was MIT-licensed but one of its dependencies was GPL-licensed, which meant the whole project was actually subject to GPL requirements. Most package managers now show you the full dependency tree, but you need to actively check it rather than assuming everything is fine. This due diligence becomes particularly critical when preparing for app store submission, where licensing compliance issues can cause rejection.

Compliance Best Practices

Building a proper licence compliance process into your development workflow is something I started doing about five years ago after seeing too many clients run into problems, and it's honestly not that complicated once you make it a habit. The key is checking licences before you add libraries to your project rather than trying to audit everything at the end when you're trying to ship.

Set up.

When I'm evaluating a new library, I look at the licence first before I even test if the code does what I need. If it's GPL or AGPL, I find an alternative unless there's a really compelling reason to use it and I've discussed it with the client. If it's MIT, Apache, or BSD, I add it to my project and make sure I've got the licence file tracked. This takes maybe two minutes per library but prevents massive headaches later, much like how proper addressing bugs early saves significant business costs down the line.

A licence audit at the end of your project is about fifty times more painful than checking licences as you add them, so build it into your workflow from day one

I keep a LICENCES.md file in every project that lists each open source library, its version, its licence type, and a link to the full licence text. Some developers use automated tools like FOSSA or Black Duck to scan their codebase and generate licence reports, which works well for larger projects but can be overkill for smaller apps. For mobile apps I also include a Licences screen in the app settings that displays all the required attributions, and there are libraries that can generate this automatically from your dependencies file.

Documentation Matters

When you modify an open source library, document what you changed and make sure you're still meeting the licence requirements for modifications. Some licences like Apache 2.0 require you to mark which files you've changed, whilst others don't care as long as you keep the original copyright notice. I worked on a mapping app where we had to fork an open source routing library to add custom functionality, and we spent an afternoon making sure we'd properly documented our changes and included all the required notices. That documentation helped when we later did an IP audit for an acquisition discussion.

Legal Review for High-Stakes Projects

For any project where there's significant money involved, whether that's venture funding, acquisition talks, or major enterprise contracts, get a lawyer who understands software licensing to review your compliance. I've probably done this ten times now with different clients, and it costs anywhere from 2k to 8k depending on the complexity of your project, but that's nothing compared to the cost of discovering compliance issues during due diligence. A fintech client I worked with spent five grand on a legal review before their Series B, and the lawyers found three licence issues we'd missed that could have derailed their funding round. Professional legal compliance is particularly important for legal apps and client-facing professional services where regulatory standards are paramount.

Managing Licence Dependencies

Keeping track of licences across your dependencies and their sub-dependencies is where things get messy, and this is an area where having some automation helps because manually checking hundreds of packages isn't realistic. Most modern development tools have built-in ways to inspect your dependency tree and see what licences are in use across your entire project.

For React Native projects, you can use a tool like licence-checker to scan your node_modules folder and generate a report of every package and its licence. I run this on every project before submitting to the app stores, and it takes about thirty seconds. For native iOS projects, CocoaPods has a plugin called cocoapods-acknowledgements that generates a settings bundle with all your licence attributions automatically. On Android, Gradle plugins like oss-licences-plugin from Google do the same thing. These tools aren't perfect and sometimes misidentify licences or miss custom licence terms, so you still need to spot-check the results, but they're much better than doing everything manually.

1. Set up automated licence scanning in your build pipeline so it runs every time you add or update dependencies
2. Create a whitelist of approved licence types for your project based on your commercial requirements
3. Configure your tools to flag or block packages with unapproved licences before they make it into your codebase
4. Keep your dependency versions pinned rather than using floating version numbers so you don't accidentally pull in a new version with a different licence
5. Review your full dependency tree at least once per release cycle to catch any changes you might have missed

Version updates are something people forget about when managing licences because they assume if version 1.0 of a library was MIT-licensed, version 2.0 will be too. That's usually true but not always... I've seen library maintainers change licences between versions, sometimes making them more restrictive. A few years back a popular JavaScript library switched from MIT to a custom licence that restricted commercial use, which caused chaos in the community. Most projects reverted to the older version, but anyone who'd blindly updated without checking would have violated the new licence terms. This kind of version control becomes especially critical when building serverless mobile apps where dependency management can be more complex.

Wrapping Up

Open source libraries power most modern mobile apps and save developers countless hours of work, but using them comes with legal responsibilities that you can't ignore. Understanding software licences, checking them before you use libraries, keeping proper attribution records, and having a process for managing dependencies will protect you from legal problems that can cost hundreds of thousands of pounds to fix. The developers who treat licence compliance as part of their standard workflow rather than an afterthought are the ones who never have problems during funding rounds, acquisitions, or legal audits.

Building licence awareness into your development process takes a bit of time upfront but becomes automatic once it's a habit, and the peace of mind is worth it. Whether you're building your first app or you're a seasoned developer working on commercial projects, taking licences seriously is just part of being professional about your work. The legal landscape around open source isn't going away, and if anything it's getting more attention as more money flows through software companies. Knowing the rules and following them properly means you can use open source confidently without worrying about what might blow up later.

If you're planning a mobile app project and want to make sure you're handling open source compliance properly from the start, get in touch with us and we can walk you through how we approach it.

Frequently Asked Questions