license issue(s)

Paolo Bonzini wrote:
>> Since you've got a lawyer's ear, can you ask
him/her if it would be
>> kosher to keep the parts running on top of the vm
under the current
>> license (vm license := GPL, image := BSD)?

> I've been doing that for GNU Smalltalk (with
s/BSD/LGPL/) for years. It
> does not force anybody who wants to distribute a
program, to release it
> under the GPL.

> The image is just the input data to the VM.  It is not
part in any way
> of it.

The above is from a thread in the strongtalk group
 http://groups-beta.google.com/group/strongt
alk-general/browse_frm/thread/b2750795b0ba45e6/304082b931669
5c5?hl=en#304082b9316695c5

My question is: Is it ok to deploy applications (on an
internal
company network) using GNU Smalltalk without GPLing the
source?

What about the foreign function interface? Isn't that part
of the VM?

Cheers,
Krishna
-- 
I long to accomplish a great and noble task, but it is my
chief duty
to accomplish small tasks as if they were great and noble !
- Helen Keller


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

> My question is: Is it ok to deploy applications (on an
internal
> company network) using GNU Smalltalk without GPLing the
source?

If the applications are 100% Smalltalk, the answer is
definitely yes.

> What about the foreign function interface? Isn't that
part of the VM?

We are on thinner ice, but not because the FFI is part of
the VM.

If you link other libraries with the VM but you do not need
to write C 
wrappers for that (like for the new ncurses bindings),
you're fine. 
They are being linked in the VM and that's it.

The question is whether modules that interface yourself with
the VM can 
be considered derivative works of the VM.  I will contact
the FSF 
lawyers to clarify this.

Paolo


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

> My question is: Is it ok to deploy applications (on an
internal
> company network) using GNU Smalltalk without GPLing the
source?
> 
> What about the foreign function interface? Isn't that
part of the VM?

I have reached consensus with Richard Stallman that:

1) any C code for the library bindings must be released
under the GPL. 
Of course this only matters when the library needs some
special glue 
code to be used with GNU Smalltalk, as in the GTK+ case.

2) on the other hand, one can add this wording to the
bindings' 
licensing terms to avoid violating the GPL or hitting grey
areas:

    Linking XYZ statically or dynamically with other modules
is
    making a combined work based on XYZ.  Thus, the terms
and
    conditions of the GNU General Public License cover the
whole
    combination.

    In addition, as a special exception, the Free Software
Foundation
    give you permission to combine XYZ with free software
    programs or libraries that are released under the GNU
LGPL and with
    independent programs running under the GNU Smalltalk
virtual machine.

    You may copy and distribute such a system following the
terms of the
    GNU GPL for XYZ and the licenses of the other code
    concerned, provided that you include the source code of
that other
    code when and as the GNU GPL requires distribution of
source code.

    Note that people who make modified versions of XYZ are
not
    obligated to grant this special exception for their
modified
    versions; it is their choice whether to do so.  The GNU
General
    Public License gives permission to release a modified
version without
    this exception; this exception also makes it possible to
release a
    modified version which carries forward this exception.

3) the good news is, rms agreed to put the exception on the
bindings 
provided with GNU Smalltalk.  Since some of these bindings
may live 
within the virtual machine, the above exception will be
placed in the 
virtual machine too.

Version 2.3 of GNU Smalltalk will include the exception.

Paolo


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 11/20/06, Paolo Bonzini <paolo.bonzinilu.unisi.ch> wrote:

> I have reached consensus with Richard Stallman that:
>
> 1) any C code for the library bindings must be released
under the GPL.
> Of course this only matters when the library needs some
special glue
> code to be used with GNU Smalltalk, as in the GTK+
case.
>
> 2) on the other hand, one can add this wording to the
bindings'
> licensing terms to avoid violating the GPL or hitting
grey areas:
>
>     Linking XYZ statically or dynamically with other
modules is
>     making a combined work based on XYZ.  Thus, the
terms and
>     conditions of the GNU General Public License cover
the whole
>     combination.
>
>     In addition, as a special exception, the Free
Software Foundation
>     give you permission to combine XYZ with free
software
>     programs or libraries that are released under the
GNU LGPL and with
>     independent programs running under the GNU
Smalltalk virtual machine.
>
>     You may copy and distribute such a system following
the terms of the
>     GNU GPL for XYZ and the licenses of the other code
>     concerned, provided that you include the source
code of that other
>     code when and as the GNU GPL requires distribution
of source code.
>
>     Note that people who make modified versions of XYZ
are not
>     obligated to grant this special exception for their
modified
>     versions; it is their choice whether to do so.  The
GNU General
>     Public License gives permission to release a
modified version without
>     this exception; this exception also makes it
possible to release a
>     modified version which carries forward this
exception.
>
> 3) the good news is, rms agreed to put the exception on
the bindings
> provided with GNU Smalltalk.  Since some of these
bindings may live
> within the virtual machine, the above exception will be
placed in the
> virtual machine too.
>
> Version 2.3 of GNU Smalltalk will include the
exception.
>
> Paolo
>

Paolo, thanks for the clarification and for getting the
exception
clause. As I understand it, any code using vmProxy should be
GPLed.
What if I want to use GNU Smalltalk as an extension language
for my
(non GPLed) app? Is it enough to provide just the source for
the glue
code ?

Cheers,
Krishna
-- 
I long to accomplish a great and noble task, but it is my
chief duty
to accomplish small tasks as if they were great and noble !
- Helen Keller


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

>  As I understand it, any code using vmProxy should be
GPLed.

Yes.  So, to recap:

1) Smalltalk programs need not be GPL.  This is even stated
explicitly 
in the exception.

2) Clients of the virtual machine (i.e. programs that embed
it, linking 
to libgst.a or otherwise getting the vmProxy) need to be
GPL.

3) Bindings are a special case of (2), where you apply the
same 
exception that will be soon applied to the VM.


> What if I want to use GNU Smalltalk as an extension
language for my
> (non GPLed) app? Is it enough to provide just the
source for the glue
> code ?

You can, for sure, if you do not need glue code.  In this
case, the 
Smalltalk program can load the code of the application as a
shared 
library and start the application from there.  There is no
need to link 
the application to the virtual machine.

If you do this with some glue code (so your application does
not link to 
the VM directly, it's the bindings that link to *both* your
application 
and the VM -- and you are the author of both bindings and
applications, 
so you can license them as you wish; see also 
http://www.gnu.org/licenses/gpl-faq.html#GPLIncompat
ibleLibs), it may be 
possible; but IANAL, and this is surely a gray area.

However, this is against the very reason why the GNU
Smalltalk virtual 
machine is GPL: because the embeddability of the virtual
machine is one 
of the few aspects that distinguishes gst from proprietary 
implementations.  In fact I would consider the first case a
loophole: a 
perfectly acceptable one, but still a loophole.

Paolo


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk