Hi there. I am just now coming across this thread and thought I should
interject my take on the situation. I am not, under any circumstances,
intending to start or continue a holy war, and this will be the last
thing I have to say on the matter unless someone has a specific question
for me, but I do want to clarify a few things that may be relevant to
the discussions above:
(1) Regarding LJT being "obsolete" or "removing features":
libjpeg-turbo forked from libjpeg prior to the involvement of the
current libjpeg developers (Guido, et al.) Our code is most directly
based on the SIMD enhancements to jpeg-6b made by Miyasaka Masaru in
2006, which predate jpeg-7 by several years. We did not approach the
current IJG developers about our fork because, at the time, they were
not the current IJG developers. Originally, libjpeg-turbo was an
in-tree codec used by TigerVNC, mostly consisting of libjpeg/SIMD with
modifications from Cendio AB to support SSE2 instructions. In early
2009, Cendio AB contracted with me to add 64-bit SSE2 support and
accelerated Huffman coding, thus making our codec perform almost as fast
as commercial codecs like Intel IPP. Over the next year, other projects
got wind of our efforts, and significant demand arose for our codec to
be made into an independent project, which it was in early 2010. Even
though more general-purpose projects have adopted LJT in recent years,
our focus remains much narrower than that of the IJG. We are not trying
to be a reference implementation.
(2) Regarding license compatibility: At the time libjpeg-turbo became
an independent project, I released the libjpeg/SIMD code from TigerVNC
largely as-is. Thus, the TurboJPEG API wrapper and the Huffman codec
(which were borrowed from VirtualGL) were still licensed under the LGPL.
The Huffman codec license was easily worked around by dropping in
jchuff.c/jdhuff.c from an unmodified release of libjpeg v6b (Mozilla, in
fact, did this for quite a while), and the TurboJPEG wrapper was just a
convenience feature-- it wasn't essential to the functionality of the
codec. In any case, all of that code has been refactored in
libjpeg-turbo 1.2 and later. The Huffman codec now bears the same
license as libjpeg, and the TurboJPEG wrapper bears a less restrictive
3-clause BSD license. I believe this license to be compatible with the
libjpeg license, but if someone disagrees, then please let me know.
This refactoring project was paid for by a company and approved by the
company's lawyers, so we did a lot of due diligence on it. Not that the
IJG developers would ever want to, but I am not aware of any legal
issues that would prevent them from merging the LJT 1.2+ code back into
libjpeg. Parts of libjpeg-turbo 1.1.x and prior did fall under a
libjpeg-incompatible license-- because of expedience and because the
projects that initially needed to use libjpeg-turbo were all GPL or LGPL
anyway, so it didn't matter. However, the SIMD extensions that are
responsible for most of our speedup have always been released under a
libjpeg-compatible licence.
(3) Regarding hostility: I was not aware of any resentment toward our
project until Fedora started integrating LJT (not any of my doing, BTW--
Red Hat spearheaded the effort initially because they were integrating
TigerVNC) and Guido posted the following:
https://bugzilla.redhat.com/show_bug.cgi?id=639672#c7. This was long
before any claim that we were violating the libjpeg license. That claim
is a relatively new thing-- the first I heard about it was in the
jpeg-8d README file from early 2012. Back in 2010, the primary
objection seemed to be that we didn't ask permission to exist (as if we
needed to-- it's open source), but then the comment goes on to say that,
had we asked, it wouldn't have been granted. At the time that
conversation took place, the only code in LJT was from Tom Lane,
Miyasaka Masaru, Pierre Ossman, and myself. Tom Lane did not object to
LJT and, in fact, offered up words of support for our efforts:
http://lists.fedoraproject.org/pipermail/devel/2010-May/136976.html. In
a nutshell, practically from the moment our project split off from
TigerVNC, the new IJG started firing shots across our bow, and it became
clear that no matter what we did, we weren't going to make them happy.
Thus, our only choice was to do what we believed to be right. We
certainly could not be expected to seek their advice after being
publicly slandered.
(4) Regarding API compatibility: In late 2010, I merged part of the
jpeg-7 and jpeg-8 code into libjpeg-turbo in order to provide ABI
compatibility with jpeg-7 and jpeg-8, so projects that already ported to
jpeg-7 or jpeg-8 could take advantage of the SIMD extensions. A
commercial software developer paid me to implement the ABI compatibility
feature, and it is what it is. We do not claim that LJT is fully
compatible with jpeg-8. Specifically, the most recent code in trunk
lacks support for the SmartScale format and the features that depend on
that format. The open source community is not exactly scrambling for
SmartScale to be implemented in LJT-- and by that, I mean that there has
been zero demand for it. Mozilla and Chrome (which both use LJT) are
bellwethers, here-- if they decide that SmartScale is ubiquitous enough
to warrant their browsers decoding that format, then they'll ask us to
implement it. Note, however, that only two browsers (Chrome and
Firefox) use libjpeg-turbo, but they are hardly the only software that
doesn't support SmartScale files. Safari and IE won't parse those web
sites that Guido posted, either.
(5) Regarding arithmetic coding: libjpeg-turbo does support arithmetic
encoding/decoding, and those features are enabled by default when
building the code with jpeg-7 and jpeg-8 ABI emulation. They can
optionally be enabled when building the code with jpeg-6b ABI emulation.
There is no technical reason why Mozilla, Chrome, and any other
software that uses libjpeg-turbo can't encode/decode arithmetic images.
The developers of those browsers have simply chosen not to enable the
feature (https://bugzilla.mozilla.org/show_bug.cgi?id=680385). Their
reasoning seems to be that other browsers, such as IE and Safari (which
don't use libjpeg-turbo) can't decode arithmetic coded JPEGs, so there
is no reason for Firefox and Chrome to do so. You can agree or disagree
with their reasoning, but either way, don't blame us.
(6) Regarding the README file: In the process of merging part of the
jpeg-7 and jpeg-8 code in order to provide ABI compatibility, I also
merged some of the jpeg-7 and jpeg-8 documentation, in order to describe
the subset of jpeg-7 and jpeg-8 features that were implemented. I did
not merge all of the upstream README file, because frankly, that file in
jpeg-7 and jpeg-8 includes some very impolitic language that slams the
ISO committee as well as the authors of one of the definitive books on
the JPEG format. If IJG wants us to include more of the text from their
README file, then they need to rewrite it to be more balanced. And, of
course, the README file in jpeg-8d slams our project as well, so we can
hardly be expected to include that text. We have clearly indicated at
the top of our modified README file that it was modified. The libjpeg
license says that the copyright and no warranty notice from the README
must be unaltered, but it doesn't say that the README must be included
verbatim. I included the relevant text that describes the subset of
libjpeg that we implement. If, however, there are specific
modifications that can be made to our README to make it less
"misleading" in the eyes of the IJG, then I'm happy to do that, as long
as those modifications do not include adding inflammatory text.
(7) Regarding the copyright headers: If there are objections to the way
in which we have modified the copyright headers of specific files, then
I am happy to change that (Osamu's suggestion above makes sense.) We
were following what is generally considered common practice for open
source code, which is to add one's own copyright message to the existing
headers, and we are far from the only people who have done that with
libjpeg. You can understand why there's a bit of a quandary in the case
of libjpeg. It is generally considered very bad practice to alter a
copyright notice in an open source file, but the copyright notices in
libjpeg also say "This file is part of the Independent JPEG Group's
Software." I agree that someone reading that file might be given the
wrong impression, but it's hard to tell which is the bigger sin:
leaving that ambiguity or altering the copyright header. Ultimately, we
opted to keep the headers in tact and include a README-turbo.txt file
that makes it clear that libjpeg-turbo is not libjpeg. This was not
sloppiness and definitely not malice. We thought all of these issues
through and did what we believed to be best. If, at any point, the IJG
had raised objections to us (in a more political manner than blasting us
in its README file, that is), we would have happily made whatever header
modifications they proposed.
(8) Regarding Wikipedia: We are not in control of the libjpeg Wikipedia
page, nor did we add the libjpeg-turbo blurb to that page. I stumbled
upon the page after someone else had added a blurb about libjpeg-turbo
to it. Their blurb actually slammed IJG a bit, so I edited it so that
it took a more balanced tone. I also corrected a couple of factual
errors about libjpeg-turbo. You can easily verify what I changed by
looking at the Wikipedia history. I've made exactly 3 modifications to
the page, none of them outside the scope of the libjpeg-turbo blurb that
was already there.
If there are any further issues with libjpeg-turbo, I am more than happy
to address them. libjpeg-turbo exists solely because people in the
community wanted it. I will not apologize for the success of our codec.
I have never done anything other than attempt to meet the demands of
the open source community, and libjpeg-turbo is thus a product of that
community.
DRC
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50e0d7a6.8080...@users.sourceforge.net
