Re: alternative compression algorithms?

* Michael Paquier (michael(dot)paquier(at)gmail(dot)com) wrote:
> On Mon, Apr 20, 2015 at 5:51 AM, Tomas Vondra wrote:
> > I'm a bit confused though, because I've noticed various other FOSS projects
> > adopting lz4 over the past few years and I'm yet to find a project voicing
> > the same concerns about patents. So either they're reckless or we're
> > excessively paranoid.
>
> Both are true, now being very careful regarding software patents
> usually pays a lot. Strange things happen in the legal world.
>
> > Also, lz4 is not the only compression algorithm available - I've done a
> > bunch of tests with lz4, lz4hc, lzo and snappy, and lzo actually performed
> > better than lz4 (not claiming that's a universal truth). But I suppose that
> > the patent concerns are not somehow specific to lz4 but about the
> > compression in general.
>
> Some proprietary algorithms may perform even better and faster, who
> knows for sure? And even if for now lzo or lz4 are better, we may find
> something still better than what we think is now. In short, I still
> tend to think that the right answer would be to have a dedicated set
> of hooks and let people play with the compression algorithms they want
> (statement stands for FPW compression as well, but that's separate
> than the multivariate statistics patch).

I'm no lawyer, but I understand that one useful defense against patent
infringment lawsuits is to stop infringing on the patent (eg: stop doing
whatever it is the patent is about). Therefore, the best approach would
be exactly this- provide a way to swap out what the compression
algorithm is. One issue we'll need to consider is how to do that for
stored data, as you'd need to recompress everything. What that
basically means is we'll need to burn bits to indicate which compression
algorithm is used.

For my 2c, I suspect that's worth it as I expect the gains to be worth
those extra bits, in the general case, but I'm sure there will be cases
where it's a loss.

Thanks,

Stephen