Toshio Kuratomi <a.badger@xxxxxxxxx> writes: > The issue would be that it's a fork. So libjpeg from the independent jpeg > group and libjpeg-turbo can gain incompatible API in isolation from each > other. (The situtation seems a bit complex, there's three projects that > I can see working on libjpeg: > * libjpeg.sf.net -- working on API compatible updates to libjpeg-6b > * independent jpeg group (one person?) -- working on jpeg-8b and beyond > * libjpeg-turbo -- seems to be based on libjpeg-6b has speedups on modern > x86 (w/SSE), licensed under the wxwindows license instead of BSD due to > using code from that project. (according to the README in libjpeg-turbo, > wxwindows license is a less restrictive form of the LGPL -- it allows > static linking without the resulting work having to take on the LGPL > license.) > tgl, is this your understanding of the separate projects as well? [ sorry for slow response ] libjpeg-turbo is news to me, but as far as the other two go: * the sf.net project was started to produce ABI-compatible updates of libjpeg 6b, but I'm beginning to despair of ever seeing a release from them. * libjpeg7/8/etc is pretty much one person, and I'm not terribly happy with the direction that that's going either. Guido doesn't seem to be very concerned with even file-level compatibility, let alone source-code compatibility (libjpeg7 is known to have broken multiple dependent packages), and he's also not worrying much about patent issues. The move to add arithmetic-coding support seems a bad idea on at least two of those grounds, and it doesn't even buy that much in file size. I suppose this is all my fault for having let libjpeg languish for so many years, but that's water under the bridge now. If the libjpeg-turbo group is doing active development and is taking care not to break things unnecessarily, I'm happy to see them become the forefront of libjpeg development. Especially if it means I don't have to do the work ;-) regards, tom lane ex-organizer, Independent JPEG Group -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
