nanogui: Thread: Licensing summary

Let me try to summarize what we need in a graphics system license:

	1. We _must_ have:
		a. The ability to have private, proprietary drivers to be used (NDA's,
and other commercial non-control issues)

		b. The ability to work with, communicate with, and be linked with,
private, proprietary applications. (commercial software shops use our engine with
their application; they'll never go open source, but still want/choose our engine)

	2. We _would_like_to_have:
		a. All modifications to original files, whether they're enhancements
or bug fixes.  It'd be nice to have them back, but not required.

		b. A community desiring to better the project as a whole,
by sending contributions to be included in the whole, whether they're original
work, new drivers, or whatever.

	3. We _must_not_have:
		a. The ability to use the graphics engine, lock stock and barrel,
for whatever purposes are desired????  [It is this 3a that I can't quite come to
grips with]

please debate

Greg

This was a reasonable summary. Below I've commented on _my_ needs
only, related to your suggestions. What I need, and what I want are
two different things, though. I'd like a more liberal use of licenses
than what we need, for the reasons of more easily growing mindshare in
the embedded systems community.

(When I talk about we/us below, I talk about Screen Media)

On Mon, 4 Oct 1999 18:39:11 -0600 you wrote:
>Let me try to summarize what we need in a graphics system license: 
> 
> 
>1. We _must_ have: 
> 
>a. The ability to have private, proprietary drivers to be used (NDA's, 
>and other commercial non-control issues) 
> 
>b. The ability to work with, communicate with, and be linked with, 
>private, proprietary applications. (commercial software shops use our engine 
>with 
>their application; they'll never go open source, but still want/choose our 
>engine) 

These are really one and the same: Being able to link proprietary
code into the server side. I still believe some people will have problem
with LGPL here, but for _me_ it doesn't matter. Even the GPL would be
acceptable for _our_ use. But then we will only be using it with network
support.
 
>2. We _would_like_to_have: 
> 
>a. All modifications to original files, whether they're enhancements 
>or bug fixes.  It'd be nice to have them back, but not required. 

The MPL allow this, but also allows people to "cheat" in some cases,
by adding enhancements in separate files. For me, I'd consider the MPL
as protection enough, but I won't object to the LGPL for the server side. 
 
>b. A community desiring to better the project as a whole, 
>by sending contributions to be included in the whole, whether they're original 
>work, new drivers, or whatever. 
> 
>3. We _must_not_have: 
> 
>a. The ability to use the graphics engine, lock stock and barrel, 
>for whatever purposes are desired????  [It is this 3a that I can't quite come 
>to 
>grips with] 

I gather that you mean that we don't want someone to take the code, and
run with it, not contributing anything back. But I'm not sure if this
would be a huge problem. Unless you add a lot of stuff that you are very
afraid of releasing, it will always be an advantage to using an unchanged
"official" version over having to backport your changes every time you
upgrade. The MPL provide some (but not as much as the LGPL or GPL) protection
against this kind of use, though.

My main concern is the client side, though. The client side is a very
small part of the code, but a liberal license on the client side code
will be a "bail out" for people that _can't_ (for contractual or other
reasons) use LGPL'd code, and thus don't want to link to a LGPL'd server,
but won't let them take the server code and run with it.

Regards,
Vidar

I've been following this discussion, sort of, and I'd just like to
comment that if you guys ever decide on a license, I'm willing to
relicense BOGL under it (as long as it's somewhat sensible, i.e., DFSG
compliant).  I don't know if you're going to use BOGL much anymore but
I'm willing to let you, if you want it.  Actually I don't care about
BOGL much anymore so maybe I'll just put it under the XFree86 license.

-- 
"Unix... is not so much a product
 as it is a painstakingly compiled oral history
 of the hacker subculture."
--Neal Stephenson

----- Original Message -----
From: Greg Haerr ####@####.####
To: 'Vidar Hokstad' ####@####.#### Bradley D. LaRonde
####@####.#### 'Alan Cox' ####@####.#### 'Alex Holden'
####@####.####
Cc: ####@####.#### ####@####.####
Sent: Monday, October 04, 1999 8:39 PM
Subject: Licensing summary


> Let me try to summarize what we need in a graphics system license:
>
> 1. We _must_ have:
> a. The ability to have private, proprietary drivers to be used (NDA's,
> and other commercial non-control issues)

I disagree.  If a vendor can take the proprietary route, he probably will.
But if he likes Micro* and wants to use it, and the server part of Micro* is
GPLed (not MPLed) he might be swayed to release his driver, which benefits
our community.

Consider this: "Yes, you can use this cool, free Micro* thingy for your
project, but you have to, uh..., er..., buy our driver to get it to work."
For embedded, it's not like you can just swap out the graphics card to a
supported one like you can in a PC.

Granted, we could reverse engineer the driver, but what I'm saying is that
vendors, if given the ($PL) route, will probably take it, but if we don't
give them that route, they might decide to release their driver, benefitting
everyone.


> b. The ability to work with, communicate with, and be linked with,
> private, proprietary applications. (commercial software shops use our
engine with
> their application; they'll never go open source, but still want/choose our
engine)

This is simply solved by using LGPL on the client side.  Take GNOME for an
example.


> 2. We _would_like_to_have:
> a. All modifications to original files, whether they're enhancements
> or bug fixes.  It'd be nice to have them back, but not required.

Yes, we would like to have them back, so let's require it for the server
side.  Linux does.


> b. A community desiring to better the project as a whole,
> by sending contributions to be included in the whole, whether they're
original
> work, new drivers, or whatever.

If a vendor is on the fence, which way do you think they will go?  I think
that they will probably go $PL if given that option.  If not given that
option, then I think that they will be more likely to contribute back.

BTW, the MPL has a serious flaw in that you can avoid contributing stuff
back to the project just by putting it in a separate file.


> 3. We _must_not_have:
> a. The ability to use the graphics engine, lock stock and barrel,
> for whatever purposes are desired????  [It is this 3a that I can't quite
come to
> grips with]

Let everyone use it as they please, only require that they release their
improvements back to the community.  Is that too much to ask?

Please, let's not fall into the trap of thinking that the success or failure
of Micro* depends on how many embedded vendors pick it up.  I think that for
it to truly succeed means that it becomes the best FREE graphics system
available for small devices, and that for it to remain free it needs the
protection that the GNU GPL affords - protection that is certainly NOT
present in (and would be effectively nullified by) the MPL.

It really comes down do this: are we committed to free software, or are we
just trying to please everyone?  I hope that we decide that free software is
more important than being popular.  Where would we be today if others before
us who were faced with this decision chose the popular way?  Would we have
GNU?  Would we have Linux?  I don't think so, and the same might be said
about Micro* someday... or not.

Regards,
Brad

On Tue, 5 Oct 1999 09:59:51 -0400 you wrote:
>Consider this: "Yes, you can use this cool, free Micro* thingy for your 
>project, but you have to, uh..., er..., buy our driver to get it to work." 
>For embedded, it's not like you can just swap out the graphics card to a 
>supported one like you can in a PC. 
> 
>Granted, we could reverse engineer the driver, but what I'm saying is that 
>vendors, if given the ($PL) route, will probably take it, but if we don't 
>give them that route, they might decide to release their driver, benefitting 
>everyone. 

Consider this: I go to a company, because I _need_ their hardware for
my project, and I want to use NanoGUI. They say: Fine, but you can't
release the source or object code. The result? I choose something other
than NanoGUI. Hardware is what drives our cost, and if I'd have to choose
more expensive, or inferior hardware to be able to use NanoGUI, then
NanoGUI - *not* the hardware - would be what I would consider my problem.
  
>> b. The ability to work with, communicate with, and be linked with, 
>> private, proprietary applications. (commercial software shops use our 
>engine with 
>> their application; they'll never go open source, but still want/choose our 
>engine) 
> 
>This is simply solved by using LGPL on the client side.  Take GNOME for an 
>example. 

It's a completely different market. Gnome doesn't run on any systems that
doesn't support networking or dynamic linking. It also isn't used primarily
in an environment where many companies have policies that prevent you from
licensing your software for use with LGPL'd or similar licenses no matter
how you do it.
 
>> 2. We _would_like_to_have: 
>> a. All modifications to original files, whether they're enhancements 
>> or bug fixes.  It'd be nice to have them back, but not required. 
> 
>Yes, we would like to have them back, so let's require it for the server 
>side.  Linux does. 

An FreeBSD etc. doesn't. That Linux does isn't an argument for or against
requiring it for NanoGUI.
  
>If a vendor is on the fence, which way do you think they will go?  I think 
>that they will probably go $PL if given that option.  If not given that 
>option, then I think that they will be more likely to contribute back. 
> 
>BTW, the MPL has a serious flaw in that you can avoid contributing stuff 
>back to the project just by putting it in a separate file. 

You see it as a flaw, some see it as a feature. It hasn't stopped Mozilla
for instance from getting massive amounts of new contributed code, even
outside the standard code base, and at the same time it has attracted lots
of companies that wouldn't have considered it had it been under the GPL
or LGPL, but that nevertheless contribute at least parts of their code
back.

>> 3. We _must_not_have: 
>> a. The ability to use the graphics engine, lock stock and barrel, 
>> for whatever purposes are desired????  [It is this 3a that I can't quite 
>come to 
>> grips with] 
> 
>Let everyone use it as they please, only require that they release their 
>improvements back to the community.  Is that too much to ask? 

No, but if you use GPL or LGPL, you don't let everyone use it as they
please. In fact, you exclude a rather large part of the embedded and
small devices community.
 
>Please, let's not fall into the trap of thinking that the success or failure 
>of Micro* depends on how many embedded vendors pick it up.  I think that for 
>it to truly succeed means that it becomes the best FREE graphics system 
>available for small devices, and that for it to remain free it needs the 
>protection that the GNU GPL affords - protection that is certainly NOT 
>present in (and would be effectively nullified by) the MPL. 

How come XFree has been so successful, then, if a license as restrictive
as the GPL is required?
 
>It really comes down do this: are we committed to free software, or are we 
>just trying to please everyone? 

I am comitted to whatever give me a good platform to develop embedded and
small systems solutions on with the minimum hassle. If the NanoGUI license
gets to restrictive, I will simply go and find some more suitable project.

>I hope that we decide that free software  is  more important than being
>popular.  Where would we be today if others before  us who were faced
>with this decision chose the popular way?  Would we have  GNU?  Would we 
>have Linux?  I don't think so, and the same might be said  about Micro*
>someday... or not. 

Would there be X?

X is a lot more widespread than GNU or Linux, so according to your argument,
maybe we should accept the XFree or X consortium license. The reality is
that comparing to X or Linux or GNU is meaningless. This is a completely
different area, and a type of devices where most users will never even
install any software themselves.

Regards,
Vidar

> I disagree.  If a vendor can take the proprietary route, he probably will.

That doesnt back up experience. The only vendor who wants to take a proprietary
route is one for whom this is 'core technology'. To everyone else its overhead
and overheads want reducing so you make more profit on the product.

> BTW, the MPL has a serious flaw in that you can avoid contributing stuff
> back to the project just by putting it in a separate file.

Same with the LGPL, you just put it inside or outside the library.

> 

>>>>> "Brad" == Bradley D LaRonde ####@####.#### writes:

    Brad> ----- Original Message ----- From: Greg Haerr
    Brad> ####@####.#### 

    >> Let me try to summarize what we need in a graphics system
    >> license:
    >> 
    >> 1. We _must_ have: a. The ability to have private, proprietary
    >> drivers to be used (NDA's, and other commercial non-control
    >> issues)

    Brad> I disagree.  

I disagree with your disagreement!  

You're simplifying the issue too much.  It's not us-vs-them.  

Example: I want to run NanoX on top of eCos on next year's CoolPalm.
Cool-Hand-Tech, Inc. is a free-friendly company, and they'd love to
write NanoX drivers in addition to their planned WinCE drivers.
Unfortunately, they're under NDA to Fascist Chips, Inc., (who makes
their video chip) and therefore they cannot release the source to the
driver for their own hardware!  If the NanoX license won't allow them
to release a binary-only driver, then they will sigh and not support
NanoX at all.  I, Joe User, get shafted.  

These issues are precisely the same as the ones that face XFree86.  

Philosophical aside:

I work on free software because I'm not a hoarder.  I believe in
helping people and making the world better.  What do I care if company
X takes my stuff and uses it in their commercial product?  More power
to them!  I wrote it to be used, and a bigger user base means more
mindshare.  I want to encourage them to contribute improvements back,
but if they don't, it doesn't slow the free community down.  I'm no
worse off than if they didn't use it at all.  

I love the GPL, but there are times when it's not the best thing.  In
this case, Open is Better.

-- 
Daniel Risacher               ####@####.####

: I work on free software because I'm not a hoarder.  I believe in
: helping people and making the world better.  What do I care if company
: X takes my stuff and uses it in their commercial product?  More power
: to them!  I wrote it to be used, and a bigger user base means more
: mindshare.  I want to encourage them to contribute improvements back,
: but if they don't, it doesn't slow the free community down.  I'm no
: worse off than if they didn't use it at all.  
:
	I completely agree with the above comment

Greg

On Tuesday, October 05, 1999 12:50 PM, Alex Holden ####@####.#### wrote:
: On Tue, 5 Oct 1999, Alan Cox wrote:
: > This is going on far too long and round in circles. Greg and Alex - pick
: > something, stick a license on it all , say so publically and be done. It
: > does more harm now than whichever is picked
: 
: Right, I vote for MPL with a "convert to GPL/LGPL" option, with David's
: original code retaining it's current Public Domain license. Vidar has
: already said he's happy with that. Greg?


	Yes.  I think I agree.  But I want to be completely clear on David's
code.  His original code retains his original PDL license.  The code that's
included in nano-X and/or MicroWindows is a derivative work, and is not
subject to any terms other than his original terms: leave the copyright
notice intact.

	In addition, the "convert to" would be strictly GPL, not LGPL.

	What are the semantics of a "conversion", anyway?

Greg

On Tue, 5 Oct 1999, Greg Haerr wrote:
> 	Yes.  I think I agree.  But I want to be completely clear on David's
> code.  His original code retains his original PDL license.  The code that's
> included in nano-X and/or MicroWindows is a derivative work, and is not
> subject to any terms other than his original terms: leave the copyright
> notice intact.

That's the reason I thought we'd have to move David's code into seperate
files- because his code wants to go into files with his Public Domain
license on them, and the new code wants to go into files with the MPL on
them.

> 	What are the semantics of a "conversion", anyway?

You just redistribute everything under the new license. It would have to
be a total conversion though, because the GPL wouldn't allow some GPL
parts and some MPL parts, and I don't think it, or any improvements made
to the GPLed version could be converted back to MPL without explicit
permission of the author of the changes.

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------