From: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Douglas McNaught <doug(at)mcnaught(dot)org>, "Stephen R(dot) van den Berg" <srb(at)cuci(dot)nl>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, lar(at)quicklz(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: QuickLZ compression algorithm (Re: Inclusion in the PostgreSQL backend for toasting rows) |
Date: | 2009-01-05 17:43:23 |
Message-ID: | 496246BB.6060609@kaltenbrunner.cc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan wrote:
>
>
> Douglas McNaught wrote:
>> On Mon, Jan 5, 2009 at 3:18 AM, Stephen R. van den Berg <srb(at)cuci(dot)nl>
>> wrote:
>>
>>> I'm not speaking for Lasse, merely providing food for thought, but it
>>> sounds
>>> feasible to me (and conforming to Lasse's spirit of his intended
>>> license)
>>> to put something like the following license on his code, which would
>>> allow
>>> inclusion into the PostgreSQL codebase and not restrict usage in any
>>> of the derived works:
>>>
>>> "Grant license to use the code in question without cost, provided that
>>> the code is being linked to at least 50% of the PostgreSQL code it is
>>> being distributed alongside with."
>>>
>>> This should allow commercial reuse in derived products without
>>> undesirable
>>> sideeffects.
>>>
>>
>> I think Postgres becomes non-DFSG-free if this is done. All of a
>> sudden one can't pull arbitrary pieces of code out of PG and use them
>> in other projects (which I'd argue is the intent if not the letter of
>> the DFSG). Have we ever allowed code in on these terms before? Are
>> we willing to be dropped from Debian and possibly Red Hat if this is
>> the case?
>>
>>
>>
>
> Presumably a clean room implementation of this algorithm would get us
> over these hurdles, if anyone wants to undertake it.
>
> I certainly agree that we don't want arbitrary bits of our code to be
> encumbered or licensed differently from the rest.
do we actually have any numbers that quicklz is actually faster and/or
compresses better than what we have now?
Stefan
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-01-05 18:04:14 | Re: QuickLZ compression algorithm (Re: Inclusion in the PostgreSQL backend for toasting rows) |
Previous Message | Andrew Dunstan | 2009-01-05 17:40:36 | Re: QuickLZ compression algorithm (Re: Inclusion in the PostgreSQL backend for toasting rows) |