nanogui: Re: Stupid licensing thread (Was: Request for comments - Microwindows)
Subject:
RE: Stupid licensing thread (Was: Request for comments - Microwindows)
From:
"Vidar Hokstad" ####@####.####
Date:
5 Oct 1999 00:49:14 -0000
Message-Id: <19991005004521.28692.qmail@mail.relight.com>
On Mon, 4 Oct 1999 18:28:03 -0600 you wrote:
>On Monday, October 04, 1999 4:51 PM, Vidar Hokstad ####@####.####
>wrote:
>: the near future I and another developer will be working
>: nearly full time on it, and we also sponsor another company to port a major
>: software product to NanoGUI.
>:
>: This is code that we contribute back.
>
>
>Correct me if I'm wrong: If we license LGPL _or_ MPL,
>it is not required to contribute any code back.
Depends on how the code is organized - with MPL you still have to
contribute back changes to the existing code, but it is easier to
add proprietary code outside the existing code.
We will contribute back no matter what license - if we'd been afraid
of releasing code we wouldn't have considered NanoGUI in the first
place. My concern is being able to use proprietary code for which we
have no control over the license terms, and were we in some cases
may explicitly not be allowed to release anything but stripped binaries.
In our case we won't link directly to the server, though, so as long
as the client library has a liberal enough license (such as the MPL),
that's enough for us.
> If the _contributors_ to NanoGUI
>: regards prefer a restrictive licensing scheme over those contributions,
>: then fine. In that case we'll spend our time and money improving
>: another product instead, or license a closed source product instead of
>: spending or time and money on supporting an open source project.
>
>
>So we need a license that:
>
>1) must
>
>or
>2) should
>
>cause contributors to contribute code back. Which?
For the server side I don't really have a preference. I know that _we_
(as in Screen Media) can live with pretty much any open source license
on the server without problem, including the GPL. I'm concerned about
what others would want for it too, though. For the client library I
would certainly prefer a much more liberal license. But since all the
logic will be on the server side anyway, I can't see the point with a
restrictive license for the client library.
But as we've been through before: Many people might prefer to link directly
with the server (doesn't apply to us), for instance when running on systems
without networking support. And the more restrictive license on the server,
the fewer of that kinds of projects will be able to use NanoGUI. For that
reason I'd prefer a not too restrictive license for the server side too,
because it might help with developer mindshare.
Regards,
Vidar
