Return-Path: 
 <ant-dev-return-14987-apmail-jakarta-ant-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-dev-archive@jakarta.apache.org
Received: (qmail 51390 invoked by uid 500); 20 Jun 2001 09:28:54 -0000
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ant-dev@jakarta.apache.org
list-help: <mailto:ant-dev-help@jakarta.apache.org>
list-unsubscribe: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
list-post: <mailto:ant-dev@jakarta.apache.org>
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 51243 invoked from network); 20 Jun 2001 09:28:53 -0000
Message-ID: <67FE02381F67D3119F960008C7845A2C0565AC12@nt_syd_ex09.macbank>
From: Tim Vernum <Tim.Vernum@macquarie.com.au>
To: "'ant-dev@jakarta.apache.org'" <ant-dev@jakarta.apache.org>
Subject: RE: Re[2]: Problems with licenses (GPL, LGPL) and task writing
Date: Wed, 20 Jun 2001 19:28:40 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

From: Yannick Menager [mailto:ymenager@yahoo.co.uk]

> Hello Tim,
> 
> what if we had a defined API for say.. CVS Tasks.. and a series of
> adaptors for multiple implementations.... would that be legal ?
> maybe as an optional task, if the jcvs classes are there, it uses
> them, if not.... Why hasn't that be done ? any legal reasons against ?

Not sure I follow entirely, but here goes:

If you developed a new ant task called "checkin" that did something like

<checkin tool="cvs">
	<param name="repositry" value="cvs.apache.org"/>
	<fileset id="myfiles/>
</checkin>

Then I beleive you could do this:

Give the checkin task had a published API that is:
	For tool="XXX" it would load ant-XXX.jar
	In that jar is will look for a "XXX_checkin" class.
	On that class it will use the methods
		* checkin( file )
		* setParam( name, value )

Then you could write classes for
	sccs_checkin
	rcs_checkin
	cvs_checkin
	p4_checkin
	pvcs_checkin
	vss_checkin

etc.

Your cvs_checkin would have to be GPL'd if it used any other GPL'd
code (eg some existing jCVS code).
But the checkin task wouldn't, since it is not specific to the cvs
task.

I do beleive though, that you would have to implement at least one
alternative implementation (such as rcs_checkin) to be truly safe.

Then org.apache.tools.ant.taskdefs.checkin could be ASF licenced
code, operating as a facade over the various implementations,
each of which could be under any licence.

BUT: IANAL, I have however had similar discussions with various
people about such techniques.

eg You could in theory write an implementation of readline that
didn't actually do anything except read text from the terminal.
If it had the same API as GNU-readline, then you could BSD 
licence it, and anyone could use it.
Then users could drop GNU-readline in as a replacement, without
you GPL'ing your program.

My information is that the FSF would see that as an attempt to
circumvent their licence, and they would seek legal injunction.

I think I agree with them.


> TV> From: Yannick Menager [mailto:ymenager@yahoo.co.uk]
> 
> >> I'm not a lawyer, but I have the strong impression that if 
> we called a
> >> GLPed binary (jarfile) using reflection, that would solve 
> the problem,
> 
> TV> Not necessarily.
> TV> If you wrote code that did something like:
> 
> TV> SUB use-gnu-stuff
> TV> BEGIN
> TV>         jar = load-jar( "gnu.jar" )
> TV>         on-error:
> TV>                 throw( "Cannot find gnu.jar" ) 
>         
> TV>         class = jar->load-class( "GNUclass" )
> TV>         on-error:
> TV>                 throw( "Cannot find 'GNUclass' in jar" )
>         
> TV>         method = class->lookup-method( "myMethod" ) 
> TV>         on-error:
> TV>                 throw( "Cannot find method 'myMethod'" )
> 
> TV>         return method->call()
> TV> END
> 
> TV> Then there would be no direct dependency on the GNU code, and no
> TV> linking, since it is all done with reflection and if you handled
> TV> the exceptions, then the code would still work if the GNU jar 
> TV> wasn't there.
> 
> TV> However, it is clear for all to see, that you are just trying to
> TV> circumvent the licensing requirements of gnu.jar, and a court
> TV> would probably declare it illegal.
> 
> TV> However, it is was using a standard interface then you would 
> TV> probably be OK.
> TV> eg: You can probably use a GPL'd bean in your code, if 
> you just treat
> TV> it as a bean.
> TV> And Ant can load GPL'd task, since it uses Ant's published API.
> 
> TV> But just putting a reflection wrapper doesn't necessarily work.
> 
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>