We've been using MySQL as a very small part of our application; in fact so small that SQLite could have done the job. Because of licensing costs we decided to move to MariaDB and this is the email we got when they understood what was happening:
I was a little surprised to be honest with your decision of no longer using MySQL as a platform for your 5 modules and the fact that XXX is currently looking at different forks like MariaDB, PostgreSQL or other MySQL Forks.
I want to raise awareness on the impact this change will have on your business and also on the risk XXX will be facing when working with freeware technology DB, as it is important for Oracle to make sure all our partners understand the terms and conditions of distribution in which concerns embedding GPL Software.
I know MariaDB and also PostgreSQL – due to the difference in our business models, Oracle cannot offer similar unlimited usage pricing plans.
Nevertheless, before we move forward I would like to share some general business concerns I hear from other companies similar like yours that have previously looked into PostgreSQL, MariaDB, and other MySQL forks.
About any Open Source GPL-Licensed software: (e.g. RedHat Linux or MySQL Community Edition):
- Anyone can fork the software and rebrand it (e.g. Oracle Linux is fork of RHEL; MariaDB, SkySQL, PostgreSQL are forks of MySQL)
- Anyone can sell Support/Training/Consulting for GPL-licensed software
About Embedding GPL-licensed software:
- Embedding a GPL-licensed component makes the entire product to become "infected", and the entire product (including source) must be released under GPL and must be given back to the community. (e.g. MariaDB embedded within your application results in returning the code of the entire product to the open source community)
Before considering a fork, please answer these questions for yourselves:
1.1. Risk of Lock in
Do you want to get locked into an unstable fork of MySQL from a 3rd party?
Can the forks keep up with the MySQL releases (features, bug fixes, etc.)
What happens when the latest MySQL releases are not compatible with forks?
1.2. Lack of Engineering Resources
How many people are dedicated to Product Development of the fork?
How many engineers do they have working on InnoDB, Replication?
Can they deliver bug fixes for InnoDB, Replication, High-Availability etc. on a timely basis?
1.3. Risk of Software Quality
Are their patches extensively tested by millions of users like MySQL?
Do you want your production system to be the test bed for 3rd party patches?
Can they deliver bug fixes on a timely basis?
1.4. Commercial Licenses for OEM/ISVs
When you need a commercial license, who is going to help you?
1.5. Lack of Support Resources
How many people are in their Support Team vs. MySQL/Oracle?
Do they have the resources to service multiple large customers simultaneously?
What happens when they are unable to escalate a bug/feature directly to the MySQL Engineering Team?
1.6. Risk of Financial Viability
How long have they been in business?
Who are their reference customers?
Are their businesses financially sustainable?
Are you, your investors and customers comfortable having Indra Navia using a replica fork product? We will not be the cheapest but I am sure we can negotiate a good structure for you based on the history behind your relationship with MySQL; plus you will deal with the source.
Are you OK to continue?