ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Wielaard <>
Subject Re: licensing (was: Ant gui tool)
Date Mon, 23 Oct 2000 18:28:46 GMT

on Mon, Oct 23, 2000 at 11:19:38AM +1000, Peter Donald wrote:
> >not because the X license was not GPL compatible but because they were
> >afraid that the X consortium would make future versions of the software
> >non-free since the X license allows this to happen. So they urged people
> >to GPL their X software to prevent this from happening but the X consortium
> >did not accept GPLed contributions.
> right but the terms of the license were incompatable with GPL I thought.
> People who GPLed code that used the X core were not doing it legally as
> such. I could be wrong as I was never involved as such. I thought that it
> was perfectly legal to write proggies that used X just like it is perfectly
> legal to write programs that used libc ... but combining it with core was a
> no no. 

Combining code under the MIT X license and under the GPL is no problem
since the MIT X license contains no more restrictions then the GPL.

> >Please let me know how I can help you with that. I believe there are people
> >working on a free javamail implementation
> theres a guy at sourceforge who has done this. Not sure on license thou.
Do you have an URL? I could not find it.

> >, but jndi and 
> >activation are big projects. 
> the same guy did activation and if not I have a 50% clone of activation
> sitting about.

> >The greatest barrier will be a free Swing implementation.
> However I long ago learned the pointlessness of such endeavors. Sun and the
> new JCP are churning out too much good quality code for free software to
> keep up. Worse is that the people who would've at one stage worked on free
> implementations are now working with JCP. So you either accept sub-standrd
> environment or just use suns libraries. Most of suns libraries are under a
> free (as in beer) license so it is too much to ask to go against that. Even
> worse is that sun holds patents that restrict free implementation of
> various libraries (ie jini and some rmi aspects) and thus you can only use
> them if you use suns version.

I am not that impressed with the results of the JCP, but I have to admit
that Sun is playing this very smart. But I personally would rather work
with free software then with the proprietary Sun stuff even though it
is distributed as free beer. And there are a lot of people in the free
software community that don't that Java that seriously because there is
no complete free implementation. But we are slowly coming there. And don't
forget that we might convince Sun in the end to make it an open and free
standard. The Apache Foundation convinced Sun to release their Servlet
implementation as free software (Tomcat). That is something I creatly
respect and which I hope is only the beginning.

> >But I am sure we will see it in the end. I try to do some work on the
> >Classpath (now merged with libgcj) project and I am very impressed with
> >how complete their 1.2 library support is (often more complete then the
> >kaffe libraries).
> yep. I worked with classpath stuff for a bit when I decided to write my own
> VM and found it fairly good except that it has mixed libraries (ie
> partially 1.0, partially 1.1, partially 1.2 etc) 

Hopefully after GCC 3.0 is released which will include the native code
gcj compiler and the libgcj library that merged with classpath it will
improve even more. (But it will be at least a couple of months before
that happens.)

> >But I also believe that people should be free to choose the license they
> >want. And sometimes you have to work with GPLed code and have to respect
> >the wishes of the original authors and not use GPL incompatible code.
> right but it is also quite insulting in some cases. Consider this case. I
> use apache stuff and develope it further then I choose GPL to license it
> under so as to block apache developers using it. This has happened in past
> even by these "GPL" projects that were not really "GPL" and will most
> likely happen more in future. I find this offensive in the extreme.

I see what you mean. That is very offensive. Although a non-copyleft
license such as the APL always allows people to do even worse things
like releasing a derived version of the code as proprietary closed
code which you cannot even inspect as you could do with an GPL version.
But I think that people should just ignore such hostile forks of the

> >I hope you succeed (see above). But couldn't you just recommend those
> >projects to use the APL minus the last two clauses (call it the
> >unrestricted APL :). That would make those projects both GPL and APL
> >compatible.
> nope. At least I don't think so. At apache everything is decided by
> consensus. So even if I could do it I wouldn't want to. It is more a
> "together we stand or together we fall" kind of atitude.

If you cannot convince the libraries to change their license because they
want to wait until the APL is GPL compatible you have to respect that
of course. Does anybody know if the issue has been discussed on ApacheCon?



View raw message