Dear all, recently, at an email conversation with pgsql hackers I had a quick shot, asking about their position to somebody replacing their palloc GC -- having roughly in mind that either here or on a Mercury mailing list (where there's a similar case with a pure declarative language and a Boehm GC), where there was a conclusion a non-pure GC would be a major hindrance to deeper interaction. Ok, I found the answer worth a discussion here; as far as I understood, they don't oppose the idea that the PostgreSQL GC might be a candidate for an update. I see three issues: (a) The most open question to me is the gain from the Haskell perspective; most critical: Would a Haskell GC inside PostgreSQL mean a significant change or rather a drop in the bucket? Once this may be answered optimistically, there comes the question about possible applications -- i.e., what can be done with such a DBMS system. Knowing about efforts like (http://groups.inf.ed.ac.uk/links/) I would like to let this open for discussion. Let me please drop here a quote that I believe their object relational efforts seem to have gotten stuck at PostgreSQL due to the conceptual clash of OO with the relational algebra underlying PostgreSQL -- which in turn seems to harmonize much better with Hindley-Milner & Co. (System F??) (b) The question I personally can say least about are the expenditures to be expected for a such project. I would be very interested in some statements. I have limited knowledge about the PostgreSQL GC and would assume it is much simpler than, e.g. the GHC GC. (c) Gain from PostgreSQL perspective: This IMO should be answered easiest, hoping the Haskell GC experts to be able to answer easily how much is the overhead to be payed for pure declarativity, and the chances (e.g. parallelism, multi cores??), too. Besides it might be interesting to see inhowfar a considerable overhead problem may be alleviated by a 'plugin' architecture allowing future PostgreSQL users to switch between a set of GCs. I would be very interested about any comments, Cheers, Nick

Thanks John, The simple answer is that I need to be able to use HDBC in proprietary products and the LGPL makes this awkward - the most serious issue being that owners of the code base don't want GNU licensed parts being linked into their code base. Packaging and delivery also gets complicated - (as I understand it) LGPL components can't be delivered pre-linked, necessitating dynamic linking of the relevant libraries or supplying a GHC kit which the customer must use to assemble the product. This is all a significant drag. Also, wouldn't it be good to get HDBC into the Haskell Platform? - but we can't do this while it is LGPL can we? On the other side, what are the risks with adopting a BSD license? Is it that somebody could fork the library into a proprietary Haskell DB library that would compete with HDBC? Chris From: John Goerzen [mailto:jgoerzen@complete.org] Sent: 22 February 2011 19:55 To: Chris Dornan Cc: Haskell Cafe; Gershom Bazerman Subject: Re: [Haskell-cafe] HDBC's future and request for help On 02/22/2011 01:33 PM, Chris Dornan wrote:

Hi John,

Two thoughts: is there any prospect of making HDBC available under a BSD-like license? The LGPL license is a significant barrier for me and I expect it will be for others.

I'm happy to discuss this with people. It would be helpful to understand concrete cases where this would be a problem. I have permitted other code to be relicensed under BSD in the past and so don't have a huge hangup about this. If it's the best thing for the community, I'd be likely to do it. On the other hand, I have seen numerous cases over the years where BSD code has been taken by some company and essentially forked into a proprietary version. I feel this is not in the long-term interests of the community, and that drawback has to be weighed against any advantage.

And, along the lines of your own comments, the ODBC interface raises a significant (technical) barrier for MySQL users. Is there any chance that we can encourage/help getting the the MySQL driver closer to production quality?

The short answer is probably to send patches to its author or fork it. Or fund someone else to do so. -- John _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1435/3457 - Release Date: 02/21/11

Thanks John, I think this is a valuable discussion. The compromise you propose wouldn't address the main point - the fear and aversion of using (L)GPL IP in proprietary IP. For me the key phrase in your email was the final one - 'if my reading is correct'. Everywhere I would take advantage of this modified license I will need to get the lawyers of the people owning the host IP to agree to this interpretation. I have checked all of the packages in the Haskell Platform and they are all BSD3. If it had been otherwise it would have destroyed a significant part of the value of the HP - clear and straightforward licensing implications for using it. I really don't want to plough work into a package that can't be bundled with the HP, the natural home for strategically-important high-quality libraries. Turning this around, it is going to be much easier to get people who are using Haskell in commercial contexts to contribute to HDBC if it has a license that meets their requirements. I do appreciate your concerns - I have regularly contributed code to the community and want to continue doing so - but I think there is little real prospect of HDBC being attacked by a proprietary derivative. I don't doubt there will be some free-loading, but this might be the inevitable price of attracting more investment. Chris From: John Goerzen [mailto:jgoerzen@complete.org] Sent: 23 February 2011 16:33 To: Chris Dornan Cc: 'Haskell Cafe'; 'Gershom Bazerman' Subject: Re: [Haskell-cafe] HDBC's future and request for help On 02/23/2011 05:48 AM, Chris Dornan wrote:

The simple answer is that I need to be able to use HDBC in proprietary products and the LGPL makes this awkward - the most serious issue being that owners of the code base don't want GNU licensed parts being linked into their code base. Packaging and delivery also gets complicated - (as I understand it) LGPL components can't be delivered pre-linked, necessitating dynamic linking of the relevant libraries or supplying a GHC kit which the customer must use to assemble the product. This is all a significant drag.

Let's talk about specifics. I imagine that in LGPL-3 that the only clause for objection here is 4(d)0, which requires that the proprietary application be conveyed in a form such that the user can relink it with a modified version of the library. I would be willing to add an exemption to that requirement to the HDBC license, which should address that concern. What do you think?

Also, wouldn't it be good to get HDBC into the Haskell Platform? - but we can't do this while it is LGPL can we?

Why not?

On the other side, what are the risks with adopting a BSD license? Is it that somebody could fork the library into a proprietary Haskell DB library that would compete with HDBC?

That's one way to put it. It's a big complaint I have about the BSD license. There are many, many examples of companies taking things licensed under BSD, adding features small or large, selling the result at profit, and neither releasing the source for the new features to the community nor compensating the original authors in any way. I see a distinction between someone that just wants to *use* HDBC and between someone that wants to "embrace and extend" it. I know that work I do on Linux, Haskell, etc. leads to companies such as Ubuntu making a profit off my work, for which they don't compensate me. I also know that if they improve on it, and it's GPL, they have to return those improvements to the community so we can all benefit. I am bothered by the notion of letting companies take work I've done on a volunteer basis, close it up, change it, never compensate me for it and also never release the changes to the community. This is why I prefer to avoid the BSD license. In the case of HDBC, if all somebody wants to do is use vanilla HDBC in their program without having to release the source to the proprietary program or jump through hoops to let end users replace HDBC, then I think that LGPL with the modification I proposed above would meet both their concern and mine. The LGPL would still require them to note HDBC's copyright (which the BSD license requires as well), and to distribute source to any modifications they make *to HDBC*, but impose no other onerous restrictions if my reading is correct. - John _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1435/3462 - Release Date: 02/23/11

John, As far as I know it is the libraries that interface to O/S libraries that have most value in the platform and, AFAIK, many HP libraries link to O/S libraries (e.g., GLUT). I had expected that at least the principle HDBC drivers would have to go into the Haskell Platform with HDBC.

And that is a useful point as well. If there is a big package that people can use and understand once, without having to analyze licenses for dozens of component packages, there's value in that for sure.

What I'm hoping the commercial people on this list could do (besides me, that is) is say something like "LGPL won't work for us because clause xxx requires us to do yyy."

I am such a commercial developer as well as soon (I hope) a Haskell Platform maintainer. I am trying to explain my concerns. There are problematic clauses in the LGPL (any clauses that set out conditions for making the using system a derived work of the LGPL-licensed library) but the key point is having, as far as possible, a single permissive license (like the BSD license) for all of the libraries. For mission-critical components all of the legal due diligence and necessary educating of parties gets done. But it is not practical to do this for non-essential libraries, so anything that isn't covered by a BSD or similar license needs to be replaced for the production release.

At the same time, if one of the HP maintainers says, "We want HDBC in the HP and all that's holding us back is the license" I think that would be compelling enough for me to switch it immediately.

It would be interesting to hear from the HP maintainers. I would expect them to have a good handle on these issues. Chris From: John Goerzen [mailto:jgoerzen@complete.org] Sent: 23 February 2011 19:34 To: Chris Dornan Cc: 'Haskell Cafe'; 'Gershom Bazerman' Subject: Re: [Haskell-cafe] HDBC's future and request for help On 02/23/2011 11:57 AM, Chris Dornan wrote:

Thanks John,

I think this is a valuable discussion.

The compromise you propose wouldn't address the main point - the fear and aversion of using (L)GPL IP in proprietary IP.

Is that fear well-grounded or not? If not, then people should be educated. If so, then let's see what we can do about it -- either add exceptions or relicense. I don't really think that this community should choose licenses based upon whether or not third parties hold an irrational fear of them.

For me the key phrase in your email was the final one - 'if my reading is correct'. Everywhere I would take advantage of this modified license I will need to get the lawyers of the people owning the host IP to agree to this interpretation.

This is no different than with any other license, but could even be made more explicit. In the end, we are (mostly) a community of non-lawyers here so such disclaimers I also don't think that we ought to cater to people who are afraid to read licenses. Those are the people that tend to do things like pirate busybox and the Linux kernel for proprietary purposes.

I have checked all of the packages in the Haskell Platform and they are all BSD3. If it had been otherwise it would have destroyed a significant part of the value of the HP - clear and straightforward licensing implications for using it.

And that is a useful point as well. If there is a big package that people can use and understand once, without having to analyze licenses for dozens of component packages, there's value in that for sure. There are two ways to accomplish that. One is to insist that everything use the same license. The other is to establish standards for what kind of licensing terms are acceptable. An example of the latter is the Debian Free Software Guidelines, http://www.debian.org/social_contract#guidelines We could propose a guideline for things that go in the Haskell Platform, and it could be such as this: * All licenses must meet the terms of the Debian Free Software Guidelines (DFSG), and must also meet the following terms: * Proprietary applications may use and link with unmodified versions of libraries without forcing the rest of the application to use a specific license * Licenses may require proprietary applications that use and link with modified versions of libraries to make source code to the modifications available to the community under the original library's license, but may not require applications to do so for other code linked to the application * Licenses may require copyright and/or warranty disclaimers to be carried with applications that use the code. Perhaps we could also list example copyright/license statements that meet the requirements.

I really don't want to plough work into a package that can't be bundled with the HP, the natural home for strategically-important high-quality libraries.

I'm not certain the HP is a good home for HDBC. One could put HDBC itself in there, but it's useless without a database backend. All of those, do date, require a C binding which probably makes them poor candidates for the HP. If the thing in the platform is useless without the backend driver, is it sensible to put it in the HP? At the same time, if one of the HP maintainers says, "We want HDBC in the HP and all that's holding us back is the license" I think that would be compelling enough for me to switch it immediately.

Turning this around, it is going to be much easier to get people who are using Haskell in commercial contexts to contribute to HDBC if it has a license that meets their requirements.

Quite so. I want to make sure we do that. That's one reason I have kept the door to the BSD license open. As I've said, I've relicensed other code under BSD in the past and may be convinced to do it again. What I'm hoping the commercial people on this list could do (besides me, that is) is say something like "LGPL won't work for us because clause xxx requires us to do yyy." Then we can have a good discussion here, revolving around: * Is the community/author prepared to say that we want to let people do yyy with our software? * And if so, what is the best response? Can we make small exceptions to the LGPL to satisfy it, or do we have to go to the BSD or some other such license?

I do appreciate your concerns - I have regularly contributed code to the community and want to continue doing so - but I think there is little real prospect of HDBC being attacked by a proprietary derivative. I don't doubt there will be some free-loading, but this might be the inevitable price of attracting more investment.

That's an interesting point. There is, of course, free-loading even with GPL'd software. The promise there is, though, that people get their rights preserved regardless of who gives them the software. I like that, and think that in the long term it produces the greatest net gain in software quality and freedom. Yet I realize that it can cause some people without that mindset to reject it, which is why I see the LGPL, perhaps with the additional exception I've outlined, a good balance. -- John _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1435/3463 - Release Date: 02/23/11

On 02/23/2011 10:03 AM, Leon Smith wrote:

My biggest (mostly) fixable complaint with HDBC is that it hasn't turned out to be a very complete or robust solution for accessing databases that like to use PostgreSQL-specific features. My biggest

This is probably true, both that it isn't designed for database-specific features and that this is fixable.

complaint that (probably) isn't easily fixed is it's reliance on Convertible, and the use of lots of unsafe pattern matching and exception-happy functions.

Use of Convertible (or toSql/fromSql which is based on it) isn't really required. You could write a complete HDBC program having never touched it, assembling and disassembling your SqlValues manually. This was a design goal of the API. Convertible makes it easy and convenient for the 95% common cases, but you can avoid it if you wish, or use some other kind of conversion. All the HDBC functions work with SqlValues (though there are some convenience wrappers that use Strings instead) so you can build them up however you like. SqlValue is documented at http://hackage.haskell.org/packages/archive/HDBC/2.2.6.1/doc/html/Database-H... If your concern really is with how SqlValue is defined, alternative proposals are always entertained ;-) When you're dealing with databases over a network, exceptions can happen just about anywhere. HDBC does have its own exception type (SqlError) so that they can be handled en masse, or picked through more closely if desired. If you have an idea how else that should be handled, I'm all ears. By "unsafe pattern matching" do you mean GHC -Wall is flagging pattern matches that don't match some possible set of input data, or something else? If the former, that should be trivially fixable too.

At least for the time being, I've found it easiest and most expedient to fix up HDBC. I'm not particularly interested in taking over the maintenance of HDBC, and I am comfortable with model #1 at the time being. However if somebody else is interested in another option, I'm probably ok with that too.

Thanks for your feedback, Leon. I've appreciated your patches. -- John