MySQL Bugs: #8508: "Our software is 100% GPL"

Bug #8508	"Our software is 100% GPL" - bdb/LICENSE makes me wonder
Submitted:	14 Feb 2005 23:00	Modified:	25 Aug 2005 4:56
Reporter:	Christian Hammers (Silver Quality Contributor) (OCA)	Email Updates:
Status:	Closed	Impact on me:	None
Category:	Licensing	Severity:	S3 (Non-critical)
Version:	latest	OS:
Assigned to:	Arjen Lentz	CPU Architecture:	Any

Description:
Hello Arjen & Co

I was just in the progress of updating the copyright file of the Debian packages when I
stumbled over http://www.mysql.com/company/legal/licensing/opensource-license.html
which acclaims that: "Our software is 100% GPL (General Public License);".

But in bdb/ there is a file LICENSE that does not look like the (L)GPL!

Can you clearify this and especially check if this licence does conflict with the FLOSS?
I.e. do the Regents of those universities who hold the copyright to the BerkeleyDB also permit linking *their* code together with the non-GPL compliant OpenSSL library as you do since the recent FLOSS update?

bye,

-christian- / Debian maintainer of MySQL

How to repeat:
-

Suggested fix:
-

Our code is GPL, at you know (glitches excepted). Of course we link with various non-GPL components, and of course the licensing of those components should be compatible with our licensing.

- If BDB is linked in, it's only into the MySQL server. Apache only links with the MySQL client. So there is no link between BDB and OpenSSL in the context of Apache.

- I wouldn't expect BDB to be compiled in your build of MySQL Server. We only enable it in our own MySQL-Max edition, as BDB is not a feature most people use. It needs to be explicitly enabled in the build process. Just leave it out.

Does this solve your prob?

Hello Arjen

- When reading "our software" I would assume that covers everything inside the MySQL
  .tar.gz that I can download... (but we can leave that asside)

- After OpenSSL is now accepted by FLOSS I thought about reenabling OpenSSL support
  in the server binaries as this has been asked for by some users. Although I remember  
  that your binaries have neither BerkeleyDB nor OpenSSL enabled, both can be enabled
  from source and I wondered if this can be problematic for distributions or users?
  (I left bdb enabled as it would only generate upgrade problems if I suddenly
  deactivate it)

Except from that, if linking openssl and libmysqlclient in a third program then this is
not relevant to any BerkeleyDB code from the server, there you are right.

bye,

-christian-

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

The "no link between ..." was my personal practical interpretation, but I don't think it flies legally. My apologies for that confusion. For linking, all licenses involved need to be compatible.

The FLOSS exception only relates to the client library, not the server.
In the server, we're moving away from the OpenSSL library. That should solve this problem.
However, I would still recommend against linking BerkelyDB into regular binaries; BDB is rarely used and therefore the interface layer is less tested. It does not qualify for production quality. It should never have been build in to Debian binaries either.

Arjen,

can you tell us something more about your current plans regarding future native SSL support in both the client and the server? Thanks.

I understand that we're going for yaSSL, in the 5.0 tree.

Arjen,

thanks for the information. The 4.1 and 4.0 SSL support won't change?

SSL support in 4.0 was limited.

In 4.1 SSL support was standard and functional. Indeed, the use of OpenSSL in 4.1 has not changed as it would be a significant change and since the 4.1 series is production, only minor bugfixes and security are applied.

For distributions, it would be ok to build 4.0 and even 4.1 without SSL support, if that was required to prevent licensing issues.

Re the BDB storage engine, I'll re-iterate that it is not enabled in the standard binaries we produce. Few people use it. Indeed, someone could build with it, and that could raise potential licensing issues depending on the situation. There's no way we can prevent this, IMHO the user has to take responsibilty for this since we can't verify all possible combinations of build configuration. If the user has specific needs, then they will be able to verify an exact list of packages/licenses for that configuration.

I hope this information and clarification resolves this report.

This is a bug report discussing whether the BerkeleyDB library included with MySQL's source code is compatible with the GPL license under which MySQL is distributed. The bug report was submitted in 2005 and eventually resolved by Arjen Lentz, who explained that the BerkeleyDB library should not be compiled into the MySQL Server because it is rarely used and has an interface layer that is less tested. He also mentioned that the MySQL team was moving away from the OpenSSL library and would be using yaSSL for future SSL support in the 5.0 tree. Finally, Lentz stated that the GPL compatibility of various components should be taken into account when building binaries and that the user has the responsibility to ensure that all components are properly licensed. Original bug URL: https://techniciansnow.com/an-overview-of-the-latest-trends-in-php-development/