“Open source” in MDM can mean four different things: fully open source, open core, source-available or a free tier. Only the first two give you rights that count in a security review or a vendor change.
The other two are mostly a nicer name for a price tier.
The phrase shows up on almost every mobile device management product page. Checking what it means takes about twenty minutes. Do it before a fleet of several thousand devices depends on the answer.
Four things vendors mean by it
- Fully open source: The code is published under a licence approved by the Open Source Initiative, such as Apache 2.0, GPL or AGPL. You can read it, run it, modify it and keep running your modified version indefinitely.
- Open core: A free core is genuinely open. The features that decide an enterprise deployment sit in a closed commercial edition. Think single sign-on, audit logging, multi-tenancy or compliance reporting. You can inspect the open part, but you would deploy the commercial one.
- Source-available: You can read the code, but the licence limits what you may do with it. The Business Source License, the Server Side Public License and the Elastic License all fall here. None of them is OSI-approved, yet vendors who use them still call their products open.
- Free tier: Nothing is open. The product is just free below a certain device count.
The test takes one email. Ask for the licence name and the repository URL, then check the licence against the OSI list. Vague answers usually mean open core or source-available.
The licence decides what you may do with your own changes
Permissive licences such as Apache 2.0, MIT and BSD let you modify the software and keep your changes to yourself.
Copyleft licences such as the GPL require you to publish your changes if you distribute the modified software.
The AGPL extends that duty to software offered over a network. Say you modify an AGPL-licensed management platform and use it to manage devices for third parties. The duty can apply even though you never shipped anyone a file.
For an internal IT department this rarely comes up. For a company that manages devices on behalf of its customers, it is a question for legal, not for IT. Ask before deployment, not after.
The server and the agent are two different codebases
This is where most open source claims in the category get thin. An MDM has a server and an agent.
The server holds the console and the database. The agent runs on the device with privileged access and does the actual enforcement.
The published repository is usually the server. Your security team cares about the agent, because it is the part with the permissions.
So the question for a security review is narrower than “is it open source?”. Can your auditor get the agent source, and under what terms? Can you verify that the binary you deploy was built from it?
A repository you can read is worth less if nobody can confirm that the package on ten thousand devices came from it.
Open code and data residency are separate questions
An open licence tells you what the software does. Where it runs is a separate decision.
A product can be fully open source and still be offered only as the vendor’s hosted service. Then your device inventory, location history and compliance records live in the vendor’s cloud, under their operational control.
Whether self-hosting exists at all is a choice each vendor makes separately from the licence. Plenty of open source platforms do not offer it.
Both answers matter for a GDPR assessment, and they come from different questions.
For the data itself, ask which fields the agent collects and how often. Ask how long they are retained and whether collection can be narrowed.
For the hosting, ask where the database is physically located and which vendor staff can reach it. Make sure that access is written into the processor agreement and not just described on a web page.
The exit cost that licences do not fix
The usual argument for open source in this category is that it protects you from lock-in. It helps, but the largest cost of leaving has nothing to do with the licence.
On Android, the management system that enrolled a device holds Device Owner. A new system cannot take that over.
For fully managed devices, dedicated devices and corporate-owned devices with a work profile, changing platforms means a factory reset and re-enrolment on every device. All local data is lost unless it was backed up first. Our guide to Android Enterprise explains the ownership models.
Google’s own migration path moves devices from a custom agent to Android Device Policy within the same enterprise. It does not move devices between two vendors.
As Jason Bayton’s EMM migration guide puts it, cross-vendor migration without a wipe is not currently available.
The exception is the BYOD work profile. You can remove it and re-enrol without touching personal data.
For most corporate fleets, then, the exit cost is physical. Somebody handles every device, or every user follows instructions correctly, and support volume rises for a few weeks. Zero-touch and Knox Mobile Enrollment reduce the handling, but not the reset.
What the licence does change is the timetable and the fallback.
With an open, self-hosted platform you can keep the old server running on your own hardware while you migrate in batches. You can export the database because it is yours. A vendor raising prices or shutting down does not set a deadline for you.
With a hosted platform, the vendor’s end-of-service date is your project deadline. You migrate at their pace.
Six questions to send before you sign
- Which licence, and what is the repository URL? Is the licence OSI-approved?
- Which features are in the open edition, and which are commercial only?
- Is the device agent’s source available, and can we verify our deployed build against it?
- Can we self-host? If so, does the commercial edition support it or only the free one?
- Which data does the agent collect, where is it stored, and which of your staff can access it?
- If we leave in three years, what do we get as an export, and what has to happen to each device?
What the answer is worth
Open source answers two questions well. Can your own people inspect what runs with privileged access on your devices? And can you keep operating the platform if the commercial relationship ends?
It does not answer where the data sits. The hosting model decides that. It also does not answer what leaving costs. The Android ownership model decides that.
Price those separately. A permissive licence and a vendor-only cloud can appear in the same product, and frequently do.
Disclosure: This post was developed in collaboration with Headwind Computer Systems & Communication Equipment Software.