For years, Sleepycat Software has developed and distributed Berkeley DB in C. Now, due to customer demand, Sleepycat has announced a version of Berkeley DB that is written entirely in Java.

Berkley DB Overview

Berkeley DB JE is a high performance, transactional storage engine written entirely in Java. Like the highly successful Berkeley DB product, Berkeley DB JE executes in the address space of the application, without the overhead of client/server communication. It stores data in the application's native format, so no runtime data translation is required. Berkeley DB JE supports full ACID transactions and recovery. It provides an easy-to-use interface, allowing programmers to store and retrieve information quickly, simply and reliably.

Berkeley DB JE was designed from the ground up in Java. It takes full advantage of the Java environment. The Berkeley DB JE API provides a Java Collections-style interface, as well as a programmatic interface similar to the Berkeley DB API. The architecture of Berkeley DB JE supports high performance and concurrency for both read-intensive and write-intensive workloads.

Berkeley DB JE is different from all other Java databases available today. Berkeley DB JE is not a relational engine built in Java. It is a Berkeley DB-style embedded store, with an interface designed for programmers, not DBAs. Berkeley DB JE's architecture employs a log-based, no-overwrite storage system, enabling high concurrency and speed while providing ACID transactions and record-level locking. Berkeley DB JE efficiently caches most commonly used data in memory, without exceeding application-specified limits. In this way Berkeley DB JE works with an application to use available JVM resources while providing access to very large data sets.

The Berkeley DB JE architecture provides an underlying storage layer for any Java application requiring high performance, transactional integrity and recoverability.

Download Berkeley DB Java Edition: Zip tar/gz

Read Berkeley DB Java Edition Getting Started Guide (PDF: 735KB)

I think Sleepycat did an excellent job of integrating a real Java API into their product. Although at the core, the Java API is byte oriented (much like their C API), they have also incorporated the open-source Greybird API into their product. Greybird (http://sourceforge.net/projects/greybird-db) created a layer on top of the Berkeley DB API that allowed databases to be represented as Java collections; it automatically serialized Java objects, hiding the byte array plumbing.

I think Sleepycat should be praised for this approach: they recognized what external users wanted and had already achieved. Instead of re-inventing the wheel (and perhaps getting it wrong) in the way that Sun has traditionally operated, they worked with the Greybird team to integrate the Greybird API directly into their project.

We should use this on SubClipse (the Eclipse plugin for Subversion) instead of the C API with JNI.

I'd like to see how many J2EE users will MySQL lose?

Why shouldn't I switch?

I'd like to see how many J2EE users will MySQL lose?Why shouldn't I switch?

Comparing Berkeley DB to MySQL is silly. MySQL is an RDBMS while Berkeley DB is just the data store without the bells and whistles.

 S.

I'd like to see how many J2EE users will MySQL lose?Why shouldn't I switch?

(NB. I work for MySQL.)

You most likely won't be able to switch easily, because you can't use SQL with BerkeleyDB for Java, and most J2EE components are built upon the availability of SQL as a query language for the datastore, as well as JDBC being available to access the datastore.

BerkeleyDB is an excellent product (we actually have it as a 'storage engine' in MySQL GPL editions, and therefore you _can_ use SQL with it).

I'd like to see how many J2EE users will MySQL lose?

Do you need JDBC? Then you probably will not look at Berkeley DB.

Need a nice binary storage mechanism and simple OS files aren't a good fit? Maybe Berkely DB makes sense for you.

BTW, if you download it, there is source code included, and it's very readable (frankly, it's very clean compared to most of what's out there.)

Only other thing to consider is the dual GPL/commercial license, which means that you have to pay for it unless you ship your own product as GPL.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing!

Only other thing to consider is the dual GPL/commercial license, which means that you have to pay for it unless you ship your own product as GPL.

I haven't read the MySQL license. Is it any different?

I haven't read the MySQL license. Is it any different?

Yes. It is shipped as GPL, but as long as you don't link to their libraries, the GPL doesn't bind your own software. The result is that you can legally use the GPL MySQL in commercial applications without paying for it, as long as you don't use any of their "proprietary" APIs. (Disclaimer: IANAL.) Note that MySQL Inc. may take a different view on this particular topic, b/c they want you to pay for it when you use it in a commercial application:

http://www.mysql.com/products/licensing.html

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing!

Good day!

MySQL AB (we are a Swedish company :) does take a different view on this.

Like Sleepycat, we distribute our software (including the APIs) under the GNU General Public License (GPL) or under a non-GPL license.

If you distribute software based on GPL licensed software, then the entire bundle of software needs to be distributed under the terms of the GPL.

In the case of MySQL we provide an extension to the GPL that allows you to freely distribute software based on GPL-licensed MySQL software, as long as all of the software is licensed under a specific set of Free/Libre and Open Source Software licenses. (See http://www.mysql.com/products/foss-exception.html for details)

If you do not wish to do this, then we sell non-GPL licensing.

Cheers!
--zak

...we sell non-GPL licensing.

GNU seems to agree with Cameron. The GPL FAQ explicates the "mere aggregation" clause as exempting ordinary JDBC deployment from viral licensing:

...pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs.

...we sell non-GPL licensing.

GNU seems to agree with Cameron. The GPL FAQ explicates the "mere aggregation" clause as exempting ordinary JDBC deployment from viral licensing:...pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs.

Unless, of course... you access MySQL through the GPLed JDBC driver.

Its the same problem as with the Berkeley DB stuff... if you're calling GPL code "in-process" then you've caught the GPL virii...

which may or may not be a bad thing, mind you, but definitely something to be aware of.

-Tim.

...we sell non-GPL licensing.

GNU seems to agree with Cameron. The GPL FAQ explicates the "mere aggregation" clause as exempting ordinary JDBC deployment from viral licensing:...pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs.

(NB I work for MySQL)

I'm of the opinion that the FAQ entry _does_not_ agree with Cameron's post. The JDBC driver itself is GPL'd. If you link it into your software, then you most likely fall under the following situation listed in the same item you point to:

"If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program."

and probably the following if you were to decide to write your own mechanism of communicating _directly_ with MySQL using the MySQL protocol over the network:

"But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program."

The simplest thing about our licensing to remebmer is if your software is licensed with an open source, you almost always can use MySQL's products under the terms of the GPL (we now even have a GPL license exception for free/open/libre source software), if your software is commercial, then you (or your lawyer) need to decide whether you can use MySQL or the GPL based on the terms and conditions set forth by the GPL, or alternatively purchase a commercial license from MySQL, which is cost-effective and in my opinion a good value.

Mark: I'm of the opinion that the FAQ entry _does_not_ agree with Cameron's post.

Just to be clear, I wasn't trying to make a definitive statement on the fine points of the license, since IANAL, etc. I do believe in respecting software licenses, and I strongly suggest that people should respect the license terms. I have some questions about the MySQL stance on the subject, though.

Mark: The JDBC driver itself is GPL'd. If you link it into your software, then you most likely fall under the ..

There are two issues. The first is "linking". My understanding, limited at best, is that linking to MySQL APIs would require the MySQL commercial license (or shipping the product that is linked to MySQL as GPL, based on the terms of the GPL.) However, if an application is linked to JDBC (which is the norm) and thus makes NO USE of MySQL APIs, and does not somehow even manage to munge the MySQL code into the same application binary (or binaries), then one would have to conclude that it is not linked, correct? MySQL provides a driver that implements the JDBC API, and thus applications can use the JDBC API to access MySQL, and the JDBC API is not GPL and has no such GPLish requirements for its use, correct?

The second has to do with distribution. My understanding is that one may freely distribute GPL code, as long as the GPL license is included and changes to the sources (if any) are made available. Again, IANAL but I did once stay at a Holiday Inn Express, and I have also read the GPL a few times. Since (according to the explanations in the GPL license) putting GPL products on the same medium as non-GPL products does not imply that the non-GPL products must be GPL'd, it should be possible to ship a commercial software product with a non-GPL license that also has various GPL software on the same medium, including MySQL and its JDBC driver.

The grey area is when an application is built to use JDBC, and it is perfectly capable of using any database like MySQL or Oracle (as another example of a database) and the author wishes to distribute the application under a commercial license, and also to distribute the GPL MySQL database and GPL MySQL JDBC driver, with the intent that the application could make use of the MySQL database+driver. It's grey because the application is not explicitly linked to MySQL, and (as mentioned) it's perfectly legit to distribute GPL products, yet MySQL AB (apologies about the earlier "Inc." thing) has clearly stated that they expect to be compensated for this type of use.

So, I guess what I'm wondering is how that grey area is made black and white. Does the "intent" that the MySQL code could be used constitute "linking"? Or is this legit if it doesn't violate the letter of the GPL?

I look forward to your answers .. I've been pondering this particular question for a long time ....

Also, the MySQL JDBC driver used to be non-GPL, correct? Or was that a different MySQL JDBC driver? (I believe that there are multiple.)

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing!

I believe, mysql jdbc driver ver 2.0.14 was the last version that uses the LGPL driver. Newer versions uses the dual licensing.

I actually raised this issue months back, or was it years, at Javalobby. But I could not get a reasonable enough answer. My 'case study' at that time was Jive which can use almost any RDBMS out there that has a JDBC driver.

Jive is not bundled with any RDBMS, but is it alright for someone to buy the Jive forum, download mysql dan it's latest jdbc and run them together?

Hi,

If you whish to push for OSS broader adoption, please use "crystal clear" licenses. I used to work for a big (known) company, developing software for embedded products. We also included some parts coming from the OSS planet into our products. The legal department maintained (and still does) a list with all known licenses and whether we could use them or not. Basically, it was saying (as far as I can remember) :
- BSD style : ALLOWED
- Apache 1.x : ALLOWED
- LGPL : BE CAREFULL ! AVOID ! ASK US !
- GPL : NOT ALLOWED
...

Sorry but I feel a bit tired of all these lengthy discussions about when you can use it, how you can ... and if you use it this way then it's ok ... bla bla bla ...
The point is that still a lot of code is written to build commercial applications. The companies behind these applications are most of the time not willing to distribute their source code. So, there are a lot of situations where we just CAN'T use GPL code, basically because the license terms are so unclear that companies don't want to take the risk.

I respect a lot the GPL, LGPL and FSF. I just wonder if they are not putting too much mess around OSS. Sorry to be a bit rude, but I just want to express my frustration.

Regards,
Sebastien.

http://www.jroller.com/pages/spetrucci

My 'case study' at that time was Jive which can use almost any RDBMS out there that has a JDBC driver.

Could a JDBC-ODBC Bridge (Type 1) driver avoid MySQL's license. Does MySQL support ODBC?

Same confusion happened with McKoi, an embedded Java DB. Maybe someone can gain insight from here: http://mckoi.com/database/maillist/msg02555.html :-)

Matthias

Cameron: There are two issues. The first is "linking".

Actually, linking is not the deciding factor, and neither is the whole "in-process" / "out-of-process" thing. The GPL is a copyright license, thus wether you have to follow it for your own code is decided on one thing only: is your own "work" (your code) a derived work of another "work" that is licensed under the GPL?

If the answer to the above question is "yes", then you have to abide by the terms of the GPL, meaning that should you distribute your code, you must do so under a license compatible with the GPL. If the answer is "no" then you can basically do whatever you want. The grey area exists because there is no conclusive legal definition of what constitutes a derived work. What ultimatly matters is if you can convice a judge.

Now, if your code uses some specific / proprietary API's of a GPL'ed library then you will have a very hard time convincing anyone that it's not a derived work of that library. If, however, your code is written to a standard API (say, JDBC) of which many implementations exist, then you might have a change convincing a judge that your code is not a derived work of one such (GPL licensed) implementation.

IANAL, of course, so feel free to ignore all of the above :).


Sven.

Cameron:

Mark: I'm of the opinion that the FAQ entry _does_not_ agree with Cameron's post.Just to be clear, I wasn't trying to make a definitive statement on the fine points of the license, since IANAL, etc. I do believe in respecting software licenses, and I strongly suggest that people should respect the license terms. I have some questions about the MySQL stance on the subject, though.Mark: The JDBC driver itself is GPL'd. If you link it into your software, then you most likely fall under the ..There are two issues. The first is "linking". My understanding, limited at best, is that linking to MySQL APIs would require the MySQL commercial license (or shipping the product that is linked to MySQL as GPL, based on the terms of the GPL.) However, if an application is linked to JDBC (which is the norm)
IANAL, however the FSF (not MySQL) does take a stand on this.
and thus makes NO USE of MySQL APIs, and does not somehow even manage to munge the MySQL code into the same application binary (or binaries), then one would have to conclude that it is not linked, correct?

Cameron,

The issue is not linking, but whether you've created a 'derivative work'. It is up to a court to decide what a 'derivate work' is, not MySQL and not the FSF.

MySQL provides a driver that implements the JDBC API, and thus applications can use the JDBC API to access MySQL, and the JDBC API is not GPL and has no such GPLish requirements for its use, correct?

If that argument holds water, then if/when Coherence supports JSR-107 will people be able to use it without honoring your license agreement as long as they only use functionality specified in JSR-107, as it is an API?

Commercial JDBC drivers also have license terms that restrict how you use and/or distribute the drivers, even though they implement JDBC as well. There's nothing from a legal standpoint that I know of that states that an open API overrides the copyright or licensing of an implementation of that API.

The second has to do with distribution. My understanding is that one may freely distribute GPL code, as long as the GPL license is included and changes to the sources (if any) are made available. Again, IANAL but I did once stay at a Holiday Inn Express, and I have also read the GPL a few times. Since (according to the explanations in the GPL license) putting GPL products on the same medium as non-GPL products does not imply that the non-GPL products must be GPL'd, it should be possible to ship a commercial software product with a non-GPL license that also has various GPL software on the same medium, including MySQL and its JDBC driver.

True, as long as the commercial product is not a derivative work of any of the GPLd components. Once again, the acid test is 'Is your application a derivative work of any GPL components', not whether it is distributed side-by-side with them.

The grey area is when an application is built to use JDBC, and it is perfectly capable of using any database like MySQL or Oracle (as another example of a database) and the author wishes to distribute the application under a commercial license, and also to distribute the GPL MySQL database and GPL MySQL JDBC driver, with the intent that the application could make use of the MySQL database+driver. It's grey because the application is not explicitly linked to MySQL, and (as mentioned) it's perfectly legit to distribute GPL products, yet MySQL AB (apologies about the earlier "Inc." thing) has clearly stated that they expect to be compensated for this type of use.

The grey area happens because there is no consistent legal definition of 'derivative work' that applies in all courts/jurisdictions/countries,etc. You will need to ask a judge for clarification.

We acknoledge that this a grey area, which is why we provide guidelines for what we believe are 'derivative works' of MySQL.

If you don't agree with those guidelines, then you should probably ask your lawyer for their interpretation.

On the other hand, we also make available a commercial license, which reduces any of the grey areas surrounding 'derivative works', and under that license we can offer things such as indeminty, warranty, etc.

Of course, _all_ contracts have grey areas, but our commercial license is a pretty standard software license agreement that would be similar to anything you've seen when licensing other commercial software components.

So, I guess what I'm wondering is how that grey area is made black and white. Does the "intent" that the MySQL code could be used constitute "linking"? Or is this legit if it doesn't violate the letter of the GPL?I look forward to your answers .. I've been pondering this particular question for a long time

The short answer is that the grey area surrounding the GPL in this case is left up to a judge to decide, as well as how comfortable you or your company is operating under this 'grey area' if you fall under it.

With the recent exceptions we added to allow other products that fall under open source licenses that are traditionally not compatible with the GPL, it basically comes down to 'is your product open source, or not?'

Our intent with the GPL/Commercial licensing of MySQL revolves around 'contribution'. That is if your product/project is open/free (as in speech, not beer) software, then you should be able to use MySQL with your open/free software, as you are contributing to the open/free software ecosystem.

However, if your project is closed-source and/or commercial, then you are not contributing to the open/free software world, and we ask for financial contribution. We value both forms of contribution, as they both lead to a better product.

If you have further questions/comments about our licensing, we are in the process of an open license review, please contact zak at mysql dot com for more details on how to participate. We sincerely want to make our intent clear through our licensing, and not alienate open source products or commercial customers so any and all feedback is appreciated.

....Also, the MySQL JDBC driver used to be non-GPL, correct? Or was that a different MySQL JDBC driver? (I believe that there are multiple.)

The current MySQL JDBC driver is based on MM.MySQL, which _was_ LPGL, but which I was the sole rights holder. MySQL is now the rights holder to the JDBC driver, and licenses it both commercially and under the GPL, which is in line with the licensing of our other client libraries.

In any case, _anyone_ can re-release a LGPLd library as GPL (see the license text of the LPGL for more information).

There used to be other projects that were JDBC drivers for MySQL, but they haven't been under active development for over 2 years or so.

Mark,

Something just doesn't add up with the explanations that are being given. It may be that I am misunderstanding the GPL, or that it may not be the right license for what MySQL is trying to accomplish (which appears to be to require compensation when MySQL is used in -- or with -- software that is not being distributed as GPL?)

... if/when Coherence supports JSR-107 will people be able to use it without honoring your license agreement as long as they only use functionality specified in JSR-107, as it is an API?

Coherence is not licensed under the GPL, nor has it ever been. However, to attempt to answer the question as best I can, I don't find it likely that our license would apply to software products that do not call any of our own APIs and do not include any of our software for distribution.

There's nothing from a legal standpoint that I know of that states that an open API overrides the copyright or licensing of an implementation of that API.

That is true, but the driver that we are discussing is licensed under the GPL. I'm not trying to imagine ways that people can go around the license; I'm simply trying to understand the implications of the license. If I buy a piece of software, and I download the GPL'd MySQL JDBC driver from somewhere, and I point the commercial software at the JAR that contains the MySQL JDBC driver, have I violated the GPL?

Once again, the acid test is 'Is your application a derivative work of any GPL components', not whether it is distributed side-by-side with them.

I'd be willing to simplify the question, as above, and just ask "what if I take a commercial app (.EAR) and download the GPL MySQL driver (.JAR) and point the app server to the app to deploy it and to the driver to load it ... is that legal? There's no distribution occurring. The only derivative work is the result of the installation and configuration process (which is a stretch at best to call it a derivative work,) but even the GPL doesn't require that you GPL derivative works, unless you distribute them, right?

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing!

Mark,Something just doesn't add up with the explanations that are being given. It may be that I am misunderstanding the GPL, or that it may not be the right license for what MySQL is trying to accomplish (which appears to be to require compensation when MySQL is used in -- or with -- software that is not being distributed as GPL?)

Cameron, the GPL states that when you distribute a 'derivative work' of something that is GPL'd, then that derivative work needs to be distributed under the same terms (i.e. the GPL).

As I've tried to explain before, 'derivative work' depends on a judge's interpretation,and the same is true with 'distribution'.

The reason that MySQL AB is very liberal with what these terms mean in our published interpretation of the GPL is that it is the most responsible thing to do, because it covers the farthest reaches of what a judge might conclude 'derivative work' or 'distribution' means.

We are not our customers' lawyers, nor are we judges. If you need to feel better about your understanding of what the GPL means in your situation, then you need to talk to a lawyer, or a judge in your local jurisdiction, not MySQL AB.

... if/when Coherence supports JSR-107 will people be able to use it without honoring your license agreement as long as they only use functionality specified in JSR-107, as it is an API?Coherence is not licensed under the GPL, nor has it ever been. However, to attempt to answer the question as best I can, I don't find it likely that our license would apply to software products that do not call any of our own APIs and do not include any of our software for distribution.There's nothing from a legal standpoint that I know of that states that an open API overrides the copyright or licensing of an implementation of that API.

The question I asked wasn't pertaining to the GPL, it was pertaining to your argument that because a standard API was being used, then a license was made invalid, or at least it appeared that it was the thrust of your argument. Maybe I read it incorrectly.

That is true, but the driver that we are discussing is licensed under the GPL. I'm not trying to imagine ways that people can go around the license; I'm simply trying to understand the implications of the license.

Unfortunately, there's a non-small minority of the people that do complain about our GPL licensing have these arguments for just that reason.

 If I buy a piece of software, and I download the GPL'd MySQL JDBC driver from somewhere, and I point the commercial software at the JAR that contains the MySQL JDBC driver, have I violated the GPL?Once again, the acid test is 'Is your application a derivative work of any GPL components', not whether it is distributed side-by-side with them.I'd be willing to simplify the question, as above, and just ask "what if I take a commercial app (.EAR) and download the GPL MySQL driver (.JAR) and point the app server to the app to deploy it and to the driver to load it ... is that legal? There's no distribution occurring. The only derivative work is the result of the installation and configuration process (which is a stretch at best to call it a derivative work,) but even the GPL doesn't require that you GPL derivative works, unless you distribute them, right?

Once again, all of the terms and conditions that you are asking me 'is that legal', or stating 'that's not illegal', are all based on what a judge may or may not say should you be involved in a court case where the person licensing software to you under the GPL feels that you have breached the contract established by the GPL. I can not tell you what is legal and illegal with respect to the GPL and your particular situations, because it would depend on how a court would define 'derivative work' and 'distribution' in your jurisdiction.

If you are open source, and meet either compatibility with the GPL, or with any of the open source licenses listed in our 'open source/free software' exception, then the GPL is an appropriate license for you to use with MySQL AB's software (although you may choose to use a commercial license anyway).

If you are a commercial entity, then you need to think a bit harder, and determine if the GPL is approriate for your situation. Other than our very liberal interpretation, we can't help you with that, MySQL AB is not a law firm. You would think that most commercial entities investigate the licensing terms they are agreeing to when purchasing software very carefully, but usually they don't. (Many commercial software licenses are full of terms that most would find more confusing or cause more discussion than the GPL would ever cause).

Alternatively, use our cut-and-dry commercial license, and don't worry about whether or not you comply with the GPL. Our commercial licensing is in almost all cases cheaper than talking with your lawyer (at least the last time I looked at anything I had done by a lawyer).

Mark,

I appreciate you taking the time to reply.

Once again, all of the terms and conditions that you are asking me 'is that legal', or stating 'that's not illegal', are all based on what a judge may or may not say should you be involved in a court case where the person licensing software to you under the GPL feels that you have breached the contract established by the GPL.

Have you considered using a more clear license to avoid that problem? One that could still theoretically be GPL compatible, but more suited to your needs?

I can not tell you what is legal and illegal with respect to the GPL and your particular situations, because it would depend on how a court would define 'derivative work' and 'distribution' in your jurisdiction.

Personally, I find that to be a hindrance to use. A license should be clear.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing!

Mark,I appreciate you taking the time to reply.Once again, all of the terms and conditions that you are asking me 'is that legal', or stating 'that's not illegal', are all based on what a judge may or may not say should you be involved in a court case where the person licensing software to you under the GPL feels that you have breached the contract established by the GPL.Have you considered using a more clear license to avoid that problem?
One that could still theoretically be GPL compatible, but more suited to your needs?

Cameron,

We are working with the open-source community at large to modify our GPL licensing to make it more clear. This of couuse needs to be done carefully, as many ethical and legal decisions to be made as well as consensus built. This takes time.

However there is a danger with just 'inventing' a new open source license, in that a lot of people won't understand it, or don't know what to do with it. Most people know what the GPL/BSD/Apache licenses are, at least on some level...Most companies know whether or not they can use GPL, BSD or Apache licensed components with their software. Many other open source projects have 'invented' their own licenses which nobody understood, or they didn't have everything correct, and the projects had to either re-license, or offer their software under multiple open source licenses, which is even more confusing. We want to avoid that scenario.

I can't stress it enough, there's an license review going on, if this topic is important to you, then please, please e-mail Zak Gerant (zak at mysql dot com) for more information on how to participate in the review.

Hi Mark,

This is the type of problem that I was referring to:

"The licensing [model] MySQL has, they can't even explain it. We called them up and said, 'Do we need to pay for this?' One guy said yes; one said no," said Rick Gabriel, director of technology development for CoreSense Inc., of Saratoga Springs, N.Y. "If you're going to charge a license, charge a license. They have all these stipulations that no one understands."

(From an eWeek article that I saw today.)

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing!

Could Mark, someone else from MySQL AB, or anyone else tell us if this has ever been tried in a court of law? If MySQL AB is sure that using their GPL licensed driver and database in a commercial application without paying for the commercial license is a violation, then I don't suppose they would hesitate a second to sue in order to protect their commercial interests. So is there any legal precedent to shed light on the interpretation of the MySQL license?

On the other hand, if MySQL AB themselves are in doubt about whether they would win such a case, to the extent that they are not even willing to try it for fear of setting a legal precedent against them, then what's the point of having a license? Unless ofcourse you are counting on that the mere uncertainty surrounding the licensing terms will get people to sign up for a commercial license just to be covered...

Mark, you state that:

Our intent with the GPL/Commercial licensing of MySQL revolves around 'contribution'. That is if your product/project is open/free (as in speech, not beer) software, then you should be able to use MySQL with your open/free software, as you are contributing to the open/free software ecosystem.

However, if your project is closed-source and/or commercial, then you are not contributing to the open/free software world, and we ask for financial contribution.

What about applications developed internaly by companies for their own use ? They can be seen as commercial apps since they provide some value (and profit) to the company that uses it. However, since there is no distribution, the GPL I think allows for it. Doesn't this contradict with your intentions to have *any* commercial usage of MySQL to require a commercial license?

Mark, you state that:

Our intent with the GPL/Commercial licensing of MySQL revolves around 'contribution'. That is if your product/project is open/free (as in speech, not beer) software, then you should be able to use MySQL with your open/free software, as you are contributing to the open/free software ecosystem.However, if your project is closed-source and/or commercial, then you are not contributing to the open/free software world, and we ask for financial contribution.

What about applications developed internaly by companies for their own use ? They can be seen as commercial apps since they provide some value (and profit) to the company that uses it. However, since there is no distribution, the GPL I think allows for it. Doesn't this contradict with your intentions to have *any* commercial usage of MySQL to require a commercial license?

Cristian,

The situation you have outlined is indeed a grey area with the GPL (which is why GPL 3.0 is being worked on to address this), and it really comes down to how 'distribution' and 'derivative works' are defined (the argument on that has already been in other portions of that thread, so I won't repeat it here).

Now, speaking not as a MySQL employee, but someone involved with open source for quite some time...

In my opion, the spirit of this agreement is still important...If you're using MySQL under the GPL, then you should be 'acting' like a good open-source citizen, releasing your software based on MySQL under an open source or free software license, filing bug reports, testing MySQL alphas/betas, helping others on the mailing lists, etc.

MySQL AB values the open source aspect of their software as much as the commercial side in furthering the development of their products, and these forms of contributions are important to MySQL AB and the community at large.

However, if you are using MySQL AB's software and not giving back to the community of open source software, I don't think it is unfair for MySQL AB to ask for some other form of contribution to help further the development of MySQL software, especially when the amount of monetary contribution they are asking for is small in comparison, and is (in my admittedly biased opinion) a good value.

If you have questions or comments on our licensing, you can always contact Zak Gerant, who is holding an 'open license review' on his weblog to determine how to solve concerns the open source community has (zak at mysql dot com).

Mark,

Our intent with the GPL/Commercial licensing of MySQL revolves around 'contribution'. That is if your product/project is open/free (as in speech, not beer) software, then you should be able to use MySQL with your open/free software, as you are contributing to the open/free software ecosystem. However, if your project is closed-source and/or commercial, then you are not contributing to the open/free software world, and we ask for financial contribution. We value both forms of contribution, as they both lead to a better product.

I think this GPL vs. commercial distinction leaves out a large number of opensource projects and organizations that are not commercial and that have choosen a different opensource license for publishing their work. This is unfortunate and could easily be avoided by publishing the JDBC drivers under the LGPL as they were before. I think this GPL license might backfire in the long run, since these projects and organizations will have to look elsewhere for a database that is licensed under more liberal terms.

I think this GPL license might backfire in the long run, since these projects and organizations will have to look elsewhere for a database that is licensed under more liberal terms.

I wasn't aware there was an "elsewhere". Where exactly is this "elsewhere" with a no fee DBMS?

Brian,

I think this GPL license might backfire in the long run, since these projects and organizations will have to look elsewhere for a database that is licensed under more liberal terms.

I wasn't aware there was an "elsewhere". Where exactly is this "elsewhere" with a no fee DBMS?

How about PostgreSQL (BSD License) or Firebird (Mozilla Public License)?

Mark,

Our intent with the GPL/Commercial licensing of MySQL revolves around 'contribution'. That is if your product/project is open/free (as in speech, not beer) software, then you should be able to use MySQL with your open/free software, as you are contributing to the open/free software ecosystem. However, if your project is closed-source and/or commercial, then you are not contributing to the open/free software world, and we ask for financial contribution. We value both forms of contribution, as they both lead to a better product.

I think this GPL vs. commercial distinction leaves out a large number of opensource projects and organizations that are not commercial and that have choosen a different opensource license for publishing their work. This is unfortunate and could easily be avoided by publishing the JDBC drivers under the LGPL as they were before. I think this GPL license might backfire in the long run, since these projects and organizations will have to look elsewhere for a database that is licensed under more liberal terms.

Thomas,

This reason is precisely why we have added 'open source/free software' exceptions to our GPL license, which does allow creation of derivative works of MySQL AB's software with software that is licensed under open source licenses that have been historically incompatible with the GPL.

If you have concerns or questions about these exceptions, or our licensing, I invite you to e-mail our community advocate, Zak Gerant (zak at mysql dot com).

Mark,

Thanks for your reponse. I understand your reasoning about wanting closed source or commercial entities paying for a commercial license. I don't know if the GPL is the best licsense for this though, since there are plenty of companies using Linux without paying for it.

Thomas,This reason is precisely why we have added 'open source/free software' exceptions to our GPL license, which does allow creation of derivative works of MySQL AB's software with software that is licensed under open source licenses that have been historically incompatible with the GPL.If you have concerns or questions about these exceptions, or our licensing, I invite you to e-mail our community advocate, Zak Gerant (zak at mysql dot com).

I appreciate that you make these exceptions. It's not fully clear to me what happens when someone takes my open source software that includes MySQL licensed portions and either distributes it or builds something that extends my software. I would guess that they now have to consider the GPL license that MySQL was originally distributed under and take that into consideration.

I see from other posts that you are reviewing the licensing and I would encourage you to at least license the drivers under the LGPL license.

So when I ask the authors of vBulletin where I can download the source for their product for free can I refer them to you for the explaination?

As far as I have heard the legal consensus is that whether or not a product which is used with a GPL licensed product also comes under the GPL terms depends on whether or not the former is a derived work or not. If it merely uses the latter (GPL product) as it is intended to be used with no modifications, it is not a derived work and therefore not covered by the GPL terms.

According to that definition Zak Greant's remark:

If you distribute software based on GPL licensed software, then the entire bundle of software needs to be distributed under the terms of the GPL.

... is only true if your "basing" your product on MySQL involves adapting the product or merging it with your own somehow. It seems to me that calling it's functions through the supplied driver would not belong in that category.

As far as I have heard the legal consensus is that whether or not a product which is used with a GPL licensed product also comes under the GPL terms depends on whether or not the former is a derived work or not. If it merely uses the latter (GPL product) as it is intended to be used with no modifications, it is not a derived work and therefore not covered by the GPL terms.According to that definition Zak Greant's remark:

If you distribute software based on GPL licensed software, then the entire bundle of software needs to be distributed under the terms of the GPL.

... is only true if your "basing" your product on MySQL involves adapting the product or merging it with your own somehow. It seems to me that calling it's functions through the supplied driver would not belong in that category.

This is what I believe too. To me using JDBC to connect to the product, without any modifications, does not tie you to it. Have to agree with the other poster about all of the confusion surrounding GPL. Isn't it funny that all of us posting on this are either working for the company that produces the GPL'd product or are probably actively using GPL'd products in our everyday work and we still can't agree on what the heck is legal or not. Scary.

Mike

MySQL AB owns the code here, so they should be reassigning it under their own license that explicitly covers the scenarios that they desire. (Ex. 'If MySQL is supported or intended to be used in any way with a for-profit product, you are not entitled to this royalty-free license').

Intead, MySQL AB is attempting to overreach in their interpretation of the GPL, and this doesn't do anyone good.

If you want to distribute a Java application with a DB, and you don't care for MySQL's commercial license, there are viable alternatives such as Firebird and PostgreSQL. Please consider using these products instead of violating the desires of the MySQL copyright holders.

I don't understand how the MySQL license comes into it. I write a product that uses JDBC to access a relational database. I distribute the product with instructions on how to configure the environment so that the DB can be accessed. Those instructions cover whatever DB I decide to test the product with. The end user decides what DB to install.

I would even say that you are OK if you distribute MySQL with it's JDBC driver as is and document how your product can be configured to use it if the customer wants to use that DB.

MySQL AB can't have it both ways. If you support a standard connection API then you can't have your viral license apply to all code that uses that API to access data in a DB.

The C version was great for message persistence in our CORBA Notification Service. Hopefully some J2EE vendors will investigate embedding this into their app servers for durable JMS provisions.

I'm interested in how this compares with db4o, which I've used and found good.