* Michael Paquier (michael.paqu...@gmail.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
signature.asc
Description: Digital signature