Re: Framebuffer port of GTK/GDK !!



> > 	We could always (diplomatically) ask the copyright holders to give
> > it to us under an LGPL license.  If no-one objects, I will subscribe to
> > their mailing list and probe them about it...?
> 
> I wouldn't recommend it, unless you like starting flamewars.

	Ahh.  Thanks for the warning (reminder, actually :).

	So there are three outstanding licensing questions (with regard to
using Microwindows for a framebuffered GDK):

1)  Should we abandon all LGPL hope?  I (or someone else) could email the
project maintainer, appearantly Mr. Greg Haerr <greg@censoft.com>,
privately so see if the LGPL issue has come up before or if he thinks
contributors would be open to the idea.

2)  Is the MPL "compatible" with the LGPL?  If not, we should probably
maintain a cleanroom environment from the Microwindows code for GDK
developers who want to work on a framebuffer GDK implementation.

3)  Should we even consider porting GDK to Microwindows if the MPL or GPL
is the only license we can get it under?  My understanding is that we
could use Microwindows' Nano-X API to implement a Microwindows version of
GDK (and still keep GDK under the LGPL), but that Microwindows itself
(being a separate program) would have its own, unrelated license.


	At first pass, it looks like the Microwindows project has done 90%
of the work for us already, but then we'd be talking about a Microwindows
port of GDK (where Microwindows happens to run on the Linux framebuffer)
instead of a true "framebuffer" port.  As Havoc has said, we'll need some
basic windowing layer anyhow, and if we can use Microwindows for that we'd
be two steps ahead of the game.

	If we want a true framebuffer port of the GTK+ library, we'll need
to write our own mini-windowing code under the LGPL, along with some sort
of basic window manager.


--Derek



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]