There have been many questions as to the viability of MySQL's
assertion that it can dictate what constitutes a derived work in order
to use the GPL against developers who don't wish their software GPL'd
and force them to pay for a commercial license.
According to the lawyers I've consulted, based on the letter of the
GPL, here is the conclusion:
Commercial users of MySQL opting for the GPL'd version are not
compelled to release their applications under GPL and may use it
freely with their applications provided they do not incorporate any of
the interface code provided by MySQL. In other words, if you use the
ODBC interface, you are not GPLing your software by association. If
you use the MySQL C-library interface, compiled into your application,
then it's GPL'd.
The simple act of connecting to a database by TCP/IP is does not
constitute a derived work of the GPL'd server. Building your own
C-library interface based on the protocol information you can
extrapolate from their C-library source does not constitute a derived
work. Distributing a GPL'd application and source on the same CD as
your proprietary application, as per the conditions detailed in the
GPL, does not constitute a derived work.
Basically, there is no reason why a commercial user cannot use the
GPL'd version of MySQL freely and without worry.
A developer cannot impose its own restrictions over the GPL unless
they release their own license. MySQL AB states, on their website,
that the GPL released version is 100% GPL, meaning that the terms and
conditions of the GPL apply. If they choose to release it under a
modified version of the GPL, then it is not 100% GPL and they need to
provide this license clearly on their website. It would essentially
become a MySQL AB Public License (not GPL) with conditions that
restrict users as they please.
In other words, you cannot say, "this software is a 100% GPL release
but if you're a commercial user then you can't use it under GPL with a
proprietary application", simply because the GPL makes no such
restriction. This claim is no different than saying, "If you connect
to Linux over the network with Windows, then Windows must be GPL'd." -
a bullshit assertion. This kind of restriction would require MySQL AB
create their own free-use license with such a specific condition.
Conclusion: Yes, Virginia, you can use the GPL'd version of MySQL with
your proprietary software. 15 2074
B. Pigman wrote: There have been many questions as to the viability of MySQL's assertion that it can dictate what constitutes a derived work in order to use the GPL against developers who don't wish their software GPL'd and force them to pay for a commercial license.
Use PostgreSQL, its better and doesn't have these problems. According to the lawyers I've consulted, based on the letter of the GPL, here is the conclusion:
Commercial users of MySQL opting for the GPL'd version are not compelled to release their applications under GPL and may use it freely with their applications provided they do not incorporate any of the interface code provided by MySQL. In other words, if you use the ODBC interface, you are not GPLing your software by association. If you use the MySQL C-library interface, compiled into your application, then it's GPL'd.
The lawyers are missing the fact that the ODBC driver links to MySQL code,
and that in turn means your application is linked to MySQL code. The simple act of connecting to a database by TCP/IP is does not constitute a derived work of the GPL'd server. Building your own C-library interface based on the protocol information you can extrapolate from their C-library source does not constitute a derived work. Distributing a GPL'd application and source on the same CD as your proprietary application, as per the conditions detailed in the GPL, does not constitute a derived work.
Basically, there is no reason why a commercial user cannot use the GPL'd version of MySQL freely and without worry.
Not true, you need a non-GPL or LGPL transport layer.
I am not against the GPL, in fact I am a proponent of it. That being said,
it is a powerful license that is being abused by MySQL. Their use of the
GPL is quite viral and amounts to nothing more than shareware.
A few years back, I wrote a high speed session manager for PHP. The session
server was GPL, but the interface library was LGPL, and the actual PHP
extension was signed over to the PHP guys.
B. Pigman wrote: There have been many questions as to the viability of MySQL's assertion that it can dictate what constitutes a derived work in order to use the GPL against developers who don't wish their software GPL'd and force them to pay for a commercial license.
Use PostgreSQL, its better and doesn't have these problems. According to the lawyers I've consulted, based on the letter of the GPL, here is the conclusion:
Commercial users of MySQL opting for the GPL'd version are not compelled to release their applications under GPL and may use it freely with their applications provided they do not incorporate any of the interface code provided by MySQL. In other words, if you use the ODBC interface, you are not GPLing your software by association. If you use the MySQL C-library interface, compiled into your application, then it's GPL'd.
The lawyers are missing the fact that the ODBC driver links to MySQL code,
and that in turn means your application is linked to MySQL code. The simple act of connecting to a database by TCP/IP is does not constitute a derived work of the GPL'd server. Building your own C-library interface based on the protocol information you can extrapolate from their C-library source does not constitute a derived work. Distributing a GPL'd application and source on the same CD as your proprietary application, as per the conditions detailed in the GPL, does not constitute a derived work.
Basically, there is no reason why a commercial user cannot use the GPL'd version of MySQL freely and without worry.
Not true, you need a non-GPL or LGPL transport layer.
I am not against the GPL, in fact I am a proponent of it. That being said,
it is a powerful license that is being abused by MySQL. Their use of the
GPL is quite viral and amounts to nothing more than shareware.
A few years back, I wrote a high speed session manager for PHP. The session
server was GPL, but the interface library was LGPL, and the actual PHP
extension was signed over to the PHP guys.
B. Pigman wrote: There have been many questions as to the viability of MySQL's assertion that it can dictate what constitutes a derived work in order to use the GPL against developers who don't wish their software GPL'd and force them to pay for a commercial license.
Use PostgreSQL, its better and doesn't have these problems. According to the lawyers I've consulted, based on the letter of the GPL, here is the conclusion:
Commercial users of MySQL opting for the GPL'd version are not compelled to release their applications under GPL and may use it freely with their applications provided they do not incorporate any of the interface code provided by MySQL. In other words, if you use the ODBC interface, you are not GPLing your software by association. If you use the MySQL C-library interface, compiled into your application, then it's GPL'd.
The lawyers are missing the fact that the ODBC driver links to MySQL code,
and that in turn means your application is linked to MySQL code. The simple act of connecting to a database by TCP/IP is does not constitute a derived work of the GPL'd server. Building your own C-library interface based on the protocol information you can extrapolate from their C-library source does not constitute a derived work. Distributing a GPL'd application and source on the same CD as your proprietary application, as per the conditions detailed in the GPL, does not constitute a derived work.
Basically, there is no reason why a commercial user cannot use the GPL'd version of MySQL freely and without worry.
Not true, you need a non-GPL or LGPL transport layer.
I am not against the GPL, in fact I am a proponent of it. That being said,
it is a powerful license that is being abused by MySQL. Their use of the
GPL is quite viral and amounts to nothing more than shareware.
A few years back, I wrote a high speed session manager for PHP. The session
server was GPL, but the interface library was LGPL, and the actual PHP
extension was signed over to the PHP guys.
mlw <ml*@nospam.no> wrote in message news:<B_wNb.58868$Rc4.214464@attbi_s54>... B. Pigman wrote:
There have been many questions as to the viability of MySQL's assertion that it can dictate what constitutes a derived work in order to use the GPL against developers who don't wish their software GPL'd and force them to pay for a commercial license. Use PostgreSQL, its better and doesn't have these problems.
That's a choice, but not the point of this discussion. According to the lawyers I've consulted, based on the letter of the GPL, here is the conclusion:
Commercial users of MySQL opting for the GPL'd version are not compelled to release their applications under GPL and may use it freely with their applications provided they do not incorporate any of the interface code provided by MySQL. In other words, if you use the ODBC interface, you are not GPLing your software by association. If you use the MySQL C-library interface, compiled into your application, then it's GPL'd. The lawyers are missing the fact that the ODBC driver links to MySQL code, and that in turn means your application is linked to MySQL code.
The ODBC driver is not being compiled into the executable and
therefore does not appropriate your application. Additionally, nothing
prevents anyone else from writing a 3rd party ODBC driver. The simple act of connecting to a database by TCP/IP is does not constitute a derived work of the GPL'd server. Building your own C-library interface based on the protocol information you can extrapolate from their C-library source does not constitute a derived work. Distributing a GPL'd application and source on the same CD as your proprietary application, as per the conditions detailed in the GPL, does not constitute a derived work.
Basically, there is no reason why a commercial user cannot use the GPL'd version of MySQL freely and without worry. Not true, you need a non-GPL or LGPL transport layer.
Not true. The transport layer is TCP/IP and cannot be appropriated
into a license.
Believe me when I say this was run among a few lawyers, some of whom
are technically knowledgeable given the cases in which they've been
involved that are in this domain. I am not against the GPL, in fact I am a proponent of it. That being said, it is a powerful license that is being abused by MySQL. Their use of the GPL is quite viral and amounts to nothing more than shareware.
They are attempting to reinterpret the GPL and expand its meaning to
support their interpretation. Bottom line is that MySQL AB has
released MySQL under 100% GPL (right smack on their website) and the
GPL does not restrict the use in the manner they pretend to interpret
it. GPL does not prevent interoperation between GPL'd and proprietary
software. Read the GPL carefully and you will note that you can freely
distribute the GPL version of MySQL & source with your proprietary
software without any problems whatsoever, regardless of what MySQL
claims on their website.
If they release software under GPL, it is governed by the GPL. Their
only course of action to assert control over their software is to
release subsequent versions under a new license and abandon the GPL.
They can't say, "well, this is GPL for you only if it's for personal
use ..." since the GPL already allows unrestricted use by definition. A few years back, I wrote a high speed session manager for PHP. The session server was GPL, but the interface library was LGPL, and the actual PHP extension was signed over to the PHP guys.
If the interface layer had been released under GPL, someone could have
rewritten it from scratch and released it under LGPL or BSD. You can't
claim derivation just because they end up doing the same thing in the
end. If that were the case, OpenOffice would have a legal problem
interoperating with MS Office file formats, Samba would have legal
issues interoperating with Windows networks, and so on.
B. Pigman wrote: mlw <ml*@nospam.no> wrote in message news:<B_wNb.58868$Rc4.214464@attbi_s54>... B. Pigman wrote:
> There have been many questions as to the viability of MySQL's > assertion that it can dictate what constitutes a derived work in order > to use the GPL against developers who don't wish their software GPL'd > and force them to pay for a commercial license. Use PostgreSQL, its better and doesn't have these problems.
That's a choice, but not the point of this discussion.
> > According to the lawyers I've consulted, based on the letter of the > GPL, here is the conclusion: > > Commercial users of MySQL opting for the GPL'd version are not > compelled to release their applications under GPL and may use it > freely with their applications provided they do not incorporate any of > the interface code provided by MySQL. In other words, if you use the > ODBC interface, you are not GPLing your software by association. If > you use the MySQL C-library interface, compiled into your application, > then it's GPL'd.
The lawyers are missing the fact that the ODBC driver links to MySQL code, and that in turn means your application is linked to MySQL code.
The ODBC driver is not being compiled into the executable and therefore does not appropriate your application. Additionally, nothing prevents anyone else from writing a 3rd party ODBC driver.
The point you are missing, and one which I think RMS is wrong, but he does
insist, is that even dynamically linked code becomes part of your
application. This includes the MySQL transport layer.
> > The simple act of connecting to a database by TCP/IP is does not > constitute a derived work of the GPL'd server. Building your own > C-library interface based on the protocol information you can > extrapolate from their C-library source does not constitute a derived > work. Distributing a GPL'd application and source on the same CD as > your proprietary application, as per the conditions detailed in the > GPL, does not constitute a derived work. > > Basically, there is no reason why a commercial user cannot use the > GPL'd version of MySQL freely and without worry. Not true, you need a non-GPL or LGPL transport layer.
Not true. The transport layer is TCP/IP and cannot be appropriated into a license.
The transport layer, on the application side, uses MySQL code to talk to the
MySQL sever. Believe me when I say this was run among a few lawyers, some of whom are technically knowledgeable given the cases in which they've been involved that are in this domain.
Then they have not the information with which to fully understand the
question. I too have talked to lawyers, a few of them, as my business
depends on being GPL clean when I have to, and GPL compliant when it makes
sense.
[snip]
A few years back, I wrote a high speed session manager for PHP. The session server was GPL, but the interface library was LGPL, and the actual PHP extension was signed over to the PHP guys. If the interface layer had been released under GPL, someone could have rewritten it from scratch and released it under LGPL or BSD.
You may be able to do that with a Phoenix "clean room" approach, but you
can't re-type copyrighted works and have them clean.
You can't claim derivation just because they end up doing the same thing in the end.
For it not to be derivative, you need a minimum of two developers. One to
read the existing code, interpret it and write a specification which is an
different form than the code. The second developer, with no prior knowledge
of the original application, then writes the "new application."
This is how phoenix escaped the IBM copyright on the PC BIOS.
If that were the case, OpenOffice would have a legal problem interoperating with MS Office file formats, Samba would have legal issues interoperating with Windows networks, and so on.
No, because the developers of these applications have not seen, and have
probably signed documents under penalty of perjury, that they have not seen
the original source code.
mlw <ml*@nospam.no> wrote in message news:<B_wNb.58868$Rc4.214464@attbi_s54>... B. Pigman wrote:
There have been many questions as to the viability of MySQL's assertion that it can dictate what constitutes a derived work in order to use the GPL against developers who don't wish their software GPL'd and force them to pay for a commercial license. Use PostgreSQL, its better and doesn't have these problems.
That's a choice, but not the point of this discussion. According to the lawyers I've consulted, based on the letter of the GPL, here is the conclusion:
Commercial users of MySQL opting for the GPL'd version are not compelled to release their applications under GPL and may use it freely with their applications provided they do not incorporate any of the interface code provided by MySQL. In other words, if you use the ODBC interface, you are not GPLing your software by association. If you use the MySQL C-library interface, compiled into your application, then it's GPL'd. The lawyers are missing the fact that the ODBC driver links to MySQL code, and that in turn means your application is linked to MySQL code.
The ODBC driver is not being compiled into the executable and
therefore does not appropriate your application. Additionally, nothing
prevents anyone else from writing a 3rd party ODBC driver. The simple act of connecting to a database by TCP/IP is does not constitute a derived work of the GPL'd server. Building your own C-library interface based on the protocol information you can extrapolate from their C-library source does not constitute a derived work. Distributing a GPL'd application and source on the same CD as your proprietary application, as per the conditions detailed in the GPL, does not constitute a derived work.
Basically, there is no reason why a commercial user cannot use the GPL'd version of MySQL freely and without worry. Not true, you need a non-GPL or LGPL transport layer.
Not true. The transport layer is TCP/IP and cannot be appropriated
into a license.
Believe me when I say this was run among a few lawyers, some of whom
are technically knowledgeable given the cases in which they've been
involved that are in this domain. I am not against the GPL, in fact I am a proponent of it. That being said, it is a powerful license that is being abused by MySQL. Their use of the GPL is quite viral and amounts to nothing more than shareware.
They are attempting to reinterpret the GPL and expand its meaning to
support their interpretation. Bottom line is that MySQL AB has
released MySQL under 100% GPL (right smack on their website) and the
GPL does not restrict the use in the manner they pretend to interpret
it. GPL does not prevent interoperation between GPL'd and proprietary
software. Read the GPL carefully and you will note that you can freely
distribute the GPL version of MySQL & source with your proprietary
software without any problems whatsoever, regardless of what MySQL
claims on their website.
If they release software under GPL, it is governed by the GPL. Their
only course of action to assert control over their software is to
release subsequent versions under a new license and abandon the GPL.
They can't say, "well, this is GPL for you only if it's for personal
use ..." since the GPL already allows unrestricted use by definition. A few years back, I wrote a high speed session manager for PHP. The session server was GPL, but the interface library was LGPL, and the actual PHP extension was signed over to the PHP guys.
If the interface layer had been released under GPL, someone could have
rewritten it from scratch and released it under LGPL or BSD. You can't
claim derivation just because they end up doing the same thing in the
end. If that were the case, OpenOffice would have a legal problem
interoperating with MS Office file formats, Samba would have legal
issues interoperating with Windows networks, and so on.
mlw <ml*@nospam.no> wrote in message news:<B_wNb.58868$Rc4.214464@attbi_s54>... B. Pigman wrote:
There have been many questions as to the viability of MySQL's assertion that it can dictate what constitutes a derived work in order to use the GPL against developers who don't wish their software GPL'd and force them to pay for a commercial license. Use PostgreSQL, its better and doesn't have these problems.
That's a choice, but not the point of this discussion. According to the lawyers I've consulted, based on the letter of the GPL, here is the conclusion:
Commercial users of MySQL opting for the GPL'd version are not compelled to release their applications under GPL and may use it freely with their applications provided they do not incorporate any of the interface code provided by MySQL. In other words, if you use the ODBC interface, you are not GPLing your software by association. If you use the MySQL C-library interface, compiled into your application, then it's GPL'd. The lawyers are missing the fact that the ODBC driver links to MySQL code, and that in turn means your application is linked to MySQL code.
The ODBC driver is not being compiled into the executable and
therefore does not appropriate your application. Additionally, nothing
prevents anyone else from writing a 3rd party ODBC driver. The simple act of connecting to a database by TCP/IP is does not constitute a derived work of the GPL'd server. Building your own C-library interface based on the protocol information you can extrapolate from their C-library source does not constitute a derived work. Distributing a GPL'd application and source on the same CD as your proprietary application, as per the conditions detailed in the GPL, does not constitute a derived work.
Basically, there is no reason why a commercial user cannot use the GPL'd version of MySQL freely and without worry. Not true, you need a non-GPL or LGPL transport layer.
Not true. The transport layer is TCP/IP and cannot be appropriated
into a license.
Believe me when I say this was run among a few lawyers, some of whom
are technically knowledgeable given the cases in which they've been
involved that are in this domain. I am not against the GPL, in fact I am a proponent of it. That being said, it is a powerful license that is being abused by MySQL. Their use of the GPL is quite viral and amounts to nothing more than shareware.
They are attempting to reinterpret the GPL and expand its meaning to
support their interpretation. Bottom line is that MySQL AB has
released MySQL under 100% GPL (right smack on their website) and the
GPL does not restrict the use in the manner they pretend to interpret
it. GPL does not prevent interoperation between GPL'd and proprietary
software. Read the GPL carefully and you will note that you can freely
distribute the GPL version of MySQL & source with your proprietary
software without any problems whatsoever, regardless of what MySQL
claims on their website.
If they release software under GPL, it is governed by the GPL. Their
only course of action to assert control over their software is to
release subsequent versions under a new license and abandon the GPL.
They can't say, "well, this is GPL for you only if it's for personal
use ..." since the GPL already allows unrestricted use by definition. A few years back, I wrote a high speed session manager for PHP. The session server was GPL, but the interface library was LGPL, and the actual PHP extension was signed over to the PHP guys.
If the interface layer had been released under GPL, someone could have
rewritten it from scratch and released it under LGPL or BSD. You can't
claim derivation just because they end up doing the same thing in the
end. If that were the case, OpenOffice would have a legal problem
interoperating with MS Office file formats, Samba would have legal
issues interoperating with Windows networks, and so on.
mlw wrote: B. Pigman wrote:
mlw wrote: B. Pigman wrote: The ODBC driver is not being compiled into the executable and therefore does not appropriate your application. Additionally, nothing prevents anyone else from writing a 3rd party ODBC driver.
The point you are missing, and one which I think RMS is wrong, but he does insist, is that even dynamically linked code becomes part of your application. This includes the MySQL transport layer.
The would implicitly GPL all Linux applications and you know that is
not so.
Assuming your argument is right, let's put your mind at ease:
1. MySQL ODBC driver licensed as GPL
2. unixODBC interface layer licensed LGPL
Your application links to unixODBC and unixODBC links to MySQL,
therefore, by your argument above, unixODBC is in violation of the
GPL.
Either way, your application is protected. Not true. The transport layer is TCP/IP and cannot be appropriated into a license.
The transport layer, on the application side, uses MySQL code to talk to the MySQL sever.
"Transport" layer is TCP/IP and the "protocol" layer is MySQL
specific. Believe me when I say this was run among a few lawyers, some of
whom are technically knowledgeable given the cases in which they've been involved that are in this domain.
Then they have not the information with which to fully understand the question.
The information was extensively compiled by an engineer and one of the
lawyers in order to assess the risk of bundling MySQL with an
application, then verified by other lawyers as part of the full
evaluation. There is no risk other than MySQL pulling an SCO by trying
to use the courts to push a bogus suit.
[snip] You can't claim derivation just because they end up doing the same thing in
the end.
For it not to be derivative, you need a minimum of two developers. One to read the existing code, interpret it and write a specification which is an different form than the code. The second developer, with no prior knowledge of the original application, then writes the "new application."
Semantics. You're assuming that a developer who has looked at a piece
of code has been tainted. By your definition, once he has looked at a
piece of someone else's code, all his works will be derived. This is a
poor argument.
[snip] If that were the case, OpenOffice would have a legal problem interoperating with MS Office file formats, Samba would have legal issues interoperating with Windows networks, and so on.
No, because the developers of these applications have not seen, and have probably signed documents under penalty of perjury, that they have not seen the original source code.
What they have done is reverse engineer file formats and protocols and
that falls under the DMCA.
There is absolutely no risk involved in bundling or using your
proprietary applications with MySQL, period.
B. Pigman wrote: mlw <ml*@nospam.no> wrote in message news:<B_wNb.58868$Rc4.214464@attbi_s54>... B. Pigman wrote:
> There have been many questions as to the viability of MySQL's > assertion that it can dictate what constitutes a derived work in order > to use the GPL against developers who don't wish their software GPL'd > and force them to pay for a commercial license. Use PostgreSQL, its better and doesn't have these problems.
That's a choice, but not the point of this discussion.
> > According to the lawyers I've consulted, based on the letter of the > GPL, here is the conclusion: > > Commercial users of MySQL opting for the GPL'd version are not > compelled to release their applications under GPL and may use it > freely with their applications provided they do not incorporate any of > the interface code provided by MySQL. In other words, if you use the > ODBC interface, you are not GPLing your software by association. If > you use the MySQL C-library interface, compiled into your application, > then it's GPL'd.
The lawyers are missing the fact that the ODBC driver links to MySQL code, and that in turn means your application is linked to MySQL code.
The ODBC driver is not being compiled into the executable and therefore does not appropriate your application. Additionally, nothing prevents anyone else from writing a 3rd party ODBC driver.
The point you are missing, and one which I think RMS is wrong, but he does
insist, is that even dynamically linked code becomes part of your
application. This includes the MySQL transport layer.
> > The simple act of connecting to a database by TCP/IP is does not > constitute a derived work of the GPL'd server. Building your own > C-library interface based on the protocol information you can > extrapolate from their C-library source does not constitute a derived > work. Distributing a GPL'd application and source on the same CD as > your proprietary application, as per the conditions detailed in the > GPL, does not constitute a derived work. > > Basically, there is no reason why a commercial user cannot use the > GPL'd version of MySQL freely and without worry. Not true, you need a non-GPL or LGPL transport layer.
Not true. The transport layer is TCP/IP and cannot be appropriated into a license.
The transport layer, on the application side, uses MySQL code to talk to the
MySQL sever. Believe me when I say this was run among a few lawyers, some of whom are technically knowledgeable given the cases in which they've been involved that are in this domain.
Then they have not the information with which to fully understand the
question. I too have talked to lawyers, a few of them, as my business
depends on being GPL clean when I have to, and GPL compliant when it makes
sense.
[snip]
A few years back, I wrote a high speed session manager for PHP. The session server was GPL, but the interface library was LGPL, and the actual PHP extension was signed over to the PHP guys. If the interface layer had been released under GPL, someone could have rewritten it from scratch and released it under LGPL or BSD.
You may be able to do that with a Phoenix "clean room" approach, but you
can't re-type copyrighted works and have them clean.
You can't claim derivation just because they end up doing the same thing in the end.
For it not to be derivative, you need a minimum of two developers. One to
read the existing code, interpret it and write a specification which is an
different form than the code. The second developer, with no prior knowledge
of the original application, then writes the "new application."
This is how phoenix escaped the IBM copyright on the PC BIOS.
If that were the case, OpenOffice would have a legal problem interoperating with MS Office file formats, Samba would have legal issues interoperating with Windows networks, and so on.
No, because the developers of these applications have not seen, and have
probably signed documents under penalty of perjury, that they have not seen
the original source code.
B. Pigman wrote: mlw <ml*@nospam.no> wrote in message news:<B_wNb.58868$Rc4.214464@attbi_s54>... B. Pigman wrote:
> There have been many questions as to the viability of MySQL's > assertion that it can dictate what constitutes a derived work in order > to use the GPL against developers who don't wish their software GPL'd > and force them to pay for a commercial license. Use PostgreSQL, its better and doesn't have these problems.
That's a choice, but not the point of this discussion.
> > According to the lawyers I've consulted, based on the letter of the > GPL, here is the conclusion: > > Commercial users of MySQL opting for the GPL'd version are not > compelled to release their applications under GPL and may use it > freely with their applications provided they do not incorporate any of > the interface code provided by MySQL. In other words, if you use the > ODBC interface, you are not GPLing your software by association. If > you use the MySQL C-library interface, compiled into your application, > then it's GPL'd.
The lawyers are missing the fact that the ODBC driver links to MySQL code, and that in turn means your application is linked to MySQL code.
The ODBC driver is not being compiled into the executable and therefore does not appropriate your application. Additionally, nothing prevents anyone else from writing a 3rd party ODBC driver.
The point you are missing, and one which I think RMS is wrong, but he does
insist, is that even dynamically linked code becomes part of your
application. This includes the MySQL transport layer.
> > The simple act of connecting to a database by TCP/IP is does not > constitute a derived work of the GPL'd server. Building your own > C-library interface based on the protocol information you can > extrapolate from their C-library source does not constitute a derived > work. Distributing a GPL'd application and source on the same CD as > your proprietary application, as per the conditions detailed in the > GPL, does not constitute a derived work. > > Basically, there is no reason why a commercial user cannot use the > GPL'd version of MySQL freely and without worry. Not true, you need a non-GPL or LGPL transport layer.
Not true. The transport layer is TCP/IP and cannot be appropriated into a license.
The transport layer, on the application side, uses MySQL code to talk to the
MySQL sever. Believe me when I say this was run among a few lawyers, some of whom are technically knowledgeable given the cases in which they've been involved that are in this domain.
Then they have not the information with which to fully understand the
question. I too have talked to lawyers, a few of them, as my business
depends on being GPL clean when I have to, and GPL compliant when it makes
sense.
[snip]
A few years back, I wrote a high speed session manager for PHP. The session server was GPL, but the interface library was LGPL, and the actual PHP extension was signed over to the PHP guys. If the interface layer had been released under GPL, someone could have rewritten it from scratch and released it under LGPL or BSD.
You may be able to do that with a Phoenix "clean room" approach, but you
can't re-type copyrighted works and have them clean.
You can't claim derivation just because they end up doing the same thing in the end.
For it not to be derivative, you need a minimum of two developers. One to
read the existing code, interpret it and write a specification which is an
different form than the code. The second developer, with no prior knowledge
of the original application, then writes the "new application."
This is how phoenix escaped the IBM copyright on the PC BIOS.
If that were the case, OpenOffice would have a legal problem interoperating with MS Office file formats, Samba would have legal issues interoperating with Windows networks, and so on.
No, because the developers of these applications have not seen, and have
probably signed documents under penalty of perjury, that they have not seen
the original source code.
mlw wrote: B. Pigman wrote:
mlw wrote: B. Pigman wrote: The ODBC driver is not being compiled into the executable and therefore does not appropriate your application. Additionally, nothing prevents anyone else from writing a 3rd party ODBC driver.
The point you are missing, and one which I think RMS is wrong, but he does insist, is that even dynamically linked code becomes part of your application. This includes the MySQL transport layer.
The would implicitly GPL all Linux applications and you know that is
not so.
Assuming your argument is right, let's put your mind at ease:
1. MySQL ODBC driver licensed as GPL
2. unixODBC interface layer licensed LGPL
Your application links to unixODBC and unixODBC links to MySQL,
therefore, by your argument above, unixODBC is in violation of the
GPL.
Either way, your application is protected. Not true. The transport layer is TCP/IP and cannot be appropriated into a license.
The transport layer, on the application side, uses MySQL code to talk to the MySQL sever.
"Transport" layer is TCP/IP and the "protocol" layer is MySQL
specific. Believe me when I say this was run among a few lawyers, some of
whom are technically knowledgeable given the cases in which they've been involved that are in this domain.
Then they have not the information with which to fully understand the question.
The information was extensively compiled by an engineer and one of the
lawyers in order to assess the risk of bundling MySQL with an
application, then verified by other lawyers as part of the full
evaluation. There is no risk other than MySQL pulling an SCO by trying
to use the courts to push a bogus suit.
[snip] You can't claim derivation just because they end up doing the same thing in
the end.
For it not to be derivative, you need a minimum of two developers. One to read the existing code, interpret it and write a specification which is an different form than the code. The second developer, with no prior knowledge of the original application, then writes the "new application."
Semantics. You're assuming that a developer who has looked at a piece
of code has been tainted. By your definition, once he has looked at a
piece of someone else's code, all his works will be derived. This is a
poor argument.
[snip] If that were the case, OpenOffice would have a legal problem interoperating with MS Office file formats, Samba would have legal issues interoperating with Windows networks, and so on.
No, because the developers of these applications have not seen, and have probably signed documents under penalty of perjury, that they have not seen the original source code.
What they have done is reverse engineer file formats and protocols and
that falls under the DMCA.
There is absolutely no risk involved in bundling or using your
proprietary applications with MySQL, period.
mlw wrote: B. Pigman wrote:
mlw wrote: B. Pigman wrote: The ODBC driver is not being compiled into the executable and therefore does not appropriate your application. Additionally, nothing prevents anyone else from writing a 3rd party ODBC driver.
The point you are missing, and one which I think RMS is wrong, but he does insist, is that even dynamically linked code becomes part of your application. This includes the MySQL transport layer.
The would implicitly GPL all Linux applications and you know that is
not so.
Assuming your argument is right, let's put your mind at ease:
1. MySQL ODBC driver licensed as GPL
2. unixODBC interface layer licensed LGPL
Your application links to unixODBC and unixODBC links to MySQL,
therefore, by your argument above, unixODBC is in violation of the
GPL.
Either way, your application is protected. Not true. The transport layer is TCP/IP and cannot be appropriated into a license.
The transport layer, on the application side, uses MySQL code to talk to the MySQL sever.
"Transport" layer is TCP/IP and the "protocol" layer is MySQL
specific. Believe me when I say this was run among a few lawyers, some of
whom are technically knowledgeable given the cases in which they've been involved that are in this domain.
Then they have not the information with which to fully understand the question.
The information was extensively compiled by an engineer and one of the
lawyers in order to assess the risk of bundling MySQL with an
application, then verified by other lawyers as part of the full
evaluation. There is no risk other than MySQL pulling an SCO by trying
to use the courts to push a bogus suit.
[snip] You can't claim derivation just because they end up doing the same thing in
the end.
For it not to be derivative, you need a minimum of two developers. One to read the existing code, interpret it and write a specification which is an different form than the code. The second developer, with no prior knowledge of the original application, then writes the "new application."
Semantics. You're assuming that a developer who has looked at a piece
of code has been tainted. By your definition, once he has looked at a
piece of someone else's code, all his works will be derived. This is a
poor argument.
[snip] If that were the case, OpenOffice would have a legal problem interoperating with MS Office file formats, Samba would have legal issues interoperating with Windows networks, and so on.
No, because the developers of these applications have not seen, and have probably signed documents under penalty of perjury, that they have not seen the original source code.
What they have done is reverse engineer file formats and protocols and
that falls under the DMCA.
There is absolutely no risk involved in bundling or using your
proprietary applications with MySQL, period.
On Thu, 15 Jan 2004 13:56:49 GMT, mlw <ml*@nospam.no> wrote: There have been many questions as to the viability of MySQL's assertion that it can dictate what constitutes a derived work in order to use the GPL against developers who don't wish their software GPL'd and force them to pay for a commercial license.
Use PostgreSQL, its better and doesn't have these problems.
This is what I've worried about for a while. MySQL AB is going to
damage MySql with their GPL games. I know of several clients who
have simply avoided MySQL altogether, rather than dealing with stupid
legal issues. I understand MySQL AB wants more people/companies to
buy the commercial license, but to try to achieve that by making the
GPL licensing more confusing is a very stupid thing.
I myself have shelved development of several MySQL add-on products
because of these licensing issues.
Chuck Gadd http://www.csd.net/~cgadd/aqua
On Thu, 15 Jan 2004 13:56:49 GMT, mlw <ml*@nospam.no> wrote: There have been many questions as to the viability of MySQL's assertion that it can dictate what constitutes a derived work in order to use the GPL against developers who don't wish their software GPL'd and force them to pay for a commercial license.
Use PostgreSQL, its better and doesn't have these problems.
This is what I've worried about for a while. MySQL AB is going to
damage MySql with their GPL games. I know of several clients who
have simply avoided MySQL altogether, rather than dealing with stupid
legal issues. I understand MySQL AB wants more people/companies to
buy the commercial license, but to try to achieve that by making the
GPL licensing more confusing is a very stupid thing.
I myself have shelved development of several MySQL add-on products
because of these licensing issues.
Chuck Gadd http://www.csd.net/~cgadd/aqua
On Thu, 15 Jan 2004 13:56:49 GMT, mlw <ml*@nospam.no> wrote: There have been many questions as to the viability of MySQL's assertion that it can dictate what constitutes a derived work in order to use the GPL against developers who don't wish their software GPL'd and force them to pay for a commercial license.
Use PostgreSQL, its better and doesn't have these problems.
This is what I've worried about for a while. MySQL AB is going to
damage MySql with their GPL games. I know of several clients who
have simply avoided MySQL altogether, rather than dealing with stupid
legal issues. I understand MySQL AB wants more people/companies to
buy the commercial license, but to try to achieve that by making the
GPL licensing more confusing is a very stupid thing.
I myself have shelved development of several MySQL add-on products
because of these licensing issues.
Chuck Gadd http://www.csd.net/~cgadd/aqua This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: madcap |
last post by:
Hi,
Our company was looking for contract programmer to develop an
internet/intranet application. We were approached by a freelancer who
have quite a lot experience and his resume was...
|
by: B. Pigman |
last post by:
There have been many questions as to the viability of MySQL's
assertion that it can dictate what constitutes a derived work in order
to use the GPL against developers who don't wish their software...
|
by: m.cantaloupe |
last post by:
I'm starting to get frustrated with the mysql licensing model.
I was pushed into moving some of my companie's databases to it under
the impression that it was 'free' as in free beer and free...
|
by: John Wells |
last post by:
Yes, I know you've seen the above subject before, so please be gentle with
the flamethrowers.
I'm preparing to enter a discussion with management at my company
regarding going forward as either...
|
by: Sai Hertz And Control Systems |
last post by:
Dear all,
Their was a huge rore about MySQL recently for something in java functions
now theirs one more
http://www.mysql.com/doc/en/News-5.0.x.html
Does this concern anyone.
What I...
|
by: Mairhtin O'Feannag |
last post by:
Hello,
I have a client (customer) who asked the question : "Why would I buy and
use UDB, when MySql is free?"
I had to say I was stunned. I have no experience with MySql, so I was
left sort...
|
by: Vincent V |
last post by:
Hey guys im about to start a large project and am wondering what
DB server to use
I have the Choise of MySql(innodb) or if i pay a bit extra i can get MS SQL
2000
The concerns i have
-What type...
|
by: Frank Rizzo |
last post by:
I've been given a project to work with which involves connecting to
MySQL from .NET 2.0 app. I've googled looked and there is a metric ton
of different MySQL ADO.NET providers from different...
|
by: Coldfire |
last post by:
Since i cannot show the differences in a two-column like table. I am first putting
MS SQL Server 2005 and then MySQL 5.x.
MS SQL Server 2005
Brief Overview
- SQL Server is a full-fledged...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
| |