Re: jcvs & ant

["M . Dietrich" <md...@diwa-gmbh.de>]

Hello,

i found the following comment in Cvs.java:

// XXX: we should use JCVS (www.ice.com/JCVS) instead of command line
// execution so that we don't rely on having native CVS stuff around
// (SM)

whatever that means - i had no time for waiting for that and because
we use ant on an AS/400 (works great) i startet programming. i have
done a first version of a module which does a checkout. but
unfortunatly we have an license problem here because jcvs is gpl, ant
ist apache. what can i do? 

for more information read my discussion with stafano:

----- Forwarded message from Stefano Mazzocchi <st...@apache.org> -----


"M . Dietrich" wrote:
> 
> On Wed, Jun 28, 2000 at 11:55:16PM +0200, Stefano Mazzocchi wrote:
> > "M . Dietrich" wrote:
> > > hi Stefano,
> > > On Tue, Jun 27, 2000 at 05:34:52PM +0200, Stefano Mazzocchi wrote:
> > > > "M . Dietrich" wrote:
> > > > > i'm about to integrate jcvs in ant - interested?
> > > > what about licensing problems? isn't JCVS gpl-ed?
> > > mmpf - i'm not a license guru. yes it is, is that a problem?
> > Of course. GPL is viral. It's incompatible with the Apache License.
> mmm - as i probably said before: i hate those license-wars.

I do too, but they are there, you can't simply do whatever you want.
 
> > > i just
> > > wrote a bridge that uses jcvs and fits in ant. put ant & jcvs in
> > > your classpath and everything's fine :) don't know if the license
> > > forbits this. i don't include jcvs, modify it or whatever. i would
> > > put my sourcesnippet under any free license that fits best.
> > That doesn't work. Everything you statically compile some GPL code,
> > your code requires to be GPL....
> is java statically compiled to that?

Everytime you do 

  new JCVS()

this is considered as static compilation by the GPL.

> but anyway jcvs is under gpl, not
> lgpl. perharps we can ask the jcvs-guys to put that parts i need under
> lgpl? would that help? 

Probably, but JCVS is an application not a library.

> then i could put my code under apache-license.
> 
> > > btw: i'm ready with an fixed (non configureable) export. that's
> > > all i needed today. export & checkout are different, i need export
> > > more so i start working on configurability, followed by checkout.
> > Tell the ant-dev mail list about this, but keep in mind the GPL
> > issue is a big one: we won't allow licensing-viral code to enter ant
> > CVS. This is a general Apache rule.
> i understand that license stuff but don't have the time to discuss
> that in detail. could you do that? 

no, I don't have the time

> could you mention my module in the
> list for me (i get hundreds of mails a day and don't want to be
> involved in another mailinglist :)?

don't tell me :)

> that would be great.

No, sorry, I don't have time to back you up on this.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------


----- End forwarded message -----

-- 
http://mitten.in-berlin.de/~mdt/
fon: +49.171.8030373
fax: +49.171.8029279
modem: +49.171.8029283
pgp fingerprint: c8a327e1a13e7b02ba4a4bd4c89e8cbb

Re: jcvs & ant

[Stefan Bodewig <bo...@bost.de>]

>>>>> "MD" == M Dietrich <md...@diwa-gmbh.de> writes:

 MD> Hello, i found the following comment in Cvs.java:

 MD> // XXX: we should use JCVS (www.ice.com/JCVS) [...]

This comment has lead Erik Meade <em...@geekfarm.org> to implement a
JCVS task and post it here a while back (beginning of June). 

Maybe we should come to a decision and remove the comment after that
(or change the Cvs task depending on the outcome).

A JCVS task could only be an optional task as we can't bundle JCVS
with Ant (the GPL problem) - and user who don't want JCVS couldn't
compile Ant if we made it a core part of it.

Apart from that my main objection against replacing the current Cvs
task with a JCVS implementation was, that JCVS didn't support the
:local: and :ext: protocols. Erik has told the list that the addition
of those is planned so sometime in the future JCVS could be a full
replacement of the command line version, but it is not right now.

My proposal: Encourage an optional JCVS based task and remove the comment
from Cvs.java.

As soon as JCVS can do everything the command line version can (and I
*need* local as well as ext) we can make the Cvs task optional as
well. The bootstrap process would compile in the JCVS version if it
found JCVS and use the command line based version otherwise.

Comments?

Stefan