Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.

[Osamu Aoki <osamu@debian.org>]

Hi,

On Wed, May 30, 2012 at 12:20:21PM +0200, Mike Gabriel wrote:
> Hi,
> 
> On Mi 30 Mai 2012 11:21:18 CEST Bill Allombert wrote:
... 

Let's focus on topic: ITP = Intent_To_Package for libjpeg-turbo

> >Whether a package is correctly licensed is certainly relevant to an ITP.
> >libjpeg-turbo is released with a different license than libjpeg, so it is
> >not possible to port code from libjpeg-turbo to libjpeg. So you can see
> >why Guido consider libjpeg-turbo with some hostility.

Understanding hostility: YES. 
  (We are not discussing replacing libjpeg based packages with
  libjpeg-turbo based packages, now.  We are discussing providing
  alternative if and only if user wish to use it.  Practically at this
  point in release cycle, no sane person wish to replace such a basic
  package.  The only package using is  VirtualGL and TurboVNC and looks
  like they are statically linked.)

Agreeing licensing issue raised by libjpeg developer: NO.

As I understand, 
 * libjpeg-turbo is a derivative work based on libjpeg
 * libjpeg is BSD style license without the advertising clause
   requirement so making derivative work (including making a patchwork
   of codes) is explicitly allowed and it is GPL compatible.
 * libjpeg-turbo is said to have some lack of features but that can not
   be the base for rejecting ITP.
 * libjpeg-turbo is not presenting itself as libjpg.  README-turbo.txt
   clearly states:

|  libjpeg-turbo is a derivative of libjpeg which uses SIMD instructions (MMX,
|  SSE2, etc.) to accelerate baseline JPEG compression and decompression on x86
|  and x86-64 systems.  On such systems, libjpeg-turbo is generally 2-4x as fast
|  as the unmodified version of libjpeg, all else being equal.
|  
|  libjpeg-turbo was originally based on libjpeg/SIMD by Miyasaka Masaru, but
|  the TigerVNC and VirtualGL projects made numerous enhancements to the codec in
|  2009, including improved support for Mac OS X, 64-bit support, support for
|  32-bit and big endian pixel formats (RGBX, XBGR, etc.), accelerated Huffman
|  encoding/decoding, and various bug fixes.  The goal was to produce a fully open
|  source codec that could replace the partially closed source TurboJPEG/IPP codec
|  used by VirtualGL and TurboVNC.  libjpeg-turbo generally performs in the range
|  of 80-120% of TurboJPEG/IPP.  It is faster in some areas but slower in others.
|  
|  In early 2010, libjpeg-turbo spun off into its own independent project, with
|  the goal of making high-speed JPEG compression/decompression technology
|  available to a broader range of users and developers.  The libjpeg-turbo shared
|  libraries can be used as drop-in replacements for libjpeg on most systems.

The only thing one can think as problematic is the correctness of
statement "all else being equal" since libjpeg-turbo is said to have
dropped support for the arithmetic encoding scheme. We could ask
upstream to fix it by replacing it with "all else being practically
equal". (Or we can patch it when we distribute so no misrepresentation
claim can be used against this package.)  

I have not checked this claim of correctness myself, though. (Besides,
this does not hinder actual usefulness as long as ABI compatible for
other functions.)

As for "patent issues" discussed elsewhere, as usual with Debian, we do
not dig deep and package it.

http://www.debian.org/legal/patent

> Ok, the license mismatch is a bummer... 

I do not see the license mismatch like GPL/BSD incompatibility nor
anyone made any clear case of it.  Please be explicit on the problem.

> License issues surely are subject of an ITP. Agreed.

Since no license mismatch exists, packaging is allowed.

Regards,

Osamu