ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Saviely <>
Subject Re: licensing (was: Ant gui tool)
Date Fri, 20 Oct 2000 16:06:21 GMT
> I am not sure you understand all the facts.

You may not be, but I am completely sure I don't.

I have been mailing, and have been frustrated at their
continual requests that I clarify myself when asking very simple questions
(that they certainly get everyday.)  Actually, I'm shifting the blame to
me; their words are that no conflict exists.

I am fully aware that I may have to use the reflection API or Kaffe in
order to use basic Java libs.  I use reflection all the time when using
IBM's xml parser, to reduce porting time.

> Apache does not require anything to be "APL compatable" it only restricts
> the way in which it is distributed (must state that it uses Apache software
> in program and must not use same name as apache product if it has been
> modified). 

I was told that anything under a gnu license woudn't be distributed with
Ant.  The clear inference was that GNU = APL incompatible, therefore can't
be distributed with Ant.

There are a number of GPLed tools that produce buildfiles for later Ant
processing.  The inference also is that they wouldn't be distributed with
Ant, though it is not illegal to make such tools.

Is this a minefield? Yes, so is proprietary licensing.  It is likely
unwise for me to have gotten into this discussion; people have such strong
feelings on the subject that the best communication is with the licenses

My point still stands, it is possible to dual-license advantageously. 
IIRC, there is also a clause that can be inserted in GPL'ed programs,
reserving that the original author may grant exceptions to the GPL on
whim.  This may also be used advantageously.


On Sat, 21 Oct 2000, Peter Donald wrote:

> >Yes, it is quite possible to dual-license.  Perl does this with the
> >Artistic & GPL.  
> but perl is self-contained or only relies on "system" components (excepted
> by clause 3 in GPL).
> >Separate sourcetrees can be maintained, or the maintainer
> >can just reject any patches that are for just one license.  (Someone else
> >can fork the code if they don't like one of the licenses.)
> yep.
> >The advantage would be that your program can be distributed with
> >say, Debian (who requires everything be GPL-compatible) and Apache (who
> >requires everything being APL-compatible.)
> which is a similar
> definition used by FSF. APL is free software so there is 0 problem
> distributing it with debian.
> >Another advantage, if you have a fondness for the GPL, is that it raises
> >its visiblity, so more people can conceivably be educated on what the GPL
> >does.
> virtually all the people who use GPL in java projects misuse it. This
> "education" you refer to has occured and has resulted in a large number of
> projects claiming to be GPL but not actually being GPL. Because GPL is a
> legal minefield unless you know what you are doing and restricts you from
> using rudimentry capabilities in java then it is much better to use a less
> restrictive license. 
> Projects who still try to use GPL-like licenses in java will try to
> copyleft on package/file/class basis and as was learnt in early days of GNU
> this is largely innefective in doing whta they aim to do and only blocks
> cooperation. 
> >I didn't think it was wise to bring it up again, so I'm glad you did. ;)
> I am not sure you understand all the facts.
> Cheers,
> Pete
> *------------------------------------------------------*
> | "Nearly all men can stand adversity, but if you want |
> | to test a man's character, give him power."          |
> |       -Abraham Lincoln                               |
> *------------------------------------------------------*

View raw message