Uwe C. Schroeder wrote: > The "fake" in MySQL is that, as discussed a thousand times, you can't use it > in any commercial project without buying a license. With MySQL you either use IIRC, isn't this because they don't provide an LGPL interface to the DB, so that if you use the GPL interface (header files, functions, calls) - your app basically either has to be GPL or a compatible license? Although I have heard that they even try to enforce this if you use ODBC access instead of direct API hits (which I think is a load of bull - ODBC should be the boundry layer between GPL and non-GPL issues - however, the direct API thing I can see). I think part of the problem is that they claim GPL - but their development environment is highly unlike other GPL projects I have seen - all the of the code comes from in-house, and while it is GPL'd (and thus, if someone wanted to, they could fork it), there isn't the multiple (ie, non MySQL) contributors giving code as GPL, etc - so that they couldn't have the dual-licensing (in a way, they kinda pre-empted this). Or am I wrong? > GPL, or proprietary commercial licenses. Since this includes all client libs > a system like OpenOffice can offer MySQL support, StarOffice basically can't > since it's not under GPL. Once again - I think they could offer ODBC support, and not break this - ODBC being the buffer (however, I think MySQL would fight this, though I believe them to be wrong). > I used the work "fake" here because it's pretty much like those "free checking > bank accounts". You have no idea when you will be charged a fee. Since the > legal side of when a license has to be bought for MySQL isn't really clear, I > decided against using or supporting MySQL. This dual policy of "unless it's > 100% GPL what you're doing, buy a license" is very hard to follow. Where is > the line of 100% GPL ? Legally my lawyer thinks that MySQL AB could enforce > the "buy a license" if you write a closed source application in PHP. Usually > the GPL ends at the interpreter. However if you write the PHP app to require > MySQL, then you could be busted. Ok, nobody ever heard of someone who was > forced to buy a license for that - but if there is a lot of money in it, > companies suddenly turn around (see SCO vs. IBM and the rest of the world) PHP is a very special case - and you are right about the ambiguity. This is one reason (aside from technical (de)merits) why I don't like MySQL - the license is not clear at all, and nothing has been settled here. While PostgreSQL uses a BSD license (personally, I like GPL licenses - I believe a GPL license in the long run is better than a BSD-like license, from a code-lifecycle viewpoint), at least they stick with it and it is very *clear* what the license it, no ambiguities. > So I rather stick with a database that is not only technically superior, but > also guarantees that neither my company, nor any of our cutomers ever has to > pay for the database. They can elect to buy support from us or from any other > company offering PostgreSQL support. But they don't HAVE TO. Here is why I like the GPL (and I don't want to start a flamewar - some people like different things - no big deal): "payment" for GPL code is in the form of more code, and knowledge. The GPL fits really well into a meritocratic mindset - ie, I give you my code and knowledge, all I require is that you do the same - so that both of us, and the world, benefits at large. In this manner, the product becomes mutually stronger over time, and eventually it hits a point where no single entity (whether that be an individual or company) can take the code and fork it without breaking the license (unless they remove all parts that are not theirs that are GPL'd). In theory, this keeps the code "available" for future generations, even if development stops on the code. Whereas, with a BSD license, another company could fork it, make it better, add proprietary extensions, not release the code for all of these changes, and make a huge buck off of it. Say these changes become popular, and people prefer it over the original? The original gradually withers and dies, the the proprietary version lives on, secure in its position. At least, that is the theory - we already have a test of it, though it is anybody's guess what the outcome will be: Apple's OSX - based on BSD. It may not be the best test, since Apple is hobbled by their expensive hardware - had OSX been brought out by Microsoft - hmm... Now - I know that this interchange of knowledge doesn't put food on the plate. Personally, I think this is only because people are still stuck with this idea that physical money actually means something. For some whack reason, people still don't understand that all the money in the world is fiat money backed up by nothing (hell, most of it is litterally bits flying around on the internet and stored in databases - possibly a lot in PostgreSQL databases!). Basically, they are already consensually agreeing to use valueless trading tokens. This agreement, and the relative stability of various countries - are the only thing keeping this system in place. So - instead of dollars or euros (fiat tokens) being traded for food, why couldn't code (still bits, after all) be traded for food (or any other kind of goods)? It could - nothing could really stop it, except for the established countries (you couldn't tax such an exchange after all - I think if people seriously went back to using barter in coutries using fiat money - the jackboots would really come out). Well - this train has left its tracks - so I will stop... Andrew L. Ayers Phoenix, Arizona -- CONFIDENTIALITY NOTICE -- This message is intended for the sole use of the individual and entity to whom it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended addressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email, and delete the message. Thank you. ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
