In various places in the repository, there are mentions of LGPL, WxWindow and
BSD licenses. Also there seems to be similarly-named (but different) products
: libjpeg-turbo, turbojpeg/oss, libturbojpeg, ...? All of them apparently
sharing source code in the same folder.
I just want to know if I can use this as a drop-in replacement statically-
linked libjpeg in my project, without having to redistribute things around
(it's a mobile app, I won't bundle this project's source code in the package).
Could you clarify?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
README-turbo.txt explains a bit about the licenses, and I will explain more
here.
With libjpeg-turbo 1.1.x and earlier, it's easier if you think of the entire
code as licensed under one license: the wxWindows Library License, which is a
derivative of the LGPL. You might think of the wxWindows Library License as
the "Lesser Lesser GNU Public License", as it basically takes the LGPL v2.1
and nullifies Sections 6 and 7. Per LGPL Section 4, if you distribute an
executable that links (statically) with libjpeg-turbo, then you are required
to distribute source for libjpeg-turbo, including any modifications you've
made to it (or make a written offer for same, or simply make the source
available on the same web site from which the executable is downloaded.) The
full-blown LGPL would additionally require you to distribute unlinked object
files for any routines in your executable that are not open source, and it
would require you to license the executable in such a way that reverse
engineering was permitted. Thus, you can think of the LGPL as being strongly
viral at the source level and weakly viral at the binary level (whereas the
GPL is strongly viral at both source and binary levels.) The wxWindows Library
License, OTOH, is strongly viral at the source level and non-viral at the
binary level. It places no restrictions on what you do with your binaries, as
long as you accompany them with the libjpeg-turbo library source that was used
to build them.
That's the "letter of the law", as it were. The "spirit of the law" is making
sure that modifications to the library source code are contributed back to the
community. From my point of view, as long as you are building from an
unmodified version of libjpeg-turbo, I don't care whether you distribute the
source for it or not.
A bit of history is helpful in understanding how things got to be the way they
are. libjpeg-turbo sprung from the TigerVNC Project originally. We took
libjpeg/SIMD into our code base and made extensive modifications to it to add
64-bit support and other features/fixes. I then ported Huffman coding
optimizations that were part of the VirtualGL source code. These sped up
libjpeg-turbo by about 20-25%. These optimizations bore the wxWindows Library
License (VirtualGL's license), but since TigerVNC is GPL-licensed, it didn't
matter what license was used as long as it was GPL-compatible (the most
restrictive license-- the GPL, in that case-- is the one that applies to the
code as a whole.)
Eventually, the libjpeg/SIMD codec in TigerVNC matured enough to where it drew
the attention of other projects and also became a suitable codec for use in my
other projects, VirtualGL and TurboVNC. I decided to split the codec into a
separate project (what is now libjpeg-turbo) so it could easily be used
outside of TigerVNC. This is where TurboJPEG comes in. TurboJPEG is a wrapper
used by VirtualGL and TurboVNC to abstract a variety of JPEG codec APIs:
TurboJPEG/OSS wraps libjpeg, TurboJPEG/IPP wraps the Intel Performance
Primitives, TurboJPEG/mediaLib wraps Sun mediaLib, and there used to be
versions for other technologies as well, such as QuickTime. TurboJPEG/OSS was
merged into the libjpeg-turbo source tree so I could provide an SDK based on
libjpeg-turbo that was ABI and API-compatible with the legacy (and now
obsolete) TurboJPEG/IPP SDK, while still giving users the option to build or
run with the legacy SDK as a transitional step. TurboJPEG/OSS also bears the
wxWindows Library License, since it came from VirtualGL. However, since
merging TurboJPEG/OSS into libjpeg-turbo, it has taken on a life of its own,
and several other projects are now using this API. It now exposes some
features, such as direct encoding to/decoding to YUV planar images, that would
be difficult to implement with the raw libjpeg API, and it provides an easy
way of doing memory encoding/decoding of JPEG images, which is important for
rapid prototyping.
So, with regards to the names:
libjpeg-turbo (which is named libjpeg.a or libjpeg.so or libjpeg.dylib on Unix
systems) provides the basic libjpeg-compatible API/ABI
TurboJPEG/OSS (which is named libturbojpeg.a or libturbojpeg.so or
libturbojpeg.dylib on Unix systems) wraps libjpeg-turbo and provides an easy-
to-use interface for in-memory JPEG encoding/decoding and generating planar
YUV images.
Now, here's the wrinkle. You may notice that, in the subversion trunk, the
libjpeg-turbo library is no longer considered to be under the wxWindows
Library License. That's because I rewrote and re-licensed the accelerated
Huffman encoding/decoding routines that had been ported from VirtualGL. Thus,
if you were building against a version of libjpeg built from the subversion
trunk, the wxWindows Library License would not apply. It would only apply if
you statically linked with TurboJPEG/OSS.
I would like to look at re-writing and re-licensing TurboJPEG/OSS in libjpeg-
turbo 1.2 to eliminate confusion. This would require a lot of work, though,
and it's difficult to give it priority when it is an unfunded effort.
In summary, I apologize for the confusion, and I'm taking steps to address it,
but it's an evolutionary process, because there are historical reasons why
things are as they are.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was able to secure funding for re-licensing the code in subversion trunk
(which will eventually become libjpeg-turbo 1.2.) trunk should all fall under
a BSD-style license now. Note that this is still undergoing legal review. The
process of re-licensing involved re-factoring to eliminate the code that was
borrowed from VirtualGL. Since some of that code was written by me while
working for my previous employers, we're doing due diligence to ensure that
none of that legacy code-- or anything that could be considered a derivative
of it-- remains.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry to reply to such an old thread, but I need some help to clarify the intent of the wording in README-turbo.txt, in particular the use of the term "Most of" in this part
Most of libjpeg-turbo inherits the non-restrictive, BSD-style license used by
libjpeg (see README.) The TurboJPEG wrapper (both C and Java versions) and
associated test programs bear a similar license, which is reproduced below:
Am I correct in saying that all of the subversion source distributions for libjpeg-turbo since 1.2 are now covered by two licenses? So we have
The license in README that covers the majority of the code.
The license in README-turbo.txt that covers all of the remainder.
The use of the term "Most of" is causing some pain because it can be read as saying that the combination of the licenses in README & README-turbo.txt cover only a sub-set of the total code and there is some other unnamed licence that covers the remainder.
cheers
Paul
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
In various places in the repository, there are mentions of LGPL, WxWindow and
BSD licenses. Also there seems to be similarly-named (but different) products
: libjpeg-turbo, turbojpeg/oss, libturbojpeg, ...? All of them apparently
sharing source code in the same folder.
I just want to know if I can use this as a drop-in replacement statically-
linked libjpeg in my project, without having to redistribute things around
(it's a mobile app, I won't bundle this project's source code in the package).
Could you clarify?
README-turbo.txt explains a bit about the licenses, and I will explain more
here.
With libjpeg-turbo 1.1.x and earlier, it's easier if you think of the entire
code as licensed under one license: the wxWindows Library License, which is a
derivative of the LGPL. You might think of the wxWindows Library License as
the "Lesser Lesser GNU Public License", as it basically takes the LGPL v2.1
and nullifies Sections 6 and 7. Per LGPL Section 4, if you distribute an
executable that links (statically) with libjpeg-turbo, then you are required
to distribute source for libjpeg-turbo, including any modifications you've
made to it (or make a written offer for same, or simply make the source
available on the same web site from which the executable is downloaded.) The
full-blown LGPL would additionally require you to distribute unlinked object
files for any routines in your executable that are not open source, and it
would require you to license the executable in such a way that reverse
engineering was permitted. Thus, you can think of the LGPL as being strongly
viral at the source level and weakly viral at the binary level (whereas the
GPL is strongly viral at both source and binary levels.) The wxWindows Library
License, OTOH, is strongly viral at the source level and non-viral at the
binary level. It places no restrictions on what you do with your binaries, as
long as you accompany them with the libjpeg-turbo library source that was used
to build them.
That's the "letter of the law", as it were. The "spirit of the law" is making
sure that modifications to the library source code are contributed back to the
community. From my point of view, as long as you are building from an
unmodified version of libjpeg-turbo, I don't care whether you distribute the
source for it or not.
A bit of history is helpful in understanding how things got to be the way they
are. libjpeg-turbo sprung from the TigerVNC Project originally. We took
libjpeg/SIMD into our code base and made extensive modifications to it to add
64-bit support and other features/fixes. I then ported Huffman coding
optimizations that were part of the VirtualGL source code. These sped up
libjpeg-turbo by about 20-25%. These optimizations bore the wxWindows Library
License (VirtualGL's license), but since TigerVNC is GPL-licensed, it didn't
matter what license was used as long as it was GPL-compatible (the most
restrictive license-- the GPL, in that case-- is the one that applies to the
code as a whole.)
Eventually, the libjpeg/SIMD codec in TigerVNC matured enough to where it drew
the attention of other projects and also became a suitable codec for use in my
other projects, VirtualGL and TurboVNC. I decided to split the codec into a
separate project (what is now libjpeg-turbo) so it could easily be used
outside of TigerVNC. This is where TurboJPEG comes in. TurboJPEG is a wrapper
used by VirtualGL and TurboVNC to abstract a variety of JPEG codec APIs:
TurboJPEG/OSS wraps libjpeg, TurboJPEG/IPP wraps the Intel Performance
Primitives, TurboJPEG/mediaLib wraps Sun mediaLib, and there used to be
versions for other technologies as well, such as QuickTime. TurboJPEG/OSS was
merged into the libjpeg-turbo source tree so I could provide an SDK based on
libjpeg-turbo that was ABI and API-compatible with the legacy (and now
obsolete) TurboJPEG/IPP SDK, while still giving users the option to build or
run with the legacy SDK as a transitional step. TurboJPEG/OSS also bears the
wxWindows Library License, since it came from VirtualGL. However, since
merging TurboJPEG/OSS into libjpeg-turbo, it has taken on a life of its own,
and several other projects are now using this API. It now exposes some
features, such as direct encoding to/decoding to YUV planar images, that would
be difficult to implement with the raw libjpeg API, and it provides an easy
way of doing memory encoding/decoding of JPEG images, which is important for
rapid prototyping.
So, with regards to the names:
libjpeg-turbo (which is named libjpeg.a or libjpeg.so or libjpeg.dylib on Unix
systems) provides the basic libjpeg-compatible API/ABI
TurboJPEG/OSS (which is named libturbojpeg.a or libturbojpeg.so or
libturbojpeg.dylib on Unix systems) wraps libjpeg-turbo and provides an easy-
to-use interface for in-memory JPEG encoding/decoding and generating planar
YUV images.
Now, here's the wrinkle. You may notice that, in the subversion trunk, the
libjpeg-turbo library is no longer considered to be under the wxWindows
Library License. That's because I rewrote and re-licensed the accelerated
Huffman encoding/decoding routines that had been ported from VirtualGL. Thus,
if you were building against a version of libjpeg built from the subversion
trunk, the wxWindows Library License would not apply. It would only apply if
you statically linked with TurboJPEG/OSS.
I would like to look at re-writing and re-licensing TurboJPEG/OSS in libjpeg-
turbo 1.2 to eliminate confusion. This would require a lot of work, though,
and it's difficult to give it priority when it is an unfunded effort.
In summary, I apologize for the confusion, and I'm taking steps to address it,
but it's an evolutionary process, because there are historical reasons why
things are as they are.
I was able to secure funding for re-licensing the code in subversion trunk
(which will eventually become libjpeg-turbo 1.2.) trunk should all fall under
a BSD-style license now. Note that this is still undergoing legal review. The
process of re-licensing involved re-factoring to eliminate the code that was
borrowed from VirtualGL. Since some of that code was written by me while
working for my previous employers, we're doing due diligence to ensure that
none of that legacy code-- or anything that could be considered a derivative
of it-- remains.
Sorry to reply to such an old thread, but I need some help to clarify the intent of the wording in README-turbo.txt, in particular the use of the term "Most of" in this part
Am I correct in saying that all of the subversion source distributions for libjpeg-turbo since 1.2 are now covered by two licenses? So we have
The use of the term "Most of" is causing some pain because it can be read as saying that the combination of the licenses in README & README-turbo.txt cover only a sub-set of the total code and there is some other unnamed licence that covers the remainder.
cheers
Paul
http://www.libjpeg-turbo.org/About/License
has a more comprehensive explanation of the licenses.
Brilliant, thank you!
Hope that is enough to keep the legal people happy.
Paul