HDBC's future and request for help

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

HDBC's future and request for help

John Goerzen-3
Hi folks,

HDBC has been out there for quite some time now.  I wrote it initially
to meet some specific needs, and from that perspective, it has been done
for awhile.  It is clear, however, that there are some needs it doesn't
meet.  Most of them relate to specific backend driver items.

I'd like to start some discussion in the community about what the future
of HDBC and its backend drivers ought to look like.  Some models might be:

  1. I continue as maintainer for HDBC and
HDBC-{postgresql,odbc,sqlite3} and act as patch manager/gatekeeper for
patches that are discussed on some public mailing list.

  2. Interested parties adopt the backend drivers while I continue to
act as maintainer/patch manager/gatekeeper for HDBC itself.

  3. Interested parties adopt all of HDBC and maintain it

I am not expressing a particular preference for any of these options;
just putting them forth.

Here are some of the current issues I am aware of:

  1. I have no Windows development platform.  I can't test the releases
on Windows.  Many Windows users don't have the skill to diagnose
problems.  These problems do eventually get fixed when a Windows user
with that skill comes along -- and I appreciate their efforts very much!
-- but it takes longer than it ought to.

  2. The ODBC documentation is monumentally terrible, and the API is
perhaps only majestically terrible, and it is not 100% clear to me all
the time that I have it right.  A seasoned ODBC person would be ideal here.

  3. Issues exist with transferring binary data and BLOBs to/from at
least PostgreSQL databases and perhaps others.  There appear to be bugs
in the backend for this, but BLOB support in the API may need to be
developed as well.

  4. Although the API supports optimizations for inserting many rows at
once and precompiled queries, most backends to not yet take advantage of
these optimization.

  5. I have received dueling patches for whether foreign imports should
be marked "safe" or "unsafe" on various backends.  There seems to be
disagreement in the community about this one.

  6. Many interactions with database backends take place using a String
when a more native type could be used for efficiency.  This project may
be rather complex given varying types of column data in a database --
what it expects for bound parameters and what it returns.  The API
support is there for it though.

  7. Various other more minor items.

Thoughts?

-- John

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: HDBC's future and request for help

Chris Dornan
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.

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?

I expect to be able to help out with this (and a CentOS HP) later in the year, provided I can resolve the license issue!

Cheers,

Chris

On 22 February 2011 16:50, John Goerzen <[hidden email]> wrote:
Hi folks,

HDBC has been out there for quite some time now.  I wrote it initially to meet some specific needs, and from that perspective, it has been done for awhile.  It is clear, however, that there are some needs it doesn't meet.  Most of them relate to specific backend driver items.

I'd like to start some discussion in the community about what the future of HDBC and its backend drivers ought to look like.  Some models might be:

 1. I continue as maintainer for HDBC and HDBC-{postgresql,odbc,sqlite3} and act as patch manager/gatekeeper for patches that are discussed on some public mailing list.

 2. Interested parties adopt the backend drivers while I continue to act as maintainer/patch manager/gatekeeper for HDBC itself.

 3. Interested parties adopt all of HDBC and maintain it

I am not expressing a particular preference for any of these options; just putting them forth.

Here are some of the current issues I am aware of:

 1. I have no Windows development platform.  I can't test the releases on Windows.  Many Windows users don't have the skill to diagnose problems.  These problems do eventually get fixed when a Windows user with that skill comes along -- and I appreciate their efforts very much! -- but it takes longer than it ought to.

 2. The ODBC documentation is monumentally terrible, and the API is perhaps only majestically terrible, and it is not 100% clear to me all the time that I have it right.  A seasoned ODBC person would be ideal here.

 3. Issues exist with transferring binary data and BLOBs to/from at least PostgreSQL databases and perhaps others.  There appear to be bugs in the backend for this, but BLOB support in the API may need to be developed as well.

 4. Although the API supports optimizations for inserting many rows at once and precompiled queries, most backends to not yet take advantage of these optimization.

 5. I have received dueling patches for whether foreign imports should be marked "safe" or "unsafe" on various backends.  There seems to be disagreement in the community about this one.

 6. Many interactions with database backends take place using a String when a more native type could be used for efficiency.  This project may be rather complex given varying types of column data in a database -- what it expects for bound parameters and what it returns.  The API support is there for it though.

 7. Various other more minor items.

Thoughts?

-- John

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: HDBC's future and request for help

John Goerzen-3
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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Possibility to implant Haskell GC into PostgreSQL interesting?

Doralicio
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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: HDBC's future and request for help

Chris Dornan
In reply to this post by John Goerzen-3
Re: [Haskell-cafe] HDBC's future and request for help

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:[hidden email]]
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


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: HDBC's future and request for help

Leon Smith-2
In reply to this post by John Goerzen-3
This seems a timely email,  as I've been submitting a steady-ish
trickle of patches to HDBC-postgresql lately.   Honestly,  I'm rather
dissatisfied with HDBC in many respects,   but I don't have a very
good idea of what a (low-level) database access library for Haskell
*should* be,  and I've found HDBC to be the least worst option
available at the moment.   HSQL doesn't support parameterized queries,
 making SQL injection issues tedious and error prone.    And while
Takusen looks rather interesting,  I find the documentation and
examples lacking,   I find the API a bit too esoteric for my current
tastes,  and I'm fairly certain that Takusen cannot possibly work for
my application due to the way Takusen reclaims connections.

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
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.

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.

Best,
Leon


On Tue, Feb 22, 2011 at 11:50 AM, John Goerzen <[hidden email]> wrote:

> Hi folks,
>
> HDBC has been out there for quite some time now.  I wrote it initially to
> meet some specific needs, and from that perspective, it has been done for
> awhile.  It is clear, however, that there are some needs it doesn't meet.
>  Most of them relate to specific backend driver items.
>
> I'd like to start some discussion in the community about what the future of
> HDBC and its backend drivers ought to look like.  Some models might be:
>
>  1. I continue as maintainer for HDBC and HDBC-{postgresql,odbc,sqlite3} and
> act as patch manager/gatekeeper for patches that are discussed on some
> public mailing list.
>
>  2. Interested parties adopt the backend drivers while I continue to act as
> maintainer/patch manager/gatekeeper for HDBC itself.
>
>  3. Interested parties adopt all of HDBC and maintain it
>
> I am not expressing a particular preference for any of these options; just
> putting them forth.
>
> Here are some of the current issues I am aware of:
>
>  1. I have no Windows development platform.  I can't test the releases on
> Windows.  Many Windows users don't have the skill to diagnose problems.
>  These problems do eventually get fixed when a Windows user with that skill
> comes along -- and I appreciate their efforts very much! -- but it takes
> longer than it ought to.
>
>  2. The ODBC documentation is monumentally terrible, and the API is perhaps
> only majestically terrible, and it is not 100% clear to me all the time that
> I have it right.  A seasoned ODBC person would be ideal here.
>
>  3. Issues exist with transferring binary data and BLOBs to/from at least
> PostgreSQL databases and perhaps others.  There appear to be bugs in the
> backend for this, but BLOB support in the API may need to be developed as
> well.
>
>  4. Although the API supports optimizations for inserting many rows at once
> and precompiled queries, most backends to not yet take advantage of these
> optimization.
>
>  5. I have received dueling patches for whether foreign imports should be
> marked "safe" or "unsafe" on various backends.  There seems to be
> disagreement in the community about this one.
>
>  6. Many interactions with database backends take place using a String when
> a more native type could be used for efficiency.  This project may be rather
> complex given varying types of column data in a database -- what it expects
> for bound parameters and what it returns.  The API support is there for it
> though.
>
>  7. Various other more minor items.
>
> Thoughts?
>
> -- John
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: HDBC's future and request for help

John Goerzen-3
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-HDBC.html#t:SqlValue 


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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: HDBC's future and request for help

John Goerzen-3
In reply to this post by Chris Dornan
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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: HDBC's future and request for help

Chris Dornan
Re: [Haskell-cafe] HDBC's future and request for help

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:[hidden email]]
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


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: HDBC's future and request for help

John Goerzen-3
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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: HDBC's future and request for help

Chris Dornan
Re: [Haskell-cafe] HDBC's future and request for help

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:[hidden email]]
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


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Possibility to implant Haskell GC into PostgreSQL interesting?

Leon Smith-2
In reply to this post by Doralicio
I'm not particularly familiar with the codebase of either PostgreSQL
or GHC,  but I'd be rather surprised that porting GHC's garbage
collector to PostgreSQL would be an easy or worthwhile task.   For
example,  GHC's garbage collector understands the memory layout that
its data structures use,  which I'm sure is rather different from the
memory layout of PostgreSQL's data structures.    Also,  often these
kinds of projects turn out to be busts;  for example,  the GHC team
worked on integrating Hugs into GHC for a while,  but after some
effort decided that it would be a lot easier to write an interpreter
from scratch instead,  which became ghci.

What would be far more likely to turn out to be realistic,  would be
to understand GHC's garbage collector and use (some of) it's ideas
when writing a replacement garbage collector for PostgreSQL.
However,  there is a lot of variation in garbage collectors because
different techniques are suited to different patterns of memory
allocation.   And based on the observation that PostgreSQL makes
reasonably effective usage of virtual memory,  whereas GHC's garbage
collector thrashes Virtual Memory,   I would bet there is a fair
number of important differences in the systems.

Best,
Leon

On Tue, Feb 22, 2011 at 7:25 PM, Nick Rudnick <[hidden email]> wrote:

> 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
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe