Return-Path: <tiff-bounces@lists.maptools.org>
Received: from mailgate002.isp.belgacom.be (mailgate002.isp.belgacom.be [195.238.6.87])
        by maildelivery013.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-2.32) with ESMTP id l6GBx4Hj023803
        for <joris.at.lebbeke@skynet.be>; Mon, 16 Jul 2007 13:59:05 +0200
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from r153.dmsolutions.ca (HELO duke.maptools.org) ([209.217.116.153])
  by in.mx.skynet.be with ESMTP; 16 Jul 2007 13:59:05 +0200
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 l6GBnM8M019542;
	Mon, 16 Jul 2007 07:49:33 -0400
Received: from homer.shelbyville.oz
	(ppp121-45-10-193.lns10.adl2.internode.on.net [121.45.10.193])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id l6GBnEvk019538
	for <tiff@lists.maptools.org>; Mon, 16 Jul 2007 07:49:14 -0400
Received: from ron by homer.shelbyville.oz with local (Exim 4.67)
	(envelope-from <ron@debian.org>) id 1IAPGK-0002ue-QZ
	for tiff@lists.maptools.org; Mon, 16 Jul 2007 21:31:12 +0930
Date: Mon, 16 Jul 2007 21:31:12 +0930
From: Ron <ron@debian.org>
To: tiff@lists.maptools.org
Subject: Re: [Tiff] [ANNOUNCE]: Libtiff 4.0.0alpha released
Message-ID: <20070716120112.GA10025@homer.shelbyville.oz>
References: <Pine.SOC.4.60.0707141917480.922@blade.simplesystems.org>
	<03c401c7c788$4d1cc800$da60fea9@EKAT>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <03c401c7c788$4d1cc800$da60fea9@EKAT>
User-Agent: Mutt/1.5.16 (2007-06-11)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: ron@debian.org
X-SA-Exim-Scanned: No (on homer.shelbyville.oz);
	SAEximRunCond expanded to false
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.00002631
X-MSP-STORE: Mon, 16 Jul 2007 13:59:14 +0200
Status:   

On Mon, Jul 16, 2007 at 10:04:20AM +0100, Andy Cave wrote:
> So what happens if someone builds a standalone piece of s/w 
> (tiffjbigdecomp) that reads (compressed) data from stdin and writes 
> (uncompressed) data to stdout. They can then write s/w that execs a 
> sub-process, redirecting stdin/stdout to be a file on disk and a pipe, and 
> then just read the decompressed data from the pipe. Does that infringe GPL? 
> I think not (as otherwise no commercial s/w could run on Linux), in which 
> case I think the claim that dynamic loading / linking does (infringe GPL) 
> is not necessarily solid, as the difference between that and dynamic 
> linking to a library is pretty thin.

I think Graeme covered the technical weaseling angle.  It doesn't
matter how you twist and turn the bits, if at the end your work is
derived from some GPL code (ie. it will stop doing something it claims
to do if you take that GPL code away), then its a derived work and
subject to the licence conditions for such works.

The GPL itself explains the difference to aggregated works, and the
exceptions for OS components.  There is no paradox here, you _can_
develop, run, buy and sell, commercial software on Linux, even the
closed source variety, but you still can't weasel out of the GPL if
you build on code released under it.

There are plenty of free legal forums where people can discuss this
if they feel the need, but the key points here are:

 - if you use libtiff with this you are bound by GPL.
 - that (and patents) is a problem for some, but not for others.
 - so long as we let people choose what they use themselves,
   any legal ramifications are for them and their laywers to
   discuss.
 - this is no different from apps using other third party libs
   alongside libtiff, the end result must comply with the
   licences of _all_ its components.

All we need to figure out here is the technical details of letting
people choose.

Cheers,
Ron


_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
