Re: Plans for 2.8 - GNOME Managed Language Services?

[Christian Fredrik Kalager Schaller <uraeus gnome org>]

Actually my previous mail mentioned the wrong GPL paragraph. The RAND
incompatability is even more clear that so, point seven spells is out
clear:

7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot distribute
so as to satisfy simultaneously your obligations under this License and
any other pertinent obligations, then as a consequence you may not
distribute the Program at all. For example, if a patent license would
not permit royalty-free redistribution of the Program by all those who
receive copies directly or indirectly through you, then the only way you
could satisfy both it and this License would be to refrain entirely from
distribution of the Program.

Christian

On Sat, 2004-03-27 at 12:35 -0500, Miguel de Icaza wrote:

> Hello,
> 
> > > MY understanding that all ECMA bits are unencumbered insofar as they
> > > *must* be licensed under RAND terms. Is my understanding incorrect?
> > 
> > One problem is that RAND is still GPL-incompatible. That's why you can't
> > ship MP3 or MPEG4 codecs licensed under the GPL, even if you buy a
> > patent license.
> 
> RAND + Royalty Free in the case of ECMA.
> 
> In any case, am wondering why RAND is incompatible with the GPL?  This
> is news to me, and a google search did not reveal anything, nor could I
> find anything about this on the gnu.org site.   
> 
> > 
> > > If we choose a open source JVM, then we get no language other than Java
> > > and get Novell mad at us.
> > 
> > I don't know that's true; Novell had a Java thing back in the day:
> > http://developer.novell.com/research/appnotes/1998/january/01/05.htm
> > 
> > But if true, it probably leaves us back at C/C++/Python.
> 
> Novell uses Java for a large number of products, and there is no plan on
> abandoning Java in any shape or form. 
> 
> Java and .NET have their own strengths and weaknesses.  We now have a
> choice of picking the right tool for the right task.
> 
> iFolder and Simias are not only products, but platforms that implement
> the WinFS-like system for Linux, Windows and MacOS and those have been
> built on top of Mono.
> 
> Simias in particular is a technology that we want to build more and more
> things on top of as it provides a general purpose metadata-aware file
> system with synchronization on top of it.  It solves many problems that
> we feel exist today on the desktop and they solve them in a general way.
> So we are likely going to use Simias/iFolder technologies more and more
> in the future, and hence more Mono in our products.  
> 
> We will likely keep those features conditionally included, for those
> that choose not to use Mono. 
> 
> There were a few talks at Brainshare by the iFolder team on why they
> chose Mono over C/C++/COM/Java despite the fact that it was still an
> early project when they decided to go with it.  Different people will
> have different needs.
> 
> Miguel
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list