Thread: I want to use postresql for this app, but...
I am working with a window-manufacturing firm (the real thing!). One of the reasons we are about to choose one of the vertical-market applications is that they claim ODBC compliance, and "Using other ODBC compliant database engines should not present a problem but may require some additional testing..." This is in stark contrast to all the other vendors who require MSSQL on the back end (or an AS400), and the usual windoziness about why you'd want to do anything else. When I asked about using PostgreSQL this is the reply I received: ---- I discussed PostureSQL with Paul and his technical director sent me the following comment: / PostgreSQL// is open source and so far they have not agreed on a blob field properly we use blob fields for the item bitmap, old conservatory data and meta files for graphics. An ODBC driver is available and describes how to fudge a blob field but it says that it does not clean them up properly when updating. I suggest moving to MySQL which is also open source ??/// They estimate about one day additional time to make necessary changes and to test for MySQL. Let me know what you think. ---- These folks develop using MSAccess and MSSQL. Can anyone shed any light on how serious this problem is, and whether it is ever likely to be resolved so that I could use PostgreSQL? TIA! PS - the vertical market software is Caliburn v8 at http://www.caliburn-software.com/ -- Derek Shaw BIS Business Information Systems Inc. Victoria, BC. voice: 250-885-2021 fax: 250-386-4060 PGP Public Key ID: 0xD3783198
On 05/02/2004 19:33 Derek Shaw wrote: > I am working with a window-manufacturing firm (the real thing!). One of > the reasons we are about to choose one of the vertical-market > applications is that they claim ODBC compliance, and "Using other ODBC > compliant database engines should not present a problem but may require > some additional testing..." This is in stark contrast to all the other > vendors who require MSSQL on the back end (or an AS400), and the usual > windoziness about why you'd want to do anything else. > > When I asked about using PostgreSQL this is the reply I received: > ---- > I discussed PostureSQL with Paul and his technical director sent me the > following comment: > / PostgreSQL// is open source and so far they have not agreed on a blob > field properly we use blob fields for the item bitmap, old conservatory > data and meta files for graphics. An ODBC driver is available and > describes how to fudge a blob field but it says that it does not clean > them up properly when updating. I suggest moving to MySQL which > is also open source ??/// > They estimate about one day additional time to make necessary changes > and to test for MySQL. Let me know what you think. > ---- > These folks develop using MSAccess and MSSQL. Can anyone shed any light > on how serious this problem is, and whether it is ever likely to be > resolved so that I could use PostgreSQL? I wonder if they've got confused about the 2 ways in PostgreSQL can store blobs. There is the older Large Object method and there is the newer bytea data type. Each has its advantages and disadvantages. http://www.varlena.com/varlena/GeneralBits/44.php could help them understand which to use. Or they could ask on this list. Perhaps you should also ask them them to comment on http://sql-info.de/mysql. Do they believe a database which can silently corrupt your data is a product worth recommending to a paying client? -- Paul Thomas +------------------------------+---------------------------------------------+ | Thomas Micro Systems Limited | Software Solutions for the Smaller Business | | Computer Consultants | http://www.thomas-micro-systems-ltd.co.uk | +------------------------------+---------------------------------------------+
Paul Thomas wrote: > On 05/02/2004 19:33 Derek Shaw wrote: >> I am working with a window-manufacturing firm (the real thing!). One of >> the reasons we are about to choose one of the vertical-market >> applications is that they claim ODBC compliance, and "Using other ODBC >> compliant database engines should not present a problem but may require >> some additional testing..." This is in stark contrast to all the other >> vendors who require MSSQL on the back end (or an AS400), and the usual >> windoziness about why you'd want to do anything else. >> >> When I asked about using PostgreSQL this is the reply I received: >> ---- >> I discussed PostureSQL with Paul and his technical director sent me the >> following comment: >> / PostgreSQL// is open source and so far they have not agreed on a blob >> field properly we use blob fields for the item bitmap, old conservatory >> data and meta files for graphics. An ODBC driver is available and >> describes how to fudge a blob field but it says that it does not clean >> them up properly when updating. I suggest moving to MySQL which >> is also open source ??/// >> They estimate about one day additional time to make necessary changes >> and to test for MySQL. Let me know what you think. >> ---- >> These folks develop using MSAccess and MSSQL. Can anyone shed any light >> on how serious this problem is, and whether it is ever likely to be >> resolved so that I could use PostgreSQL? > > I wonder if they've got confused about the 2 ways in PostgreSQL can store > blobs. There is the older Large Object method and there is the newer bytea > data type. Each has its advantages and disadvantages. > http://www.varlena.com/varlena/GeneralBits/44.php could help them > understand which to use. Or they could ask on this list. > > Perhaps you should also ask them them to comment on > http://sql-info.de/mysql. Do they believe a database which can silently > corrupt your data is a product worth recommending to a paying client? > In addition to this, "also open source" is correct, but there are significan differences in the quality of "open" vs. "open". MySQL is not free, so if the application developed is closed source, it requires the end user to purchase a commercial MySQL license per installation. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
On 09/02/2004 15:25 Jan Wieck wrote: > Paul Thomas wrote: > [snip] > In addition to this, "also open source" is correct, but there are > significan differences in the quality of "open" vs. "open". MySQL is not > free, so if the application developed is closed source, it requires the > end user to purchase a commercial MySQL license per installation. Another good point in our favour IMHO. -- Paul Thomas +------------------------------+---------------------------------------------+ | Thomas Micro Systems Limited | Software Solutions for the Smaller Business | | Computer Consultants | http://www.thomas-micro-systems-ltd.co.uk | +------------------------------+---------------------------------------------+
Paul Thomas wrote: > On 09/02/2004 15:25 Jan Wieck wrote: > >> Paul Thomas wrote: >> [snip] >> In addition to this, "also open source" is correct, but there are >> significan differences in the quality of "open" vs. "open". MySQL is >> not free, so if the application developed is closed source, it >> requires the end user to purchase a commercial MySQL license per >> installation. > > Another good point in our favour IMHO. > This is *WRONG*. MySQL is *free*, but is double-licensed. Please refer to this page for further details. http://www.mysql.com/products/licensing.html -- Claudio Cicali c.cicali@mclink.it http://www.flexer.it GPG Key Fingerprint = 2E12 64D5 E5F5 2883 0472 4CFF 3682 E786 555D 25CE
> This is *WRONG*. > MySQL is *free*, but is double-licensed. > Please refer to this page for further details. > http://www.mysql.com/products/licensing.html Are you serious? By free, we also mean that a product is developed by a community of people, not a company raising funds. MySQL AB is mainly backed-up by investors. When all this money is burnt-away, this will be the end of it. Free software is a cultural and shared development organisation, tightly linked to the motivation of a individuals. In a way, MySQL is NOT ***free***. It will be free the day when you see normal people taking decisions and committing new features to CVS. There is no freedom without equal access to information and decision makers. Visit: http://www.mysql.com/company/index.html "MySQL staff develop new releases every..." Equal access will (probably) never happen, because MySQL AB would not be able to release "double-licences" without the agreement of all authors. Do not hesitate to contact us back if normal people from the normal world ever commit code in MySQL CVS. This would be a clear sign that MySQL AB is on the good trend and will probably go faster than a 3 year release cycle. By choosing PostgreSQL, people are investing in a community work that will never dissapear and will probably superseed all existing databases within 10 years. This is as simple as life. Unless PostgreSQL hackers and manpower is wiped-out by a nuclear winter or any natural catastrophy, there is no possibility to stop PostgreSQL rise (joke, I am not really serious here). Best regards, Jean-Michel
Jean-Michel POURE wrote: >>This is *WRONG*. >>MySQL is *free*, but is double-licensed. >>Please refer to this page for further details. >>http://www.mysql.com/products/licensing.html > > Are you serious? > Yes, I am. > By free, we also mean that a product is developed by a community of people, > not a company raising funds. MySQL AB is mainly backed-up by investors. When > all this money is burnt-away, this will be the end of it. You can't say what YOU mean with "free". In this context "free" is what is licensed under GPL or GPL-compatible licenses. MySQL, as a *product*, it's not free as you argue. Ok. But MySQL as simple "software", is free. You can get the whole source and begin "forking" as you like. This is enough for me, and for anyone pondering "licensing" problems while choosing a dbms for her company. > Free software is a cultural and shared development organisation, tightly > linked to the motivation of a individuals. I could not agree more. > In a way, MySQL is NOT ***free***. It will be free the day when you see normal > people taking decisions and committing new features to CVS. There is no > freedom without equal access to information and decision makers. Yes, in A WAY. Not the way that (imho) we were discussing here. > Visit: http://www.mysql.com/company/index.html > "MySQL staff develop new releases every..." > > Equal access will (probably) never happen, because MySQL AB would not be able > to release "double-licences" without the agreement of all authors. Wonder what is missing to Postgresql ? (hint: strong commercial support. No flame, please ! :)) > Best regards, > Jean-Michel Nice post, nice thread. -- Claudio Cicali c.cicali@mclink.it http://www.flexer.it GPG Key Fingerprint = 2E12 64D5 E5F5 2883 0472 4CFF 3682 E786 555D 25CE
Le Mardi 10 Février 2004 10:59, Claudio Cicali a écrit : > Wonder what is missing to Postgresql ? Thanks for your answer. In fact, PostgreSQL is not missing much, even in commercial support. Now, as a joke and invitation, at pgAdmin: - we are missing 48 Italian strings in http://www.pgadmin.org/pgadmin3/translation.php. - a translation of pgAdmin website in Italian would be nice too. Then, if you have time, visit pgAdmin advocay page: http://www.pgadmin.org/pgadmin3/advocacy.php Using the PAD file, you will be able to register pgAdmin III on Italian downloading web sites. MySQL does it all the time for several softwares, including "MySQL control center". :) Any help is welcome. Cheers, Jean-Michel
Claudio Cicali wrote: > Paul Thomas wrote: >> On 09/02/2004 15:25 Jan Wieck wrote: >> >>> Paul Thomas wrote: >>> [snip] >>> In addition to this, "also open source" is correct, but there are >>> significan differences in the quality of "open" vs. "open". MySQL is >>> not free, so if the application developed is closed source, it >>> requires the end user to purchase a commercial MySQL license per >>> installation. >> >> Another good point in our favour IMHO. >> > > This is *WRONG*. > > MySQL is *free*, but is double-licensed. > > Please refer to this page for further details. > http://www.mysql.com/products/licensing.html > Did you even bother to look at that page yourself? It clearly says exactly what I said up there. If your code is available free of change as open source, then and only then, you and the users of your code are free from license fees. In any other case you have to buy or keep your stuff for yourself. Special restrictions apply to any changes you might want to make to it, and so on and so forth. Free to me means a little more than "currently free of charge under certain restrictions that are subject to change under our discretion". And the latter is how I read the MySQL license explanations, but IANAL. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Jan Wieck wrote: > Claudio Cicali wrote: >> >> This is *WRONG*. >> >> MySQL is *free*, but is double-licensed. >> >> Please refer to this page for further details. >> http://www.mysql.com/products/licensing.html >> > > Did you even bother to look at that page yourself? It clearly says Yes, I did. > exactly what I said up there. If your code is available free of change > as open source, then and only then, you and the users of your code are > free from license fees. In any other case you have to buy or keep your > stuff for yourself. Special restrictions apply to any changes you might > want to make to it, and so on and so forth. (quite) Right. Free of charge and Open Source are not, technically, synonims. License fees are another story. > Free to me means a little more than "currently free of charge under > certain restrictions that are subject to change under our discretion". > And the latter is how I read the MySQL license explanations, but IANAL. Wrong. That's true for *every* software that holds a copyright (as the GPL). As far as I'm the (only) copyright holder of a software, I (and only me) could CHANGE COMPLETELY the way I distribute that software. This changes do not apply to yet-released version. This, btw, is the problem that currently leaves the new XFree86 version (by 4.3.99) sligthly away from GPL. They changed the licence to a more restrictive one (point 4.). So, your assumption is meangingless. > > Jan > -- Claudio Cicali c.cicali@mclink.it http://www.flexer.it GPG Key Fingerprint = 2E12 64D5 E5F5 2883 0472 4CFF 3682 E786 555D 25CE
I'm pretty sure this belongs, if anywhere, on -advocacy, so I've set
Reply-To accordingly. Of course, if you're munging the Reply-To,
that won't work, which is why this little note is here.
On Tue, Feb 10, 2004 at 10:59:24AM +0100, Claudio Cicali wrote:
> MySQL, as a *product*, it's not free as you argue. Ok. But MySQL as simple
> "software", is free. You can get the whole source and begin "forking" as you
> like. This is enough for me, and for anyone pondering "licensing" problems
> while choosing a dbms for her company.
Are you quite sure about that? Cause I can say for sure that both my
managers and our customers would think long and hard about my
committal if I suggested that we just fork Postgres and try to
sell things with a proprietary DBMS underneath it. I'd also have to
think pretty hard about whether I'd want to use such a product.
Consider the disadvantages, from the point of view of a customer, of
such a proprietary system. They don't know how stable it is. They
have no point of reference about its stability. They don't know how
many bugs might be lurking in there. Most importantly, if you go
bankrupt, they may not be able to get their data out _at all_.
I know, and probably you know too, that all of those limitations are
also problems for something based on Oracle, or MySQL, or Berkeley
DB, or PostgreSQL: the truth is that most users of an application don't
need to care about the guts underlying it. But they _do_ need to be
able to justify their decisions in case something goes wrong. When
something _does_ go wrong, you can bet that the person who made the
decision to buy the proprietary system will be in trouble unless that
proprietary system comes with a long list of satisfied customers.
And the last point is the rub: if you fork MySQL, you can't use the
MySQL name. So you can't talk about your satisfied customers who are
using MySQL, because you've forked.
I'm not pretending that any of this is rational behaviour, but I'd
think that the last 50 (anyway) years of research in sociology and
economics would convince everyone that the myth of the rational
consumer is handy for economic models, but several degrees removed
from a description of actual human behaviour.
Having access to the source is indeed a protection that proprietary
systems don't usually offer, but only in case there is an active
community supporting the product. If not, the source is a liability,
because you have to support it yourself. This is why fostering an
active community is in the interests of PostgreSQL users, and why I
would be somewhat anxious about the GPLd version of MySQL, even if
MySQL AB was not asserting rather broad application of the GPL beyond
its seeming purpose.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
This work was visionary and imaginative, and goes to show that visionary
and imaginative work need not end up well.
--Dennis Ritchie
On Tue, 10 Feb 2004, Claudio Cicali wrote: > Jan Wieck wrote: > > > Claudio Cicali wrote: > >> > >> This is *WRONG*. > >> > >> MySQL is *free*, but is double-licensed. > >> > >> Please refer to this page for further details. > >> http://www.mysql.com/products/licensing.html > >> > > > > Did you even bother to look at that page yourself? It clearly says > > Yes, I did. > > > exactly what I said up there. If your code is available free of change > > as open source, then and only then, you and the users of your code are > > free from license fees. In any other case you have to buy or keep your > > stuff for yourself. Special restrictions apply to any changes you might > > want to make to it, and so on and so forth. > > (quite) Right. Free of charge and Open Source are not, technically, > synonims. License fees are another story. I'm confused. The message in question used the word "free" along with qualifications for closed source and last time I checked the word free did not implicitly mean free software especially when combined with a qualification for closed source. I mean, I'm not the best English speaker/writer in the world, but I'd thought the word was in common usage before the advent of computers. ;)
On Tue, 10 Feb 2004, Claudio Cicali wrote: > Jean-Michel POURE wrote: > > > Visit: http://www.mysql.com/company/index.html > > "MySQL staff develop new releases every..." > > > > Equal access will (probably) never happen, because MySQL AB would not be able > > to release "double-licences" without the agreement of all authors. > > Wonder what is missing to Postgresql ? (hint: strong commercial support. No flame, please ! :)) Yes, that same problem has certainly seemed to hamper the implementation of the apache web server. I mean, no one uses that thing... without a single strong company behind it, apache has just floundered the last few years. Guess what? Both Postgresql and apache have strong commercial support. It just isn't provided by one company who holds all the strings. That's a good thing, by the way.
On Tuesday 10 February 2004 12:13 am, Claudio Cicali wrote: > Paul Thomas wrote: > > On 09/02/2004 15:25 Jan Wieck wrote: > >> Paul Thomas wrote: > >> [snip] > >> In addition to this, "also open source" is correct, but there > >> are significan differences in the quality of "open" vs. "open". > >> MySQL is not free, so if the application developed is closed > >> source, it requires the end user to purchase a commercial MySQL > >> license per installation. > > > > Another good point in our favour IMHO. > > This is *WRONG*. > > MySQL is *free*, but is double-licensed. > > Please refer to this page for further details. > http://www.mysql.com/products/licensing.html MySQL seems to have a weird self-serving interpretation of GPL and I don't trust them. They repeatedly talk about restrictions on _internal_ distribution. From the MySQL licensing page (http://www.mysql.com/products/licensing.html) they have a: "...Commercial License, which allows you to provide commercial software licenses to your customers or distribute MySQL-based applications within your organization. This is for organizations that do not want to release the source code for their applications as open source / free software..." From the MySQL licensing FAQ (http://www.mysql.com/products/opensource-license.html): "Free use for those who never copy, modify or distribute. As long as you never distribute (internally or externally) the MySQL Software in any way, you are free to use it for powering your application, irrespective of whether your application is under GPL license or not." From the MySQL commercial license page (http://www.mysql.com/products/commercial-license.html): "If you distribute MySQL Software within your organization, you should purchase a commercial license." The same page in its description of things interpreted to be commercial distribution of MySQL includes this gem: "Selling software that requires customers to install MySQL themselves on their own machines." If this licensing interpretation applied to Linux (imagining for the moment that a commercial licence for Linux were to exist) any organization wishing to use the Linux version of Oracle or OpenOffice or even PostgreSQL even for strictly internal use would have to purchase a commercial Linux license. MySQL claims on its licensing page that "MySQL AB bases its interpretation of the GPL on the Free Software Foundation's Frequently Asked Questions" and includes a link to that FAQ but note the disparity between MySQL's interpretation and the FSF interpretation which reads (http://www.fsf.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic): The GPL does not require you to release your modified version. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization. IANAL but it appears to me from their FAQs that MySQL AB seeks to require any company using a MySQL based product in any way to buy a commercial license. I'll stick with PostgreSQL (and not just for the license). Cheers, Steve
On Tue, 10 Feb 2004, Claudio Cicali wrote: > Jean-Michel POURE wrote: > > > > By free, we also mean that a product is developed by a community of people, > > not a company raising funds. MySQL AB is mainly backed-up by investors. When > > all this money is burnt-away, this will be the end of it. > > You can't say what YOU mean with "free". In this context "free" is what is > licensed under GPL or GPL-compatible licenses. > > MySQL, as a *product*, it's not free as you argue. Ok. But MySQL as simple > "software", is free. You can get the whole source and begin "forking" as you > like. This is enough for me, and for anyone pondering "licensing" problems > while choosing a dbms for her company. You isn't quite right here. This does not fix the licensing issues, since you would still be wholly bound by the GPL. I.e. all the code you write that connects to MySQL would therefore have to be GPL'd. I.e. it does nothing to fix the licensing problems that have been brought up.
On Tue, Feb 10, 2004 at 09:50:31AM -0700, scott.marlowe wrote:
> you would still be wholly bound by the GPL. I.e. all the code you write
> that connects to MySQL would therefore have to be GPL'd. I.e. it does
> nothing to fix the licensing problems that have been brought up.
I know that's what MySQL claims, but (a) I can't see any plausible
interpretation of the GPL which makes that enforcable; and (b)
assuming someone really did fork, I can't see how MySQL's reading of
the GPL would be relevant (since you'd no longer be using MySQL, but
YourSQL or whatever it was called).
A
--
Andrew Sullivan | ajs@crankycanuck.ca
The fact that technology doesn't work is no bar to success in the marketplace.
--Philip Greenspun
On Tue, 10 Feb 2004, Andrew Sullivan wrote: > On Tue, Feb 10, 2004 at 09:50:31AM -0700, scott.marlowe wrote: > > you would still be wholly bound by the GPL. I.e. all the code you write > > that connects to MySQL would therefore have to be GPL'd. I.e. it does > > nothing to fix the licensing problems that have been brought up. > > I know that's what MySQL claims, but (a) I can't see any plausible > interpretation of the GPL which makes that enforcable; and (b) > assuming someone really did fork, I can't see how MySQL's reading of > the GPL would be relevant (since you'd no longer be using MySQL, but > YourSQL or whatever it was called). simple. They GPL'd their connection libs. So, if you write code that has their connection libs in it, it's gotta be GPL'd. Now, if you don't mind using the ODBC connector, you're scott free. but you WILL be bound by the GPL, and the GPL (not MySQL's interpretation, just the GPL in general) being applied to connect libs seriously limits your ability to distribute code, since you'd have to GPL your own code if you distributed it outside your own private organization. Renaming it would do nothing to help you. The GPL would still bite you pretty hard on distribution if you decide to use the GPL'd connect libs.
On Tue, Feb 10, 2004 at 12:06:43PM -0700, scott.marlowe wrote:
> simple. They GPL'd their connection libs. So, if you write code that has
> their connection libs in it, it's gotta be GPL'd.
Yes. But you could fork from their old libs (which were, IIRC, LGPL)
and work from there. Of course, you can't look at the new code
first, but if Compaq could clean room the IBM BIOS, it's gotta be
possible to find someone who knows nothing about this either.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism.
--Brad Holland
On Tue, 10 Feb 2004, Andrew Sullivan wrote: > On Tue, Feb 10, 2004 at 12:06:43PM -0700, scott.marlowe wrote: > > simple. They GPL'd their connection libs. So, if you write code that has > > their connection libs in it, it's gotta be GPL'd. > > Yes. But you could fork from their old libs (which were, IIRC, LGPL) > and work from there. Of course, you can't look at the new code > first, but if Compaq could clean room the IBM BIOS, it's gotta be > possible to find someone who knows nothing about this either. But they changed their connection methods completely, so the old libs won't talk to the 4.x database. So, you'd have to clean room implement their 4.0 connect protocal, and make your own non-GPL connect lib by wire sniffing it or having someone read the code, write down a white paper of the connection protocal and then implement from there.
Claudio Cicali wrote: > Jan Wieck wrote: > >> Claudio Cicali wrote: >>> >>> This is *WRONG*. >>> >>> MySQL is *free*, but is double-licensed. >>> >>> Please refer to this page for further details. >>> http://www.mysql.com/products/licensing.html >>> >> >> Did you even bother to look at that page yourself? It clearly says > > Yes, I did. > >> exactly what I said up there. If your code is available free of change >> as open source, then and only then, you and the users of your code are >> free from license fees. In any other case you have to buy or keep your >> stuff for yourself. Special restrictions apply to any changes you might >> want to make to it, and so on and so forth. > > (quite) Right. Free of charge and Open Source are not, technically, > synonims. License fees are another story. I might be a little slow, or misunderstand you completely. You claimed that "MySQL is *free*". In what sense is it free? Obviously you don't mean that MySQL is free because you can download and use the software for some purpose without paying money directly or indirectly to MySQL AB in Sweden. Because under that definition Oracle 10g is *free*, you can download and install the complete Linux x86 Enterprise Edition and use it for some purposes and don't owe Oracle a nickle. I don't think that anyone, including Oracle, would agree here that this is *free* software. So can you please explain in detail why you think that the term *free* applies to MySQL. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Scott, On Feb 10, 2004, at 2:06 PM, scott.marlowe wrote: > Now, if you don't mind using the ODBC connector, you're scott free. > but > you WILL be bound by the GPL, and the GPL (not MySQL's interpretation, > just the GPL in general) being applied to connect libs seriously limits > your ability to distribute code, since you'd have to GPL your own code > if > you distributed it outside your own private organization. So are you saying that if you connect to any GPL database (e.g. gnumed is a GPL database created with Postgresql), you must GPL your code? Even when using something like ODBC as the connection method? Thanks, John DeSoi, Ph.D.
"scott.marlowe" <scott.marlowe@ihs.com> writes: > Now, if you don't mind using the ODBC connector, you're scott free. but > you WILL be bound by the GPL, and the GPL (not MySQL's interpretation, > just the GPL in general) being applied to connect libs seriously limits > your ability to distribute code, since you'd have to GPL your own code if > you distributed it outside your own private organization. Note that in the case in question it's not entirely clear that the GPL is at all a problem. The original poster was talking about a vertical market application delivered for to a single user. That user is probably not interested in reselling the software, so any restrictions on them reselling it wouldn't actually bother them. This is in fact precisely the type of consultant market that the GPL envisions. And it's more common than one might think. Cygnus had various clients for gcc/binutils/gdb targets who weren't concerned about what restrictions the source came with as long as they got the software they needed. The GPL is after all a heck of a lot less restrictive than the typical EULA that accompanies binary software products. -- greg
On Wed, 2004-02-11 at 03:06, scott.marlowe wrote: > > simple. They GPL'd their connection libs. So, if you write code that has > their connection libs in it, it's gotta be GPL'd. > > Now, if you don't mind using the ODBC connector, you're scott free. but > you WILL be bound by the GPL, and the GPL (not MySQL's interpretation, > just the GPL in general) being applied to connect libs seriously limits > your ability to distribute code, since you'd have to GPL your own code if > you distributed it outside your own private organization. > I am not sure I agree. There are plenty of ways of circumventing this issue with the connecting libraries. For example, if I really wanted to (and it would be quite feasible for me to do so) I could write a SOAP server, CORBA component, or just a simple UNIX socket server which I could use to communicate with a GPL'd program. This new "server" would connect using client libraries licensed under the LGPL and released to the world. I don't think MySQL would be happy, but I don't really think that they could do much. I might even call it OurSQL to piss them off ;-). Of course, I don't do this because I prefer PostgreSQL anyway. Best Wishes, Chris Travers
On Wed, 2004-02-11 at 00:47, Steve Crawford wrote: > > MySQL seems to have a weird self-serving interpretation of GPL and I > don't trust them. This is not only a problem with MySQL, IMO. I stopped using PDFLib for a similar reason. Their license (Aladdin Public License) stated that use was beyond the scope of the license, but their web site asked for a fee for any "commercial use" and their interpretation seemed to include many in-house uses. I am in the process, among other things, of finalizing the business plan for a consulting firm I will be starting based on open source solutions. Our choice of products to support has a lot to do with these sorts of issues. Needless to say, PostgreSQL gets our vote :-) Part of the issue is avoiding litigation. If MySQL AB starts to run out of funds, I don't want to see another fiaSCO emerge... If they are not trustworthy, or seem to be pushing the limits of a license, then they are not worth doing business with. Best Wishes, Chris Travers
On 12 Feb 2004, Chris Travers wrote: > On Wed, 2004-02-11 at 03:06, scott.marlowe wrote: > > > > > simple. They GPL'd their connection libs. So, if you write code that has > > their connection libs in it, it's gotta be GPL'd. > > > > Now, if you don't mind using the ODBC connector, you're scott free. but > > you WILL be bound by the GPL, and the GPL (not MySQL's interpretation, > > just the GPL in general) being applied to connect libs seriously limits > > your ability to distribute code, since you'd have to GPL your own code if > > you distributed it outside your own private organization. > > > I am not sure I agree. There are plenty of ways of circumventing this > issue with the connecting libraries. For example, if I really wanted to > (and it would be quite feasible for me to do so) I could write a SOAP > server, CORBA component, or just a simple UNIX socket server which I > could use to communicate with a GPL'd program. This new "server" would > connect using client libraries licensed under the LGPL and released to > the world. I don't think MySQL would be happy, but I don't really think > that they could do much. I might even call it OurSQL to piss them off > ;-). > > Of course, I don't do this because I prefer PostgreSQL anyway. no kidding. I have to admit that in my mad scientist moments, I have envisioned writing a new connect lib that's BSD/LPGL licensed. Primarily just because I can be a bit antisocial... :)
On 12 Feb 2004, Greg Stark wrote: > > "scott.marlowe" <scott.marlowe@ihs.com> writes: > > > Now, if you don't mind using the ODBC connector, you're scott free. but > > you WILL be bound by the GPL, and the GPL (not MySQL's interpretation, > > just the GPL in general) being applied to connect libs seriously limits > > your ability to distribute code, since you'd have to GPL your own code if > > you distributed it outside your own private organization. > > Note that in the case in question it's not entirely clear that the GPL is at > all a problem. The original poster was talking about a vertical market > application delivered for to a single user. That user is probably not > interested in reselling the software, so any restrictions on them reselling it > wouldn't actually bother them. > > This is in fact precisely the type of consultant market that the GPL > envisions. And it's more common than one might think. Cygnus had various > clients for gcc/binutils/gdb targets who weren't concerned about what > restrictions the source came with as long as they got the software they > needed. The GPL is after all a heck of a lot less restrictive than the typical > EULA that accompanies binary software products. Very good point.
scrawford@pinpointresearch.com (Steve Crawford) writes: > The same page in its description of things interpreted to be > commercial distribution of MySQL includes this gem: > > "Selling software that requires customers to install MySQL themselves > on their own machines." > > If this licensing interpretation applied to Linux (imagining for the > moment that a commercial licence for Linux were to exist) any > organization wishing to use the Linux version of Oracle or > OpenOffice or even PostgreSQL even for strictly internal use would > have to purchase a commercial Linux license. I find it disingenous that, in view of this, there is the attempt to associate MySQL(tm) with 'open source software' like Linux, Perl, and Apache (those being the other 'members' of "LAMP.") If Linux, or Apache, or Perl, or any number of the other pieces of free software that helped to popularize the use of free systems "that resemble Unix" had had the encumbrances that MySQL AB claims for their product, they would _never_ have gotten popular the way they have. The reason why Linux web/file servers pop up everywhere is precisely because there is NO mandate to report "commercial use" to some fixed owner that wants to audit licensing fees. They would never have gotten into such widespread use in industry otherwise. There's certainly room for PostgreSQL to have a sub-motto something like: _PostgreSQL: Free software means no need to fear license audits._ -- "cbbrowne","@","cbbrowne.com" http://cbbrowne.com/info/sap.html Canada, Mexico, and Australia form the Axis of Nations That Are Actually Quite Nice But Secretly Have Nasty Thoughts About America
John DeSoi wrote: > Scott, > > On Feb 10, 2004, at 2:06 PM, scott.marlowe wrote: > >> Now, if you don't mind using the ODBC connector, you're scott free. >> but >> you WILL be bound by the GPL, and the GPL (not MySQL's interpretation, >> just the GPL in general) being applied to connect libs seriously limits >> your ability to distribute code, since you'd have to GPL your own code >> if >> you distributed it outside your own private organization. > > So are you saying that if you connect to any GPL database (e.g. gnumed > is a GPL database created with Postgresql), you must GPL your code? > Even when using something like ODBC as the connection method? No, if you "link" to any library that is GPL you have to ship your stuff under GPL as well. You don't have to ship your application at all, you can keep it just for yourself and everything is fine. But as soon as you want to give your stuff to anyone else, and for commercial application vendors this is rather likely, you have to GPL your code when you need GPL libraries, and that now is rather unlikely for commercial vendors. This is the very reason why many GPL server or development products ship their client connect or runtime libraries under LGPL. You can link against a LGPL lib that connects to a GPL server and sell your stuff closed source. Those GPL projects that do this don't care what you use their product for, they only care what you do in their code. If you do enhancements to their server or tool code to make your stuff work (better), the GPL makes sure they get those enhancements. If you just use it out of the box, do it, be happy and nice to meet you. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
scott.marlowe@ihs.com ("scott.marlowe") wrote:
> no kidding. I have to admit that in my mad scientist moments, I have
> envisioned writing a new connect lib that's BSD/LPGL licensed. Primarily
> just because I can be a bit antisocial... :)
A group of users, distressed at license changes, proposed doing
exactly that for SAP-DB(tm), and were warned that the vendor would be
likely to assume that this was an attempt to circumvent their license,
and that this would be likely to lead to legal action. Beware of
litigious vendors...
--
(format nil "~S@~S" "cbbrowne" "ntlug.org")
http://www.ntlug.org/~cbbrowne/wp.html
Economists are still trying to figure out why the girls with the least
principle draw the most interest.
On Tue, 10 Feb 2004 15:32:11 -0500 Chris Browne <cbbrowne@acm.org> wrote:
> There's certainly room for PostgreSQL to have a sub-motto something
> like:
> _PostgreSQL: Free software means no need to fear license audits._
here's something that Theo de Raadt says (in the context of OpenBSD)
that seems apropos:
"Free means free"
richard
--
Richard Welty rwelty@averillpark.net
Averill Park Networking 518-573-7592
Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > There`s certainly room for PostgreSQL to have a sub-motto something > > like: > > > _PostgreSQL: Free software means no need to fear license audits._ > > here`s something that Theo de Raadt says (in the context of OpenBSD) > that seems apropos: > > "Free means free" That is very ironic, considering it was a license audit that got PostgreSQL yanked from the OpenBSD distribution, all because they have an (IMO) irrational fear of being sued (by whom?) over a license that has held up for many, many years. Thus, OpenBSD does not consider us "free". - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200402171930 -----BEGIN PGP SIGNATURE----- iD8DBQFAMrJnvJuQZxSWSsgRAgWxAKCuFHJZSt5NPla+79nFojWQtIqUbQCfU8Fr 5eO+tUvXU0iU1Idb7tlbDI4= =dZS4 -----END PGP SIGNATURE-----
On Wed, 18 Feb 2004 00:30:58 -0000 Greg Sabino Mullane <greg@turnstep.com> wrote:
attribution of my quote of Theo de Raadt got stripped some how:
> > "Free means free"
>
> That is very ironic, considering it was a license audit that got PostgreSQL
> yanked from the OpenBSD distribution, all because they have an (IMO) irrational
> fear of being sued (by whom?) over a license that has held up for many,
> many years. Thus, OpenBSD does not consider us "free".
you call it irrational, but Theo did it based on advice from an attorney.
i do not wish to reopen the license debate, so this will be my last
post in this thread.
cheers,
richard
--
Richard Welty rwelty@averillpark.net
Averill Park Networking 518-573-7592
Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
SCO is acting on advice from attorneys as well.
My last post.;^)
>>> Richard Welty <rwelty@averillpark.net> 02/17/04 05:38PM >>>
On Wed, 18 Feb 2004 00:30:58 -0000 Greg Sabino Mullane <greg@turnstep.com> wrote:
attribution of my quote of Theo de Raadt got stripped some how:
> > "Free means free"
>
> That is very ironic, considering it was a license audit that got PostgreSQL
> yanked from the OpenBSD distribution, all because they have an (IMO) irrational
> fear of being sued (by whom?) over a license that has held up for many,
> many years. Thus, OpenBSD does not consider us "free".
you call it irrational, but Theo did it based on advice from an attorney.
i do not wish to reopen the license debate, so this will be my last
post in this thread.
cheers,
richard
--
Richard Welty rwelty@averillpark.net
Averill Park Networking 518-573-7592
Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
> I mean, I'm not the best English > speaker/writer in the world That's irrelevant, given how much time native English speakers spend debating the "proper" use of the word "free" ;-) -- Scott Ribe scott_ribe@killerbytes.com http://www.killerbytes.com/ (303) 665-7007 voice
> >Now, if you don't mind using the ODBC connector, you're scott free. > >but you WILL be bound by the GPL, and the GPL (not MySQL's interpretation, > >just the GPL in general) being applied to connect libs seriously limits > >your ability to distribute code, since you'd have to GPL your own code > >if you distributed it outside your own private organization. > > So are you saying that if you connect to any GPL database (e.g. gnumed > is a GPL database created with Postgresql), you must GPL your code? The above only talks about the relationship between the license of the connection libraries used on the client side in some frontend code and the license of that frontend code. Any driver can connect to PostgreSQL regardless of the driver's license. But software that wants to *incorporate* the *driver*, say, load it as a Python DB-API module is bound to comply with the license of the driver. So, GnuMed has to be GPL if it wants to use pyPgSQL which happens to be a GPL Python DB-API driver for PostgreSQL. What you seem to be asking, though, is whether I as a GnuMed developer can say "No, you cannot connect to our GPL *schema* unless your connection application is also GPL." Interesting. Common Sense says "No, I can't do that." But Common Sense also ponders why. Myself, personally, as a GnuMed developer, don't really feel inclined to think that I can stop you from connecting a commercial application to "our" schema. I would prefer cooperation. > Even when using something like ODBC as the connection method? No, see above. Karsten Hilbert, MD GnuMed i18n coordinator -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Hi Karsten, On May 24, 2004, at 7:59 PM, Karsten Hilbert wrote: > Myself, personally, as a GnuMed developer, don't really feel > inclined to think that I can stop you from connecting a > commercial application to "our" schema. I would prefer > cooperation. OK, this is really spooky. As best as I know, I did not send this message today -- only the original post back in February. It does not appear I have a copy of it anywhere on my computer. I have no clue how it was reposted today apparently from me. But anyway, thanks for your input on this. Best, John DeSoi, Ph.D.
Hi John, > >Myself, personally, as a GnuMed developer, don't really feel > >inclined to think that I can stop you from connecting a > >commercial application to "our" schema. I would prefer > >cooperation. > > OK, this is really spooky. As best as I know, I did not send this > message today -- only the original post back in February. It does not > appear I have a copy of it anywhere on my computer. I have no clue how > it was reposted today apparently from me. Don't worry. Just yesterday a repost from me appeared mysteriously on GnuMed-devel from 10 weeks back ... They are out there, I'm sure ;-) Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
> So are you saying that if you connect to any GPL database (e.g. gnumed > is a GPL database created with Postgresql), you must GPL your code? Even > when using something like ODBC as the connection method? I don't think so. The difference is, that PostgreSQL is BSD and you are connecting from a GPL source versus say MySQL which is GPL and connecting from a BSD source. The GPL is pervasive in that if your app requires libs that are GPL then your app must also be GPL. However, since PostgreSQL libs are BSD we don't have that issue. IANAL but I believe that is the case. Sincerely, Joshua D. Drake > > Thanks, > > John DeSoi, Ph.D. > > > ---------------------------(end of broadcast)--------------------------- > TIP 8: explain analyze is your friend -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL