nanogui: Thread: Request for comments - Microwindows

I am considering some bigger changes to the graphics engine
project I've been working on the last six months.  I'd like to get
your comments before I go headlong into this.  Following are
some of the changes being considered:

	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."

Comments?

Greg

> 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

His license doesnt clash with the LGPL. The LGPL doesnt allow you to
remove other peoples copyright notices either

> 

On Monday, October 04, 1999 12:13 PM, Alan Cox ####@####.#### wrote:
: > 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
: 
: His license doesnt clash with the LGPL. The LGPL doesnt allow you to
: remove other peoples copyright notices either
:
	So even though David Bell said "Permission is granted to use, distribute,
or modify this source, provided that this copyright notice remain intact" we
can say that now his code is subject to another agreement, the LGPL?
Doesn't the LGPL restrict more than the above?

Also, can we have a GPL license on the server and an LGPL license
on the applications?  Can we have both even if we allow linked-in
apps and client/server apps?

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 ####@####.####
To: ####@####.####
Cc: ####@####.####
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."

----- Original Message -----
From: Greg Haerr ####@####.####
To: 'Alan Cox' ####@####.####
Cc: ####@####.#### ####@####.####
Sent: Monday, October 04, 1999 2:37 PM
Subject: RE: Request for comments - Microwindows


> On Monday, October 04, 1999 12:13 PM, Alan Cox
####@####.#### wrote:
> : > 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
> :
> : His license doesnt clash with the LGPL. The LGPL doesnt allow you to
> : remove other peoples copyright notices either
> :
> So even though David Bell said "Permission is granted to use, distribute,
> or modify this source, provided that this copyright notice remain intact"
we
> can say that now his code is subject to another agreement, the LGPL?
> Doesn't the LGPL restrict more than the above?

Yes, it does, but he doesn't restrict placing new restrictions on derived
works with his copyright, which is the main reason for using GPL vs. his
license. GPL prevents ppl from making proprietary works based on your free
work.

> Also, can we have a GPL license on the server and an LGPL license
> on the applications?  Can we have both even if we allow linked-in
> apps and client/server apps?

Wow, seems like we are thinking along the same lines. :-)  I commented on
that already in my previous message.

Regards,
Brad

On Mon, 4 Oct 1999 14:38:00 -0400 you wrote:
>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'd suggest dual licensing. *GPL is completely unworkable for many people,
for a variety of reasons.

>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 problem, as you've noted, is that many would want to link the server
into their applications. I know that we (Screen Media) can't continue to
work on it if the code isn't available under another license (apart from
the *GPL's) as well, and the result would be yet another code split.

I thought we'd already agreed on the MPL as a decent common denominator,
but I'd have no problems with dual licensing the code under both *GPL
and MPL.
 
Vidar Hokstad.

: 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.
: 
	Well, we could always have LGPL for static model, otherwise
GPL for server and LGPL for applications.  If someone wants to develop
a non-free program, and link it statically, we still let them

----- Original Message -----
From: Greg Haerr ####@####.####
To: 'Bradley D. LaRonde' ####@####.#### ####@####.####
Cc: ####@####.####
Sent: Monday, October 04, 1999 2:51 PM
Subject: RE: Request for comments - Microwindows


>
> : 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.
> :
> Well, we could always have LGPL for static model, otherwise
> GPL for server and LGPL for applications.  If someone wants to develop
> a non-free program, and link it statically, we still let them

Wow, I never thought of that possibility.  One thought, though, is that it
might convolute things too much to #ifdef the licensing.

Regards,
Brad

> 	So even though David Bell said "Permission is granted to use, distribute,
> or modify this source, provided that this copyright notice remain intact" we
> can say that now his code is subject to another agreement, the LGPL?
> Doesn't the LGPL restrict more than the above?

Yes. But that is allowed. 

You can take his work and use it as allowed by his license to create a
derivative work - his license allows this. What you cannot do is stop someone
taking David Bell's original work and using it under David Bell's license 
alone.

The derivative work (the combination) is differently licensed to the original
code he wrote.

> Also, can we have a GPL license on the server and an LGPL license
> on the applications?  Can we have both even if we allow linked-in
> apps and client/server apps?

It gets complicated in the linked in case.

Alan

> The problem, as you've noted, is that many would want to link the server
> into their applications. I know that we (Screen Media) can't continue to
> work on it if the code isn't available under another license (apart from
> the *GPL's) as well, and the result would be yet another code split.

Nod.

> I thought we'd already agreed on the MPL as a decent common denominator,
> but I'd have no problems with dual licensing the code under both *GPL
> and MPL.

I still personally think the MPL is the only standard license that fits
the linked in case at all