Sun buys out MySQL

Roedy Green <see_website.DeleteThis@mindprod.com.invalid> wrote:

>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?
 >> Stay informed about: Sun buys out MySQL 

David Segall wrote:
> Roedy Green <see_website.DeleteThis@mindprod.com.invalid> wrote:
>> 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?

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
 >> Stay informed about: Sun buys out MySQL 

Arne Vajhøj <arne.DeleteThis@vajhoej.dk> wrote:

>David Segall wrote:
>> Roedy Green <see_website.DeleteThis@mindprod.com.invalid> wrote:
>>> 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?
>
>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.
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?
 >> Stay informed about: Sun buys out MySQL 

David Segall wrote:
> Arne Vajhøj <arne.DeleteThis@vajhoej.dk> wrote:
>> 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.
> 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.

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
 >> Stay informed about: Sun buys out MySQL 

Arne Vajhøj wrote:

> 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
--
Lothar Kimmeringer E-Mail: spamfang.DeleteThis@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
 >> Stay informed about: Sun buys out MySQL 

Lothar Kimmeringer wrote:
> Arne Vajhøj wrote:
>> 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.

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
 >> Stay informed about: Sun buys out MySQL 

Arne Vajhøj wrote:

> Lothar Kimmeringer wrote:
>> Arne Vajhøj wrote:
>>> 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
--
Lothar Kimmeringer E-Mail: spamfang.RemoveThis@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
 >> Stay informed about: Sun buys out MySQL 

Lothar Kimmeringer wrote:
> Arne Vajhøj wrote:
>
>> Lothar Kimmeringer wrote:
>>> Arne Vajhøj wrote:
>>>> 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.

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
 >> Stay informed about: Sun buys out MySQL 

Arne Vajhøj wrote:
> Lothar Kimmeringer wrote:
>> Arne Vajhøj wrote:
>>
>>> Lothar Kimmeringer wrote:
>>>> Arne Vajhøj wrote:
>>>>> 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.
>
> 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.

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
 >> Stay informed about: Sun buys out MySQL 

David Harper wrote:
> Arne Vajhøj wrote:
>> Lothar Kimmeringer wrote:
>>> Arne Vajhøj wrote:
>>>
>>>> Lothar Kimmeringer wrote:
>>>>> Arne Vajhøj wrote:
>>>>>> 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.
>>
>> 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.
>
> 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.

True.

Arne
 >> Stay informed about: Sun buys out MySQL 

Arne Vajhøj wrote:
> 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.

--
Lew
 >> Stay informed about: Sun buys out MySQL 

Lew wrote:
> Arne Vajhøj wrote:
>> 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.

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
 >> Stay informed about: Sun buys out MySQL 

Arne Vajhøj wrote:

> 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
--
Lothar Kimmeringer E-Mail: spamfang DeleteThis @kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
 >> Stay informed about: Sun buys out MySQL