Some free utilities for Java, with Hebrew support.

[bbound]

[snip continued hostility]

The few things that seem to be valid questions in there are addressed
in my response to Owen Jacobson.

As for you, I don't know what your problem with me is and why you
respond in a hostile manner to a substantial fraction of my posts. And
frankly, I don't care either. Please leave me alone. If something in
my postings is consistently bothering you, feel free to killfile me,
but please do leave me alone. If you continue pestering me with
insulting and pointless followups I will become annoyed. You don't
want to see me become annoyed. Trust me on that.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

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.

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
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.)

Following your logic a Windows Vista DVD should cost just little
over what the DVD media cost.

Try make a reality check.

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).

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

As for you, I don't know what your problem with me is and why you
respond in a hostile manner to a substantial fraction of my posts. And
frankly, I don't care either. Please leave me alone. If something in
my postings is consistently bothering you, feel free to killfile me,
but please do leave me alone. If you continue pestering me with
insulting and pointless followups I will become annoyed. You don't
want to see me become annoyed. Trust me on that.

As long as you keep posting false, misleading or inaccurate information
to newsgroups, then you will be corrected. Me or somebody else. Does
not matter.

Accept it or stop using newsgroups. It has been so for decades and
will continue that way.

Arne

 

[bbound]

As for you, I don't know what your problem with me is and why you
respond in a hostile manner to a substantial fraction of my posts. And
frankly, I don't care either. Please leave me alone. If something in
my postings is consistently bothering you, feel free to killfile me,
but please do leave me alone. If you continue pestering me with
insulting and pointless followups I will become annoyed. You don't
want to see me become annoyed. Trust me on that.

As long as you [vicious and false insult deleted]

Okay, then. You insist on continuing to flame me instead of killfiling
me and getting on with your life? Indeed, you explicitly refuse to do
the latter? Fine, then. Go to hell. And don't let the door hit you in
the ass on your way out!

 

[bbound]

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.

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
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 [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.)

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 (*).

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).

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.

 

[Joshua Cranmer]

You are [insult deleted]

Nice -- I make a logical point; you respond with an ad hominem attack.

The "insult deleted" :

The rest of that paragraph:

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...

 

[bbound]

You are [insult deleted]

Nice -- I make a logical point; you respond with an ad hominem attack.

The "insult deleted" :

[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.

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

Actually, I might add, since when is [implied insult]

**** 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 assholes 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.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

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.

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.

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
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.

I don't think FooSoft would make money.

Apparently none else has, because there are no FooSoft.

It is called reality.

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 !

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.

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

 

[Owen Jacobson]

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.

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.

 

[bbound]

[snip]

You simply will not give it a rest or leave me alone, will you? You're
obsessed!

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]

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.

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.

 

[bbound]

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.

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
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.

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.

 

[Owen Jacobson]

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.

 

[nebulous99]

[snip latest attack]

This entire discussion should have been over after:

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.

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 on MySQL I'd expect would provide a
client/server pair that implements that application and uses MySQL
under the hood as an implementation detail. If the client half here is
closed source the problem arises again, along with reverse engineering
and eventually having your own divergent client/server pair as
described above; also, having the end-users do the linking (e.g.
dynamically, via a DLL or .so) seems to circumvent the GPL anyway as
then the end-users get the unmodified library as a separate file,
perhaps directly from MySQL, then make a derivative themselves upon
linking but don't distribute this derivative.

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.

Changing the protocol gratuitously is the behavior of a closed-source
vendor. When the protocol is embodied in GPL'd code it would seem to
be a futile tactic.

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.

That's a serious flaw in the legal system that still awaits
addressing; not a fault in anything I said or did. Of course fixing it
is left as an exercise for the reader.

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.

Clean-room reverse engineering cannot violate diddly-squat, unless
there's a patent involved. (And patents, especially software patents,
are even more broken than copyrights.)

 

[Lew]

Every damn thing has its own risk/reward balance, in case you hadn't
noticed.

Good point, Nebulous. Glad you brought it up.

For example, Brian Goetz's book, /Java Concurrency in Practice/ has a risk in
the price (roughly $35 U.S. at www.amazon.com), and a reward in the enhanced
capability of the reader to write robust, correct, stable multi-threaded Java
programs, something especially important in the increasingly dominant
multi-processor marketplace.

 

[nebulous99]

Every damn thing has its own risk/reward balance, in case you hadn't
noticed.

Good point, Nebulous. Glad you brought it up.

[snip irrelevancy that appears to have been posted to the wrong thread, since I know of a thread elsewhere in this ng where it might have qualified as relevant]

Addressed in the other thread.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

What demand, then, do you believe the MySQL company is addressing when
it sells non-GPL versions of its own client library?

Very little.

I think most refuse to pay.

Several pay for the support (which is said to be excellent) and get
the non-GPL license as a bonus.

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).

End users don't care - GPL is not a problem for them.

ISV's using an open source layer between them and MySQL does
not care - the FLOSS exception cover them.

Other ISV's have a dilemma - my impression is that only the minority
pay and that the majority goes for other solutions - PostgreSQL being
one of them.

MySQL seems to see one.

Maybe. Maybe not.

They definitely need the connectors to sell their main product the
database.

Whether GPL'ing the connectors is based on business or more ideological
reasons I do not know.

Arne

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

The alternate library everyone insists doesn't exist does, and is
actually just an older, more liberally licensed version of the GPL
one.

A library that is not even able to connect to a newer server
with the new password security.

Arne

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

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.

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.

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.

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.

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.

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

 

[nebulous99]

- 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.

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?

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]

 

[nebulous99]

A library that is not even able to connect to a newer server
with the new password security.

Do you have some sort of a point here? Nothing (legally) stops someone
from *not upgrading*, or even from forking the old version and
creating parallel improvements in their fork. (Of course, there is a
lemming-like tendency for people to upgrade stuff. How many iPhone
users who had hacked their phones installed an Apple firmware update
despite being warned that it might be harmful to modified phones? And,
security aside, it's often the case that there's no compelling reason
to upgrade anyway. )