|
Home > Archive > MySQL PlusPlus > November 2005 > License Question
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Hardy, Allan 2005-11-08, 8:24 pm |
| -- Boundary_(ID_fi8kQxN
1c2nz7wt9G7Y0/w)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
I have some confusion about the licensing, hopefully someone can set me
straight.
Where the description page says "Since MySQL++ is licensed under the
LGPL, you cannot link it statically to closed-source programs"
My understanding is just the opposite.
That one can link to LGPL programs without the copyleft, GPL licensing,
issues.
So closed source programs can use LGPL, that's like the whole reason for
GPL.
Perhaps I've taken something out of context?
Allan Hardy
-- Boundary_(ID_fi8kQxN
1c2nz7wt9G7Y0/w)--
| |
| Chris Frey 2005-11-08, 8:24 pm |
| On Tue, Nov 08, 2005 at 07:11:23PM -0500, Hardy, Allan wrote:
> Where the description page says "Since MySQL++ is licensed under the
> LGPL, you cannot link it statically to closed-source programs"
>
> My understanding is just the opposite.
> That one can link to LGPL programs without the copyleft, GPL licensing,
> issues.
> So closed source programs can use LGPL, that's like the whole reason for
> GPL.
I'm not a lawyer, so this is not legal advice.
You might be interested in a post I made a while back:
http://lists.mysql.com/plusplus/4675
Remember though, that while mysql++ is licensed under LGPL, it is based
on the mysql C API, and recent versions of that are licensed under
the GPL. So you're still stuck, when it comes to closed source programs.
I'm not a legal expert when it comes to layering LGPL on top of GPL,
but it seems a fuzzy area to me, and would side on the GPL for safety.
If you are writing closed source applications, use Postgresql and its C++
library: libpqxx. Both are licensed under a BSD-style license.
- Chris
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?uns...sie.nctu.edu.tw
| |
| Chris Frey 2005-11-09, 3:24 am |
| On Tue, Nov 08, 2005 at 09:21:05PM -0500, Hardy, Allan wrote:
> So why isn't MySQL++ licensed as GPL?
mysql++ wasn't originally written by the MySQL company, and started out as a
cross-database C++ library that happened to implement MySQL first. Early
versions were called "sqlplus". See the user manual for more info on the
history.
Indeed, earlier versions of the MySQL C API were LGPL too. I believe
MySQL changed this around version 4.0.20. You can still get mysql 3.23.x
if license matters in your application.
mysql++ can still be used as a cross-database C++ wrapper, and I'd like to
do that someday, or help with the effort, so there's no reason to change
from LGPL.
It's interesting to note how companies like MySQL and Trolltech (Qt) use
the GPL in a defensive manner, while companies like RedHat (Cygwin/Gnome)
use LGPL.
- Chris
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?uns...sie.nctu.edu.tw
| |
| Hardy, Allan 2005-11-09, 3:24 am |
| Chris,
Thanks. IANAL (I am not a lawyer) either, but do hang around them a
bit to much :)
I assume the MySQL++ author had a reason to pick LGPL over GPL
(despite Stallmans request he use GPL
http://www.fsf.org/licensing/licenses/why-not-lgpl.html)
The reason for LGPL existence is to allow free software to survive in an
unfree market place. At the times when using GPL would lead to the
non-adoption of the work because there are competing alternatives.
It does that by lessening the copyleft, derived work, requirement.
So, again I am still not sure why the MySQL++ author indicates that LGPL
cannot work well with non-open software?
As to the LGPL on top of GPL thing. Normally I would assume that this is
not possible to do. If MySQL was licensed under a normal GPL license
then it would seem that any 'wrapper' would need to be GPL licensed as
well. However MySQL has an exception, called the FOSS Exception, that
allows programs using a set list of FOSS licenses to avoid the GPL
copyleft requirement. I assume that is how MySQL++ gets away with being
LGPL?
Though of course now we have the slippery slope, if MySQL++ as LGPL
allows integration by proprietary products, then we have caused a hole
in the MySQL GPL protection.
So why isn't MySQL++ licensed as GPL?
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?uns...sie.nctu.edu.tw
| |
| Warren Young 2005-11-09, 7:23 am |
| Hardy, Allan wrote:
>
> Where the description page says "Since MySQL++ is licensed under the
> LGPL, you cannot link it statically to closed-source programs"
>
> My understanding is just the opposite.
> That one can link to LGPL programs without the copyleft, GPL licensing,
> issues.
You're not understanding static linking, then. Static linking makes the
MySQL++ binary code part of your executable. Dynamic linking, by
contrast, keeps the MySQL++ binary code elsewhere, and your code only
links to it when the program runs.
The LGPL provisions basically allow your users to replace parts of
MySQL++ if they want, without affecting your program. They cannot do
this if you give them an executable with MySQL++ statically linked.
There is a workaround: you can also give your users object files for
your program, so they can relink it to MySQL++ themselves. This would
allow you to statically link to MySQL++, but most people find providing
*.o files too odious.
If you want to argue further about this, I'm not interested. See the
FAQs and documentation on gnu.org, and/or consult a lawyer.
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?uns...sie.nctu.edu.tw
| |
| Warren Young 2005-11-09, 7:23 am |
| Chris Frey wrote:
>
> Remember though, that while mysql++ is licensed under LGPL, it is based
> on the mysql C API, and recent versions of that are licensed under
> the GPL. So you're still stuck, when it comes to closed source programs.
Yes, but you can purchase a license from MySQL AB which puts it under a
different license. You just need to call them up and work out a
reasonable solution.
If you're selling a product based on MySQL++, it shouldn't be a hardship
to get MySQL database licenses for your product.
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?uns...sie.nctu.edu.tw
| |
| Hardy, Allan 2005-11-09, 1:23 pm |
| Warren,
Was I arguing?
Putting all the technical details aside, why did you choose LGPL over
GPL?
LGPL clearly exist to make working with proprietary software easier.
You clearly don't want, or care, about that, which is fine.
(That's not a judgment or accusation, just an observation)
I am just curious then what other attributes/advantages are in LGPL that
took you down that path?
The differences of Static over Dynamic linking to LGPL libraries is
interesting.
It seems that Static linking to LGPL libraries offers no advantages over
GPL?
I mean it doesn't meet the objective of working with proprietary
software any better.
Thanks for your thoughts.
Allan
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?uns...sie.nctu.edu.tw
| |
| Hardy, Allan 2005-11-09, 1:23 pm |
|
hardship to get MySQL database licenses for your product.
How is that possible?
If I purchase a commercial MySQL license I can produce commercial
applications all day that call MySQL AB interfaces, things covered by
their commercial license.
Except I still cant use MySQL++ because it LGPL and all the other
discussion says that my application will bound to LGPL terms (releasing
object or releasing source).
Is MySQL++ covered by the MySQL AB commercial license?
Allan
-----Original Message-----
From: Warren Young & #91;mailto:mysqlpp@e
tr-usa.com]
Sent: Wednesday, November 09, 2005 8:09 AM
To: MySQL++ Mailing List
Subject: Re: License Question
Chris Frey wrote:[color=darkred
]
>
> Remember though, that while mysql++ is licensed under LGPL, it is
> based on the mysql C API, and recent versions of that are licensed
> under the GPL. So you're still stuck, when it comes to closed source
programs.
Yes, but you can purchase a license from MySQL AB which puts it under a
different license. You just need to call them up and work out a
reasonable solution.
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe:
http://lists.mysql.com/plusplus?uns....hardy@lmco.com
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?uns...sie.nctu.edu.tw
| |
| Warren Young 2005-11-09, 1:23 pm |
| Hardy, Allan wrote:
>
> Putting all the technical details aside, why did you choose LGPL over
> GPL?
I am not the original author, and neither is MySQL AB. The original
author chose it, but he is no longer involved with MySQL++. The
original author will not relicense his code, so we are stuck with this
license.
> It seems that Static linking to LGPL libraries offers no advantages over
> GPL?
No. With GPL you have to provide human-readable source code to your
users. If you statically link an LGPL library to your program, you only
have to provide sufficient files to be able to relink the executable;
unless your program is truly weird, that means object files.
Both of these are spelled out in the licenses themselves. Have you read
them lately?
> I mean it doesn't meet the objective of working with proprietary
> software any better.
Why is static linking tied to proprietary applications in your mind?
What's wrong with dynamic linking?
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?uns...sie.nctu.edu.tw
| |
| Hardy, Allan 2005-11-09, 1:23 pm |
|
Warren
I truly appreciate the response.
I am not trying to use you as a replacement for reading the GPL/LGPL
FAQs, etc etc. I've done all that many times. I even attended a
seminar given by FSF lawyers and technical staff. The LGPL license is
frankly a bit of a mess, in their words, and it will go through more
modifications then GPL in the upcoming GPL 3 next wave effort.
My only point is I don't agree that things are 'spelled out' as in
clear, black and white etc.
So your comments are appreciated.
users. If you statically link an LGPL library to your program, you only
have to provide sufficient files to be able to relink the executable;
unless your program is truly weird, that means object files.
What I meant by no significant advantages is that as you said, providing
the object code and pieces needed to do this is onerous, and while it is
technically/legally a choice its very impractical, right? I mean I
believe that's what I hear you and chris saying?
[color=darkred]
I am not sure what I said that went down this path. Heres what I meant:
Proprietary App -> Static Link to LGPL -> has to release object
code/allow for relinking - difficult
Proprietary App -> Dynamic Link to LGPL -> has no obligations since
relinking is not an issue - easy
Allan
-----Original Message-----
From: Warren Young & #91;mailto:mysqlpp@e
tr-usa.com]
Sent: Wednesday, November 09, 2005 1:13 PM
To: MySQL++ Mailing List
Subject: Re: License Question
Hardy, Allan wrote:[color=darkred
]
>
> Putting all the technical details aside, why did you choose LGPL over
> GPL?
I am not the original author, and neither is MySQL AB. The original
author chose it, but he is no longer involved with MySQL++. The
original author will not relicense his code, so we are stuck with this
license.
> It seems that Static linking to LGPL libraries offers no advantages
> over GPL?
No. With GPL you have to provide human-readable source code to your
users. If you statically link an LGPL library to your program, you only
have to provide sufficient files to be able to relink the executable;
unless your program is truly weird, that means object files.
Both of these are spelled out in the licenses themselves. Have you read
them lately?
> I mean it doesn't meet the objective of working with proprietary
> software any better.
Why is static linking tied to proprietary applications in your mind?
What's wrong with dynamic linking?
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe:
http://lists.mysql.com/plusplus?uns....hardy@lmco.com
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?uns...sie.nctu.edu.tw
| |
| Warren Young 2005-11-09, 1:23 pm |
| Hardy, Allan wrote:
>
> Proprietary App -> Static Link to LGPL -> has to release object
> code/allow for relinking - difficult
> Proprietary App -> Dynamic Link to LGPL -> has no obligations since
> relinking is not an issue - easy
Precisely. That leads me to:
proprietary app linking to LGPL library: dynamic only
It is not the only possible way, but it is the only sane way.
What difficulties remain, once you make that decision?
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?uns...sie.nctu.edu.tw
| |
| Chris Frey 2005-11-09, 1:23 pm |
| On Wed, Nov 09, 2005 at 01:29:42PM -0500, Hardy, Allan wrote:
> What I meant by no significant advantages is that as you said, providing
> the object code and pieces needed to do this is onerous, and while it is
> technically/legally a choice its very impractical, right? I mean I
> believe that's what I hear you and chris saying?
I'm not saying there's no significant advantage. If you're writing
closed source apps, the LGPL is a significant advantage, since it lets
you do it at all.
I'm not sure what your goal or real question is anymore. :-) Originally,
mysql++ and mysql could be used, via LGPL, in closed source apps. That
has since changed for mysql, but not for mysql++.
If closed source is your goal, then as Warren mentioned, buy a commercial
license from MySQL AB that lets you link with mysql++, and everybody's
happy. mysql++'s LGPL won't stop you in this case, as I understand it.
- Chris
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?uns...sie.nctu.edu.tw
| |
| Chris Frey 2005-11-09, 1:23 pm |
| On Wed, Nov 09, 2005 at 11:48:05AM -0700, Warren Young wrote:
> Precisely. That leads me to:
>
> proprietary app linking to LGPL library: dynamic only
>
> It is not the only possible way, but it is the only sane way.
>
> What difficulties remain, once you make that decision?
Only the mysql commercial license. We now have:
Proprietary app ->
dynamically linked to LGPL mysql++ ->
dynamically linked to commercially licensed mysql
Or:
Proprietary app ->
dynamically linked to LGPL mysql++ ->
dynamically linked to BSD Postgresql
Of course, option 2 is still vapourware. :-)
- Chris
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?uns...sie.nctu.edu.tw
| |
| Hardy, Allan 2005-11-09, 8:24 pm |
|
Now wait, if MySQL++ can be dynamically linked to then this is also a
viable option:
Proprietary app ->
dynamically linked to LGPL mysql++ ->
dynamically linked to GPL licensed mysql
Since the LGPL woul isolate the Proprietary App from the GPL copyleft
Allan
-----Original Message-----
From: Chris Frey & #91;mailto:cdfrey@fo
ursquare.net]
Sent: Wednesday, November 09, 2005 2:01 PM
To: plusplus@lists.mysql.com
Subject: Re: License Question
On Wed, Nov 09, 2005 at 11:48:05AM -0700, Warren Young wrote:
> Precisely. That leads me to:
>
> proprietary app linking to LGPL library: dynamic only
>
> It is not the only possible way, but it is the only sane way.
>
> What difficulties remain, once you make that decision?
Only the mysql commercial license. We now have:
Proprietary app ->
dynamically linked to LGPL mysql++ ->
dynamically linked to commercially licensed mysql
Or:
Proprietary app ->
dynamically linked to LGPL mysql++ ->
dynamically linked to BSD Postgresql
Of course, option 2 is still vapourware. :-)
- Chris
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe:
http://lists.mysql.com/plusplus?uns....hardy@lmco.com
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?uns...sie.nctu.edu.tw
| |
| Hardy, Allan 2005-11-09, 8:24 pm |
|
So what started me on all this was the statement that MySQL++ via LGPL
was no good for use by proprietary apps.
Which I thought ran counter to what LGPL was about.
I assume then it only allows for static linking? (because of the type of
technology it is)
Allan
-----Original Message-----
From: Warren Young & #91;mailto:mysqlpp@e
tr-usa.com]
Sent: Wednesday, November 09, 2005 1:48 PM
To: MySQL++ Mailing List
Subject: Re: License Question
Hardy, Allan wrote:
>
> Proprietary App -> Static Link to LGPL -> has to release object
> code/allow for relinking - difficult Proprietary App -> Dynamic Link
> to LGPL -> has no obligations since relinking is not an issue - easy
Precisely. That leads me to:
proprietary app linking to LGPL library: dynamic only
It is not the only possible way, but it is the only sane way.
What difficulties remain, once you make that decision?
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe:
http://lists.mysql.com/plusplus?uns....hardy@lmco.com
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?uns...sie.nctu.edu.tw
| |
| Hardy, Allan 2005-11-09, 8:24 pm |
| Chris
As I noted to Warren, what started all this was the statement in the
MySQL web site that because it used LGPL that it was not useful for
closed source applications.
Which runs counter to what LGPL was about. It seems that the only way
this is the case is if MySQL++ is used in static link fashion.
Allan
-----Original Message-----
From: Chris Frey & #91;mailto:cdfrey@fo
ursquare.net]
Sent: Wednesday, November 09, 2005 1:51 PM
To: plusplus@lists.mysql.com
Subject: Re: License Question
On Wed, Nov 09, 2005 at 01:29:42PM -0500, Hardy, Allan wrote:
> What I meant by no significant advantages is that as you said,
> providing the object code and pieces needed to do this is onerous, and
> while it is technically/legally a choice its very impractical, right?
> I mean I believe that's what I hear you and chris saying?
I'm not saying there's no significant advantage. If you're writing
closed source apps, the LGPL is a significant advantage, since it lets
you do it at all.
I'm not sure what your goal or real question is anymore. :-)
Originally,
mysql++ and mysql could be used, via LGPL, in closed source apps. That
has since changed for mysql, but not for mysql++.
If closed source is your goal, then as Warren mentioned, buy a
commercial license from MySQL AB that lets you link with mysql++, and
everybody's happy. mysql++'s LGPL won't stop you in this case, as I
understand it.
- Chris
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe:
http://lists.mysql.com/plusplus?uns....hardy@lmco.com
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?uns...sie.nctu.edu.tw
| |
| Warren Young 2005-11-09, 8:24 pm |
| Hardy, Allan wrote:
>
> Proprietary app ->
> dynamically linked to LGPL mysql++ ->
> dynamically linked to GPL licensed mysql
>
> Since the LGPL woul isolate the Proprietary App from the GPL copyleft
Ah, no. The most restrictive license always obtains.
If your statement were the case, then on Linux, the LGPL nature of glibc
would free a lot of apps from needing to be GPL.
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?uns...sie.nctu.edu.tw
| |
| Warren Young 2005-11-09, 8:24 pm |
| Hardy, Allan wrote:
>
> So what started me on all this was the statement that MySQL++ via LGPL
> was no good for use by proprietary apps.
I guess you're referring to the MySQL++ FAQ, where it states this for
Cygwin and MinGW compilers, neither of which can currently build a
dynamic version of MySQL++. This has nothing to do with other platforms.
If you want to talk about Cygwin or MinGW, take that up in a new thread.
Or use Visual C++, which does not have this problem.
> I assume then it only allows for static linking?
I link a proprietary application to MySQL++ every day, dynamically. So
no, you cannot have my object files. :)
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?uns...sie.nctu.edu.tw
| |
| Chris Frey 2005-11-09, 8:24 pm |
| On Wed, Nov 09, 2005 at 12:52:39PM -0700, Warren Young wrote:
> Hardy, Allan wrote:
>
> Ah, no. The most restrictive license always obtains.
>
> If your statement were the case, then on Linux, the LGPL nature of glibc
> would free a lot of apps from needing to be GPL.
This is turning into the debian-legal mailing list without the experts. :-)
I believe this is a bad example. People can write proprietary apps
on linux using the LGPL'd glibc, since you're not linking with the kernel
when you write an app. They just have to be careful not to use any
GPL'd library in the process.
If proprietary binary modules are allowed *inside* the kernel (e.g. NVidia),
then proprietary apps are definitely possible.
- Chris
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?uns...sie.nctu.edu.tw
| |
| Hardy, Allan 2005-11-09, 8:24 pm |
|
Ok, now I will argue :) 0r respectively disagree, but I guess there is
limited reason to continue I will just state where I am at.
I do not see the path that allows GPL to reach through the LGPL code and
affect the proprietary application?
We have gLib Applications that are not licensed as GPL (they use various
open/semiopen licenses).
It seems to me as if this all creates an unhealthy scenario that would
allow me to get around having to use commercial MySQL.
Not sure if they will respond but sent an email to licensing at the FSF
asking about the Prop->LGPL->GPL scenario
Actually I am not clear on how a derived work of an GPL product can be
licensed under LGPL?
I asked them about that as well.
(I didn't ask them directly but since MySQL++ was originally calling
LGPL MySQL, now that MySQL has changed to GPL, doesn't MySQL++ need to)
I'll leave you all alone as this is taken you into debian land :)
but I do appreciate the thought provoking and educational input.
If I get any response from FSF I will update you all if interested
Allan
-----Original Message-----
From: Warren Young & #91;mailto:mysqlpp@e
tr-usa.com]
Sent: Wednesday, November 09, 2005 2:53 PM
To: MySQL++ Mailing List
Subject: Re: License Question
Hardy, Allan wrote:[color=darkred
]
>
> Proprietary app ->
> dynamically linked to LGPL mysql++ ->
> dynamically linked to GPL licensed mysql
>
> Since the LGPL woul isolate the Proprietary App from the GPL copyleft
Ah, no. The most restrictive license always obtains.
If your statement were the case, then on Linux, the LGPL nature of glibc
would free a lot of apps from needing to be GPL.
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe:
http://lists.mysql.com/plusplus?uns....hardy@lmco.com
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?uns...sie.nctu.edu.tw
| |
|
|
| Chris Frey 2005-11-09, 8:24 pm |
| On Wed, Nov 09, 2005 at 04:01:19PM -0500, Hardy, Allan wrote:
> Actually I am not clear on how a derived work of an GPL product can be
> licensed under LGPL?
> I asked them about that as well.
> (I didn't ask them directly but since MySQL++ was originally calling
> LGPL MySQL, now that MySQL has changed to GPL, doesn't MySQL++ need to)
No. mysql++ is a separate library, authored separatedly, and has no need
to change its license because someone else does. We don't distribute
mysql code.
The LGPL allows you to change the license to GPL (section 3). I believe
this is what allows LGPL to link against GPL.
If I'm correct (consult a lawyer) the Prop -> LGPL -> GPL equation becomes:
Prop -> GPL -> GPL
.... which doesn't work.
> If I get any response from FSF I will update you all if interested
I'd be interested. Feel free to email me privately if you don't want to
add it to the list... although by now, it's probably a good idea to finish
this thread with an official word if we get it. :-)
- Chris
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?uns...sie.nctu.edu.tw
| |
| Hardy, Allan 2005-11-09, 8:24 pm |
|
The following applies if you DISTRIBUTE and only IF,
In house or internal use has no obligations legally what so ever. You
are not obligated to provide the changes back to the MySQL++ team, not
legally though morally you have consider your self.
Also, note you can static link all day, as long as its internal use.
There is none of the other happy crap about derived works to be
concerned with.
But for distribution:
LGPL and GPL require you to either provide source or make an offer for
source. You are much better off providing source at the same time as
you provide executables.
An offer, such as email me, go to my web site, etc, must be available
for 3 years and must be available to the public. Hence you get into the
distribution business. If you ship source at the same time as the
executables, then your done, no further obligations to provide the
source to anyone else.
The above applies to the source for MySQL++ and any changes you have
made.
Lastly, you cannot point people to the MySQL++ site as a way to meet
your obligation to provide source for MySQL++
This is because of the 3 year requirement. Unless you have cut a deal
with someone else, such as the MySQL team, that they promise to make the
source (for that version) available for 3 years, then you have to meet
that obligation yourself. You can't simply point to someone else.
Hope that helps.
Allan
-----Original Message-----
From: Mark Merendino [mailto:Mark.Merendino@mcdata.com]
Sent: Wednesday, November 09, 2005 4:15 PM
To: Hardy, Allan; MySQL++ Mailing List
Subject: RE: License Question
All this talk of Licenses has lead me to a question of my own. Feel
free not to respond if you all are fed up with the license talk
If I am working on an a propriotery application and Im using a version
of MySQL++ that I have made modifications to, what are my
responsibilities?
Im gathering from earlier discussion that I can not link staticly. So I
guess I need to link dynamically. But do I also need to distribute the
mysql++ source along with the modifications I have made?
-----Original Message-----
From: Hardy, Allan [mailto:allan.hardy@lmco.com]
Sent: Wednesday, November 09, 2005 4:01 PM
To: MySQL++ Mailing List
Subject: RE: License Question
Ok, now I will argue :) 0r respectively disagree, but I guess there is
limited reason to continue I will just state where I am at.
I do not see the path that allows GPL to reach through the LGPL code and
affect the proprietary application?
We have gLib Applications that are not licensed as GPL (they use various
open/semiopen licenses).
It seems to me as if this all creates an unhealthy scenario that would
allow me to get around having to use commercial MySQL.
Not sure if they will respond but sent an email to licensing at the FSF
asking about the Prop->LGPL->GPL scenario
Actually I am not clear on how a derived work of an GPL product can be
licensed under LGPL?
I asked them about that as well.
(I didn't ask them directly but since MySQL++ was originally calling
LGPL MySQL, now that MySQL has changed to GPL, doesn't MySQL++ need to)
I'll leave you all alone as this is taken you into debian land :) but I
do appreciate the thought provoking and educational input.
If I get any response from FSF I will update you all if interested
Allan
-----Original Message-----
From: Warren Young & #91;mailto:mysqlpp@e
tr-usa.com]
Sent: Wednesday, November 09, 2005 2:53 PM
To: MySQL++ Mailing List
Subject: Re: License Question
Hardy, Allan wrote:[color=darkred
]
>
> Proprietary app ->
> dynamically linked to LGPL mysql++ ->
> dynamically linked to GPL licensed mysql
>
> Since the LGPL woul isolate the Proprietary App from the GPL copyleft
Ah, no. The most restrictive license always obtains.
If your statement were the case, then on Linux, the LGPL nature of glibc
would free a lot of apps from needing to be GPL.
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus To unsubscribe:
http://lists.mysql.com/plusplus?uns....hardy@lmco.com
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus To unsubscribe:
http://lists.mysql.com/plusplus? un...
@cnt.com
SPECIAL NOTICE
All information transmitted hereby is intended only for the use of the
addressee(s) named above and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or distribution of
confidential and privileged information is prohibited. If the reader of
this message is not the intended recipient(s) or the employee or agent
responsible for delivering the message to the intended recipient, you
are hereby notified that you must not read this transmission and that
disclosure, copying, printing, distribution or use of any of the
information contained in or attached to this transmission is STRICTLY
PROHIBITED.
Anyone who receives confidential and privileged information in error
should notify us immediately by telephone and mail the original message
to us at the above address and destroy all copies. To the extent any
portion of this communication contains public information, no such
restrictions apply to that information. (gate02)
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?uns...sie.nctu.edu.tw
| |
| Hardy, Allan 2005-11-09, 8:24 pm |
| Warren,
I was trying to, although I hopefully added some value in answering the
source code distribution questions
MySQL++ is a derived work of MySQL. This is where you are perhaps the
one not up to speed with the FSF's definition of derived work. My C++
programs may also be derived from gLibc (in FSF definition of derived)
but the LGPL license accommodates this.
In defining derived works FSF looks not only at the technical aspects of
the integration, but also at the semantics of the integration, how much
intimacy there is between the two applications. MySQL++ cannot
standalone, it has no use or perhaps even functions without MySQL,
everything they have said to date would indicate MySQL++ is a derived
work of MySQL.
From the LGPL preamble:
"When a program is linked with a library, whether statically or using a
shared library, the combination of the two is legally speaking a
combined work, a derivative of the original library."
But I forgot that MySQL AB has covered you with the FOSS exception,
silly me, This allows you to keep your LGPL license even if you are a
derived work of a GPL work. Sorry for that confusion.
Though that doesn't address how it seems to allow a proprietary app to
call the lgpl and avoid the underlying gpl requirements.
Anyway, I'm happy to go away and see that I can learn from the FSF as to
this whole thing.
Again I appreciate your time.
Allan
-----Original Message-----
From: Warren Young & #91;mailto:mysqlpp@e
tr-usa.com]
Sent: Wednesday, November 09, 2005 4:14 PM
To: MySQL++ Mailing List
Subject: Re: License Question
Hardy, Allan wrote:[color=darkred
]
>
> Ok, now I will argue :)
> Actually I am not clear on how a derived work of an GPL product can be
> licensed under LGPL?
MySQL++ isn't a derivative work of MySQL, any more than your C++ program
is a derivative work of glibc. There is no MySQL code in MySQL++.
Please, can we give this a rest?
--
MySQL++ Mailing List
For list archives: [url]http://lists.mysql.com/plusplus" target="_blank">http://www.gnu.org/licenses/gpl-faq...ql.com/plusplus
To unsubscribe:
http://lists.mysql.com/plusplus?uns....hardy@lmco.com
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?uns...sie.nctu.edu.tw
| |
| mysqlpp@etr-usa.com 2005-11-10, 8:24 pm |
| ------ =_NextPart_200_becb_
92ec41a9.860bd46f_.MIX
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hardy, Allan wrote:
> =20
> Proprietary App -> Static Link to LGPL -> has to release object
> code/allow for relinking - difficult
> Proprietary App -> Dynamic Link to LGPL -> has no obligations since
> relinking is not an issue - easy
Precisely. That leads me to:
proprietary app linking to LGPL library: dynamic only
It is not the only possible way, but it is the only sane way.
What difficulties remain, once you make that decision?
--=20
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus? un...ald@sa
t=
urncorp.com
------ =_NextPart_200_becb_
92ec41a9.860bd46f_.MIX
Content-Type: text/plain;
name="GWAVADAT.TXT"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="GWAVADAT.TXT"
AdmID:7B71330EA97032
09A2FA96D77102BFE0
------ =_NextPart_200_becb_
92ec41a9.860bd46f_.MIX
Content-Type: text/plain; charset=us-ascii
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?uns...sie.nctu.edu.tw
------ =_NextPart_200_becb_
92ec41a9.860bd46f_.MIX--
|
|
|
|
|