Return-Path: <tiff-bounces@remotesensing.org>
Received: from inmx008.isp.belgacom.be (inmx008.isp.belgacom.be [195.238.3.88])
        by mailst006.isp.belgacom.be (8.12.11/8.12.11/Skynet-MAILSTORE-2.14) with ESMTP id i6AHW0p5015306
        for <joris.at.lebbeke@skynet.be>; Sat, 10 Jul 2004 19:32:00 +0200
        (envelope-from <tiff-bounces@remotesensing.org>)
Received: from xserve.flids.com (adsl-065-083-169-202.sip.mco.bellsouth.net [65.83.169.202])
        by inmx008.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id i6AHVooa030393
        for <joris.at.lebbeke@skynet.be>; Sat, 10 Jul 2004 19:31:52 +0200
        (envelope-from <tiff-bounces@remotesensing.org>)
Received: from adsl-065-083-169-202.sip.mco.bellsouth.net (localhost [127.0.0.1])
	by xserve.flids.com (Postfix) with ESMTP
	id 8C97B1184B5; Sat, 10 Jul 2004 13:31:32 -0400 (EDT)
X-Original-To: tiff@remotesensing.org
Delivered-To: tiff@remotesensing.org
Received: from lakermmtao02.cox.net (lakermmtao02.cox.net [68.230.240.37])
	by xserve.flids.com (Postfix) with ESMTP id DD9B8118491
	for <tiff@remotesensing.org>; Sat, 10 Jul 2004 13:31:29 -0400 (EDT)
Received: from gwendolyn.in.ql.org ([68.100.32.28]) by lakermmtao02.cox.net
	(InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP
	id <20040710173129.CPSQ923.lakermmtao02.cox.net@gwendolyn.in.ql.org>;
	Sat, 10 Jul 2004 13:31:29 -0400
Received: from potamus.in.ql.org (dhcp-7.in.ql.org [10.160.59.135])
	by gwendolyn.in.ql.org (8.12.11/8.12.11/Debian-1) with ESMTP id
	i6AHVSLd004571; Sat, 10 Jul 2004 13:31:28 -0400
Received: from potamus.in.ql.org (localhost [127.0.0.1])
	by potamus.in.ql.org (8.12.11/8.12.11/Debian-5) with ESMTP id
	i6AHVktN003015; Sat, 10 Jul 2004 17:31:46 GMT
Received: (from ejb@localhost)
	by potamus.in.ql.org (8.12.11/8.12.11/Debian-5) id i6AHVkug003010;
	Sat, 10 Jul 2004 17:31:46 GMT
Date: Sat, 10 Jul 2004 17:31:46 GMT
From: Jay Berkenbilt <ejb@ql.org>
To: warmerdam@pobox.com
In-reply-to: <40F01573.8070200@pobox.com> (warmerdam@pobox.com)
Subject: Re: [Tiff] LZW and libtiff
References: <Pine.SOC.4.60.0407081812530.845@blade.simplesystems.org>
	<20040709034341.GA3749@ak4719.spb.edu> <40F01573.8070200@pobox.com>
Message-ID: <20040710133141.0188872159.qww314159@potamus.in.ql.org>
Cc: tiff@remotesensing.org
X-BeenThere: tiff@remotesensing.org
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: TIFF and libtiff discussion  <tiff.remotesensing.org>
List-Unsubscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=unsubscribe>
List-Archive: <http://xserve.flids.com/pipermail/tiff>
List-Post: <mailto:tiff@remotesensing.org>
List-Help: <mailto:tiff-request@remotesensing.org?subject=help>
List-Subscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=subscribe>
Sender: tiff-bounces@remotesensing.org
Errors-To: tiff-bounces@remotesensing.org
X-UIDL: 64760561c69b2a95b72dac25f8891fd8


>   Andrey Kiselev wrote:
>   > On Thu, Jul 08, 2004 at 06:14:18PM -0500, Bob Friesenhahn wrote:
>   >
>   >>Now that the Unisys LZW patent has expired world-wide (as of
>   >>yesterday), what is libtiff's position on including LZW support in
>   >>libtiff?  If source for LZW is included by default, will support for
>   >>LZW be enabled by default in libtiff?
>   >
>   >
>   > I can merge LZW code back to the main trunk, if nobody can't give a
>   > reason not to do that. It is not an issue for me, because there are no
>   > software patents in my country, but LZW code was separated to help users
>   > to avoid problems in their countries, so if someone has opinions against
>   > LZW, please, tell us.
>   >
>   > All libtiff codecs and features are enabled by default, and LZW will do
>   > after inclusion.

This topic was lightly discussed in the context of GIF on the
debian-legal mailing list.  See this message and its references and
follow-ups:

http://lists.debian.org/debian-legal/2004/07/msg00091.html

If there was a consensus, it seems to be that it's okay to consider
the LZW patent over since IBM never enforced their patent.  One person
also states that the patent is actually for a related but different
algorithm (LZMW) which, like LZW, is an LZ78 derivative.

The site burnallgifs.org also now starts with, "GIFs are now
patent-free, but you can learn from the GIF fiasco and protect the
digital information you create from patent attacks."

Apparently, the GD Graphics Library is going to be reactivating GIF
write support shortly. (http://www.boutell.com/gd/)

ImageMagick also appears to be re-enabling LZW by default
(http://studio.imagemagick.org/magick/viewtopic.php?p=192) though it's
hard to say for sure since this announcement is old.

Most of the discussions I've seen about this topic are about GIF.
People seem to forget about LZW compression in TIFF.  This is
important as it is the best non-lossy compression algorithm supported
by virtually all TIFF readers.  (Deflate is not as widely supported,
JPEG is lossy.)  But of course everyone here knows that already.

The League for programming freedom also seems to think that the LZW
patent has really expired (http://lpf.ai.mit.edu/Patents/Gif/Gif.html)
and doesn't mention the IBM patent at all.

I'm not a lawyer, but there does seem to be a preponderance of
evidence that it would be safe to consider the LZW patent issue over
and include it by default in libtiff once again.

If this happens, what is the schedule for the first release that will
include it?  Will there be a new 3.6 release with it, or will we wait
for 3.7.0 for a non-alpha release that includes LZW by default?  (I
know, that's not really a fair question.)

-- 
Jay Berkenbilt <ejb@ql.org>
http://www.ql.org/q/
_______________________________________________
Tiff mailing list
Tiff@remotesensing.org
http://xserve.flids.com/mailman/listinfo/tiff
