You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Glenn A. Thompson" <gt...@cdr.net> on 2002/07/07 14:16:02 UTC
Re: MySQL vs SVN licensing
Hey:
Karl Fogel wrote:
> Thanks for the heads up.
>
> We weren't planning to put any MySQL code into Subversion, so we
> should be okay, but we'll keep this in mind for the future...
What does this mean?
Do you guys not want what I'm working on? Assuming it can make through a code review
of course.
Or do you mean it in the sense that I'm using ODBC so we should be fine?
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: MySQL vs SVN licensing
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
"Paul Smith" <pa...@nortelnetworks.com> writes:
> I know there have been requests that this thread be deemed off-topic,
> but I'm not sure that it is.
Just to be clear: my request wasn't that the thread itself be deemed
off-topic, but that people making posts in this thread keep them
relevant to Subversion. Which not all of them have been :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: MySQL vs SVN licensing
Posted by Paul Smith <pa...@nortelnetworks.com>.
%% "Bryan O'Sullivan" <bo...@serpentine.com> writes:
bo> On Sun, 2002-07-07 at 11:39, Paul Smith wrote:
>> Well, I double-checked right before I posted to make absolutely sure:
>>
>> http://www.mysql.com/support/arrangements.html
>>
>> Looks like we have a discrepancy here... :-/.
bo> Ah, this is the version of the text that includes the obnoxious old
bo> chestnut: "This is because we view this as linking even if it is done
bo> over the network."
bo> This gave our lawyers fits.
Maybe so, but it's irrelevant for Subversion, as it only applies if (a)
you cannot work with any other SQL database except MySQL, _and_ (b) you
ship your product with the server included. Neither of which are true
for Subversion. And anyway, this is not relevant to the issue of how
the client library is licensed: it only discusses how the server is
licensed.
However, if they have changed the license of the client library to GPL,
that's a big problem. There are plenty of open source licenses which
are not compatible with the GPL, which means that none of those projects
would be able to use MySQL even as a client. Bummer.
--
-------------------------------------------------------------------------------
Paul D. Smith <pa...@nortelnetworks.com> HASMAT--HA Software Mthds & Tools
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: MySQL vs SVN licensing
Posted by Bryan O'Sullivan <bo...@serpentine.com>.
On Sun, 2002-07-07 at 11:39, Paul Smith wrote:
> Well, I double-checked right before I posted to make absolutely sure:
>
> http://www.mysql.com/support/arrangements.html
>
> Looks like we have a discrepancy here... :-/.
Ah, this is the version of the text that includes the obnoxious old
chestnut: "This is because we view this as linking even if it is done
over the network."
This gave our lawyers fits.
<b
Re: MySQL vs SVN licensing
Posted by Paul Smith <pa...@nortelnetworks.com>.
%% "Bryan O'Sullivan" <bo...@serpentine.com> writes:
bo> On Sun, 2002-07-07 at 08:16, Paul Smith wrote:
>> Because the MySQL client library is covered under the LGPL, not the GPL,
>> and there is _absolutely no problem at all_ linking the LGPL'd client
>> library with your package, no matter _what_ the license is.
bo> This is the sticking point. MySQL AB *used* to claim that the
bo> client library was covered by the LGPL, but they now make it clear
bo> that it is covered by the GPL.
bo> http://www.mysql.com/doc/C/o/Copyright.html
Well, I double-checked right before I posted to make absolutely sure:
http://www.mysql.com/support/arrangements.html
Looks like we have a discrepancy here... :-/.
--
-------------------------------------------------------------------------------
Paul D. Smith <pa...@nortelnetworks.com> HASMAT--HA Software Mthds & Tools
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: MySQL vs SVN licensing
Posted by Bryan O'Sullivan <bo...@serpentine.com>.
On Sun, 2002-07-07 at 08:16, Paul Smith wrote:
> Because the MySQL client library is covered under the LGPL, not the GPL,
> and there is _absolutely no problem at all_ linking the LGPL'd client
> library with your package, no matter _what_ the license is.
This is the sticking point. MySQL AB *used* to claim that the client
library was covered by the LGPL, but they now make it clear that it is
covered by the GPL.
http://www.mysql.com/doc/C/o/Copyright.html
Even when the client library was allegedly covered by the LGPL, it was
still de facto GPLed, because of a bizarre definition used by MySQL AB
to cover the notion of "linking".
Frankly, I'm glad they changed the client library to be GPLed. Their
additional licensing language used to be thoroughly obnoxious, but they
seem to have dropped all the stupidities and gone for something entirely
consistent and reasonable. Even if not compatible with SVN :-)
<b
Re: MySQL vs SVN licensing
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
Hey:
ODBC isthe Open Data Base "C" API.
In involves DB vendors writing a driver that supports the standard. Applications
link against a development library that offers the ODBC Manager layer functions.
Managers provide the glue between the Application an the ODBC driver. They provide
selectable access to numerous DBs from the same central Manager. MS Windows
includes it with most their OSes.
Search for ODBC on the Web. You should find some decent architecture desriptions.
Anyway. My belief is that any license issues would fall to the end user. ODBC is
a open standard.
I'm using unixODBC right now. But iODBC is another choice.
As for lining against the client libs. I'm sure they do I'll have to go double
check the make files.
cheers
gat
Paul Smith wrote:
> I did read the thread, but I guess my major problem is I don't know what
> ODBC _is_. Is it some other interface to the DB that does not use the
> MySQL client library? Does the ODBC interface use MySQL code which is
> covered by the GPL?
>
> That is the only question of interest. If you are linking (even
> dynamically!) GPL'd code into your app, then you are in a grey area at
> best.
>
> If you are dynamically linking LGPL'd code into your app (through a
> shared library of some sort), then you are free and clear regardless of
> what license you are using.
>
> --
> -------------------------------------------------------------------------------
> Paul D. Smith <pa...@nortelnetworks.com> HASMAT: HA Software Mthds & Tools
> "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
> -------------------------------------------------------------------------------
> These are my opinions---Nortel Networks takes no responsibility for them.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: MySQL vs SVN licensing
Posted by Paul Smith <pa...@nortelnetworks.com>.
%% "Mark C. Chu-Carroll" <mc...@watson.ibm.com> writes:
>> Do you guys not want what I'm working on? Assuming it can make
>> through a code review of course. Or do you mean it in the sense
>> that I'm using ODBC so we should be fine?
mcc> It's a bit funny to me watching this discussion this
mcc> weekend. Stellation was released open-source last thursday. By
mcc> thursday afternoon, we had our first request/volunteer for adding
mcc> MySQL support. So we've been having almost exactly this
mcc> discussion about whether or not we can support MySQL due to the
mcc> fact that MySQL is GPL, and Stellation is CPL, and the two are
mcc> incompatible.
I know there have been requests that this thread be deemed off-topic,
but I'm not sure that it is.
Can someone please explain to me what problems you see with creating
interfaces to MySQL? How, exactly, are you interfacing with the
database?
Because the MySQL client library is covered under the LGPL, not the GPL,
and there is _absolutely no problem at all_ linking the LGPL'd client
library with your package, no matter _what_ the license is. It could be
100% proprietary and that would _still_ be OK. You just need to follow
the terms of the license which are not, after all, very onerous.
The only time you need to be concerned is if you're linking with GPL'd
code, such as the code contained in the MySQL server.
Maybe I'm misunderstanding what you're doing when you are adding MySQL
support... are you not using the client library?
mcc> But these legal issues are tricky enough that a bunch of hackers
mcc> simply *can't* draw conclusions safely. It's obnoxious, but the
mcc> reality of the situation is, *someone* is going to have to consult
mcc> a lawyer about this, to make sure that what you want to do isn't
mcc> going to get Subversion into legal trouble.
Of course I'm not going to tell anyone they shouldn't consult an
attorney, but I think the situation surrounding the LGPL is quite well
understood, even by laymen, and the fact that LGPL libraries have been
used for years in this manner and no one, including the FSF, has lifted
a finger to stop it is pretty reassuring.
And, as I mentioned before, a very good way forward for those who don't
want to pay legal fees (maybe even safer, in some ways, than asking your
own attorney) is to just ask the copyright holder and see what they
say. I've known many people who've asked both the FSF and MySQL AB
about details of licensing and they always have responded with what they
think the license allows and doesn't. And, after all, what we're really
about here is following the wishes of the author as best we can, not
feeding the court system.
--
-------------------------------------------------------------------------------
Paul D. Smith <pa...@nortelnetworks.com> HASMAT--HA Software Mthds & Tools
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: MySQL transactional support?
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
hey
I'm using InnoDB for my development.
No problems so far.
Although their tablespaces aren't as robust as Oracle's.
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: MySQL transactional support?
Posted by "Mark C. Chu-Carroll" <mc...@watson.ibm.com>.
On Sunday 07 July 2002 04:23 pm, Justin Erenkrantz wrote:
> On Sun, Jul 07, 2002 at 10:29:02AM -0400, Mark C. Chu-Carroll wrote:
> > It's a bit funny to me watching this discussion this weekend. Stellation
> > was released open-source last thursday. By thursday afternoon, we had
> > our first request/volunteer for adding MySQL support. So we've been
> > having
>
> I know in my conversations with Dave Shields, he mentioned that
> MySQL didn't support transactions properly. Therefore, MySQL can
> not be used by anyone looking for a consistent DB. Or, have recent
> MySQL databases improved their robustness?
We looked at MySQL about a year ago, and at the time, transactional
tables had been added, but there was no way to wrap a collection
of statements into a single transaction. For Stellation, we need the
ability to properly handle long transactions, because our checkins
are a single transaction.
One of the first messages we got after we released the code last week
pointed us at the InnoDB extensions to MySQL, which add long-transaction
support. With InnoDB, MySQL can be used as a full ACID RDB.
> Regardless of the licensing debates, if that is still the case,
> that alone should make Subversion not use MySQL. Subversion is
> going to require solid transactional support on the backend. If
> MySQL is going to open the door for inconsistencies, then we must
> not support it.
With InnoDB, that's no longer the case. Single SQL statements are
all fully transactional, and there's a form of SQL support for long
transactions.
> In point of opinion, I believe MySQL is nightmare to work with and
> its (write) performance is awful. If we are going to support any SQL
> DB, IMHO, MySQL should not be our preference. -- justin
I haven't worked with it at all. InnoDB has some *very* impressive
performance numbers. But since we haven't put support for it
into Stellation (yet), I can't say how it works in practice.
-Mark
--
Mark Craig Chu-Carroll, IBM T.J. Watson Research Center
*** The Stellation project: Advanced SCM for Collaboration
*** http://www.eclipse.org/stellation
*** Work Email: mcc@watson.ibm.com ------- Personal Email: markcc@bestweb.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: MySQL transactional support?
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
Hey:
Justin Erenkrantz wrote:
> On Sun, Jul 07, 2002 at 10:29:02AM -0400, Mark C. Chu-Carroll wrote:
> > It's a bit funny to me watching this discussion this weekend. Stellation
> > was released open-source last thursday. By thursday afternoon, we had
> > our first request/volunteer for adding MySQL support. So we've been having
>
> I know in my conversations with Dave Shields, he mentioned that
> MySQL didn't support transactions properly. Therefore, MySQL can
> not be used by anyone looking for a consistent DB. Or, have recent
> MySQL databases improved their robustness?
Not True. I have tested InnoDB and all seems good so far. I tested across
tables. All tables need to be InnoDB though. So unless someone can show me how
I'm wrong. It's all merely DB preference to me.
>
>
> Regardless of the licensing debates, if that is still the case,
> that alone should make Subversion not use MySQL.
Which DB do you suggest? I'll put it on my list to look at.
> Subversion is
> going to require solid transactional support on the backend. If
> MySQL is going to open the door for inconsistencies, then we must
> not support it.
I'm not concerned.
>
>
> In point of opinion, I believe MySQL is nightmare to work with and
> its (write) performance is awful. If we are going to support any SQL
> DB, IMHO, MySQL should not be our preference. -- justin
>
Well, I'm trying to design my stuff so that with a little work other databases
can be swapped in.
DB opinions are are like assholes... or something like that:-)
I so hate engaging in these "which is better" discussions. So much so that I
intend to support quite a few DBs before all is said and done.
Postgres comes to mind. Only, As far as I can tell, It doesn't support
tablespaces. This can be a problem when you are storing large files. Sure you
can use external references. But I'm not a advocate of that approach. Personal
taste I guess.
My repos will most likely start at about 50GB.
As for MySQL being a nightmare. Never had a problem installing, running, or
maintaining it.
Anyway, let me go back under the rock from which I came. When I have something
I will glading play review tenis:-)
Cheers,
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: MySQL transactional support?
Posted by Ask Bjoern Hansen <as...@develooper.com>.
On Sun, 7 Jul 2002, Justin Erenkrantz wrote:
Recent versions of MySQL does support transactions properly (through
the InnoDB backend and others).
[...]
> In point of opinion, I believe MySQL is nightmare to work with and
> its (write) performance is awful.
Configured properly MySQL can perform really really well. From my
experience (MySQL, postgresql, Oracle) it's also very simple to
install and administrate.
- ask
--
ask bjoern hansen, http://askbjoernhansen.com/ !try; do();
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
MySQL transactional support?
Posted by Justin Erenkrantz <je...@apache.org>.
On Sun, Jul 07, 2002 at 10:29:02AM -0400, Mark C. Chu-Carroll wrote:
> It's a bit funny to me watching this discussion this weekend. Stellation
> was released open-source last thursday. By thursday afternoon, we had
> our first request/volunteer for adding MySQL support. So we've been having
I know in my conversations with Dave Shields, he mentioned that
MySQL didn't support transactions properly. Therefore, MySQL can
not be used by anyone looking for a consistent DB. Or, have recent
MySQL databases improved their robustness?
Regardless of the licensing debates, if that is still the case,
that alone should make Subversion not use MySQL. Subversion is
going to require solid transactional support on the backend. If
MySQL is going to open the door for inconsistencies, then we must
not support it.
In point of opinion, I believe MySQL is nightmare to work with and
its (write) performance is awful. If we are going to support any SQL
DB, IMHO, MySQL should not be our preference. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: MySQL vs SVN licensing
Posted by "Mark C. Chu-Carroll" <mc...@watson.ibm.com>.
> Hey:
>
> Karl Fogel wrote:
>
>> Thanks for the heads up.
>>
>> We weren't planning to put any MySQL code into Subversion, so we
>> should be okay, but we'll keep this in mind for the future...
>
> What does this mean?
> Do you guys not want what I'm working on? Assuming it can make through
> a code review of course.
> Or do you mean it in the sense that I'm using ODBC so we should be
> fine?
It's a bit funny to me watching this discussion this weekend. Stellation
was released open-source last thursday. By thursday afternoon, we had
our first request/volunteer for adding MySQL support. So we've been having
almost exactly this discussion about whether or not we can support
MySQL due to the fact that MySQL is GPL, and Stellation is CPL, and
the two are incompatible.
We faced this earlier, because our primary support is PostgreSQL, and
the JDBC support is LGPL. Our lawyers thought that that was not a problem,
due to the way that JDBC loads and links DB specific components.
Unfortunately, I think that that's a very specific conclusion, due to
the particular properties of how JDBC works. Can it apply to ODBC
in SubVersion? I don't know. But these legal issues are tricky
enough that a bunch of hackers simply *can't* draw conclusions safely.
It's obnoxious, but the reality of the situation is, *someone* is going
to have to consult a lawyer about this, to make sure that what you want
to do isn't going to get Subversion into legal trouble.
-Mark
--
*** Mark Craig Chu-Carroll, <mc...@watson.ibm.com>
*** IBM T.J. Watson Research Center
*** The Stellation project:
http://domino.research.ibm.com/synedra/synedra.nsf
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: MySQL vs SVN licensing
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
"Glenn A. Thompson" <gt...@cdr.net> writes:
> Karl Fogel wrote:
> > We weren't planning to put any MySQL code into Subversion, so we
> > should be okay, but we'll keep this in mind for the future...
>
> What does this mean?
> Do you guys not want what I'm working on? Assuming it can make
> through a code review of course.
> Or do you mean it in the sense that I'm using ODBC so we should be fine?
Right (your last question, that is).
You're quoting a private mail out of context, so what I said above
probably won't make sense to most people here :-).
The original mail was sent by a friendly watcher to some CollabNet
ppl, warning us that if we're going to link MySQL with the Subversion
we ship, we might need to consult a lawyer first. My response simply
means "Thanks, we're not planning to do that anytime soon, so we'll
cross that bridge if/when we come to it."
That doesn't mean your code isn't wanted by the Subversion project
(which includes everyone working on SVN, not just CollabNet
employees).
But you wouldn't expect CollabNet to be making business plans based on
unfinished code being written by someone over whom it has little or no
influence, would you? :-)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org