Who Owns Drupal? Governance, Licensing and What It Means for Procurement

Nobody owns Drupal, and for a procurement team that is the single most useful fact about it: there is no vendor who can change the licence, raise a price, or take the product away.

This page exists because "who controls this platform" is a real due-diligence question, and the answer for Drupal is unusual enough to be worth stating plainly. It is a short page on purpose.

The licence is the guarantee

Drupal core is GPL-2.0-or-later — read from composer.json and LICENSE.txt in core 11.4.6. That is not a detail, it is the whole protection. Under the GPL, any version you hold can be used, modified and redistributed by you, permanently. No entity can retroactively withdraw that.

Compare that to a proprietary CMS, where the vendor's pricing, roadmap and continued existence are all risks on your register. With Drupal those specific risks do not exist. Different risks do — you own maintenance, and you need people who know it — but they are risks you can price and control.

Who actually does what

• The Drupal Association is a non-profit. It runs drupal.org, the packaging infrastructure and DrupalCon. It does not own the code and cannot relicense it.
• Core maintainers — a named group of individuals — decide what goes into core, through public issues on drupal.org.
• The security team handles vulnerability reports and publishes advisories, for core and for contributed projects that opt into the policy.
• Contributors, most of them employed by agencies and end users, write the code. The commercial ecosystem funds most of the work.

Every one of those functions operates in public. Decisions land in issue queues you can read without an account. That is unusual and it is worth using: if you want to know whether something is being worked on, you can go and look rather than asking a salesperson.

What this means for your risk register

1. Vendor lock-in: not applicable to the platform. It does apply to whoever builds and hosts for you, so keep your code in your own repository and your configuration exported.
2. Platform discontinuation: not a meaningful risk. The code you hold is yours under the GPL regardless of what happens upstream.
3. Security response: covered for core and for contributed projects with the security advisory policy. Verify that policy applies to every contributed module in your build — not all of them opt in.
4. Maintenance: yours. Core has no unattended updates; in 11.4.6 the staging API package_manager is marked lifecycle: experimental and hidden: true. Budget for someone to own patching.

That last row is the one that actually bites, and it is the one a governance page ought to say out loud. Freedom from a vendor means the obligations are yours.

Common questions

Is Drupal owned by Acquia?

No. Acquia is a company founded by Drupal's project lead and is a major contributor and hosting vendor, but core is GPL-licensed and no company owns it.

Could Drupal change its licence?

Not retroactively. Existing releases stay under the GPL you received them under, permanently.

Who do I contact about a security issue?

The Drupal security team, through the private reporting process on drupal.org. Do not file it in a public issue queue.

Next

If you are past due diligence and into build decisions, the questions that matter next are cost and platform fit — what a Drupal site costs by band and Drupal against WordPress both address them directly.

For a build where governance and compliance are part of the brief, a Drupal architect is the right first conversation, or tell me what your review board is asking and I will answer the specific question.