White-labeling open-source Metabase

Is it possible to white-label the application using the open-source version of MetaBase? I’ve seen some posts about white-labeling posted before there was an Enterprise edition. I know this version has white-labeling as a feature, and I’d like to know if this is a feature I can work on myself using the open-source code.

I believe your question is covered pretty well in this issue thread:

Even though the answer there may predate the Enterprise version there also was a paid option at that point in time that included white labeling.

1 Like

Just to play the devil’s advocate, let’s fictitiously consider that you want to rebrand Metabase and sell it to a third-party client. (Please don’t feel targeted by the “you”. It is just an example.)
To maximize your profit, you want to use the free (as in speech… and beer) MB open-source version, modify the code to adapt the branding, and sell it without redistributing any gain with MB developers.

Because Metabase open-source version is licenced under AGPL, my understanding is that you are legally allowed to fork the repo, modify the source code (in your case to change the logo or colour code, etc.), compile it and run it on your servers (or even sell you’re rebranded version) — as long as you comply with AGPL requirements; namely:

  • include copyright, and licence (would have to be AGPL too)
  • state the changes you’ve made,
  • disclose the sources,
  • include install instructions.

So I believe (I am not a lawyer) you are allowed to act as in the scenario above. Yet… it would then be as easy for me or your client to use your rebranded version of MB without paying you anything, just like it’s easy to use the vanilla one. (If you don’t make you’re code public, you are infringing the AGPL licences term and Metabase could easily sue you. You don’t want this.) Plus your client would be able to see that you are just charging them for a free MB + a couple commits.

Another downside for you would be that you would have to rebase your couple commits onto Metabase master's HEAD each time there is a new release and compile it, etc. But the heavier burden would be to ensure that your couple commits aren’t broken by the new changes ported into MB.

Of course, it would be fairly straightforward if it’s just a matter of using an orange colour theme (i.e. replacing #509EE3 with #edad45) because MB codebase is quite clean and DRY, and you don’t have to change this variable in a tons of files. But still, you’d have to ensure your “improvements” still works at every release.
And the burden of maintaining your fork increases with the count of changes you want to make.

That’s for the the legal/workload aspect: my understanding is that you are allowed to, you can, but you then need to explain your client why they pay you when you’re just repackaging something free with a couple extra commits and they can legally get it for free if they download the code from your repo.

But should you to?
I won’t talk ethics; indeed, your mileage may vary and I’m not sure you’re interested in my moral compass. But let’s use the analogy of the goose that lays the golden eggs to explain why it should be a good idea to support original developers of MB.

In your case, you are selling to your client golden eggs (i.e. Metabase) of the goose (MB developers — sorry guys!), with a little added value — e.g. a nice egg box + the fact you’re carrying the eggs up to the market where it’s convenient for the client to collect them (your orange branding).
What is awesome is that you don’t have to do anything for eggs to be produced daily (new MB releases are delivered with you doing anything or contributing in any way). That’s because the goose has its own grain reserve (i.e. money from investors) plus is sometimes fed by other people who use/sell golden eggs (other paying clients).

That’s all good for now, but:

  • your client could realize that your neighbour has access to the same eggs as you, and would sell it for way less than you
    → you have lost your client.
  • if you by extra grain or vitamins for the goose, it could lay bigger eggs and faster
    → sponsoring MB developers ensure that the product you sell increases in value and that bugs are solved quicker (because more money, more rockstar developers).
  • if you don’t buy grain for the goose (you’re a free rider), that the goose’s own stash runs out (no more seed money in the company), and that your neighbours don’t feed the goose (no more third party paying clients), the goose will starve (MB go bankrupt) and you won’t have any new eggs to sell (MB development stall)… but will have to face your customers whom you’ll have to explain to why you can’t provide them with eggs any more
    → paying for MB development also ensures that you keep benefiting from the goods of the goose over time.

With F/LOSS software, you can only be a free rider for so long; especially if the value you gain from it is critical to you. The good thing is that you don’t have to pay alone for all the grains to feed the goose: if you only pay for a handful, but you neighbour does too, and their neighbours as well, etc. The goose will be fat and you will all benefits for its eggs.
(If you considering buying half a handful only, you might not notice any changes. But then take the time to read about the tragedy of the commons.)

By the way, feeding the goose with grain (money) is the easiest and most effective way to ensure it continues laying eggs. But that is not the only way. You can also encourage other people feeding it grain, making it easier for the goose to lay (use your time to write PR) — even if you might not be as effective as the goose itself, or making it know how to produce better eggs (write bug reports), etc.


This is all well and good speech. But to be fully honest, I should add as disclaimer that, despite this display of good intention, me/my company is currently using Metabase… as free-rider.

4 Likes