Re: Questions

[George <jirka 5z com>]

On Wed, Dec 05, 2001 at 02:09:27PM -0600, Linas Vepstas wrote:
> The cause-n-effect model is totally contaminating: your prorpietary 
> web browser can make a library-like cause-n-effect action on my 
> GPL'ed webserver.

No it can't.  I don't have a proprietary web browser :)

> > Imagine that you would write an emulator for
> > linux x86 ELF binaries.  Then if you load the binary into the emulator you're
> > running it in-process.  The binary itself doesn't know.  So can you run GPLed
> > code in a non-GPL compatible emulator?  
> 
> yes.  The emulator provides an address space to the emulated binary.
> The emulated binary cannot 'break out' of that address space to 
> corrupt the emulator, or corrupt the address spaces of other emulated
> binaries that might also be running.  (bugs don't count).

With the separate memory spaces it does make more sense to me now (well, sort
of:).  However how about shmem then?  Then you are sharing a part of the
memory, although I suppose you could argue that as long as there is a well
defined protocol it's not really just shared random memory bits, but
a way to pass data along.

I think with the above rationalle for licensing I suppose then that we would
need to require only in-proc platform components to be LGPLed, and require
the out-of-proc platform components just any free software license.

This raises an issue.  Are 'panel applets' considered part of the 'platform'
and if so should in-proc ones be LGPLed.  I don't think this makes all that
much sense since they're mostly to use in the panel and they're not a library
or anything.  But they are components.

I wanted to get back to the actual topic of the thread rather then discussing
which license is more like what flower/tree/weed.  As in, what license should
platform (I hate this word) components be is an actual on-topic discussion
here I think.

George

-- 
George <jirka 5z com>
   In the fight between you and the world, back the world.
                       -- Franz Kafka