What you suggest is brilliant IMO. I recommend to go ahead with your ideas.
Only two comments, both about the licensing:
1) I would prefer *GPL over MPL.
2) I'm fine with LGPL, but I would like to see GPL in here somewhere if
feasable.
I was thinking, how about using GPL for server layer(s), and LGPL for client
layer(s)? I think that as long the client and server are separated by a
messaging protocol it will work.
The nice thing about this is that it provides that all server code (e.g.
drivers) will be free (open-source) - which seems like a Good Thing to me.
However, it does appear to kill the static model, but ONLY FOR NON-FREE
ROGRAMS. Free programs could still use the static model just fine, and
non-free programs could still use the client/server model, since the client
side is LGPL.
Comments?
Regards,
Brad
----- Original Message -----
From: Greg Haerr <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, October 04, 1999 2:16 PM
Subject: Request for comments - Microwindows
> Move to Xlib reimplementation. I've been thinking that the
> proper way to go with the microwindows project is to build a close
> resemblance to Xlib, much like I've done with the win32 api portion.
> This would allow, for instance, with little effort, the graphics
applications
> that currently use Gtk on top of Gdk on top of Xlib to be ported to
> all the systems that microwindows supports with very little effort.
> Also, the Xlib reference manual could be used for most instances
> to learn about the micro-X api.
>
> License under LGPL. All of the code I've written,
> which includes all of microwindows and all the enhancements
> to mini-X, can be easily licensed this way. But the nano-X
> project has a large core of GrXXX routines that were originally
> written by David Bell, and his license is completely unrestrictive,
> except that his copyright notice must still be included. So
> we can't downgrade his license to LGPL. This means that
> his code can't be used if this project goes strictly MPL or LGPL.
> One idea is to contact David, another is to rewrite it as Xlib.
>
> Reorganize source code so that micro-Win32 and micro-X
> can both be worked on simultaneously. Currently, the source
> is organized with win32 getting the "upper hand". The win32
reimplementation
> would be placed in a subdirectory from the engine code. The
> Xlib reimplementation would be placed in a subdirectory under the engine
> code. Thus, Xlib development could proceed much more quickly,
> without having to know anything about win32.
> In this way, the MicroWindows project goal
> could become "A micro-reimplementation of the Xlib and Win32
> api's, catering to small size and speed of porting, on Linux[CE,86]
platforms."