Return-Path: <tiff-bounces@lists.maptools.org>
Received: from inas006.isp.belgacom.be (localhost [127.0.0.1])
        by inav015.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-AV-3.00) with ESMTP id kAPAh16Z010854
        for <joris.at.lebbeke@skynet.be>; Sat, 25 Nov 2006 11:43:01 +0100
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from inmx007.isp.belgacom.be (inmx007.isp.belgacom.be [195.238.5.89])
        by inas006.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-AS-2.03) with ESMTP id kAPAgthZ004252
        for <joris.at.lebbeke@skynet.be>; Sat, 25 Nov 2006 11:42:55 +0100
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from duke.maptools.org (r153.dmsolutions.ca [209.217.116.153] (may be forged))
        by inmx007.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-2.32) with ESMTP id kAPAgjYT026982
        for <joris.at.lebbeke@skynet.be>; Sat, 25 Nov 2006 11:42:46 +0100
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from duke.maptools.org (duke.maptools.org [127.0.0.1])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id kAPAXHLZ026640;
	Sat, 25 Nov 2006 05:34:14 -0500
Received: from cgp.spb.edu (vlan3.cgp.spb.edu [195.70.196.207])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id kAPAX4CG026635
	for <tiff@lists.maptools.org>; Sat, 25 Nov 2006 05:33:04 -0500
Received: from wg.pu.ru ([193.124.85.219] verified)
	by cgp.spb.edu (CommuniGate Pro SMTP 5.0.12)
	with ESMTP id 49829486 for tiff@lists.maptools.org;
	Sat, 25 Nov 2006 13:32:10 +0300
Received: (from uucp@localhost)
	by wg.pu.ru (8.9.1a/8.9.1) with UUCP id KAA14690
	for tiff@lists.maptools.org; Sat, 25 Nov 2006 10:33:03 GMT
Received: from ak4719.spb.edu (localhost.localdomain [127.0.0.1])
	by ak4719.spb.edu (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	kAPAKa0a001760
	for <tiff@lists.maptools.org>; Sat, 25 Nov 2006 13:20:37 +0300
Received: (from dron@localhost)
	by ak4719.spb.edu (8.13.4/8.13.4/Submit) id kAPAKaTR001759
	for tiff@lists.maptools.org; Sat, 25 Nov 2006 13:20:36 +0300
From: Andrey Kiselev <dron@ak4719.spb.edu>
Date: Sat, 25 Nov 2006 13:20:36 +0300
To: tiff@lists.maptools.org
Subject: Re: [Tiff] Windows HD Photo - any interest?
Message-ID: <20061125102036.GA1604@ak4719.spb.edu>
Mail-Followup-To: tiff@lists.maptools.org
References: <200611242123.29432.bradh@frogmouth.net>
	<20061124160254.GB28777@ak4719.spb.edu>
	<200611250853.25499.bradh@frogmouth.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200611250853.25499.bradh@frogmouth.net>
X-GnuPG-Key: http://www.srces.spb.org/dron/export.home.key
X-Face: "t+se9s~+y~[XUH]L|pmeO3Pt/Q@DNv**S, d@_1-C=}/,
	c%<3Qp]eu!ok<"2lYJm$!9qVcg F?7o*L; |$`6|Q|>Rt-cU%2_y@6tQ|`!Li}TsvZvEKx;
	>fuY=fc(=sX^`7Wmw8%SsR`AvM$a; 0U/eN\ P?B\FTyqD, 0np$U2!*'z_4D,
	VPlFf?bN0&zYf"zF0s!7Tl7?$we)xD0@lL>[h|8bhys0i.g|zLnu@C
	Ti@d]i=[!:j1CB\5/TF[m]`lfHfaqSN[0qn@T3zeosV/[LAss{@p_?],x*j8P_9t[}uHD^X-;
	j~\M! gyTly;fj`}&Y~i{<#bN.#QmkE}#T`dxP.I1\.)_MEN{@#W
User-Agent: Mutt/1.5.9i
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=subscribe>
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org
X-UIDL: 000000000023ceae.00001da7
X-MSP-STORE: Sat, 25 Nov 2006 11:43:04 +0100
Status: RO

Brad,

On Sat, Nov 25, 2006 at 08:53:20AM +1100, Brad Hards wrote:
> > But the codec implementation supplied with this Kit is effectively
> > non-free. It is not compatible neither with libtiff license terms
> > nor with other popular free software licenses. I hope that it is
> > possible to use documentation to do  independent implementation:
> I would also like to see an independent implementation (and I think
> there might be enough information to do one given the Bitstream
> specification in the DPK), however I'm not sure why you think the
> current codec is incompatible with the libtiff license terms.
> Certainly I would agree it might not be compatible with the GPL, but
> my reading of the libtiff license says that as long as the codec is
> generally released (i.e. no licensing fees) then it could be
> incorporated into libtiff.
> 
> This is not to say I am sure - I think it is ambiguous.
> 
> > "1. You may review these Materials only (a) as a reference to assist
> > You in planning and designing Your product, service or technology
> > ("Product") to interface with a Microsoft product, specification,
> > service or technology ("Microsoft Product") as described in these
> > Materials; and (b) to provide feedback on these Materials to
> > Microsoft.  All other rights are retained by Microsoft; this
> > Agreement does not give You rights under any Microsoft patents."
> I don't think that any of this says that the codec couldn't be used in
> libtiff. Probably worth a clarification though.

The excerpt I cited here is from documentation license. I cited it to be
sure that we can read documentation to implement alternative solution.
But the code itself covered by the separate EULA which contains many
statements unsuitable for us. Of course we have an option to not
integrate codec into libtiff and allow users to link it in form of
separate library (as in case of libjpeg and zlib).

> > Anyway, it is out of scope for libtiff at the moment.
> I don't understand this part either. If you consider HD Photo to just
> be a different version of TIFF, how does it differ from BigTIFF? [This
> really is a question, not an argument to say that it should be in
> scope - I'm just trying to understand your thinking].

Well, personally I think that we still not know what benefit we can get
with that new format. If their codec really works faster and compress
better than other TIFF codecs it is worth to look into this problem.
Also there are no files in such format "in the wild" and I can't predict
when they start arriving, so why bother? Finally, I do not like the fact
that this new format is not TIFF, and tag numbers will be assigned by MS
and if we will decide to implement complete support for that format we
need one more tag namespace, and that needs a lot of work. The most
important tasks for libtiff development are BigTIFF and proper custom
IFD support, we even do not have a time to complete these ones.

Anyway, that should not stop discussion.

Best regards,
Andrey

-- 
Andrey V. Kiselev
ICQ# 26871517
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
