Why doesn't mysql just forget the whole dual licensing of the server
thing and just tell everyone to use the GPL versions of everything.
Then dual license the client libraries which I would think they
already own outright. I think this is what forces most people to
need a commercial license. Do most of their customers really need to
modify the server?
The other thing that most of their customers probably need is just a
support contract in case something goes wrong and to keep the bosses
happy. And that is not really something that oracle can interfere
with (unless they try to buy off all of their employees individually).
Of course they should all just switch to postgres anyway but that is
another story. :)
Rick
On Feb 15, 2006, at 10:05 AM, Chad wrote:
I am not concerned about Sleepycat revoking their open source license
for future versions of BDB. I am less concerned about them revoking
licenses for current and older releases. That would be impossible.
However this "deal" troubles me and I cant quite put my finger on why.
I'll try to tease it out. Please bear with me.
As I understand it Sleepycat make most of their money by selling
commercial licenses to companies who use their stuff but who don't
want
to open source their own code. Companies such as these will in the
future be required to talk to Oracle to negotiate a new license. So
far
nothing sinister about this.
However, I see MySQL as the future losers here. I cannot see why else
Oracle would buy both of the MySQL storage engines other than to
effectively remove both of them from the MySLQ product suite in future
releases, thereby weakening it. Im just wondering how they are
going to
achieve it though. According to Olson, BDB will still be available
under the dual license. Lets assume for the moment that at least the
open source license will still be available. Happy days, unless of
course the product you own is called "MySQL". Do MySQL or any MySQL
customers need a commercial license for BDB? I think not. MySQL does
not as all its code is open source. As for MySQL customers, unless
they
are making direct API calls into BDB (which most don't) I don't think
they are categorized as BDB Api users and so can keep their code
proprietary without having to answer to Sleepycat/Oracle for a
commercial license.
Therefore I see only the following mechanisms for Oracle to remove BDB
from MySQL
1. Discontinue BDB
2. "Change their mind" about free licensing and start charging
exorbidant fees for use of BDB, regardless of the type of application
3. And I feel if 1 and 2 do not happen then this is the highly
probably: use a non-compete clause in the BDB license to effectively
prevent companies like MySQL ever licensing BDB again. Sleepycat
have a
similar clause in their own license to prevent companies releasing
products using BDB which could be seen to compete with Sleepycat. This
clause will change to refer to Oracle instead of Sleepycat. I
hasten to
add this non-compete clause only refers to non-open source
applications
today. This will signal the end of relationship between MySQL and BDB.
Question is: can they put non-compete clauses into open source
licenses? I dont think so. Maybe Oracle will just proceed with step 2,
first. Either way there is no way Oracle will allow to continue the
situation where MySQL gets to use BDB, a world class storage engine
for
FREE, as they happily steal customers from Oracle the very company
that
now owns said engine.
As of today I consider myself to be an EX-Berkeley DB user/developer.
What we need now is an open source DB with clean APIs into various
places in the software stack (eg we need a Berkeley DB kind of API
under the hood into something like Postgres) A full bells and whistles
relational DB with these low level ACCESS APIs will be a powerfull
thing in the future. PostgreSQL take note. If you don't already
have it
you should begin exposing such a thing today in my humble opinion.
Being part of a big company changes you. This deal may stifle
innovation in BDB going forward. If so there is an opportunity to fill
that gap. I turn to the PostgreSQL community to rise to the challenge.
---------------------------(end of
broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
