Re: Some free utilities for Java, with Hebrew support.

On Sep 26, 5:16 am, Owen Jacobson <angrybald...@xxxxxxxxx> wrote:

[snip latest attack]

This entire discussion should have been over after:

Twisted wrote:
Someone wrote:
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.

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


.

Relevant Pages

  • Re: Confusion about database updates
    ... all connecting to the same database server. ... MySQL can easily handle many simultaneous clients. ... AlphaCluster all open multiple connections to a MySQL server running on ... Let the MySQL server do that when your client ...
    (comp.lang.java.databases)
  • Re: MySQL in installed but mysqld nowhere to be found!!!!
    ... If you choose to install MySQL ... > there is a good possibility that you will run the server. ... think that on any system you'd more likely need client stuff. ... As for "customer relationships" well...you didn't get there to find out ...
    (RedHat)
  • Re: commands out of sync problem
    ... server and client application like this: ... Add a SQLconnection for the MySQL database ... and...tada 'commands out of sync: you can't run this command now'. ...
    (alt.comp.lang.borland-delphi)
  • Re: MySQL permission
    ... I haven't bought any part of MySQL from anyone. ... I'm just trying to use the Fedora MySQL server on one machine, ... and access it from a Fedora mysql client on another. ... But what I would have liked was a straightforward account - ...
    (comp.os.linux.misc)
  • Re: Gradual move to own mail server - strategy for noob
    ... many webmail interfaces use php imap extensions, ... less trouble with the client and server talking to each other ... easy as pie.Never cared about which imap libs were used on the client vs the ... time / space / libraries involved). ...
    (freebsd-questions)