 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / November 2007Some free utilities for Java, with Hebrew support.
Hello, I am looking for some free utilities for Java, that supports other languages then English (I need utilities that support Hebrew). 1. Database (Is My-Sql good enough). 2. Report maker. 3. Code for reveal the result of formulas (should not be recrousive, but by stack). Thanks :) ... Also 4. Verison control (Like source safe). The free utilities should be multi-platform (so I can run them on linux nor windows). Thanks :) 在 Sat, 8 Sep 2007 19:31:09 +0300 时, "Mr. X." <no_spam_please@nospam_please.com> 写了: -- >Hello, >I am looking for some free utilities for Java, that supports other languages >then English >(I need utilities that support Hebrew). 1. Database (Is My-Sql good enough). it is enough 2. Report maker. JasperReports, http://www.jaspersoft.com/ >3. Code for reveal the result of formulas (should not be recrousive, but by >stack). > >Thanks :) gumpagain@163.com /** /* Java Is Not Platform-independent.It Is The Platform! */ >Hello, >I am looking for some free utilities for Java, that supports other languages >then English >(I need utilities that support Hebrew). > >1. Database (Is My-Sql good enough). I have a list of free, full featured, databases at <http://users.bigpond.net.au/DavidSegall/ee_freedbms.html>. Of this list MySQL is the only one that may not be free. I'm sure IBM and Oracle support Hebrew but I don't know about the rest. > I have a list of free, full featured, databases at > <http://users.bigpond.net.au/DavidSegall/ee_freedbms.html>. Of this > list MySQL is the only one that may not be free. Eh? I thought we recently had a thread here about MySQL being GPL when parts of it ought to be LGPL. It doesn't get more free as in Free Software Foundation than GPL. :P >> I have a list of free, full featured, databases at >> <http://users.bigpond.net.au/DavidSegall/ee_freedbms.html>. Of this [quoted text clipped - 3 lines] > parts of it ought to be LGPL. It doesn't get more free as in Free > Software Foundation than GPL. :P MySQL is definitely "free software" but that is not "free for everyone". Arne On Sep 9, 9:06 pm, Arne Vajh?j <a...@vajhoej.dk> wrote: > MySQL is definitely "free software" but that is not "free for everyone". ??? >> MySQL is definitely "free software" but that is not "free for everyone". > > ??? In other words, they make some people pay for it.  SignatureLew > nebulou...@gmail.com wrote: > > On Sep 9, 9:06 pm, Arne Vajh?j <a...@vajhoej.dk> wrote: [quoted text clipped - 3 lines] > > In other words, they make some people pay for it. It's GPL. Anyone can use it without paying, so long as they adhere to the terms of the GPL and open source any derivative works. For instance I can legally run a for-profit web site using a MySQL DBMS at the back end and not pay; assuming the site doesn't distribute binary-only modified copies of MySQL stuff at least. If it, say, sells T-shirts with clever slogans like ThinkGeek or suchlike, it doesn't run afoul of the GPL and it certainly doesn't require paying money to legally use MySQL at the back end. I don't see how your statement can be true other than in the narrow case where the "some people" wish to make and distribute a closed- source database system derived from MySQL, or at least something closed-source that uses MySQL code. They'd have to either open source whatever used the MySQL code or negotiate an exemption from MySQL's copyright's holder. The latter might result in being granted permission in exchange for a fee. But how common is that going to be in practise? > They'd have to ... negotiate an exemption from MySQL's > copyright's holder. The latter might result in being granted > permission in exchange for a fee. But how common is that going to be > in practise? Quite common. It's a major source of MySQL's revenue, AFAIK. They are quite open about their dual-licensing policy. SignatureLew > I don't see how your statement can be true other than in the narrow > case where the "some people" wish to make and distribute a closed- [quoted text clipped - 4 lines] > permission in exchange for a fee. But how common is that going to be > in practise? Very common. That is how the majority of the software industry works. Some pay. Other uses another open source database with a non GPL license. Arne On Sep 15, 2:15 pm, Arne Vajh?j <a...@vajhoej.dk> wrote: > nebulou...@gmail.com wrote: > > I don't see how your statement can be true other than in the narrow [quoted text clipped - 7 lines] > > Very common. Eh. This doesn't make sense. Making and distributing a proprietary DBMS derived from MySQL, and having to pay MySQL for the privilege, and then charge at least as much to your own customers? Won't those customers just download and use MySQL instead? Only if you're adding a big useful added feature or something that MySQL lacks, in which case MySQL in allowing the closed-sourcing of such for money instead of insisting all such improvements be folded back into the community is violating the spirit of free software! Or are you referring to how they "cleverly" GPL'd instead of LGPL'd a client library so apps that use it to connect to a database will have to be open sourced or pay? The obvious thing to do then is to use another SQL client library, and perhaps still use MySQL server-side. In short, it doesn't seem like much of a business model for MySQL. A closed source derivative of the MySQL DBMS that costs money is likely to be outcompeted by vanilla MySQL. Use without redistribution is free. And the client library surely has lots of alternatives that can be used in a closed-source client program. > Or are you referring to how they "cleverly" GPL'd instead of LGPL'd a > client library so apps that use it to connect to a database will have > to be open sourced or pay? Yes. > The obvious thing to do then is to use > another SQL client library, and perhaps still use MySQL server-side. Do you know any ? > In short, it doesn't seem like much of a business model for MySQL. A > closed source derivative of the MySQL DBMS that costs money is likely > to be outcompeted by vanilla MySQL. I don't even know if the commercial license allows modifications. > Use without redistribution is > free. And the client library surely has lots of alternatives that can > be used in a closed-source client program. Links please. Arne On Sep 21, 8:13 pm, Arne Vajh?j <a...@vajhoej.dk> wrote: > > The obvious thing to do then is to use > > another SQL client library, and perhaps still use MySQL server-side. > > Do you know any ? Not personally, no, but they're out there. > > free. And the client library surely has lots of alternatives that can > > be used in a closed-source client program. > > Links please. If you want links you go and google it. It's not my job to find you the libraries you want with the licensing terms you want. But it's surely not going to be difficult; SQL is a standard so a variety of client libraries for that standard should be fairly easy to find, same as for FTP, HTTP, and suchlike. Java itself has a basic HTTP client library come *standard*, and there's a bunch of database stuff in JEE libraries that probably includes client-side SQL. Of course Sun's Java license, I'm fairly sure, allows distributing proprietary Java software without paying Sun (or anyone else). Of course, if the MySQL server butchers the standard this might not work with the MySQL server but in that case what you want is a *real* SQL server instead of something that claims to be, but really isn't. On Sep 22, 12:15 am, bbo...@gmail.com wrote: > On Sep 21, 8:13 pm, Arne Vajh?j <a...@vajhoej.dk> wrote: > [quoted text clipped - 11 lines] > > If you want links you go and google it. Surely if you're confident saying that the MySQL client library surely has alternatives, you must have an example, no? Personally I find the assertion somewhat surprising, since there is no market nor "itch" for a third-party MySQL client library that I know of. > SQL is a standard so a variety of client libraries for that standard should > be fairly easy to find While SQL the language is indeed a standard, there is no standard for wire represntations of either queries or result sets -- the mechanism by which SQL queries are actually performed is left entirely to the implementation. SQL doesn't even mandate that there be a wire-level representation: there are several databases that run entirely in the client process's address space, and queries are parsed and turned into function calls, not byte streams. > Of course, if the MySQL server butchers the standard Heh. Cheers, Owen > Surely if you're confident saying that the MySQL client library surely > has alternatives, you must have an example, no? Personally I find the > assertion somewhat surprising, since there is no market nor "itch" for > a third-party MySQL client library that I know of. What you're saying doesn't make sense. There are a ton of independent, third-party libraries for every *other* common type of networking function, language, transport, protocol, or what-have-you. And there's market forces to consider. Clearly there's demand for a client library license-compatible with closed-source development. The marginal cost of such a thing is obviously zero. The price MySQL charges for such a library is considerably greater. SQL itself is not proprietary; not patented/secret/whatever. Ergo, someone will and probably someone has undercut MySQL's price for this particular good. That I don't know of a specific example is immaterial; it is easy to demonstrate its probable existence by simple reasoning. The same reasoning that says that if mints cost 10 cents to make and some store is selling brand-name ones for a buck a pop, and nothing in the nature of a "mint" is secret or patented or anything, then somewhere you will likely find someone selling mints for fifty cents, or a quarter, or even just fifteen cents. (I'd look to see if the very same store carried no-name mints at half the price, before even looking in other stores.) > While SQL the language is indeed a standard, there is no standard for > wire represntations of either queries or result sets That's very odd. If there isn't, there certainly should be. That's as if they'd standardized HTML without bothering to standardize HTTP. Nevertheless, whatever protocol MySQL server uses is surely easy to reverse engineer without "infecting" whatever you're developing with the GPL, using the standard clean-room reverse engineering method used to avoid copyright infringement when developing interoperable software more generally. >> Surely if you're confident saying that the MySQL client library surely >> has alternatives, you must have an example, no? Personally I find the [quoted text clipped - 4 lines] > third-party libraries for every *other* common type of networking > function, language, transport, protocol, or what-have-you. No. There are lots of closed protocols with only one implementation out there. > And there's > market forces to consider. Clearly there's demand for a client library > license-compatible with closed-source development. Not very clear to me. Those that are willing to pay probably just pay MySQL for a commercial license. BTW, I thought we are talking about a zero cost alternative. > The marginal cost > of such a thing is obviously zero. The price MySQL charges for such a > library is considerably greater. SQL itself is not proprietary; not > patented/secret/whatever. Ergo, someone will and probably someone has > undercut MySQL's price for this particular good. You are not making much sense. The marginal cost of software is zero, but the cost of software is not zero. > That I don't know of > a specific example is immaterial; it is easy to demonstrate its > probable existence by simple reasoning. But if the arguments look like a swiss cheese then ... > The same reasoning that says that if mints cost 10 cents to make and > some store is selling brand-name ones for a buck a pop, and nothing in [quoted text clipped - 3 lines] > same store carried no-name mints at half the price, before even > looking in other stores.) Following your logic a Windows Vista DVD should cost just little over what the DVD media cost. Try make a reality check. >> While SQL the language is indeed a standard, there is no standard for >> wire represntations of either queries or result sets > > That's very odd. If there isn't, there certainly should be. That's as > if they'd standardized HTML without bothering to standardize HTTP. Your opinion about how it should be does not change how it is. > Nevertheless, whatever protocol MySQL server uses is surely easy to > reverse engineer without "infecting" whatever you're developing with > the GPL, using the standard clean-room reverse engineering method used > to avoid copyright infringement when developing interoperable software > more generally. It is possible. But there are no indications that it would make sense to do as a business. And none has so far wanted to spend the time to do a non-GPL open source library (*). Arne *) Not quite true. Someone did. But that became the MySQL driver and they changed the license from LGPL to GPL at some version change (possible 2.x to 3.x). On Sep 23, 8:15 pm, Arne Vajh?j <a...@vajhoej.dk> wrote: > There are lots of closed protocols with only one implementation > out there. And we are not discussing any of them. The only protocols at issue here have GPL implementations and thus can hardly be called "closed". Stop trying to bolster your attacks on me with irrelevant red herrings such as this; it's intellectually dishonest behavior. > > And there's > > market forces to consider. Clearly there's demand for a client library > > license-compatible with closed-source development. > > Not very clear to me. This flatly contradicts the earlier claim that selling such is the primary business model for the MySQL company. Pick one or the other to support and stick with it please. Or just give up and save both of us further wasted time in this thread. > > The marginal cost > > of such a thing is obviously zero. The price MySQL charges for such a [quoted text clipped - 3 lines] > > You are [insult deleted] Nice -- I make a logical point; you respond with an ad hominem attack. Shall I simply claim victory, or elaborate upon my original point? Or maybe someone needs remedial lessons in economics, such as the basic fact that in a competitive economy a non-secret non-patented good will become available at or not much above marginal cost as a natural outcome of competition, given that it or its ingredients are not physically scarce and that it is in enough demand. MySQL itself gives away copies of MySQL's client library under the GPL. Copies of a compatible third-party library would presumably have the same tiny marginal cost. Selling very cheaply, or giving away, something of the sort under the LGPL or the like would not cost more than with the GPL, and is a natural and likely result of market forces in this area. For example, FooSoft might clean-room-reverse-engineer up such a library and add some extras, then sell a FooSoft server that functions as MySQL server plus plus, and give away their LGPL'd client library. It will gain rapid wide currency with MySQL users who don't want a fully-GPLd client library and have a budget to adhere to, and create a market for the FooSoft server. Some companies might want to buy the souped up server down the line, possibly with money saved from not buying anything from MySQL. It's a straightforward give away the razor business model, in short, and only one of many possible ones that would involve undermining MySQL and competing on price. The only situation I can see where this sort of thing wouldn't tend to happen is if there's a superior and more open database platform -- perhaps PostgreSQL? -- but if that's the case MySQL should be in the process of imploding already anyway. And my original question still stands -- who buys database clients, modifies, and resells them rather than either making their own or purely reselling? Given the way databases are used, I'd expect to just see a) vendors making database servers and client libraries and b) companies acquiring same and deploying them internally, e.g. as part of their web server farm or for financial apps. Internal deployment doesn't seem to invoke the GPL, and so what if it did? If I ran, say, a bank, and in deploying an internal database I had to disclose to the world the source code for any modifications made to the client software, I'd stick it on some obscure corner of the corporate Web site and shrug. Obviously I'd ensure that all our confidential information was located in the database itself rather than any being embedded in or implied somehow by the code, mind you. There still also seem to be ways around this anyway. Suppose I did want to modify the database client and sell a closed-source app based off it. I could modify the database client into an adapter that connected to the database at one end, and provided a simple RMI or similar method to send and receive SQL queries and responses from other processes running on the same hardware -- e.g., by named pipe or a simple HTTP-esque protocol on localhost:8080 or something. This I'd GPL. Then I'd make and sell some proprietary app that looks for a service on localhost:8080...clearly legal since it doesn't contain any GPL'd code. (If this app could fall under the GPL merely by communicating via TCP/IP with GPL'd code, then Microsoft Internet Exploder has to be open sourced under the GPL since it's often used to communicate via TCP/IP with assorted Web servers running GPL'd code.) > Following your logic a Windows Vista DVD should cost just little > over what the DVD media cost. No; Windows Vista is proprietary, whereas SQL is not, and whatever wire protocol might additionally be used by MySQL also is not. A better analogy would be that Windows Vista will support TCP/IP without either being GPL'd or paying anyone for the privilege of implementing a TCP stack. And guess what -- Windows Vista *does* support TCP/IP without either being GPL'd or paying anyone... (TCP having lots of GPL'd implementations, perhaps including the very first.) > > That's very odd. If there isn't, there certainly should be. That's as > > if they'd standardized HTML without bothering to standardize HTTP. > > Your opinion about how it should be does not change how it is. I never claimed it did. Just that it was very odd, if what you were saying is true. > It is possible. > > But there are no indications that it would make sense to do as a > business. Saving a buck no longer makes sense to do as a business? Undercutting a competitor, likewise? America really HAS gone to pot, then. > And none has so far wanted to spend the time to do a non-GPL > open source library (*). [quoted text clipped - 4 lines] > they changed the license from LGPL to GPL at some version change > (possible 2.x to 3.x). There's your non-GPL, non-pay compatible library right there -- told you you could find one. Rather ironic that it's an older version of MySQL's own product, rather than a competitor's, though. >> You are [insult deleted] > > Nice -- I make a logical point; you respond with an ad hominem attack. The "insult deleted" : >> You are not making much sense. The rest of that paragraph: >> The marginal cost of software is zero, but the cost of software is >> not zero. He was: a) Pointing out the lack of clearness in your response. b) Rebutting your point. Since when is an observation about someone's lack of clarity an insult? Furthermore, since when is an observation at all about the presentation an ad hominem attack? Actually, I might add, since when is the truth an insult or an ad hominem attack? It should be obvious that there is a cost to developing software. While the marginal cost may be zero or (in my opinion) very near zero, it is irrefutable that the total cost of development of software is nonzero. I would like to take this time to remind users of this Usenet group -- Twisted and his various aliases in particular -- that it is always important to treat each sentence, and the component phrases thereof, as a cohesive entity that should not be split up and must be represented in totality. Twisted, you in particular have responded to many posts by tossing out wads of very crucial points in an argument under the category of "insults". As an aside, this has made very good material for my discussions on spin... SignatureBeware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth > bbo...@gmail.com wrote: > >> You are [insult deleted] [quoted text clipped - 4 lines] > > [insult deleted] Repeating insults redundantly seems to be quite the pastime around here. It is also off-charter; this is a newsgroup for discussing Java, not the merits or demerits of particular personalities. There are rec.fan newsgroups and alt.flame newsgroups for the latter subject matters; I trust you to know which are for which. And if the subject doesn't rate "celebrity" or above on the fame-o-meter, the only appropriate forum is private e-mail -- *if* that person considers such welcome. Which, in the flame case at least, is doubtful. > He was: > > a) Pointing out the lack of clearness in your response. > b) Rebutting your point. He was: a) Insulting me in typical fashion. b) Wrong. > Since when is an observation about someone's lack of clarity an insult? Since the same day an "observation" (read: allegation) about someone's purported lack of intelligence, integrity, or whatever other desirable trait was an insult. Probably a few tens of thousands of years ago; whenever humans began to be self-aware. I think it might have been a Tuesday, but I'm not certain. Wikipedia hasn't much information on specific historic dates and events going back that far, I'm afraid. :P > Furthermore, since when is an observation at all about the presentation > an ad hominem attack? Since when is anything that implies that <some person> is <something bad> (or not <something good>, anyway) *not* an ad-hominem attack? At least when the nominal subject of discussion is something unrelated to the <something badness> of <some person>. Software licensing, just as an example. Or even Java. > Actually, I might add, since when is [implied insult] f.ck off. > It should be obvious that there is a cost to developing software. While > the marginal cost may be zero or (in my opinion) very near zero, it is > irrefutable that the total cost of development of software is nonzero. And I never claimed otherwise. However, a one time R&D cost amortized over an infinite number of downstream instances of the finished product does equal zero; unlike a physical good, software can be easily duplicated endlessly and copies can still be made and used vast amounts of time after the original maker is dust. (Failure to appreciate the durability of software, in this narrow sense of "durability", is in large part responsible for the Y2K crisis; nobody thought back when they coded all those two-digit years that the stuff they were writing would still be in use anywhere near that far in the future!) It's irrelevant anyway; market forces drive prices down to marginal costs, absent monopoly effects (such as from patents) that prevent free copying or interoperable clones (software copyrights don't prevent interoperable clones). > Twisted, you in particular have responded to many posts by > tossing out wads of very crucial points in an argument under the > category of "insults". I'm sure that to the a.sholes attacking me the insults were indeed "very crucial points", but clearly it is not in the public interest for their nefarious wishes to carry the day, is it now? Of course, this also means that if you have "very crucial points" to make on a subject that is actually on-charter here (i.e. not on the subject of Person Foo's relative merits or lack thereof, but on the subject of Java or something at least tangentially related to it), that you make those "very crucial points" in a neutral and professional manner rather than in a hostile one, or laced with insults or venom in any form, or people will not consider them in the way that you wish. So "X + Y = Z" is neutral. "X + Y = Z, you idiot!" is not; nor is "Anyone with half a brain knows that the answer is *Z*!" or anything else of the sort that takes a derisive tone towards somebody, whatever else it tries to communicate at the same time. In short, if you want your Z taken seriously, don't mix it up with anything irrelevant such as, say, the price of tea in China, or how moronic some person is in your opinion, or whatever. > As an aside, this has made very good material for my discussions on spin... Posting copies of insults against me anywhere else behind my back will be detected and dealt with harshly. Any attempt to spread flamage to other newsgroups, or to spread lies or nasty rumors about me behind my back, likewise. I *will* be intermittently googling to see if my name pops up elsewhere online. Especially given the implications of what you just wrote. Anyone who is found to be badmouthing me gratuitously and without provocation elsewhere on the net will know the consequences of earning my wrath. >> There are lots of closed protocols with only one implementation >> out there. [quoted text clipped - 3 lines] > Stop trying to bolster your attacks on me with irrelevant red herrings > such as this; it's intellectually dishonest behavior. First: GPL licenses apply to source code not to protocols, so what you are writing does not make much sense. Secondly: I was replying to something you wrote: # every *other* common type of networking #function, language, transport, protocol, or what-have-you. which does not sound as protocols implemented in GPL source code only. >>> And there's >>> market forces to consider. Clearly there's demand for a client library [quoted text clipped - 3 lines] > This flatly contradicts the earlier claim that selling such is the > primary business model for the MySQL company. You are assuming that: 1) MySQL actually makes money on connectors as a separate product 2) that there are market for more than one vendor 3) it is possible to compete development wise with the company that defines the protocol That is not clear. > Nice -- I make a logical point; you respond with an ad hominem attack. > Shall I simply claim victory, or elaborate upon my original point? Or [quoted text clipped - 21 lines] > business model, in short, and only one of many possible ones that > would involve undermining MySQL and competing on price. I don't think FooSoft would make money. Apparently none else has, because there are no FooSoft. It is called reality. >> But there are no indications that it would make sense to do as a >> business. > > Saving a buck no longer makes sense to do as a business? Undercutting > a competitor, likewise? America really HAS gone to pot, then. If you think it is good business, then please start one ! >> *) Not quite true. Someone did. But that became the MySQL driver and >> they changed the license from LGPL to GPL at some version change [quoted text clipped - 3 lines] > you you could find one. Rather ironic that it's an older version of > MySQL's own product, rather than a competitor's, though. But that is an interesting piece of historical trivia - it does not provide a library that meet current JDBC standards or support new features in MySQL. Arne [snip] You simply will not give it a rest or leave me alone, will you? You're obsessed! > > And we are not discussing any of them. The only protocols at issue > > here have GPL implementations and thus can hardly be called "closed". > > First: GPL licenses apply to source code not to protocols, so > what you are writing does not make much sense. Yes, it does make sense. You implied that the protocol used by MySQL client/server pairs was proprietary, which is clearly wrong since there's an open source implementation of the client side AND an open source implementation of the server side. [snip some incoherent stuff that does not parse] > > This flatly contradicts the earlier claim that selling such is the > > primary business model for the MySQL company. > > You are assuming that: [snip] That you told the truth earlier? Yeah, maybe not such a smart assumption. > 2) that there are market for more than one vendor There are markets for products and services, not for vendors (well, maybe them too, when you include the stock market, but we were discussing DBMS products, not stocks). > 3) it is possible to compete development wise with the company that > defines the protocol Are you changing the subject again? The only protocol originally under discussion here, and the only one relevant here, has GPL implementations of both ends. We're not talking some proprietary Microsoft protocol that M$ changes randomly with every new version to stop OpenOffice, Linux, or whatever from easily interoperating with Windows. :P > I don't think FooSoft would make money. Think whatever you wish; it won't change the facts. [snip remainder of irrelevant twaddle] Now return to posting about Java, and stop harassing me. > [snip] >>> And we are not discussing any of them. The only protocols at issue [quoted text clipped - 6 lines] > there's an open source implementation of the client side AND an open > source implementation of the server side. I repeat: - code can be either closed source or open source - one form of open source code is via the GPL license - protocols can be proprietary or open standards There are nothing preventing closed source from implementing an open standard protocol or open source to implement a proprietary protocol. >> 2) that there are market for more than one vendor > > There are markets for products and services, not for vendors (well, > maybe them too, when you include the stock market, but we were > discussing DBMS products, not stocks). You seem to not get the point here. >> 3) it is possible to compete development wise with the company that >> defines the protocol [quoted text clipped - 5 lines] > stop OpenOffice, Linux, or whatever from easily interoperating with > Windows. :P MySQL can change this proprietary protocol exactly as Microsft can change their proprietary protocols. It will be easier to reverse engineer. But that will not sound too appealing to paying customers. >> I don't think FooSoft would make money. > > Think whatever you wish; it won't change the facts. The fact is that FooSoft does not exist today. If you think FooSoft will make money, then start PD MySQL Client Library Inc. yourself. Arne > - code can be either closed source or open source > - one form of open source code is via the GPL license [quoted text clipped - 3 lines] > an open standard protocol or open source to implement a > proprietary protocol. Except that only a closed-source vendor can *define* a proprietary protocol. If a protocol's latest version is always immediately embodied in open source code, the protocol clearly cannot be meaningfully called "proprietary" now can it? > > There are markets for products and services, not for vendors (well, > > maybe them too, when you include the stock market, but we were > > discussing DBMS products, not stocks). > > You seem to not get the point here. That might have something to do with the fact that you clearly don't have one. Not a coherent one, at any rate. > MySQL can change this proprietary protocol exactly as Microsft > can change their proprietary protocols. MySQL does not have a proprietary protocol, because they have no IP barrier around it (it is not patented and their implementations are not closed-source). [snip remainder of nonsense attack post] >> - code can be either closed source or open source >> - one form of open source code is via the GPL license [quoted text clipped - 8 lines] > embodied in open source code, the protocol clearly cannot be > meaningfully called "proprietary" now can it? Yes. It can. A proprietary protocol mean that a single company controls the protocol. They can change it whenever they want. They do not need to supply an official specification. Open source means that some source code is available for everyone. No conflict between theese. >> MySQL can change this proprietary protocol exactly as Microsft >> can change their proprietary protocols. > > MySQL does not have a proprietary protocol, because they have no IP > barrier around it (it is not patented and their implementations are > not closed-source). Proprietary does not require patents or closed source. Arne > > Except that only a closed-source vendor can *define* a proprietary > > protocol. If a protocol's latest version is always immediately > > embodied in open source code, the protocol clearly cannot be > > meaningfully called "proprietary" now can it? > > Yes. It can. No, it can't, arnehole, and stop posting pure-attack posts in response to everything I write, and pretty much nothing else, or I will report you to your ISP for abuse. > A proprietary protocol mean that a single company controls the > protocol. They can change it whenever they want. They do not > need to supply an official specification. > > Open source means that some source code is available for everyone. Open source means that they have supplied an official specification: the source code for a reference implementation, which is about as exact a specification as can be. > Proprietary does not require patents or closed source. Yes, it does. Proprietary means that they own, in some sense, a format, protocol, or other thing. It basically equates to IP. That requires either a copyright (and restrictively used, rather than, say, GPL) or patents more or less by definition. With the GPL the MySQL company owns very little, other than they have retained the power of being the guys you have to negotiate with to license it in any way *other* than GPL. >>> Except that only a closed-source vendor can *define* a proprietary >>> protocol. If a protocol's latest version is always immediately [quoted text clipped - 5 lines] > to everything I write, and pretty much nothing else, or I will report > you to your ISP for abuse. Feel free to do so. They will be rolling on the floor laughing. >> A proprietary protocol mean that a single company controls the >> protocol. They can change it whenever they want. They do not [quoted text clipped - 5 lines] > the source code for a reference implementation, which is about as > exact a specification as can be. If you were a programmer then you would know that there is a big difference between a specification and an implementation. >> Proprietary does not require patents or closed source. > [quoted text clipped - 5 lines] > being the guys you have to negotiate with to license it in any way > *other* than GPL. Again: you can not copyright a protocol. MySQL owns the power to change the protocol whenever they want to. Arne > > No, it can't, arnehole, and stop posting pure-attack posts in response > > to everything I write, and pretty much nothing else, or I will report [quoted text clipped - 3 lines] > > They will be rolling on the floor laughing. Your ISP responds to serious complaints of spammy behavior in such a manner? Then I will suggest to *other* ISPs that it be subjected to a UDP. Your repetitious attacks on me for no apparent motive save to keep attacking me amount to spam by sheer ... repetitiveness. > If you were a programmer then you would know that there is a big > difference between a specification and an implementation. A specification is implied by a given implementation, assuming that implementation is conforming. It is safe to assume that the vendor's own reference implementation qualifies, in the absence of an explicit specification. The implicit specification is then "behave the same way this implementation, which you can freely study, behaves". > Again: you can not copyright a protocol. THANK YOU for finally seeing the light. > MySQL owns the power to change the protocol whenever they want to. It's GPL software. ANYONE can make a new version with a changed protocol whenever they want to. Any greater impact from MySQL doing so follows solely from their marketing position and has no basis in law or "ownership" of anything. Also, nobody has to upgrade if they don't want to. This isn't Microsoft software we're talking about here. Again, it's GPL, so you can keep an old version around in source form and recompile it. You can edit out any auto-update functionality, or anything that makes it break if its attempts to update itself are blocked, and recompile. You just have to share the modified source if you distribute the update- defanged version you made in binary form. If you just use it in-house, you needn't worry about the GPL at all. >>> No, it can't, arnehole, and stop posting pure-attack posts in response >>> to everything I write, and pretty much nothing else, or I will report [quoted text clipped - 6 lines] > manner? Then I will suggest to *other* ISPs that it be subjected to a > UDP. You seem to ignore the fact that noone that had read all your posts can consider anything you write seriously. The other ISP's would laugh of you as well. >> Again: you can not copyright a protocol. > > THANK YOU for finally seeing the light. So now we agree that your statement: > It's GPL software. ANYONE can make a new version with a changed > protocol whenever they want to. Sue you can also create your own improved HTTP protocol. And what good will that do you ? None. Because no browsers or web sites will support it. Anyone could create an improved MySQL protocol, but since it will not be able to communicate to MySQL databases there ar enot much point. > Any greater impact from MySQL doing so > follows solely from their marketing position and has no basis in law > or "ownership" of anything. Whatever. The result is the same. > Also, nobody has to upgrade if they don't want to. This isn't > Microsoft software we're talking about here. Again, it's GPL, so you > can keep an old version around in source form and recompile it. You > can edit out any auto-update functionality, or anything that makes it > break if its attempts to update itself are blocked, and recompile. You can. But noone will want to do that. Arne You again! You just argue for the sake of arguing, and to try to make me look bad, don't you? f.ck off! > You seem to ignore the fact that [insult deleted] Liar! f.ck off! > Sue you can also create your own improved HTTP protocol. > > And what good will that do you ? > > None. Because no browsers or web sites will support it. HTTP is a widely standardized protocol. And an open one. There's a big difference there. > Anyone could create an improved MySQL protocol, but since > it will not be able to communicate to MySQL databases > there ar enot much point. It'd be able to communicate with whatever it was designed to communciate with. By your reasoning "there ar enot much point" in HTTP either, since HTTP is also not able to communicate "to" MySQL databases. [snip remainder of nonsensical blather] >> Sue you can also create your own improved HTTP protocol. >> [quoted text clipped - 13 lines] > either, since HTTP is also not able to communicate "to" MySQL > databases. If the logic is to difficult for you, then I can try an explain it more carefully: There are a lot of point in using the HTTP protocol because web servers and browsers support it. There are a lot of point in using the MySQL protocol, because MySQL server and client apps support it. There are no point in a modified HTTP protocol and there are no point in a modified MySQL protocol, because it will not be able to talk to anybody. Arne >There are a lot of point in using the HTTP protocol because >web servers and browsers support it. The other big advantage is HTTP can tunnel through firewalls. Pretty well anything else you cook up, unless it masquerades as HTTP, will require special openings created in the firewalls, meaning support hassles. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com >> There are a lot of point in using the HTTP protocol because >> web servers and browsers support it. [quoted text clipped - 3 lines] > require special openings created in the firewalls, meaning support > hassles. True. But that is a bit besides the point in this thread. Arne > If the logic is to difficult for you, then I can try an explain it > more carefully [remainder of insults snipped] Correct spelling, grammar, AND logic are obviously way above your pay grade. You should quit playing the wannabe at these things and just shut the hell up. > There are a lot of point in using the HTTP protocol because > web servers and browsers support it. See? > There are a lot of point in using the MySQL protocol, because > MySQL server and client apps support it. See? > There are no point in a modified HTTP protocol and there are no > point in a modified MySQL protocol, because it will not be able > to talk to anybody. See? Not only is your grammar as atrocious as usual, but you can't even come up with a cogent argument. The one you just proffered, if it were valid, would mean that there was no point in ever again creating any new protocols for use over TCP/IP. If your argument had been widely believed a bit more than a decade ago we wouldn't even *have* HTTP -- "There are [sic] no point in an HTTP protocol because Gopher is widely supported and ought to be enough for anybody". Of course we've heard sh.t like that before. That there's a worldwide market for maybe five computers; that 640K ought to be enough for anybody; that the telephone was an "electronic toy" of no practical value; "Who the hell wants to hear actors talk?" ... the list goes on. Fortunately the last time someone like you reared his ugly head Tim Berners-Lee paid him no heed and went ahead with his pet project at CERN. Other protocols we might not have if attitudes like yours had prevailed not too far in the past include SSH, SFTP, and several other secured versions of/functional replacements for pre-existing protocols. >> If the logic is to difficult for you, then I can try an explain it >> more carefully [remainder of insults snipped] > > Correct spelling, grammar, AND logic are obviously way above your pay > grade. You should quit playing the wannabe at these things and just > shut the hell up. How many foreign languages do you speak, Paul? /W Wildemar Wildenburger skrev: >>> If the logic is to difficult for you, then I can try an explain it >>> more carefully [remainder of insults snipped] [quoted text clipped - 4 lines] >> > How many foreign languages do you speak, Paul? Arne seems to have a problem with using the right form (plural or singular) of verbs. That is fairly common with Scandinavians, since we don't have that distinction in our languages any longer. Germans have other problems... > Germans have [insult deleted] None of the nasty things you imply about Germans are even remotely true! /W >> Germans have [insult deleted] > > None of the nasty things you imply about Germans are even remotely true! I hope that is was a mistake that :-) was missing ... Arne >>> Germans have [insult deleted] >> [quoted text clipped - 3 lines] > > Arne I don't make mistakes! Ever! I delibarately left out the emoticon, because everyone in the civilized world should recognize parody when confronted with it. It is not my fault that you have no grasp of the widespread conventions of comedy. /W On Nov 5, 9:25 pm, Wildemar Wildenburger <lasses_w...@klapptsowieso.net> wrote: > How many foreign languages do you speak, Paul? Who are you talking to? There is no "Paul" participating in this thread that I'm aware of. I also don't see any relevance to foreign languages here; this part of the thread, at least, seems to be written solely in English. Given that you're talking about a subject that hasn't come up in this thread, to a person that isn't participating in this thread, I must suspect that perhaps you posted this to the wrong thread? > On Nov 5, 9:25 pm, Wildemar Wildenburger > <lasses_w...@klapptsowieso.net> wrote: [quoted text clipped - 8 lines] > thread, to a person that isn't participating in this thread, I must > suspect that perhaps you posted this to the wrong thread? Thanks for snipping the context. You attacked Arne, a non-native English speaker, because he makes spelling and grammar mistakes. I find this very insulting (to him) and a sign of disrespect. Such behavior I find more common in someone who do not speak a foreign language, because learning another language gives you some appreciation and respect for the people who manage that task. I therefore asked you how many languages you spoke, to have my theory confirmed or rejected. I would still like to know. As to calling you Paul ... Childish reply: If you didn't feel addressed, why did you reply, huh? Serious reply: It was a device to tease you, don't think too much of it. I'm not convinced that you are Paul Whoever, and I don't care. We will quite possibly never meet, so it doesn't matter. I however did not snip any context so it was obvious that I'm in the thread I'd wanted to post to. You're handling of this therefore qualifies for "smartassery". I wonder if you will be able to reply without snipping and snapping, and actually give to-the-point replies. I hope you do. /W On Nov 9, 4:51 pm, Wildemar Wildenburger <lasses_w...@klapptsowieso.net> wrote: > Thanks for snipping the context. You're most welcome. > You attacked Arne, a non-native English speaker, because he makes > spelling and grammar mistakes. No, I attacked Arne, whose native-ness is unknown to me, because he is an a.shole that had just attacked me. > I find this very insulting (to him) and a sign of disrespect. I find every single thing he posts to this newsgroup very insulting (to me) and a sign of disrespect. What goes around comes around. > I therefore asked you how many languages you spoke, to have my theory > confirmed or rejected. I would still like to know. And since it's really none of your beeswax ... I'd recommend you not hold your breath. > I'm not convinced that you are Paul Whoever, and I don't care. Well, someone found a link to his obituary and posted it elsewhere recently, so hopefully that particular issue has now been laid to rest. (And I no longer need to feel concerned about the way that the poor sap is being abused gratuitously around here, since he's obviously past caring.) > You're [sic] handling of this therefore qualifies for "smartassery". That's to be expected when I reply to a flame unworthy of a more respectful type of response. > I wonder if you will be able to reply without snipping and snapping Not to someone whose purpose is hostile. Or rather, I would be able to; I just would not choose to. nebulous99@gmail.com skrev: > On Nov 9, 4:51 pm, Wildemar Wildenburger > <lasses_w...@klapptsowieso.net> wrote: >> Thanks for snipping the context. > > You're most welcome. You're not very good at detecting irony... >> I'm not convinced that you are Paul Whoever, and I don't care. > [quoted text clipped - 3 lines] > poor sap is being abused gratuitously around here, since he's > obviously past caring.) Of course, that went over your head. If you had checked the link you would have found that this Paul Derbyshire was an English painter and teacher, born 1936. > nebulous99@gmail.com skrev: >> On Nov 9, 4:51 pm, Wildemar Wildenburger [quoted text clipped - 4 lines] > > You're not very good at detecting irony... Well, I think he is. But he is even better at ignoring it completely. This is a very common, and even pretty useful trick to counter irony, sarcasm and the like. Then again, it's eventual effectivness depends on how cleverly you use that device. /W > Of course, that went over your head. Blades of grass are over Paul's head. sherm-- SignatureWV News, Blogging, and Discussion: http://wv-www.com Cocoa programming in Perl: http://camelbones.sourceforge.net [insult deleted] None of the nasty things that you have said or implied about me are at all true. [insults and assorted nonsense deleted] None of the nasty things that you have said or implied about me are at all true. >> You attacked Arne, a non-native English speaker, because he makes >> spelling and grammar mistakes. > [quoted text clipped - 5 lines] > I find every single thing he posts to this newsgroup very insulting > (to me) and a sign of disrespect. What goes around comes around. That of course is child-logic. And gosh, how well it works! >> I therefore asked you how many languages you spoke, to have my theory >> confirmed or rejected. I would still like to know. > > And since it's really none of your beeswax ... I'd recommend you not > hold your breath. OK. So the answer is "One". Thanks for clearing that matter. >> I'm not convinced that you are Paul Whoever, and I don't care. > [quoted text clipped - 3 lines] > poor sap is being abused gratuitously around here, since he's > obviously past caring.) Oh yes. Now that the only Paul Derbyshire in the world is dead, it is logically proven, that ... This is getting silly. >> You're [sic] handling of this therefore qualifies for "smartassery". > > That's to be expected when I reply to a flame unworthy of a more > respectful type of response. No, that's to be expected when you reply. Period. /W On Nov 12, 5:49 am, Wildemar Wildenburger <lasses_w...@klapptsowieso.net> wrote: [insults and assorted bullshit deleted] > OK. So the answer is "One". Thanks for clearing that matter. I didn't. You are guessing, but you have no confirmation (or refutation) at this time. [remainder of insulting and pointless post deleted] None of the nasty things that you have said or implied about me are at all true. > On Nov 12, 5:49 am, Wildemar Wildenburger > <lasses_w...@klapptsowieso.net> wrote: >> OK. So the answer is "One". Thanks for clearing that matter. > > I didn't. You are guessing, but you have no confirmation (or > refutation) at this time. You did. I am deducing. /W On Nov 14, 11:16 am, Wildemar Wildenburger <lasses_w...@klapptsowieso.net> wrote: > You did. I did not. > I am deducing. Don't quit your day job. > On Nov 9, 4:51 pm, Wildemar Wildenburger > [quoted text clipped - 3 lines] > And since it's really none of your beeswax ... I'd recommend you not > hold your breath. English-only, eh? No need to be so defensive about it, it's really nothing to be ashamed of. > Well, someone found a link to his obituary and posted it elsewhere > recently, so hopefully that particular issue has now been laid to > rest. Different fellow. That Paul Derbyshire was quite old, not from Canada, and one of many people of the same name to be found using Google. The Paul Derbyshire we're talking about here is younger, Canadian, attended Carleton, and trolls usenet using various pseudonyms (such as Neodynium, Twisted, TwistedOne, Nebulous, etc.) in a futile attempt to hide his boorish behavior from potential employers. sherm-- SignatureWV News, Blogging, and Discussion: http://wv-www.com Cocoa programming in Perl: http://camelbones.sourceforge.net > English-only, eh? I didn't say that. [snip a bunch of lies and bullshit] a) I am not that man. b) None of the nasty things that you have said or implied about me are at all true. >> English-only, eh? > > I didn't say that. But you implied it. And by that you damaged your reputation much more than by simply admitting it openly (or staying quiet about it). /W On Nov 14, 11:18 am, Wildemar Wildenburger <lasses_w...@klapptsowieso.net> wrote: > But you implied it. I did not. [remainder of BS deleted] None of the nasty things that you have said or implied about me are at all true. >> There are a lot of point in using the HTTP protocol because >> web servers and browsers support it. [quoted text clipped - 17 lines] > HTTP -- "There are [sic] no point in an HTTP protocol because Gopher > is widely supported and ought to be enough for anybody". > Other protocols we might not have if attitudes like yours had > prevailed not too far in the past include SSH, SFTP, and several other > secured versions of/functional replacements for pre-existing > protocols. Besides that you apparently are ignorant of the fact that Gopher and HTTP were invented with just a few months interval, then you are also missing the big picture: it is very likely be new and improved database wire protocols in the future, but that does still not make much sense to create a modified MySQL protocol for anyone else than MySQL. Arne On Nov 12, 9:19 pm, Arne Vajh?j <a...@vajhoej.dk> wrote: [assorted insults and bullshit deleted] None of the nasty things that you have said or implied about me are at all true. On Sep 23, 12:48 pm, bbo...@gmail.com wrote: > > Surely if you're confident saying that the MySQL client library surely > > has alternatives, you must have an example, no? Personally I find the [quoted text clipped - 3 lines] > Clearly there's demand for a client library license-compatible with > closed-source development. For MySQL? Forgive my blindness, but I see no such demand on the market at large. Perhaps you could illustrate for me? Keep in mind that due to the proprietary and unilateral nature of database wire protocols, any MySQL-compatible driver would necessarily either be MySQL-specific or contain a MySQL-specific protocol adapter. The JDBC and ODBC models are such that the database vendor provides exactly that adapter to fill in a standard API. I do see a demand for closed-source-compatible database access, certainly. That demand is well served by other players in the market, such as PostgreSQL (open source; berkeley licensed) and SQL Server Express Edition (closed source; different licensing structure from MySQL) as well as others. > The marginal cost of [producing software] is obviously zero. But the initial cost is not, and I hold that the initial cost of reverse-engineering and redeveloping the MySQL client libs would never be recovered by sales even when the marginal cost of each sale is zero, because I see no viable market for a MySQL client library. > SQL itself is not proprietary; not patented/secret/whatever. Ergo, > someone will and probably someone has undercut MySQL's price for this > particular good. Agreed, and examples abound. While the only third party to provide MySQL client libraries has since been folded into MySQL and support for the LGPL version dropped in favour of the commercial and GPL versions, there is plenty of competition in the database arena. It's not at the level of client libraries, though: it's at complete SQL implementations. MySQL's competition comes primarily from other database vendors: Firebird, PostgreSQL, Oracle, and various others. Each (along with MySQL) takes the SQL standard and provides its own "extensions", but code that avoids those extensions allows different databases to be dropped in exactly as you envision different client libraries being dropped in. > > While SQL the language is indeed a standard, there is no standard for > > wire represntations of either queries or result sets > > That's very odd. If there isn't, there certainly should be. That's as > if they'd standardized HTML without bothering to standardize HTTP. Where is the business value in any database vendor changing their product to conform to a third standard (after the SQL language and JDBC/ODBC/$LANG db connector standards)? And how would a wire protocol standard encompass non-network databases such as Hypersonic and SQLLite which translate queries into function calls and structs? Imposing a byte stream layer on those databases would seriously hinder their primary benefit: speed. There are also issues with the ancillary crud surrounding primary purpose: not all databases have the same authorization and authentication models, nor the same default behaviour in the absence of an explicit transaction, nor the same implementations of the XA APIs for distributed transactions, nor... a long list of things not directly concerned with DDL or DML. Such a standard would have to do one of two things: leave huge areas to vendors to specialize on, making the standard effectively useless, or mandate one or a handful of strategies for features that differ across vendors, which may not be appropriate for all situations. The database client development community and the database service development community have already reached a good compromise between feature flexibility and standardization at the API level. Why move the standardization point when the existing situation is good enough? And if someone did, would anyone follow? > Nevertheless, whatever protocol MySQL server uses is surely easy to > reverse engineer without "infecting" whatever you're developing with > the GPL, using the standard clean-room reverse engineering method used > to avoid copyright infringement when developing interoperable software > more generally. Indeed, and if you believe there's a market for a clean-room implementation of MySQL's wire protocols, and are willing to play catch-up when MySQL AB unilaterally changes the protocol (as they are wont to do), I encourage you to make one and sell it! Just because I see no market doesn't mean it's not there, and capitalisim is built on exploiting the shortsightedness of others. You've repeatedly stated that someone could reverse-engineer MySQL's protocol and server and add "extensions" to make their product more competitive -- I ask this: what is the benefit in doing so as opposed to creating a complete database implementation (client libraries and all), and what are the risks inherent in doing so as opposed to creating a complete database implementation? Cheers, Owen [0] Anywhere in this post you could replace MySQL with any other database and have the same post. > > Clearly there's demand for a client library license-compatible with > > closed-source development. > > For MySQL? Forgive my blindness, but I see no such demand on the > market at large. What demand, then, do you believe the MySQL company is addressing when it sells non-GPL versions of its own client library? > I do see a demand for closed-source-compatible database access, > certainly. That demand is well served by other players in the market, > such as PostgreSQL (open source; berkeley licensed) and SQL Server > Express Edition (closed source; different licensing structure from > MySQL) as well as others. Sounds like the "more open" PostgreSQL should be taking over MySQL's market share, assuming the Postgre server performs decently and can easily be populated with data from a MySQL database so migration is easy. If migration is hard, then established MySQL-using systems will exhibit inertia though, and same where there's no benefit of migration (e.g. the use of MySQL is open source, so MySQL isn't sticking their hand in anyone's pocket). > I see no viable market for a MySQL client library. MySQL seems to see one. > > SQL itself is not proprietary; not patented/secret/whatever. Ergo, > > someone will and probably someone has undercut MySQL's price for this > > particular good. > > Agreed, and examples abound. At last! Someone sees the light. > Where is the business value in any database vendor changing their > product to conform to a third standard (after the SQL language and [quoted text clipped - 3 lines] > Imposing a byte stream layer on those databases would seriously hinder > their primary benefit: speed. The idea was that database clients connecting to servers over the 'net would be more flexibly mixed and matched; I never suggested that the APIs for accessing a database directly on the same host hardware change in any way, though there, too, there might be benefit from standardization to one API per platform -- this may partially have happened with for example JDBC. I was thinking, for example, a Windows DLL with particular entry points, standardized such that different versions for different database implementations would be interchangeable as far as the calling application was concerned. Actually, a virtual device driver might be better in that case. > The database client development community and the database service > development community have already reached a good compromise between > feature flexibility and standardization at the API level. Why move > the standardization point when the existing situation is good enough? > And if someone did, would anyone follow? Well, it sounds as though the current standardization point produces a situation where some vendors charge well above marginal cost for some uses of some things, which leads to a large deadweight loss to the economy. Such situations are usually inherently unstable anyway, though. Most likely, the evolution in this area is for Postgre and any others like it to become more dominant in the near future, and perhaps for some kind of standards to emerge whereby databases become virtual devices of a sort, with permissions systems either inherited from the host OS or with a few standard, specialized varieties suited for different situations. > You've repeatedly stated that someone could reverse-engineer MySQL's > protocol and server and add "extensions" to make their product more > competitive -- I ask this: what is the benefit in doing so as opposed > to creating a complete database implementation (client libraries and > all) Less work, obviously. A new client that works with an existing server is less work than a new client and a new server. The flip side is you have no control over the server feature-set if you want a new feature at that end of the connection. Then again, maybe not -- in the case of MySQL. You could change (subject to the GPL) the server you were using to support something new, and your independently-developed closed-source client remains your independently-developed closed-source client. The odd suggestion that the MySQL company would push a button and magically cause the copy of the server you'd installed to stop speaking the same language as your client code I won't bother to rebut in detail; of course there would be a risk of something like that happening if you installed a different version of the server software some day. If the server software tries to auto-update it wouldn't be hard to stop it with a decently configured firewall and a decently knowledgeable sysadmin to configure it. Might be a good idea to suppress any auto-updates regardless, if it's behind your organization's firewall anyway and it's working the way you like it; if it ain't broke don't fix it. On Sep 25, 11:17 am, bbo...@gmail.com wrote: > > You've repeatedly stated that someone could reverse-engineer MySQL's > > protocol and server and add "extensions" to make their product more > > competitive -- I ask this: what is the benefit in doing so as opposed > > to creating a complete database implementation (client libraries and > > all) You snipped a question I consider crucial enough to any business discussion that I'm going to ask it again at the expense of the entire preceeding text: What are the risks in reverse engineering MySQL's protocol, adding your own extra features as extensions, and releasing your own driver implementing that protocol and those extensions as a product? I've outlined a handful below, but there are others. All of these risks *must* be balanced against the projected profits. Remember, you framed the concept of replacing the MySQL client library as making a competing product - not an in-house replacement project. > you have no control over the server feature-set if you want a new feature at > that end of the connection. ... Provided you want to remain compatible with the "stock" MySQL client library. That's risk one. > Then again, maybe not -- in the case of MySQL. You could change > (subject to the GPL) the server you were using to support something > new, and your independently-developed closed-source client remains > your independently-developed closed-source client. Extending the MySQL server has its own risk/reward balance, which is mostly separate from the one for replacing the client library. > in detail; of course there would be a risk of something like that > happening if you installed a different version of the server software > some day. But if you're selling it as a product, it's not "you" (the manufacturer) upgrading the database -- it's your customers upgrading their databases. There's support costs intrinsic in telling them that no, your driver doesn't support the new version yet, and development costs in making it support the new version. Less tangibly, your user base will see you as slow to provide support for new MySQL server features no matter how quickly after they're released you release an updated driver, simply because you're slower than someone else (MySQL AB). That perception, though somewhat unfair, has real effects on your bottom line. MySQL AB would have an interest in introducing features competing client libraries don't support or in changing the protocol to break competing libraries, so I'd expect to see it happen sooner or later. Particularly onerous would be MySQL AB releasing a new feature (say, stored procedures, to pick a fairly recent example) that your customers want badly: as their client library provider, you will have a very short period of time to implement support in your library for the new features before your customers, who want to use the feature, jump ship for another library that *does* provide support. Since the feature is new, that library is most likely to be MySQL AB's own -- they'll have had as long as they want to implement support in their own library prior to announcing the new feature. Worse, since MySQL AB includes upgrades in their license fee, you can't (usefully) charge your customers for the upgrade; they'll simply go where the upgrade is cheaper -- MySQL's own library. > If the server software tries to auto-update it wouldn't be > hard to stop it with a decently configured firewall and a decently > knowledgeable sysadmin to configure it. Would that customers could be configured so readily. There's another risk you may or may not have considered: the cost of legal defense. Regardless of the merit of the case, MySQL AB could bring a suit against you for intellectual property violations. The cost of legal proceedings to get the suit dismissed is not trivial, even if MySQL AB were entirely in the wrong. However, with intellectual property law in as messy a state as it's in, it's not even clear to me that MySQL AB *would* be entirely in the wrong. [snip latest attack] This entire discussion should have been over after: Twisted wrote: > Someone wrote: >> Someone did. But that became the MySQL driver and [quoted text clipped - 4 lines] > you you could find one. Rather ironic that it's an older version of > MySQL's own product, rather than a competitor's, though. The alternate library everyone insists doesn't exist does, and is actually just an older, more liberally licensed version of the GPL one. > You snipped a question No, I addressed it, if you'd care to reread the original post and this time actually pay attention and not skip any of it in your haste to post another public verbal assault against me. > Extending the MySQL server has its own risk/reward balance, which is > mostly separate from the one for replacing the client library. Every damn thing has its own risk/reward balance, in case you hadn't noticed. Using MySQL vs. PostgreSQL. Using any given version or library. Upgrading vs. standing pat. Open sourcing your own stuff vs. trying to control it completely. And so forth. > But if you're selling it as a product... Then you're a MySQL reseller, by the sounds of it, rather than a MySQL competitor. A reseller has no reason to do anything but pass on MySQL's products unmodified save for branding. I think there's confusion here over the three things that might be done with software: * Use it in-house (and possibly customize it) * Resell it * Make a competing, compatible product, e.g. by reverse engineering, or just copying and modifying if the license permits. The first and last of these involve modifying it in some manner, but the second generally does not, save maybe for some sort of rebranding of the product. If one of us has been talking about some of those three cases and the other about different ones, then we'll be talking right past each other. You seem to be discussing reselling it now, whereas the original discussion centered around modifying or re- engineering it instead. Of course, in the competing case, if you soup up your divergent product with extra features that may break compatibility with future updates to the MySQL database, your clients would be using a product that's meant to be used with your divergent server-side tool anyway. I.e. they might use MySQL server and client, or your server and client, and might be told not to expect mixing and matching to work there. In one particular hypothetical scenario, your server is the MySQL server modified (and it's GPL, and free); your client is a product of reverse engineering rather than copying (and it's closed- source and costs money); you're giving away the razor (server) and selling the blades. This seems a viable business model, though MySQL patching serious server bugs will necessitate your integrating those into your forked server or your clients won't be too happy. You seem to be thinking the clients would run vanilla MySQL on the server side and the proprietary client; that would make sense where the client is a straight reimplementation rather than adding anything new. In this case it's the client that has to catch up to any changes MySQL makes so it will interoperate if clients update the server. Clients may have to trade off between getting the new version later and using your library on your terms, or getting the new version sooner and using MySQL's library on their terms. Of course, if they can use MySQL's for free, MySQL is competing successfully on quality and price. But then the original question was about making closed- source derivatives of the client library. The reason to do that being to add new features, which goes back to the other scenario. As for applications that use the library, I'd thought those were developed and used in-house by the end-users; companies making prepackaged applications built |
Enable EMail Alerts
Start New Thread
Reply to this Message