The ongoing MySQL campaign
If the deal is approved based on the fact that 'MySQL can be forked', that will be a big blow to open source Software. It means that open source software is not protected for anti-competitive measures and it will be ok for big companies to freely buy up their open source competitors and kill them. Note that not even PostgreSQL is safe from this threat! For example, Oracle could buy some companies developing PostgreSQL and target the core developers. Without the core developers working actively on PostgreSQL, the PostgreSQL project will be weakened tremendously and it could even die as a result."
Posted Dec 31, 2009 23:32 UTC (Thu)
by cowsandmilk (guest, #55475)
[Link] (3 responses)
There might be some other obvious source I'm not thinking of, but it was quite surprising when I
Posted Jan 1, 2010 22:48 UTC (Fri)
by hingo (guest, #14792)
[Link] (2 responses)
Posted Jan 3, 2010 3:36 UTC (Sun)
by toddj1 (guest, #42952)
[Link] (1 responses)
Posted Jan 3, 2010 20:45 UTC (Sun)
by hingo (guest, #14792)
[Link]
Posted Jan 1, 2010 0:11 UTC (Fri)
by davidw (guest, #947)
[Link] (1 responses)
http://journal.dedasys.com/2009/12/13/mysql-oracle-and-th...
There are a ton of way more important things to worry about, like patents, real monopolists, what to do about 'the cloud', and things like that. He sold his project fair and square, now he should live with the consequences.
Posted Jan 1, 2010 1:59 UTC (Fri)
by eparis123 (guest, #59739)
[Link]
Posted Jan 1, 2010 5:59 UTC (Fri)
by sitaram (guest, #5959)
[Link] (8 responses)
Good timing; I'd barely just gotten my post ready; it's at http://sitaramc.blogspot.com/2010/01/mysql-campaign-my-th... if you're interested.
I guess the summary would be that I have no sympathy for that cause. If anything, the opposite.
Sitaram
Posted Jan 1, 2010 19:05 UTC (Fri)
by dmarti (subscriber, #11625)
[Link] (7 responses)
Posted Jan 1, 2010 22:52 UTC (Fri)
by hingo (guest, #14792)
[Link] (6 responses)
Posted Jan 2, 2010 22:00 UTC (Sat)
by butlerm (subscriber, #13312)
[Link] (5 responses)
A GPL project without copyright assignment, on the other hand, is designed to
Of course with BSD style licenses people can fork off little monopolies, but
Posted Jan 2, 2010 22:11 UTC (Sat)
by foom (subscriber, #14868)
[Link] (4 responses)
Sure, but here we have a project where the majority of whose code is owned by Sun and licensed
Posted Jan 2, 2010 23:11 UTC (Sat)
by rahulsundaram (subscriber, #21946)
[Link] (3 responses)
Unfortunately Sun seems to be doing it worse on all the Sun managed
Posted Jan 3, 2010 5:38 UTC (Sun)
by JoeBuck (subscriber, #2330)
[Link] (2 responses)
It certainly made matters delicate, in that relations had to be maintained with the FSF during a very tense time. But a group of people who didn't own the copyright successfully put out releases that became the dominant branch of development for a couple of years.
For that reason, I'm confident that Oracle can't kill MySQL. It's true that Monty can't make money on non-GPL commercial licensing of the code or a derivative of the code, and maybe that's his angle.
Posted Jan 3, 2010 11:19 UTC (Sun)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
Note however there are some fundamental differences betweeen GCC and MySQL.
Posted Jan 3, 2010 18:24 UTC (Sun)
by foom (subscriber, #14868)
[Link]
Yeah, it was pretty annoying when MySQL AB changed the license on their client library from LGPL
But if it's really a problem, the fork of MySQL can rewrite the client library from scratch, and that
Posted Jan 1, 2010 8:54 UTC (Fri)
by trasz (guest, #45786)
[Link]
Posted Jan 1, 2010 10:43 UTC (Fri)
by markusw (guest, #53024)
[Link] (3 responses)
A company founded about ten years ago, called Great Bridge LLC "targeted" several Postgres developers (i.e. paid them to work on Postgres). Late 2001 that company went out of business again. However, it almost didn't affect the Postgres community.
For more information, read these interviews with Bruce Momjian:
So, no, Postgres has already proven to cope pretty well with company buy-outs. Something MySQL still has to prove. And it looks like it's time for that now. I'm curiously watching from the safe distance.
Happy new year to all open source developers.
Markus Wanner
Posted Jan 1, 2010 21:49 UTC (Fri)
by dlang (guest, #313)
[Link] (2 responses)
but as a result of that the core postgres developers make it a point to not concentrate in one company so that no matter what happens to any company the other developers are not affected.
so to significantly affect postgres a company would have to buy and shutdown postgres development at many different companies, and do this fast enough that the individual developers could not get jobs with other companies just as fast.
it's far easier for a company who depends heavily on postgres to hire one developer and let that person work on postgres much of the time then it is for a company to hire a team of people (in fact, if you compare the cost of hiring one postgres developer to the cost of licensing Oracle, many companies will find it much cheaper to hire the developer)
Since many of the companies who use Postgres extensively are very large companies (especially in the far east), it is not reasonable to consider all such companies (or even a significant fraction of them) being bought by _any_ one company (not even microsoft or IBM)
So the postgres team has anticipated this problem and implemented policies to eliminate the risk.
Posted Jan 2, 2010 1:27 UTC (Sat)
by bmomjian (guest, #44864)
[Link] (1 responses)
Posted Jan 2, 2010 1:33 UTC (Sat)
by dlang (guest, #313)
[Link]
according to at the different core developers I have heard talk about it, this is why the core developers all work for different companies, it's not accidental, it's a deliberate effort to spread the employment around to protect the projects from problems with any one company
Posted Jan 1, 2010 10:50 UTC (Fri)
by kripkenstein (guest, #43281)
[Link]
To put it another way, if you argue that forking isn't a safeguard, then the code isn't the real core asset that antitrust regulators would need to be concerned about. It would be the developers. But developers are people. They can decide not to work on it if they want. So there isn't really much to do about that - antitrust regulators can't tell people "keep working on X, to foster competition". That would be a violation of their basic rights.
Posted Jan 1, 2010 11:16 UTC (Fri)
by djzort (guest, #57189)
[Link] (15 responses)
I am thankful for its easy interface and more ergonomic design (compared to oracle, holding a sword the wrong way could be considered ergonomic), however it has failed to deliver the advanced features that would otherwise make it comparable to oracle, db2 etc.
More interest in PostreSQL will encourage its already outstanding feature set to be further refined and improved. The EnterpriseDB product line is a tribute to how advanced postgresql has become, and RedHats partnership with E.Db has further acknowledged that a postgresql database is a real alternative to the oracle database.
Firebird is also an excellent open source database, very much a quiet achiever.
Posted Jan 1, 2010 11:47 UTC (Fri)
by rvfh (guest, #31018)
[Link] (9 responses)
If I had tangible information, I might be able to convince my management to make an experiment on one of our test machines, then post more info on what went right and wrong.
My main question so far is: is the syntax 100% compatible? Is is just some corner cases that are not (those we probably do not use anyway)? Is it comparable performance-wise?
Sorry if this has already been answered many time, but I think now is the time to review the state of things for people/companies thinking of steering away from MySQL...
Posted Jan 1, 2010 12:17 UTC (Fri)
by ringerc (subscriber, #3071)
[Link] (6 responses)
No, it isn't. It's probably not even 90% compatible. However, if you've stuck to the SQL standard you won't have many things - if any - to change. However, there are some very commonly used MySQL extensions (like AUTO_INCREMENT) which you must do a different way in PostgreSQL, so you must be prepared for a few changes even to fairly simple code. (Note that there are good reasons why PostgreSQL uses sequences and the SERIAL pseudo-type instead of using AUTO_INCREMENT. It's one of those things that MySQL has but PostgreSQL doesn't implement because it's actually pretty broken in transactional systems.) The PostgreSQL documentation is extremely complete and discusses the relationship of its syntax with the standard in the documentation for each command/function. So you can learn a lot from there. There's also a lot of information about MySQL to PostgreSQL migrations all around the 'net. If you're using MyISAM tables, then you're not asking much from your database. You don't need it to be reliable or to support basic transactional features, for example. So it's fairly likely you won't have too many issues, though you'd need to handle AUTO_INCREMENT and probably move to sql-standard datatype names for a few things. Usually I'd just say "yes"... because MySQL and PostgreSQL have comparable performance for "serious database" uses. For some workloads and queries one is faster, for others another, but there's no clear and obvious winner. However, that's assuming you're using InnoDB tables on MySQL and are relying on transactional behaviour. You're using MySQL in quick-and-dirty MyISAM mode, where it's not even crash-safe let alone transactional. If you don't need reasonable safety you could get comparable performance from PostgreSQL by setting That's really not the right approach, though. If you want that sort of thing, stick with MySQL. It's designed for it, whereas PostgreSQL is "safety first". If you actually want your data to be safe, then you'll want to (a) Move to InnoDB tables and adapt your app so that it does all database-modifying work in transactions, then (b) port over to PostgreSQL if you want that as an option. You'll never get the raw queries-per-second performance out of PostgreSQL that you do from MyISAM tables in MySQL. Of course, your data will never be that unsafe, either ;-) . If you're prepared to do the work to make your app smarter - let the database intelligently do work you're currently doing by reading stuff into your app and processing it app-side, etc - then you might find that you get better performance out of Pg, because it's very good at more complex and difficult queries and can often do things much faster than you can do with the data in your app.
Posted Jan 1, 2010 20:28 UTC (Fri)
by nevyn (guest, #33129)
[Link] (1 responses)
I've only ever used PostgreSQL, so I'm wondering how AUTO_INCREMENT is
different? Looking at the docs. the only "interesting" property I could see
was it's use with more than one primary key for the table (but I'd
assume/hope this wasn't common).
Posted Jan 2, 2010 2:13 UTC (Sat)
by ringerc (subscriber, #3071)
[Link]
Postgresql's sequences are lock-free and don't block other transactions. They allow high INSERT concurrency, but don't guarantee gapless sequences (ie: on ROLLBACK or statement failure, you might have a "missing" number, which you shouldn't care about for a primary key).
Looking at some MySQL documentation, though, it looks like for recent versions of InnoDB AUTO_INCREMENT works much like PostgreSQL's sequences. I don't know enough about the MySQL side to go into depth on any differences. It looks like InnoDB's AUTO_INCREMENT these days may behave very like a sequence if InnoDB has the configuration param "innodb_autoinc_lock_mode = 2" set, but that's about all I can say.
http://dev.mysql.com/doc/refman/5.1/en/innodb-auto-increm...
( PostgreSQL doesn't support statement level replication, so the statement-replication concerns about auto-increment don't apply ).
Posted Jan 3, 2010 7:44 UTC (Sun)
by nicku (guest, #777)
[Link] (3 responses)
Posted Jan 3, 2010 9:34 UTC (Sun)
by ringerc (subscriber, #3071)
[Link] (2 responses)
VACUUM or something like it is pretty much required in any MVCC design, and should occur in the background without interrupting anything. It's a cost of operation that should be amortized as smoothly as possible across time. If you're having to use VACUUM FULL rather than plain VACUUM to control table bloat, though, then something is wrong with your configuration. Are you using an ancient version of Pg without built-in autovacuum? Is your autovacuum set to be so conservative that it's useless? Are you running out of free_space_map room so VACUUM is losing track of where it needs to do work? Some people configure autovacuum to run less, thinking that by doing so they'll somehow reduce the amount of work to be done. If you've done so, there's your problem. In fact, autovacuum should run MORE if you want your database faster, so the work is done promptly (avoiding table and index bloat) and spread evenly rather than occurring in big user-annoying chunks. It's like garbage collection in that regard. See VACUUM FULL on the Pg wiki. Note that vacuum and autovacuum improve with every version. 8.4 for example eliminates the free_space_map parameter, making it automatically (and better) managed by the server. If you're on an old version, upgrade. Unfortunately Pg isn't yet clever enough to fully automatically manage the autovacuum parameters, so you may still need to tweak autovacuum params on particularly UPDATE-heavy tables and/or tell autovacuum to run more frequently in general.
Posted Jan 3, 2010 20:21 UTC (Sun)
by butlerm (subscriber, #13312)
[Link] (1 responses)
Not quite. Oracle's MVCC, for example, works something like the following
1. The latest version of any row is stored in the primary data block, along
The main advantage of this scheme is that data blocks generally only get
Posted Jan 4, 2010 4:12 UTC (Mon)
by ringerc (subscriber, #3071)
[Link]
A redo log does have a large disk I/O cost if you have a high update/delete volume and/or any long-running SERIALIZABLE transactions, but it doesn't require the same sort of work as Pg's in-place storage of superceded rows. On the other hand, it has a HUGE cost to queries - in the form of random disk I/O - if they have to hit the redo log on disk.
I don't know enough to comment on which is "better". I suspect that like most things, it's probably a trade-off where some workloads benefit from one and others from the other.
Posted Jan 3, 2010 7:36 UTC (Sun)
by nicku (guest, #777)
[Link] (1 responses)
Posted Jan 3, 2010 10:42 UTC (Sun)
by dlang (guest, #313)
[Link]
the big change in 8.5 is that there will be a synchronous replication via log shipping built into the core. There are already options (pgpool or slony to name a couple) that will do replication and let you read from all boxes at the same time.
I'm not a MySQL expert, but my understanding of the guarantees that it's replication provides make me think that these existing replication tools let you get equivalent safety to what MySQL replication provides.
Posted Jan 1, 2010 17:33 UTC (Fri)
by qu1j0t3 (guest, #25786)
[Link] (4 responses)
The Ingres Database offers high-volume transaction processing, high availability, multi-
platform support, and security for mission-critical application deployments. ... Ingres Database 9.3
provides easy migration from MySQL and proprietary databases such as Oracle, SQL Server and
Sybase.
Posted Jan 4, 2010 7:42 UTC (Mon)
by man_ls (guest, #15091)
[Link] (3 responses)
Posted Jan 4, 2010 15:23 UTC (Mon)
by qu1j0t3 (guest, #25786)
[Link] (2 responses)
Posted Jan 4, 2010 22:42 UTC (Mon)
by man_ls (guest, #15091)
[Link] (1 responses)
When these resources keep quiet about something, usually it is not worth trying.
Posted Jan 4, 2010 23:52 UTC (Mon)
by qu1j0t3 (guest, #25786)
[Link]
There are many database systems (relational and non-relational) performing very well for relatively
If you want for something to make the Slashdot front page, you'll miss many good things.
Posted Jan 1, 2010 17:58 UTC (Fri)
by PO8 (guest, #41661)
[Link] (7 responses)
Uh, X Window System. Several times. Worked out well each time. Can recommend forking as a strategy for dealing with a project that has gotten broken somehow. X isn't even GPL. In theory it should be even easier to have a good fork with GPL'ed code.
Posted Jan 1, 2010 22:37 UTC (Fri)
by robla (subscriber, #424)
[Link]
I doubt that Oracle would abandon the MySQL trademark if one
It's almost impossible for me to imagine how neglect by Oracle would *not*
Posted Jan 1, 2010 23:00 UTC (Fri)
by hingo (guest, #14792)
[Link] (5 responses)
Posted Jan 4, 2010 7:39 UTC (Mon)
by man_ls (guest, #15091)
[Link] (4 responses)
Posted Jan 4, 2010 8:04 UTC (Mon)
by hingo (guest, #14792)
[Link] (3 responses)
Posted Jan 4, 2010 9:00 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (2 responses)
If you are a third-party software vendor whose product supports MySQL,
chances are that you don't actually need to futz around inside the MySQL
database server in order to make your product work with it. Instead, you
talk to the server over the network (via TCP or a Unix-domain socket).
Hence all that keeps you from releasing your own software under a
proprietary license is the fact that the MySQL client library,
which is the bit that does get linked into your product,
is licensed under the GPL and would force you to release your code under
the GPL (or one of a bunch of other free-software licenses).
Come up with your own compatible clean-room replacement to
libmysqlclient, and you're home free -- you can still distribute (and
support) the unmodified MySQL server under the GPL, and use
whatever license you fancy for your own code.
I haven't looked at libmysqlclient recently, but whatever it does is
unlikely to
be rocket science. The GPL version of MySQL will be available essentially
forever, no matter what Oracle may do to the »enterprise« version, so
whoever
is using the MySQL database server as a client in a »proprietary«
fashion today is basically a small push away from being able to continue
using it for as long as they like. I don't see a big problem here.
I agree with various others in this thread in that it appears to me that
Monty dreams of the EU giving MySQL back to him (preferably for free),
after
he sold it to Sun to $$$ some time ago. Monty's main problem is that,
unlike
most other »proprietary« users of MySQL, his business is about
futzing around inside the MySQL server (where most others just
talk to it via the client library), so if Oracle doesn't let go of the
code and he is restricted to using the GPL version of MySQL, he will have
to make his improvements to the server available under the GPL, too. Which
of course is a bit of a downer. Thus, the big smoke screen.
Posted Jan 4, 2010 9:30 UTC (Mon)
by mjw (subscriber, #16740)
[Link] (1 responses)
Posted Jan 7, 2010 16:54 UTC (Thu)
by vonbrand (subscriber, #4458)
[Link]
Futzing around I came to the MySQL Connector for OOo page, which states that this is LGPLv3 but runs on top of MySQL Connector/C++, which is GPLv2 with FLOSS exception. AFAIU, this still means that you can't use this from non-FLOSS software.
Posted Jan 1, 2010 19:14 UTC (Fri)
by aba (guest, #24118)
[Link] (41 responses)
At the larger level, there are many competitors in the database market: IBMs DB2, Oracle database, Informix, MaxDB and even Microsoft SQL-Server are part of the per-license databas camp, whereas Postgresql, MySQL and sqlite are open source products. People don't choose a non-free database because they "just need any database", but because they need special features which are available only there (or because the license fees are cheap compared to the necessary handholding anyways).
Actually Postgresql is good on catching up the selling points of commercial databases, so the market share is shifting to open source database systems anyways (and gives the commercial ones a bit more of competition). MySQL is just quite dominant as free database because it was available very early, but there are free and easy replacements available. On the low end side, sqlite is now known as new competitor for cases where one doesn't need all the user management etc - often already enough for a web site.
If MySQL really goes off the market (and that's a very big if, we have seen successful forks of open source products being badly handled like e.g. X first to XFree86, and then from there to Xorg, as the commercial entities did something too wrong there), it won't help oracles database. It however would increase the number of postgresql and sqlite installations. And it would damage Oracles picture in public, and the trust people have in the promises by Oracle. So in the end it would weaken Oracle, and let the other open source products become stronger.
So, summarizing up: All that ranting about the Oracle-Sun-merger doesn't help the open source software community. It might help very few companies with a specific business model connected with MySQL. There are many far more important assets involved in the merger like the ownership of NFS or java, and we should focus on those. Putting all energy on the ownership of MySQL gives in the best case reason for a good laugh, and in the worst spoils the image of open source products and people because there is nothing serious behind it.
Posted Jan 1, 2010 22:15 UTC (Fri)
by rahvin (guest, #16953)
[Link] (33 responses)
Monty and Florian are doing nothing more than seeking to damage FOSS, not protect it and when they lied about asking for a license change everyone should have ignored everything else they said.
Posted Jan 2, 2010 1:33 UTC (Sat)
by sitaram (guest, #5959)
[Link] (32 responses)
This is the email I sent to the EC yesterday, FWIW:
----
Dear EC commissioners,
I am writing this in my individual capacity, as an open source user, enthusiast, and evangelist for the past 15 years.
I would like to state that, after doing all the research I need to do, and asking all the people who ought to be asked, I have come to the following conclusions:
(1) Whether Oracle buys MySQL or not is completely irrelevant to the open source community.
(2) Such a purchase affects *only* some commercial projects that have a commercial license for MySQL. Any changes in their license terms caused by this acquisition have nothing to do with open source users of MySQL. As such, those changes should be dealt with using the normal anti-trust related rules, without being clouded by "open source community" concerns.
(3) Monty Program AB and their CEO M Widenius are mis-representing this issue as affecting the open source community. However, nowhere in their web pages or blogs or campaign sites do they list even one **purely open source** project that is currently using MySQL that will be badly affected by this acquisition.
(3.1) I submit that asking for that sort of an example is the only meaningful way to validate their current claims.
In effect, I see this as commercial interest masquerading as open source interest, and using claimed damages to the open source community as a way to influence policy. As an open source enthusiast, this makes me uncomfortable, and is my motivation for this email.
Posted Jan 2, 2010 22:12 UTC (Sat)
by hingo (guest, #14792)
[Link] (31 responses)
Posted Jan 2, 2010 23:02 UTC (Sat)
by hingo (guest, #14792)
[Link]
Posted Jan 3, 2010 2:04 UTC (Sun)
by sitaram (guest, #5959)
[Link] (9 responses)
In my other life, I do care about proprietary software, so that is not a valid interpretation of what I think.
I'm saying that (1) people who have commercial licenses should have factored in that risk [of owner, and therefore terms/cost, changing] when they decided to go for MySQL [I would have...], and (2) please stop pretending this affects OSS users because it doesn't.
> If because of (2) it wouldn't be possible or attractive to use MySQL also for proprietary software, MySQL becomes a less interesting option also for open source software. This is because often organizations want to standardize on as few options as possible, so they would be reluctant to pick an option that even potentially couldn't serve all their needs.
How many organisations do you know that have both proprietary products and open source products? Offhand I can't think of any, and even if you name a few, they're the exception. You don't mount worldwide campaigns to influence the EC on the basis of exceptions and rare cases.
> currently is GPLv2 and therefore incompatible with GPLv3 software and only Sun/Oracle can fix that. In other words Oracle could severely limit MySQL usage also on the open source side.
This is about the only valid point in the whole deal, but I chose to ignore it in all my writing because Monty himself (in http://monty-says.blogspot.com/2009/10/importance-of-lice...) says that "This is a problem, but less severe than the problem of economics." I will continue to ignore it for now, except for saying that if that was *all* the petition had, I'd have been with you.
> But the EU can regulate the merger event, if it thinks that it would be harmful to competition overall.
Again, if you want to play this as "commercial interests currently depending on MySQL will be harmed", fine. But Monty keeps saying "open source is affected", which I certainly do not agree with.
> As for the open question, don't take this as any official response, but the answer has already been given above: 1) The primary concern was always the MySQL customers that use MySQL for proprietary SW,
not according to Monty, who has made this out to be a serious problem for open source and that he is trying to save the world for all of *us*.
> which is a significant part of the MySQL universe. (We have them to thank for funding most of the development work that is in MySQL
Circular reasoning, or confusing cause and effect. You used the GPL (and dual licensing) to force most of that revenue generation in the first place. The development model was closer to closed source than open source, so any 3rd party development would naturally gravitate that way. Now it wants to perpetuate itself.
Once again, nothing wrong with that, but please dont keep saying this affects the OSS world. That's the dishonest part, from my p.o.v.
Posted Jan 3, 2010 20:12 UTC (Sun)
by hingo (guest, #14792)
[Link] (8 responses)
Posted Jan 4, 2010 1:27 UTC (Mon)
by sitaram (guest, #5959)
[Link] (7 responses)
We *are* thinking of the same thing: end users.
Let me rephrase what I had said, (and I'm sorry that I wasn't clear enough earlier). I had said "How many organisations do you know that have both proprietary products and open source products?". Now s/have/distribute/ in that sentence.
End users do not distribute. And so they can do what they damn well please, even mix GPL v2 and v3 (gasp!) if they wish, for their in house development. For products they purchase, they'll buy support. For OSS products they just use without buying support, nothing changes anyway.
[As for IT/ITES companies like the names you mentioned or indeed my own employer -- in that business they'd better be able to deal with any popular piece of software that their customers might be using or want to use instead of trying to standardise.]
...but...
all this is moot. I should have just focused on this one point in your previous post and ignored everything else, because as far as I am concerned that is the crux. You said:
> As for the open question, don't take this as any official response, but the answer has already been given above: 1) The primary concern was always the MySQL customers that use MySQL for proprietary SW,
You're the first MPAB person who's said this so far, (AFAIK of course).
Go back to the top of the page and take a look at the abstract that Jon put up. If you don't see a major, major, disconnect between what you said above and that abstract, there really is nothing to discuss anymore.
If you do, you might want to tell your boss about it. I do not speak for anyone but myself but this is the basis for my feelings of outrage, even disgust, at what Monty is doing.
It also appears that melodrama, rhetoric, even hysteria ("help keep the internet free"? come on...!), have become his stock in trade. Normally I wouldn't take digs like this at people in a public forum, but in this case it's part of the real problem -- he's essentially rabble rousing because his main point is false, and patently so.
Posted Jan 4, 2010 4:53 UTC (Mon)
by TRS-80 (guest, #1804)
[Link]
You're the first MPAB person who's said this so far, (AFAIK of course).
Posted Jan 4, 2010 7:04 UTC (Mon)
by hingo (guest, #14792)
[Link] (5 responses)
Posted Jan 4, 2010 7:23 UTC (Mon)
by jjs (guest, #10315)
[Link] (3 responses)
1. So the issue is proprietary MySQL - please admit that, don't frame it as an "Open Source" issue.
2. Sure they can choose to run MySQL. They may have to find alternatives to the 3rd party software, but again, they chose to use proprietary software, they took the risk. Of course, the 3rd parties could choose to GPL / Open Source their products and provide support. Just because a business model used to work doesn't mean the government has to guarantee it will always work.
3. Why should Oracle give away the product? Assuming what you say is true (I disagree, but for arguments sake assume you're right), the standard antitrust action would be to sell the product. You're proposing Oracle give it away to (among others) you. Why? Why should they not be forced to sell it? I understand you can't afford it - that's your problem. Others may be able to. It could even be spun out as a new company. The only rationale so far for relicencing in a more lenient manner (BSD/Apache) is so MPAB can get into the old proprietary game at no cost. Why should the EU give you the business? Why should Oracle get no compensation for what they are giving away - esp seeing the compensation Monty got by selling it to Sun.
Posted Jan 4, 2010 8:22 UTC (Mon)
by hingo (guest, #14792)
[Link] (2 responses)
Posted Jan 4, 2010 17:44 UTC (Mon)
by rahvin (guest, #16953)
[Link] (1 responses)
MySQL is not a threat to Oracles business, it never has been and it likely never will be. MySQL is so far behind Oracles main product that it will be multiple decades before it could even have a chance of getting to Oracles current level. For that reason alone Oracle has no reason whatsoever to hamper, harm or kill mysql. It's going to fit perfectly into their low end product line that INNODB+ currently occupies.
Regardless, this sale is not a threat to FOSS software. Any argument to the contrary is just what's getting mine and others hackles up. Monty's and others framing this as an FOSS issue is nothing other than a fabrication at best and an outright lie at the worst. It's appalling to me that the EU merger review process has been so corrupted over a non-issue and the public campaign Monty is making in the name of FOSS when he doesn't give a damn about FOSS. (Pardon my language) His attack on Eben not being in touch with the GPL and other arguments do nothing but harm the community.
Posted Jan 5, 2010 8:17 UTC (Tue)
by hingo (guest, #14792)
[Link]
Posted Jan 4, 2010 9:31 UTC (Mon)
by sitaram (guest, #5959)
[Link]
I think we lost track of the original point here, which was, loosely, "the same organisation distributing open source as well as proprietary applications". I still don't see that happening.
> And don't worry about Monty, he won't be disturbed by your outrage or disgust - for better or worse.
Why would I worry about Monty? I imagine you need pretty thick skin to mount a campaign based on false premises combined with melodramatics, and to tell an entire community that you're their saviour when it's not at all clear they need one.
My slightly apologetic tone in that post was for you, not for him, in case you were wondering. Thank you for being a reasoned debater.
Posted Jan 3, 2010 6:36 UTC (Sun)
by jjs (guest, #10315)
[Link] (19 responses)
2. Monty sold his right to sell proprietary versions when he sold to Sun. He got considerable money for it.
3. Anyone, including Monty, can choose to bid for MySQL - try and convince Oracle to sell it to him. Instead, Monty wants EU to dictate that Oracle GIVE him the code and right to proprietarize the software, WITHOUT paying for it.
4. Red Hat. IBM. Novell. Zope. Numerous companies have built successful business models around Open Source WITHOUT the dual licensing scheme. Dual Licensing is a business model. It's not the only business model.
5. Monty HAS stated that it's about Open Source. See 1 above - it is NOT about Open Source. It's about Monty wanting to have a proprietary business WITHOUT paying for it. He wants his cake and eat it too. EU should tell him flat out - you want the code, fork over the money. Monty (like every one else, since MySQL is GPLv2) is free to take the current code and support it for money. Whether or not he manages to make money is his problem. NOT Oracle's. NOT Sun's. NOT EU's. NOT US's.
Posted Jan 3, 2010 7:25 UTC (Sun)
by jjs (guest, #10315)
[Link] (16 responses)
If they feel the need to speak up, they can. They are NOT your customers. Sorry, but Monty sold the business. They aren't your customers, and pretending to speak for them is the height of arrogance. How do you KNOW they aren't migrating? Have you spoken with them? Note I said KNOW, not SUSPECT, not THEORIZE, not ASSUME, not ASSESS. KNOW.
Posted Jan 3, 2010 20:42 UTC (Sun)
by hingo (guest, #14792)
[Link] (15 responses)
Posted Jan 4, 2010 4:37 UTC (Mon)
by jjs (guest, #10315)
[Link] (14 responses)
2. If they are moving to proprietary MySQL - see my comment. This is a known risk with proprietary software. If they didn't factor in they company could go out of business / discontinue the product, that's their problem for not being good businessmen.
3. How many are in the SW distribution business? If they merely use the software, they can use the GPL version with no restrictions. GPL only affects distribution.
4. They submitted their own papers - that's good, because THEY'RE the ones affected. You and Monty are NOT speaking for them, CANNOT speak for them (because they are NOT your customers).
5. Regarding funding. I know how you used to fund MySQL development. That's not the only model. Many others are funded differently (to include Linux by various entities funding development of a GPL product). Just because something worked in the past is no reason for the government to guarantee to you it will work in the future.
6. Read the top of this article. Monty presents this as an Open Source issue. EVERYTHING you have presented has to do with the proprietary version of MySQL. Nothing against that, but it is NOT an Open Source issue - you are misrepresenting it (or you're not being truthful here), and as such, I will now have to discount EVERYTHING you present (because of your known misrepresentation - if I can't trust your word on one thing, why should I trust it on another thing?).
Again, if you want to sell proprietary products, fine. But, having sold the company, don't expect or demand EU to GIVE you the company/business back for nothing. And don't represent your desire to have a proprietary business as being an "Open Source" issue.
Posted Jan 4, 2010 7:49 UTC (Mon)
by hingo (guest, #14792)
[Link] (13 responses)
Posted Jan 4, 2010 8:48 UTC (Mon)
by jjs (guest, #10315)
[Link] (12 responses)
2. If you're supporting GPL, why the insistence on Apache license? I'm sorry, but everything you say above that you want to do can be done with GPL. If they're moving to the GPL codebase, the fact the code is GPL'd doesn't create a problem. Unless you're not being honest. You're stating it's the model that was successful in the past, but you state you're not interested in using it, nor have you identified anyone who is. Your proposed solution is just as "pie in the sky" as keeping it GPL and forking. Unless you're planning to fork over the cash, buy MySQL, and recreate MySQL AB.
3. I've seen the public Oracle commitments to GPL'd MySQL. Made to the EU. Spell out why those don't work for companies moving to the GPL'd version of MySQL (which you claim the companies are moving to).
4. I'll state again - why should Oracle be forced to GIVE AWAY the product? Standard anti-trust would be for them to sell the product. You're insisting on a punishment that's not been supported in the past. Insist they sell it - fine. but why the give-away, unless you're looking to get the product for free?
Why do we keep going in circles? Because you keep insisting it's about Open Source, yet only bringing up issues with the Proprietary model. Sorry, but until you admit the issue is proprietary model, we'll continue to look askance at your statements. Again, I have nothing per se against proprietary software, if that's what you want to talk about, admit it. Don't try and claim it's an "open source problem" when it's not.
Also, I used to do Open Source software support - specifically advising businesses on risks/options - again with Open Source (GPL'd in this case) the options for support are fully open - they can contract with anyone they want, from a major company to "joe the coder" - unlike proprietary.
Posted Jan 5, 2010 8:36 UTC (Tue)
by hingo (guest, #14792)
[Link] (11 responses)
Posted Jan 5, 2010 12:12 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (10 responses)
It seems to me, upon reading the entire thread between you and jjs, that jjs is asking why the GPL isn't good enough for Open Source MySQL users. You're answering that it's not good enough for proprietary MySQL users, and you believe that if they're not kept happy, Open Source MySQL will die. The response is that jjs disagrees about Open Source MySQL depending on the proprietary users, and feels that a relicensing of MySQL to GPLv2 or any later version, rather than the current GPLv2 only would fix the concerns for Open Source MySQL users.
You disagree with this, saying that it needs to be relicensed to something more liberal (e.g. MIT) if Open Source MySQL is to survive under Oracle's ownership, but your reasoning appears to be entirely based around the proprietary MySQL users.
Is that a fair summary of the situation? If not, where am I going wrong?
Posted Jan 5, 2010 13:42 UTC (Tue)
by anselm (subscriber, #2796)
[Link]
The problem is really that a GPLed MySQL with the copyrights held by
Oracle is bad for Monty, who wants to make a living selling proprietary
versions of the MySQL server to paying customers. To do that, obviously he
would much rather have a GPLed MySQL with the copyrights held by his own
company (like before he sold MySQL AB to Sun) that he can dual-license,
or, failing that, a MySQL under a BSD-like license that doesn't force him
to publish source code.
The GPL version of MySQL is used by a very large number of people and
is unlikely to go away anytime soon, no matter what Sun, Oracle, or the EU
do. As far as proprietary users of MySQL are concerned,
people who are not interested in hacking on the MySQL server itself can
write all the proprietary MySQL-using software they care for by using a
non-GPL version of the MySQL client library -- either one they come up
with themselves or else one that may be available from Sun under the LGPL
under the auspices of OpenOffice.org, as alluded to elsewhere in this
discussion.
Posted Jan 5, 2010 19:02 UTC (Tue)
by hingo (guest, #14792)
[Link] (6 responses)
Posted Jan 5, 2010 19:46 UTC (Tue)
by dlang (guest, #313)
[Link] (3 responses)
as far as Linus is concerned, it's not an exception, it's just pointing out something that was true anyway. Namely that ff you use published interfaces to something that doesn't make your code a derivative of the code you are interfacing with, and therefor the GPL cannot possibly apply.
Posted Jan 5, 2010 21:29 UTC (Tue)
by hingo (guest, #14792)
[Link] (2 responses)
Posted Jan 5, 2010 21:48 UTC (Tue)
by dlang (guest, #313)
[Link] (1 responses)
Linus and others don't view that as a change to the license, just pointing out something that should have been obvious to begin with. Userspace apps are not a derivative of the kernel.
And as others have pointed out in this thread, you don't need to have a GPL application to connect to a GPL MySQL server, you just need a client library that's LGPL or BSD and then you can have your proprietary code connect to a GPL server. IFF you change the internals of the server, then you need to worry about the GPL, but not if you just access it.
Posted Jan 6, 2010 16:53 UTC (Wed)
by hingo (guest, #14792)
[Link]
Posted Jan 6, 2010 5:40 UTC (Wed)
by mikov (guest, #33179)
[Link] (1 responses)
Perhaps I am very cynical, but I suspect that what bugs most people is the impression they got that Monty personally sold MySQL and received the fat check. Perhaps you guys should publicize more that it wasn't his decision and, as you noted elsewhere, he got only about 5%.
For me the crux of the matter is very simple: Oracle should not be allowed to buy a major competitor to their database. Yes, MySQL is definitely such a competitor, and people who do not see that are kidding themselves (if not literally today, but in a few years). This definitely will decrease competition, and definitely will affect ant GPL-licensed fork of MySQL. (Why kid ourselves, MySQL was so successful, despite being technically inferior to some alternatives, precisely because of its dual-license model).
This has nothing to do with Monty.
Posted Jan 6, 2010 7:57 UTC (Wed)
by sitaram (guest, #5959)
[Link]
> You keep trying to present clear information, but the truth is most people haven't really bothered to study the situation in detail (or read Monty's blog) and have made their conclusions in advance:
[snip]
> Perhaps I am very cynical, but I suspect that what bugs most people is the impression they got that Monty personally sold MySQL and received the fat check. Perhaps you guys should publicize more that it wasn't his decision and, as you noted elsewhere, he got only about 5%.
What bugs most people is the mis-representation. Even MPAB folk will agree that this is basically about protecting the current users of the proprietary version, and yet Monty keeps saying that the OSS world is affected.
> For me the crux of the matter is very simple: Oracle should not be allowed to buy a major competitor to their database. Yes, MySQL is definitely such a competitor, and people who do not see that are kidding themselves (if not literally today, but in a few years). This definitely will decrease competition, and definitely will affect ant GPL-licensed fork of MySQL. (Why kid ourselves, MySQL was so successful, despite being technically inferior to some alternatives, precisely because of its dual-license model).
"Technically inferior" coupled with "successful" usually means "good marketing/PR". However, in this case, it was also because they used the GPL as a weapon, which is easy when you combine GPL with copyright assignment and a single *commercial* owner (aka, not like ASF, FSF, etc).
Either way, I don't see a need for the open source community to help perpetuate that state of affairs, and I definitely don't see how Oracle can harm the open source version. I still have an open question on that: show me one purely open source project that is currently using MySQL, and cannot switch to something else for *technical* reasons, that would be badly affected by this purchase, and explain how precisely it would be affected.
> This has nothing to do with Monty.
This has *everything* to do with him, sadly, but I'm not in a name-calling mood today. Or at least not to *repeat* what I have already said.
Posted Jan 5, 2010 22:17 UTC (Tue)
by jjs (guest, #10315)
[Link] (1 responses)
However, I trust (based on Red Hat, IBM, Novell/Suse, Canonical, Mozilla, Xorg, etc) that Open Source does NOT depend on proprietary. Therefore, making the argument that the need to keep a proprietary version of MySQL out there to "save" the GPL version is wrong.
Also, if the Open Source model of development depends on a proprietary version, that's saying Open Source can't work. yet, Monty's current company is supposedly based on total Open Source. Either F/LOSS works and can exist without proprietary, or Red Hat should be going out of business.
Even with that, there is plenty of competition in the DB world - MySQL will live on (GPL guarantees that), and if companies bet on the proprietary version, they took a risk.
However, it does illustrate the dangers of having a single company control a GPL/Open Source project - you don't build the community that can help rescue or fork the project, because (IMO) one entity (the company) has special rights, and people don't like giving someone else rights they don't have.
Posted Jan 6, 2010 16:58 UTC (Wed)
by hingo (guest, #14792)
[Link]
Posted Jan 3, 2010 20:58 UTC (Sun)
by hingo (guest, #14792)
[Link] (1 responses)
Posted Jan 4, 2010 3:54 UTC (Mon)
by jjs (guest, #10315)
[Link]
Also, you didn't explain, you rationalized. I'll repeat - Monty (who sold his right to sell proprietary versions of MySQL to Sun for a large amount of money) has requested EU force Oracle to provide him that ability without compensation. He has shown why it is in HIS interest. He has not shown it is the interest of any customers of MySQL right now. I Repeat - how do you KNOW what they need? I've heard you & Monty lay out why YOU think it should be that. I have seen 0 (zero) from current mySQL customers complaining or worrying about it. You DON'T speak for them - they are NOT your customers. Name one current MySQL customer who has told you they are worried or will be harmed.
Monty does NOT have a business model based on the the GPL version - otherwise why would he be trying to get the right to sell proprietary licenses? His model has ALWAYS been based on proprietary code. I'm not arguing with that - his business. But don't try to claim that's not what it is. If his business model was based on the GPL version, he CURRENTLY has full rights to the support the GPL software. He just can't take it proprietary.
You state you can't afford to by MySQL back. So why should EU force Oracle to GIVE you the code? If there is a concern (which I disagree with), why should Oracle not be forced to sell the code? The fact that YOU can't afford it doesn't mean someone else can't.
Sorry, but it continues to look like you and Monty want the EU to set you up in business without paying any costs. That's not the government's job. If you can't develop a business plan that makes money without such extortion (I use that word deliberatly), maybe you need to rethink your business plans.
Posted Jan 3, 2010 2:25 UTC (Sun)
by robert_s (subscriber, #42402)
[Link] (6 responses)
Hah. The most common reason for people choosing non-free databases is salesmen successfully persuading the execs that they need an "Enterprise" ($$$$$) solution.
Posted Jan 3, 2010 20:59 UTC (Sun)
by butlerm (subscriber, #13312)
[Link] (1 responses)
The "clone" part is important - to succeed, such a database should be a
Now Oracle's dialect may not be the be all and end all of all things, but
The fastest way to *beat* Oracle is to be compatible with Oracle.
Posted Jan 4, 2010 6:32 UTC (Mon)
by ringerc (subscriber, #3071)
[Link]
I agree there are a few places where Oracle's dialect is better than the SQL standard - 'CONNECT BY' comes to mind. The SQL standard is hardly an example of great design, and is full of bizarre warts.
In most cases, though, I find Oracle's dialect painful, and its differences seem like a mix of unnecessary historical anachronisms and deliberate customer lock-in. I'm not a big fan of its left outer join syntax - it's succinct, but that's about all it has going for it. DECODE doesn't appeal when compared to CASE. Many of its odd little functions are alternatives to standard ones with different names and/or parameters that don't seem in any way better.
Of course, many developers code to the Oracle dialect anyway, because they're used to it, they prefer it, or Oracle doesn't support the standard way of doing a particular thing. So I agree that in practice it's a big adoption barrier, much as supporting all those little MySQL quirks (AUTO_INCREMENT, REPLACE upsert statement, etc) would help. On the other hand, anyone who tries to keep on using their new database as if it's just the same as their old one will be doomed to poor performance and continual irritation. Such compatibility wrappers are really just porting aids.
EnterpriseDB tries to maintain Oracle compatibility. I have no idea how well they succeed, and would be interested in your comments. For performance, while Oracle is indeed rather impressive in many cases, you can get a lot out of Pg with the hardware you can afford from your Oracle license savings. Its lack of multi-master replication is its main scaling issue these days.
Posted Jan 4, 2010 6:37 UTC (Mon)
by ringerc (subscriber, #3071)
[Link] (3 responses)
Right now, MySQL fails on "reliable" and "trustworthy" for its MM clustering, and PostgreSQL doesn't have it at all. I'm not equipped to evaluate the MM clustering add-ons to Pg like Bucardo, but I'm figuring the approach hasn't been integrated into Pg core for a reason.
Sometimes you really do need things the OSS databases don't yet provide.
That said: frequently, the reasons are lack of understanding, lack of sales materials targeted at middle/upper management, a belief that having another company "standing behind" the product makes it invulnerable to failure, "having someone to sue", or the nice week-long party cruise the salesman promised the TIO if they'll sign on the dotted line.
Posted Jan 4, 2010 7:45 UTC (Mon)
by dlang (guest, #313)
[Link] (2 responses)
different variations of replications have different advantages and disadvantages.
the replication that is going in requires core support, so it can't be maintained as a separate package
Posted Jan 4, 2010 17:06 UTC (Mon)
by foom (subscriber, #14868)
[Link] (1 responses)
That seems like a terrible reason to bless one package and not any of the others. I hope that's not
Posted Jan 4, 2010 20:53 UTC (Mon)
by mainpc (guest, #62803)
[Link]
PostgreSQL has been able to load point in time recovery (PITR) log files from one server onto another, creating a warm standby solution for fail-over. Recently, 8.5 gained the ability to serve read-only queries while performing recovery. This feature is called Hot Standby. In a separate feature, Streaming Replication, PostgreSQL will be able to send PITR data across a TCP stream in addition to the log files. Combining Hot Standby with Streaming Replication provides a solid master-slave replication solution, suitable for fail-over and load balancing of read-only queries.
This replication solution happens to be in core because that is the right place for Hot Standby and Streaming Replication to be. It is also a very low overhead design because it is based on log files that are created during normal operation anyway.
The ongoing MySQL campaign
helpmysql.org. I don't want to make any accusations, but the only place I can think of is from
registering at mysql.com and I wonder why he would still have access to the list of accounts from
there, presuming it was transferred to Sun.
had an email from him turn up in my inbox today.
Hi
The ongoing MySQL campaign
I work with Monty, although I've been on vacation for these past days so wasn't involved.
If you got email from Monty personally, then most likely you have had some email discussion with him in the past why he would have your email. (Such as, on MySQL mailing lists.) We are of course still quite close with many of our friends and former collagues still at Sun, but no, we wouldn't have access to the MySQL.com email database.
The ongoing MySQL campaign
personal email correspondence with anyone at MySQL, let alone Monty.
If you let me know the email address that was used, I can investigate when I return to work tomorrow. (My work email is hingo@askmonty.org)
The ongoing MySQL campaign
As far as I know, there is no email database as such, people are just forwarding the email to their friends and contacts. If you got it from Monty, then somehow he has your address.
The ongoing MySQL campaign
The ongoing MySQL campaign
The ongoing MySQL campaign
According to their credits list, the Drizzle project now has a majority of contributors from outside Sun (by head count, not lines of code--project leader Brian Aker is at Sun.) And they don't seem to be requiring a copyright assignment, making a GPL buyout impossible. Anyone using Drizzle yet?
Drizzle?
The outside contributors (not employed by Sun) have to license their contributions as BSD, which is more or less just another form of copyright assignment. http://drizzle.org/wiki/FAQ#How_are_my_contributions_licensed.3F
Drizzle? Nope, still GPL/owned by Sun.
BSD license vs. copyright assignment
you can get from copyright assignment. With copyright assignment, the
copyright owners monopolize the distribution of the code under alternative
licenses. With the BSD license, anyone can do so. In other words, under the
BSD license, there is no monopoly at all.
create a monopoly in favor of the public. And a GPL project with copyright
assignment is designed to create a monopoly in favor of the interests of the
copyright holder.
with few exceptions, that usually doesn't work so well, or rather it is
usually in everyone's best interest to continue to work on a common code
base. How many successful Apache forks are there out there?
BSD license vs. copyright assignment
> you can get from copyright assignment.
under the GPL, but where *everyone else's* contributions are required to be licensed under BSD.
That creates essentially the same resulting conditions as copyright assignment to Sun.
BSD license vs. copyright assignment
licensed project in the longer run and while that might leave open the
possibility of proprietary forks, it doesn't create a monopoly like
copyright assignment does. The catch in the Drizzle project however is that
Sun employees are NOT licensing their contributions under the BSD. So they
have different rules depending on whether or not you are employee of Sun or
not. That's bad.
projects including Openoffice.org, OpenJDK etc where they demand copyright
assignment and it hurts them and the project they manage pretty badly.
I'm not convinced. After all, the egcs developers successfully forked and then took over gcc development, even though the copyrights were assigned to the FSF the whole time.
BSD license vs. copyright assignment
BSD license vs. copyright assignment
argument was never that forking is not possible in a project that requires
copyright assignment. It is merely that copyright assignments creates a
privileged position for one entity. In that case of FSF, it allows them to
relicense code to GPLv3 or later. In the case of Sun or Oracle, it allows
them to sell proprietary versions.
Applications that are compiled with GCC aren't affected by the GCC license.
Applications that link to MySQL database are.
BSD license vs. copyright assignment
to GPL...
will be that.
The ongoing MySQL campaign
The ongoing MySQL campaign
http://lwn.net/2001/features/oreilly2001/BruceMomjianInte...
http://www.open-mag.com/features/Vol_12/great_bridge/grea...
The ongoing MySQL campaign
Greatbridge closure had little affect on PostgreSQL
Greatbridge closure had little affect on PostgreSQL
Not convincing IMO.
The ongoing MySQL campaign
So how does PostGreSQL compare to MySQL?
So how does PostGreSQL compare to MySQL?
"My main question so far is: is the syntax 100% compatible?"
Is is just some corner cases that are not (those we probably do not use anyway)?
Is it comparable performance-wise?
fsync = off in postgresql.conf but this is extremely unsafe and will damage your database if you have an unsafe server shutdown. Just like with MyISAM there's no guarantee the database can be repaired in such a case, so you may have to restore from backups.So how does PostGreSQL compare to MySQL?
However, there are some very commonly used MySQL extensions (like
AUTO_INCREMENT) which you must do a different way in PostgreSQL
So how does PostGreSQL compare to MySQL?
The other issue with PostgreSQL is the need for applications to avoid the need for full VACUUMs, which require an outage. All our PostgreSQL databases seem to eventually require this. Avoiding the need for full VACUUMs is a matter of application design, but we don't seem to have the hang of that yet :-)
So how does PostGreSQL compare to MySQL?
So how does PostGreSQL compare to MySQL?
MVCC implementation
design</em>
(I believe InnoDB uses much the same scheme):
with some transaction related meta data.
2. The information necessary to recover prior versions of any row is stored
in separate rollback segments
3. Changes to both are written to the redo log
4. When a query is processed, if the version of the row currently stored in
a data block isn't the one needed, a prior version is recovered by
referring to the appropriate rollback segment.
5. When a transaction commits, or soon thereafter, the rollback data for
that transaction is discarded. No disk I/O required.
6. Alternatively, if a transaction is rolled back, prior versions of
modified rows are recovered from the rollback segment and restored to their
original positions in the primary data blocks.
modified once per transaction, rather than once initially and once some
time later, during the vacuum process. However, redo log overhead is
probably twice as high, and if a transaction is large or long enough, the
rollback entries will physically hit the the disk before they are discarded
as well.
MVCC implementation
My main problem with deploying PostgreSQL instead of MySQL is to replace
the replication of MySQL. The announcement in the Linux Conference PostgreSQL talk program that 8.5 "will support native replication" brought eager, enthusiastic support from members of the team I am in. In the meantime, members of that team will migrate at least one application from PostgreSQL to MySQL to scale read operations.
So how does PostGreSQL compare to MySQL?
So how does PostGreSQL compare to MySQL?
There is also Ingres
If Ingres actually delivers all of that, then it must have changed a lot since I used it (one of the last proprietary versions). It stunk so bad it was painful.
What kind of mission?
Why not try it and see?
Personal experience is the best way, but not the only one. In fact there is a whole industry devoted to letting people know what products are good and which aren't, and endless community forums where people give their opinion. And of course there is the comment section of LWN where I have learned more than in all other places combined.
Life is too short
Life is too short
small user communities (have you heard of GT/M, for example?) That the mainstream doesn't talk
about them much does not correlate well with their quality, reliability, richness of features, level of
innovation etc. Naturally MySQL gets most attention. But in fact a wider survey of the field turns up
much more interesting things.
The ongoing MySQL campaign
Also gcc and Apache
over the keys. Apache was an NCSA httpd fork, and was, of course, wildly
successful.
of the forks became more popular, but I'm guessing the fork won't have a
huge problem establishing an alternate brand.
result in a successful fork of MySQL.
Hi
The ongoing MySQL campaign
I don't know where exactly you quoted from, but that sentence is incorrect and Monty should have said, and usually does say: "...licensed as GPL...".
The sentence is almost true just because not a lot of infrastructure software is licensed as GPL anyway. I can think of MySQL and Qt mainly. (GCC is not a library, database or framework, rather an application/utility. Other software don't depend on GCC in ways that the GPL would have an effect.)
GPL infrastructure software
not a lot of infrastructure software is licensed as GPL anyway. I can think of MySQL and Qt mainly.
If you somehow limit your mental query to what comes from the Scandinavian countries then you are right (apart from the Linux kernel itself). Otherwise there is some more infrastructure software under the GPL: glibc, JBoss, ghostscript, Samba... Actually most infrastructure software is under the GPL, apart from a few notable exceptions. Maybe I am misunderstanding your point?
No. glibc, just like most GNU libraries are LGPL (yes, this is the big difference). JBoss is LGPL. Linux has the user space exception (without which glibc couldn't be LGPL).
GPL infrastructure software
Samba is almost a good example of what you are trying to say. The difference is that applications using Samba over the CIFS protocol are not affected by the GPL. In contrast any application using MySQL, will use a MySQL client library, which are GPL licensed (plus FOSS exception to allow for some other FOSS licenses, but not GPLv3).
So the point is that unlike all other software we have in our infrastructure, MySQL (and Qt), to enable a specific business model, have been licensed in a way that gives the owner as much control as possible. The motives in that choice are just different from the typical FSF/GNU library or Samba or other community developed software.
And just because it was mentioned elsewhere: GCC is not infrastructure software in this sense, meaning that other software don't run on top of it. (Similarly Emacs is not infrastructure software, even if it is used to create new software.)
You got Ghostscript right! It is of course also a dual licensed product. This is typically the reason to choose GPL for infrastructure software. (Then we also have readline, which is an exception in the GNU stack of otherwise LGPL licenses.) I don't know that ghostscript has ever been forked either, which was Monty's original statement.
GPL infrastructure software
GPL infrastructure software
http://extensions.services.openoffice.org/project/mysql_c...
GPL infrastructure software
The ongoing MySQL campaign
The ongoing MySQL campaign
The ongoing MySQL campaign
Hi Sitaram
The ongoing MySQL campaign
I'd best reiterate that I work for Monty and have been involved in the campaign. While trying to combat all the misunderstandings and opinions on the web would be pointless, I have felt it useful to engage in the discussion on LWN, since people here are mostly well informed and smart. In other words, I won't bother "converting" people, but it feels useful to add missing pieces of information where people are at least on the right track. Your comment and related blog post qualify too, so I hope you take this comment as positive and constructive. (In fact, this comment turned out rather long, exactly because you open up some insightful and completely appropriate questions.)
Unlike a surprisingly large amount of people, you have understood how dual licensing works with MySQL. What you say in (2) is exactly what we said to the EU in August.
The reason it was important for us to get involved was that: 1) Oracle had implied to the EU that since MySQL is open source it is irrelevant who owns it and they can't do anything to harm MySQL customers. Like you say, this is not true since part of MySQL customers don't fall under the open source umbrella. 2) Oracle had specifically identified Monty Program and MariaDB as such a fork, so we had to make sure the EU doesn't count on us to "save the world", since we can't. The EU specifically came to us to ask for our answer to this. 3) You seem to belong to the people who more or less think "who cares about proprietary software anyway", which is a valid opinion, but we on the other hand felt responsible to also speak up for the MySQL customers that are not open source themselves. Also the EU of course isn't biased for or against open source, so this approach is "legitimate" for our Brussels effort. And 4) About half of MySQL's commercial business was this kind of non-GPL licensing revenue, so it is not an insignificant part of the MySQL universe.
About (3): I personally do believe Oracle having control of MySQL (copyrights, and the development organization) affects also the open source side of the MySQL universe. Of course, the effect is not as direct as in (2), so you are welcome to disagree. My belief is because: 1) MySQL is a general purpose database. If because of (2) it wouldn't be possible or attractive to use MySQL also for proprietary software, MySQL becomes a less interesting option also for open source software. This is because often organizations want to standardize on as few options as possible, so they would be reluctant to pick an option that even potentially couldn't serve all their needs. 2) MySQL currently is GPLv2 and therefore incompatible with GPLv3 software and only Sun/Oracle can fix that. In other words Oracle could severely limit MySQL usage also on the open source side. 3) Like you say in your blog, MySQL is "NQOSS", in other words was always an in-house effort. While the GPL gives anyone the right to pick up a fork, building a developer community from scratch isn't that easy - I would feel better if we wouldn't have to depend on it for MySQL's future.
I may as well make some comments on your blog posting while at it:
Vendor lock in: Migrating between any 2 databases is surprisingly difficult. This is why the database typically is the most costly component in your entire SW and HW stack today. According to SAP, only 2% of their customers migrate from one database to another each year, this is a very low number! For this reason the HW layer, OS layer and app server layer have all been commoditized by now, but we still speak of a "database tax", because there you still have the high margins. Of course, if MySQL is taken away, the world does not come to an end, but again, I'd much prefer if it had stayed in the game independent of Oracle.
You are right that Monty (or any other former MySQL AB shareholder) cannot dictate to Sun who they can sell MySQL to. Otoh any government can and actually must regulate mergers that are anti-competitive. (So this is really a judicial process, it is not supposed to be a political one.) Merger regulation is also not the same as regulating monopolies. So for instance, if Oracle does bad things to MySQL, post-merger the EU cannot do anything, because Oracle is not a monopoly, like Microsoft or Intel are considered to be in their respective cases. But the EU can regulate the merger event, if it thinks that it would be harmful to competition overall.
Also in this LWN thread another poster made the "MySQL really deserves to get killed" argument, for different reasons than you do, but still. Again, it's a valid opinion, which I of course don't share. The only thing I would want to comment on your argument specifically is that a GPLv2-only fork of MySQL, even if being more inclusive of the community and everything are great things, might actually be uninteresting to many, due to not being able to serve proprietary SW, GPLv3 SW, etc... (But if I'm wrong, and in the future we do see a vibrant MariaDB community, then all the better :-)
As for the open question, don't take this as any official response, but the answer has already been given above: 1) The primary concern was always the MySQL customers that use MySQL for proprietary SW, which is a significant part of the MySQL universe. (We have them to thank for funding most of the development work that is in MySQL today.) 2) If your open source project is GPLv3, then you are out of luck already. 3) In other cases, it depends whether a MySQL fork will survive and continue to evolve or not. I was personally hoping we wouldn't need to find out. 4) You can of course always keep on using the historical versions of MySQL, this is even true for the proprietary MySQL customers since those licenses too typically are perpetual.
Oh, I forgot the most important thing: Thank you for emailing the EC! Believe it or not, it is helpful to saving MySQL.
The ongoing MySQL campaign
The ongoing MySQL campaign
Great, so we seem to more or less aligned on facts. Just one comment then:
The ongoing MySQL campaign
How many organisations do you know that have both proprietary products and open source products? Offhand I can't think of any, and even if you name a few, they're the exception. You don't mount worldwide campaigns to influence the EC on the basis of exceptions and rare cases.
We seem to be thinking completely differently here. As I see it, a company producing both closed source and open source code is the rule, not the exception. MySQL Ab did it, Sun did it, you mentioned EnterpriseDB that does it... IBM, HP... But I wasn't even thinking of those, rather end users. In my experience, most enterprise data centers will be running: proprietary 3rd party software, open source software, in-house software. And they will prefer databases (such as by having company procurement policies) that can be used for all of those or as many of those as possible.
In summary, I don't see proprietary software and open source software inhabiting separate universes and used by separate people. If this was the case, then the LGPL wouldn't exist.
The ongoing MySQL campaign
The ongoing MySQL campaign
> As for the open question, don't take this as any official response, but the answer has already been given above: 1) The primary concern was always the MySQL customers that use MySQL for proprietary SW,
Colin Charles (who now works for MPAB) said much the same thing when I challenged him about it two weeks ago, and my response was the same as yours - proprietory MySQL customers have nothing to do with open source.
But if the vendors of 3rd party proprietary software cannot support MySQL anymore, then the end users cannot really choose MySQL to run it either, even if they of course legally can do what they want with GPL software in-house.
The ongoing MySQL campaign
So for this reason, but also for other reasons (Oracle getting control of the MySQL organization and customers, regardless of licenses and business models) both me, Colin and many others still at MySQL/Sun fear that this very much will be the end of MySQL, including for those who use the GPL version. I don't mind that you don't agree, many others seem to do so. (And like I said, even your letter to the EC is helpful, thanks. We always wanted people to give their honest opinion, and not do like Oracle who more or less put words in their customers mouths, so I've heard.)
And don't worry about Monty, he won't be disturbed by your outrage or disgust - for better or worse. FWIW, I don't like this public debate either. This LWN thread is almost the only place on internet where on average people even understand what they are talking about. In a perfect world the EU would have decided the case based on its substance alone, and we wouldn't have needed to be concerned about public opinion.
The ongoing MySQL campaign
1. Like I've said, I'm convinced that the threat is against MySQL as a whole.
The ongoing MySQL campaign
2. Some people seem to think that it will actually be advantageous, if MySQL could only be used by GPL software and it would miraculously force everyone to GPL their software. (For instance, we could have a fully GPL'd telecom software stack!) Unfortunately, I don't think this is realistic. It would be great if it was though! If the world worked this way, we should immediately start by re-licensing all GNU libraries as GPL. See also Richard Stallman on this same topic.
3. Why don't people listen to what I'm saying? We always said that Oracle should sell MySQL to a suitable third party. (press release) Yes, this is the typical action that is taken in these kinds of situations. Since you ask, I could speculate that Oracle could have proposed some kind of license change to the EU, because then they could still keep MySQL. Oracle's problem in selling MySQL to someone else is that removing MySQL as a competitor is more worth to Oracle than what MySQL is worth in itself, so they don't want to sell it away. So if they could get MySQL by liberating the MySQL licensing a little bit, they might be interested, because then they would still take away MySQL/Sun as the competing business. (For instance, PostgreSQL's existence under BSD is not noticeable at all as a competitive threat to Oracle.) For the same reasons, I'm not sure if the EU would then accept such a solution, they would prefer divesting MySQL.
Btw, formally, the EU cannot ask for anything specific. It can only deny the merger as a whole, and it is up to Oracle to propose remedies if needed.
The ongoing MySQL campaign
Hi Rahvin
The ongoing MySQL campaign
Like before, I don't have a need to convince you to change your opinion. But for the benefit of our fellow readers, allow me to quickly share some statistics so everyone can form an informed opinion.
Oracles problem in selling MySQL is that they won't get what the software is worth, nor what SUN paid for it. Under a forced sale scenario it's going to go a fire sale prices and I believe that that's Monty's hope, that they can come in and buy it back at fire sale prices then sell it again down the road for another billion to another major company.
Given that MySQL continued to grow during the Sun period, you would expect its value to be more now, than back then. Sure, maybe Sun was desperate and overpaid and also the economy is down, but still. Monty got somewhere around 5% of the billion that Sun paid. Even if he used all his money (which would be a bad investment strategy), the reduction in MySQL's value would have to be 95% for your theory to work.
MySQL is not a threat to Oracles business, it never has been and it likely never will be. MySQL is so far behind Oracles main product that it will be multiple decades before it could even have a chance of getting to Oracles current level. For that reason alone Oracle has no reason whatsoever to hamper, harm or kill mysql. It's going to fit perfectly into their low end product line that INNODB+ currently occupies.
Customers that migrate from an all-Oracle data center to use MySQL find that typically it is feasible to migrate 60-80% of your apps. For the last 20% it would cost more than it saves, but then over time some of those apps get switched to new ones, at which point they can use MySQL too. So your comment is 20% right, because MySQL is only a threat to about 80% of Oracle's database business. Btw, your comment is similar in spirit to a famous quote about Linux that "it will not be big and professional" (like GNU).
Where can you buy INNODB+?
His attack on Eben not being in touch with the GPL and other arguments do nothing but harm the community.
I believe you confuse Monty with Florian Müller.
Monty and Eben are good friends and we all had a nice coffee in Brussels together. (Eben may not fully have understood how MySQL's business models work, and as a lawyer he was poorly informed about the technical architecture such as the client libraries being GPL, but that's another story. I'm sure that with better background info he wouldn't have any problem interpreting the GPL license itself.)
The ongoing MySQL campaign
The ongoing MySQL campaign
The ongoing MySQL campaign
> we on the other hand felt responsible to also speak up for the MySQL customers that are not open source themselves
Yes I do know them. I used to sell MySQL around Europe and left a few weeks after the Oracle acquisition. Most of the time I was involved with customers migrating from Oracle to MySQL to save costs. Most of these efforts of course stopped immediately when the acquisition was announced. (Some still make sense to proceed because of MySQL being technically superior for that particular use case.) I have been in touch with some of them during the EU investigation. They have also submitted their own papers to the EU. But since they are also big Oracle customers, they can't really speak about it in public can they? So you don't have to like me for it, but yes, my personal motivation in this is to do a favor to my European MySQL customers.
The ongoing MySQL campaign
Of course, even if I know many of them, there are even more that I don't know personally, and the EU is aware of them too.
Note: I worked in the telecom industry, so my heavy "Oracle exposure" is probably not representative of the world as a whole. (For instance, Microsoft SQL Server doesn't exist here as this is a Linux/Solaris only world.)
The ongoing MySQL campaign
Hi. I'm starting to get the feeling that this is going in circles now, but I'll take your questions for the honest questions they are, and answer them best I can:
The ongoing MySQL campaign
1. All end users move to GPL MySQL (also MySQL Enterprise is GPL, even if the software is not available "for free"). I guess a majority were OEM customers, but some were end users. The reason they canceled those migrations is twofold: 1) They don't see any guarantees that MySQL actually will be forked. Do you know of anyone who is stepping up to the plate? MP has not released anything yet, so don't count on us. Further, it is not in our plans to provide 24/7 support, this is stated clearly on our website. And of course the fact that a GPLv2 only fork is a bit restricted in what it can actually do for them, even if successful. 2) It is not about the code or the license. There needs to be a large support organization, active sales organization, etc... For instance, as great as PostgreSQL is as a piece of software, at least in Europe it is commonly thought that you simply cannot buy support for it, anywhere. (The 2 large companies I know that use PostgreSQL in Finland, both have in-house expertise to support it, one employs a core developer.) The main point is that just because some code is available on the internet, doesn't mean that it is being maintained or is useful. It is not sufficient that organizations would actually migrate from Oracle to an Open Source solution. Many of the customers also were looking at what is called "a dual vendor procurement strategy", where you expect to get cheaper prices from both vendors due to competing them against each other. But if both databases are owned by the same vendor, well then it's not a dual vendor strategy.
2. True. On the other hand in their risk assessment they are also right in assuming that the government will regulate mergers that are anti-competitive. For instance, I don't think anyone assumes that Oracle would be allowed to buy away Sybase (or Microsoft or IBM), so customers expect to be "safe" from that threat. Yet, MySQL by most measures has a much bigger market share than Sybase, and is a bigger Oracle competitor than Sybase.
3. For end users, the software is distributed to them. If they cannot buy software that supports MySQL, they cannot use MySQL.
4. Yes. I'm still happy I can support them in the same cause.
5. Yes I know, I've written a book about Open Source business models. We are not asking the government to guarantee anything for us. We have our own business model, this is about MySQL. But the counter argument to what you are saying is that why should the government think that some proposed model will save MySQL rather than trusting that the model which historically actually was used and was successful, could continue to be successful. Sure, MySQL possibly could be developed like Linux is developed. (But to even enable that, the license regime would have to be changed, so today it's not possible.) But that statement is to some extent "wishful thinking". Even in the best case, it will take time for the new system to build up and organize itself. Even just re-recreating MySQL Ab from scratch using the old and proven business models would take years. Customers and the EU of course are concerned about that part - even in the best case there would be reduced competition for many years. It is completely appropriate to be more conservative and say, "if it isn't broken, don't mess with it".
6. In other comments I've explained that I do believe, and many other MySQL'rs do believe, that Oracle getting their hands on MySQL is a threat to MySQL *as a whole*. The discussion on the web, such as here, is mostly focused on licenses and forking, but I see the issues as more interrelated than that.
7. Just to clarify again, Monty Program is not in the business of selling proprietary products. On our website we are committed to the Hacking Business Model, which commits us to FOSS. (And this is unlike Sun/MySQL, actually.)
The ongoing MySQL campaign
Hi
The ongoing MySQL campaign
It seems you are not asking any new questions anymore, rather just saying you think Monty (or me?) is a liar. Since there is no new information coming out here, I guess this is a good place to stop this thread.
Reading this reminded me of the one mandatory course in psychology that I had in high school. The teacher was one of the best in that school. Here's her definition of the Freudian school of psychology:
You go to a psychiatrist who is of the Freudian school.
Psychiatrist: All of your problems are due to the fact that you want to have sex with your mother!
You: I certainly don't want to have sex with my mother!
Psychiatrist: Ah, you say you don't want to have sex with your mother, but I know that at least subconsciously you do want to have sex with your mother.
You realize you need to talk to a psychiatrist who is not of the Freudian school. (The lesson is supposed to illustrate why Freud's psychology is not considered real science.)
An attempt to summarize this thread, so that we can stop going round in circles.
An attempt to summarize this thread, so that we can stop going round in circles.
It is a good summary.
An attempt to summarize this thread, so that we can stop going round in circles.
I would add that the incompatibility with any GPLv3 software is a problem on the open source side directly. It's just another example of how MySQL copyrights and licensing have on purpose been designed such that the owner does have the control and can do bad things if it wants to.
During these months I've heard many proposals on how the issue could be resolved. For instance one person said MySQL should stay GPL but then you could add a lot of exceptions to the GPL to address the same issue (similar to Linux). As long as people would at least understand what the problem is, I don't have a strong opinion on that, I'm an engineer so if you ask me I just pick one of the well known licenses.
And finally it is worth re-iterating that the EU isn't as concerned about the MySQL license as the Open Source community is (in threads like this). Regardless of license they seem to be concerned about the MySQL business and organization itself. This is because they are interested in competition, and software that exists on the internet does not yet mean there is any competition.
An attempt to summarize this thread, so that we can stop going round in circles.
We are talking about:
An attempt to summarize this thread, so that we can stop going round in circles.
NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".
Also note that the GPL below is copyrighted by the Free Software
Foundation, but the instance of code that it refers to (the Linux
kernel) is copyrighted by me and others who actually wrote it.
I've most often heard to this thing referred as "user space exception". Given that it is outside the license text, I guess you may equally well argue that it is not an exception but a clarification.
The main point in our discussion is that a similar "thing" does not exist in the GPL version of MySQL, so applications running on top of MySQL are not analogous to applications running on Linux.
An attempt to summarize this thread, so that we can stop going round in circles.
Possibly so. The problem is that for the last decade MySQL Ab and then Sun would push the interpretation of the GPL in their favor. So for instance, they might say to a customer that if you ship an application together with MySQL server, and the application is also using MySQL specific SQL, it is a derivative of MySQL. I know, because I was one of them. You may not agree that that is the right way to interpret the GPL, but on the other hand that is not yet a guarantee that Oracle as the new owner of MySQL wouldn't sue such users. Given how MySQL Ab historically has interpreted its own copyright, it would be nice to have clarity on the topic, otherwise people can still be scared away from using MySQL, regardless of what the right interpretation is.
An attempt to summarize this thread, so that we can stop going round in circles.
The other thing is that MySQL is used in various ways: as a client server, fully embedded in the application process (libmysqld), and as a framework for proprietary storage engines (which are .so libraries to MySQL server). The question is, do you want to solve the problem for all of those different MySQL customers, or just the client-server scenario.
An attempt to summarize this thread, so that we can stop going round in circles.
* Monty personally got the whole billion from the sale of MySQL. Now he wants more, the greedy bastard!
* He wants to buy MySQL back on the cheap in order to continue to rob the open source movement
* Closed-source software is evil and must die, as well as everybody who profits from it.
* Who needs MySQL anyway?
An attempt to summarize this thread, so that we can stop going round in circles.
An attempt to summarize this thread, so that we can stop going round in circles.
Hi. I'm kind of done with this thread, but I just wanted to say I fully agree with your last paragraph. I was also often critizising that state of affairs when I was inside MySQL/Sun. (Not the dual licensing itself, but lack of strong community, direction to make MySQL ever more closed source, etc...) Monty has a publicly documented history of critizing the same.
An attempt to summarize this thread, so that we can stop going round in circles.
About (1), you are correct about "proprietary". The non-GPL license was commonly called either "OEM license" or "commercial license" at MySQL/Sun. Apparently I still use it sometimes, but I'm aware it is incorrect.
The ongoing MySQL campaign
About the other comments, I have explained elsewhere in this thread why I don't believe the FOSS part and the proprietary part of the MySQL universe are separate universes unaffected by each other. But this is of course something you can disagree with - the issue is not as clear cut as it is for the users of the proprietary MySQL version. And unless the EU steps in - it is something we will eventually find out. Can we at least agree that the need to fork any FOSS project is always an undesirable state to be in, regardless of license?
True. Monty Program has a business model that is based on the GPL version of our MySQL fork. (The company was created before the Oracle acquisition.) We just want people to understand that this cannot help all MySQL users and we are not trying to do that (which Oracle suggested to the EU). No, we don't want MySQL back and certainly couldn't afford it. But we would like MySQL to continue on the path it was, including competing against Oracle and providing Oracle users a free/low-cost alternative.
The ongoing MySQL campaign
The ongoing MySQL campaign
The (de)merits of proprietary databases
while maintaining basic Oracle compatibility and the world will line up at
your doorstep. I certainly would.
drop in replacement for Oracle for most applications. Incompatibility with
Oracle's quirky null handling is the number one obstacle to moving
practically any good sized application from Oracle to PostgreSQL.
Compatibility with common little functions like DECODE() is another, and
support for Oracle's *much* superior outer join syntax. Lots of other
minor things, up to and including PL/SQL compatibility.
what good does it do to have multiple competing SQL databases when each one
implements a completely different dialect with dozens of severe semantic
differences, such that you have to marry your database platform for life,
warts, deficiencies, evil licensing overlords and all?
The (de)merits of proprietary databases
The ongoing MySQL campaign
The ongoing MySQL campaign
The ongoing MySQL campaign
package
all there is to it, and that the blessed one is, additionally, the best (overall, for most uses)
replication package for postgres.
Why is it in core?