On Wed, 13 Oct 1999, J.H.M. Dassen (Ray) wrote: > Berlin is an SPI project.
I'm curious, actually, what is meant by this, as it is also stated on the SPI pages; it's an ambiguous phrase. If SPI says we should code left, can we code right, or are we under a mandate to act a particular way as an SPI project? I don't mean to imply that I disagree with SPI's mandate, but I'd hate to find out someday that, for instance, I had been implicitly assigning copyrights on everything I write to some other organization or something. > I'm fairly sure this means that Berlin's "contrib" status will be temporary. we were unaware of omni's "semi-free" status when we began working with it. when we were informed, we considered dropping omni and porting to TAO (you can check the mailing list archives) but were dissuaded by remarks to the effect that having sun's IDL parser in omniidl2 was a horrible mistake anyway, and none of the omni programmers liked it, so they were going to evict it shortly. furthermore, omniidl2 is _not_ required to develop berlin (only to rebuild its interface marshalling code from IDL), nor is omniidl2's output covered by the sun license. free code goes in, free code comes out. the situation would be analogous to putting all GPL'ed C programs in contrib because there were no free compilers, or putting all CGI programs in contrib because there were no free webservers. _our_ code is free, going into and coming out of omniidl2. Thus you can just as easily "pretend" that someone "magically" hand-codes all the stubs and skeletons during development, and commits them to CVS under LGPL, and then everyone else uses that code. we could even evict omniidl2 from the makefiles if it would make everyone happy. we have every intent of porting to TAO (and orbit C++, if they ever get around to working) anyway, to evaluate features/performance and interoperability; and we already use config.h macros to insulate ORB-dependent parts. we're really just lacking person-power to do the ports. -graydon
