Sun buys out MySQL

Thread view:

Roedy Green - 02 Mar 2008 04:12 GMT

Sun bought out opensource MySQL on 2008-02-28.

http://mysql.com/news-and-events/sun/marten_mickos.html
--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

Reply to this Message

Arne Vajhøj - 02 Mar 2008 05:53 GMT

> Sun bought out opensource MySQL on 2008-02-28.
>
> http://mysql.com/news-and-events/sun/marten_mickos.html

They completed some paper work.

The acquisition was announced January 16th.

Arne

Reply to this Message

David Segall - 02 Mar 2008 06:38 GMT

>Sun bought out opensource MySQL on 2008-02-28.
>
>http://mysql.com/news-and-events/sun/marten_mickos.html

Yes, but they don't seem to have changed the license to conform with
their other open source products. It seems that you can still only
distribute MySQL with an open source application and you need to buy a
commercial license to use it with a commercial product. Has anyone
seen any indication that Sun intends to change this?

Reply to this Message

Arne Vajhøj - 02 Mar 2008 14:26 GMT

>> Sun bought out opensource MySQL on 2008-02-28.
>>
[quoted text clipped - 4 lines]
> commercial license to use it with a commercial product. Has anyone
> seen any indication that Sun intends to change this?

SUN are already using the same model as MySQL !

First of all: MySQL is dual licensed GPL with FLOSS exception and
commercial license.

But the name is a slightly misleading - the GPL version can be used
with open source - the commercial version can be used with closed
source - it is all about open versus closed source - it does not
matter whether it is commercial or not.

SUN has released their JVM and Java tool chain under GPL license. But I
believe they still sell it under a different license to companies that
want to use it as a basis for Java on their platform.

Same basic model as far as I can tell.

There is a small but important difference. MySQL changed the license
of the client libraries from LGPL to GPL some years ago. If they follow
SUN's model for Java libraries that should be changed to GPL with
classpath exception.

Which would really make MySQL more attractive for closed source
developers.

Arne

Reply to this Message

David Segall - 02 Mar 2008 15:30 GMT

>>> Sun bought out opensource MySQL on 2008-02-28.
>>>
[quoted text clipped - 25 lines]
>SUN's model for Java libraries that should be changed to GPL with
>classpath exception.

I should have followed your nomenclature and used "closed source"
instead of "commercial".

My post was really only about the "small but important difference" in
your paragraph above. I can distribute a version of all of MySQL's
competitors, including the closed source ones, with my closed source
application. (See <http://database.profectus.com.au>). If I want to
use MySQL without paying for it I must open source my application. I
can use the NetBeans platform, GlassFish, JavaDB and Solaris with my
closed source application and I expected Sun to change the license of
MySQL to conform to this model. Is there any indication that they will
do so?

Reply to this Message

Arne Vajhøj - 02 Mar 2008 20:05 GMT

>> SUN are already using the same model as MySQL !
>>
[quoted text clipped - 24 lines]
> application. (See <http://database.profectus.com.au>). If I want to
> use MySQL without paying for it I must open source my application.

No.

You can use MySQL all you want to internally without open sourcing
anything. The GPL effect only becomes active when you start distributing
your software.

And the criteria is whether your code is "linked" with GPL code. Your
code can use MySQL via Hibernate without problems, because it is
Hibernate not your code that are linked with MySQL libs and
Hibernate meets the open source criteria. It is only if your
code is linked with MySQL that the license becomes an issue.

What really constitutes "linking" in Java is not very well defined,
but Class.forName("com.mysql.jdbc.Driver") can definitely be argued
to be linking.

> I
> can use the NetBeans platform, GlassFish, JavaDB and Solaris with my
> closed source application and I expected Sun to change the license of
> MySQL to conform to this model.

JavaDB is an Apache product not a SUN product - and the Apache license
does not have any GPL type issues.

NetBeans and Glassfish are GPL with classpath exception.

> Is there any indication that they will
> do so?

I don't know.

I think they should.

It would have a relative small impact for those making closed
source end user Java apps.

But it would have big impacts for those creating closed source
Java middleware (used by end user Java apps).

Arne

Reply to this Message

Lothar Kimmeringer - 08 Mar 2008 18:39 GMT

> What really constitutes "linking" in Java is not very well defined,
> but Class.forName("com.mysql.jdbc.Driver") can definitely be argued
> to be linking.

And what about Class.forName(driverName) with driverName being
initialized from a properties-file being edited by the customer?
Or using ODBC? Especially with the JDBC-drivers there already have
been a lot of discussions and opinions differ.

Regards, Lothar

Signature

Lothar Kimmeringer E-Mail: spamfang@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

Reply to this Message

Arne Vajhøj - 08 Mar 2008 21:19 GMT

>> What really constitutes "linking" in Java is not very well defined,
>> but Class.forName("com.mysql.jdbc.Driver") can definitely be argued
[quoted text clipped - 4 lines]
> Or using ODBC? Especially with the JDBC-drivers there already have
> been a lot of discussions and opinions differ.

If the Java byte code can work with any database providing
a JDBC version X compliant JDBC driver, then it should not be
considered linking.

Arne

Reply to this Message

Lothar Kimmeringer - 09 Mar 2008 16:58 GMT

>>> What really constitutes "linking" in Java is not very well defined,
>>> but Class.forName("com.mysql.jdbc.Driver") can definitely be argued
>>> to be linking.

[...]

> If the Java byte code can work with any database providing
> a JDBC version X compliant JDBC driver, then it should not be
> considered linking.

I think, these two statements are the opposite of each other
but it shows the different views.

Regards, Lothar

Signature

Lothar Kimmeringer E-Mail: spamfang@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

Reply to this Message

Arne Vajhøj - 09 Mar 2008 20:07 GMT

>>>> What really constitutes "linking" in Java is not very well defined,
>>>> but Class.forName("com.mysql.jdbc.Driver") can definitely be argued
[quoted text clipped - 8 lines]
> I think, these two statements are the opposite of each other
> but it shows the different views.

No.

Code with a hardcoded Class.forName("com.mysql.jdbc.Driver") will
only work with MySQL.

It is a thin line, but I think the line is there.

Arne

Reply to this Message

David Harper - 09 Mar 2008 20:15 GMT

>>>>> What really constitutes "linking" in Java is not very well defined,
>>>>> but Class.forName("com.mysql.jdbc.Driver") can definitely be argued
[quoted text clipped - 15 lines]
>
> It is a thin line, but I think the line is there.

There's also the issue of whether the code sends MySQL-specific commands
to the database server, such as to set session variables. Then you
could argue that the application is tied to MySQL, whether or not the
driver class name is hard-coded or not.

David Harper
Cambridge, England

Reply to this Message

Arne Vajhøj - 09 Mar 2008 21:01 GMT

>>>>>> What really constitutes "linking" in Java is not very well defined,
>>>>>> but Class.forName("com.mysql.jdbc.Driver") can definitely be argued
[quoted text clipped - 20 lines]
> could argue that the application is tied to MySQL, whether or not the
> driver class name is hard-coded or not.

True.

Arne

Reply to this Message

Lew - 10 Mar 2008 06:10 GMT

> Code with a hardcoded Class.forName("com.mysql.jdbc.Driver") will
> only work with MySQL.
>
> It is a thin line, but I think the line is there.

How would you view code that injects a driver from a deployment descriptor,
similarly to
Class.forName( context.getAttribute( "dbdriver" ));
during init()?

Here we're assuming a getAttribute() that returns a class name read from a
deployment descriptor at run time.

This idiom will work with any database system for which a JDBC driver JAR is
available at run time, whether obtained from the application vendor or some
other source (such as directly from MySQL). It could even allow an
application to hot-swap its back end, though goodness knows why anyone would
do such a thing.

Every time I've encountered this controversy over whether the GPL restricts
certain uses of GPLed JDBC drivers, it hinges on the definition of "linking"
to the JDBC driver. The term is a holdover from when most GPLed code was
written in C (gcc), and doesn't apply as neatly to Java. I think it would
require case law to resolve the question.

Signature

Lew

Reply to this Message

Arne Vajhøj - 11 Mar 2008 00:06 GMT

>> Code with a hardcoded Class.forName("com.mysql.jdbc.Driver") will
>> only work with MySQL.
[quoted text clipped - 20 lines]
> when most GPLed code was written in C (gcc), and doesn't apply as neatly
> to Java. I think it would require case law to resolve the question.

You are right that some rulings from the legal system
would help clear up things.

But as long as the code in question can run unchanged with
multiple databases, then I would not call it linking.

Arne

Reply to this Message

Lothar Kimmeringer - 16 Mar 2008 00:18 GMT

> But as long as the code in question can run unchanged with
> multiple databases, then I would not call it linking.

Your view is different from the view of the developer
of McKoi-DB.

Regards, Lothar

Signature

Lothar Kimmeringer E-Mail: spamfang@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

Reply to this Message

Arne Vajhøj - 16 Mar 2008 03:18 GMT

>> But as long as the code in question can run unchanged with
>> multiple databases, then I would not call it linking.
>
> Your view is different from the view of the developer
> of McKoi-DB.

Could be.

But I think I am right.

If the ability to have code use MySQL by putting the right
text in a config file would make that code fall under
GPL rule, then all Java code and code in any other language
that reads config info and load a driver based on that
would fell under the GPL rule.

Which would be absurd. And is obviously not true.

Arne

Reply to this Message

David Segall - 16 Mar 2008 16:33 GMT

>>> But as long as the code in question can run unchanged with
>>> multiple databases, then I would not call it linking.
[quoted text clipped - 5 lines]
>
>But I think I am right.

Surely the lesson from this debate is what it might cost if you and
MySQL were paying lawyers and expert witnesses to fight over it.

I don't disagree with your interpretation of the MySQL license but why
risk a costly legal battle with MySQL AB when there are open source
and free closed source alternatives that are at least as good as
MySQL?

Reply to this Message

Arne Vajhøj - 16 Mar 2008 23:54 GMT

>>>> But as long as the code in question can run unchanged with
>>>> multiple databases, then I would not call it linking.
[quoted text clipped - 10 lines]
> and free closed source alternatives that are at least as good as
> MySQL?

If somebody prefer to hardcode their Java apps to use a specific
database that are not MySQL because they are afraid MySQL may
sue them if they make the the program load the drivename and
and connection URL from a config file, then I would recommend
them to look at a career outside of software development.

Arne

Reply to this Message

Sun buys out MySQL

Free Magazines