nanogui: Request for comments - Microwindows
Subject:
Re: Request for comments - Microwindows
From:
"Vidar Hokstad" ####@####.####
Date:
5 Oct 1999 01:02:59 -0000
Message-Id: <19991005005906.28726.qmail@mail.relight.com>
On Mon, 4 Oct 1999 19:52:51 -0400 you wrote:
>> At the very least
>> the server needs to be LGPL'd, preferrably MPL'd, or as Alex suggested
>> MPL'd with an added provision for users to do a one way conversion to
>> GPL/LGPL.
>
>The server needs? I don't need it. Who here needs it? Or are we trying
>to accomodate hypothetical users?
My hope would be that we'd try to accomodate the typical embedded systems
developers. If you believe you can get people to use NanoGUI for that
type of projects without being able to link proprietary code, fine. But
I wouldn't count on it - I know of more than enough of people considering
NanoGUI for platforms that doesn't support dynamic linking or networking,
and that require third party code that they'd never be allowed to link
to GPL'd or LGPL'd code by the companies they've licensed code from.
>> In that case I'll have to start evaluating other systems for my work,
>> since it was a hard enough sell to go for the MPL for some of our
>partners.
>
>The only thing is you can't use proprietary drivers in the server. Does
>that mean that you have to stop contributing to the LGPL client side, or
>abandon Micro* completely? You could (I imagine very easily) derive a new
>server for the proprietary hardware from the same original sources, but
>still use the LGPL Micro* client side non-statically linked.
As I've said time and time again, we have partners that would make it
problematic enough that, yes, it would likely make economic sense for
us to stop contributing to NanoGUI/MicroWindows completely, and abandon
it completely in favor of a less restricted system.
Also, it seems that maybe you are confusing the client and server side
in the above paragraph. It is the server that contain all of the logic. The
client side is only a small set of functions to connect to the server via
Unix domain sockets, and send request and read responses. Which makes it
even more silly to use a restrictive license on it. Also remember that
not all systems people might want to use it under may even support dynamic
linking.
If the server is under the LGPL it will still be usable for us. However
I'd still prefer a less restrictive license for the server as well, or
dual licensing, since it might attract a larger audience in the embedded/
small systems world, which i currently _very_ tied up in proprietary systems.
>Are we going to cater to proprietary interests or create a completely
>open-source system? And if we don't create it open-source, how long will
>it be before MicroFree* comes along?
We're hopefully creating a completely open source system. But that doesn't
require a license that precludes people to link proprietary code to it.
I would hope that we would cater to the interest of those most likely to
use NanoGUI in embedded and small systems projects: embedded and small
systems developers. In that case, you'll meet countless problems with
a restrictive license.
Vidar.
