We produce a commercial product based on Oracle (i.e. are a VAR). As
Frank mentioned, I'm 95% certain that we don't pay any licensing fees
for developing our product against Oracle - in other words, we can set
up Oracle instances in-house that we run against for dev & testing
purposes, but we don't have any of our data in them (obviously, confirm
this with Oracle sales). We do pay for support, however (highly
recommended).

When our customers purchase our product, they also must purchase an
Oracle license. So your friend's client changing their system to
Oracle won't mean more licensing costs for them (there will be other
costs associated with switching technologies, of course), but it will
add to the cost of each unit sold of their product. Even if they're
not selling Oracle with the product, their customer's going to pay for
it, so whether you add $N to the final price or the customer does, the
result is in increase in cost or a decrease in profit.

Keep in mind that selling a "turnkey" product based on Oracle has its
own set of problems. In addition to the licensing costs, you're going
to have some customers that want nothing to do with Oracle - they may
be "100% SQL Server/DB2" shops, etc. You'll have others who have their
own IT & DBA people who want to have ownership of the server or the
backup process (you're going to want them to have some ownership over
backup, even if it means they need to copy the files RMAN produces to
some other location on their network periodically). They may dictate
what kind of hardware you're going to want to run the system on, or may
insist on auditing your database if they think they're really something
special or have an IT department that's looking for something to do.

I'm a big fan of Oracle, but for both political & technical reasons, it
is not always the best solution for software products that have an
"embedded" database. If you don't think you're going to need the high
availability/high reliability features of Oracle (hot backups,
clusters, etc.), or if customers are okay with the idea of losing up to
a day of data in the event of a catastrophic crash and only use the
system during business hours (meaning you can just take a cold backup
of your data files during the evening when the system is offline), you
may want to choose a lighter weight solution. MySQL can be a good
solution for a system that only needs basic SQL functionality and
doesn't require high write performance (in terms of many concurrent
users) - if you have occasional (as in less than 10/minute) writes and
many queries, it's a good choice.

Your friend willl definitely learn a ton working with a system like
Oracle, but make sure you're using the right tool for the customer.