For Programmers: Free Programming Magazines  


Home > Archive > Smalltalk > October 2007 > Smalltalk and the GPL









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Smalltalk and the GPL
Bruce Badger

2007-10-03, 4:24 am

IANAL, but nonetheless I have been thinking about the GPL in the context
of Smalltalk.

A worry with the GPL, regardless of programing language, is that the
license may unintentionally be applied to code because of the GPL
"linking" clause. What "linking" means in the context of Smalltalk is key.

The terms of the GPL apply to "distribution". Distribution is passing
GPLed code to another entity. If an entity (a person or a company) just
uses code without passing it on (distributing it) then they are not
subject to the terms of the GPL. If an entity does pass on GPLed code
then the terms of the license must be observed.

If I use a GPLed library in my Smalltalk image, have I "linked" to that
library? If so, does this mean that *everything* in the image is
potentially subject o the GPL? This question has been rolling around
for a while and the consensus is that using the LGPL (the "library" or
"lesser" GPL) probably makes things OK. Some people (Alan Knight with
GLORP for example IIRC) have added clauses to the LGPL to make it clear
that they intend use of their library in an image is *not* to be taken
as linking to that library.

But if I never distribute the code in an image the above question is
moot ... I think.

It seems to me, then, that GPLed Smalltalk libraries can be used in
distributed (in the GPL sense) Smalltalk apps as long as the GPLed code
is not distributed as part of an image. If the app files-in (or loads
as a parcel) the GPLed library as part of it's installation or pulls it
in at runtime then this is not a part of the distribution process (in
the GPL sense).

Distributing a Smalltalk app as an image plus a number of files for
GPLed libraries seems to have a few advantages:

o The distributed app is clearly *not* linked to the GPLed code

o the requirements to make the source of GPLed code available is
addressed at the same time (as long as you don't ship "binary" parcel
files, for example).

o GPLed (rather than LGPLed) code can be used too

o The GPLed libraries are obviously distinct within a distribution which
means the recipient of the distribution can easily pick out and use the
library in other contexts if they wish.

But IANAL. It would be interesting to run this by a lawyer of my own
and then run it by Richard Stallman and Eben Moglen too.

There you go,
Bruce
Yanni Chiu

2007-10-03, 4:24 am

Bruce Badger wrote:
> But IANAL. It would be interesting to run this by a lawyer of my own
> and then run it by Richard Stallman and Eben Moglen too.


IIRC, it's been run by RS already, and his opinion was that pulling
Smalltalk code into an image would constitute "linking" in the GPL
sense. Also, use of LGPL code in an image would not exempt the rest of
the image from being "captured" by the license - but that's RS's
interpretation of LGPL. Attaching additional wording to express the
author's interpretation of LGPL (as is done with GLORP), certainly
helps, but the ultimate test would be an actual court case. IANAL.

[I can try to dig up the reference. It came up in one of the numerous
Squeak licensing threads.]

--
Yanni Chiu
Paolo Bonzini

2007-10-03, 4:24 am


> IIRC, it's been run by RS already, and his opinion was that pulling
> Smalltalk code into an image would constitute "linking" in the GPL
> sense.


IANAL, but I know the GPL and LGPL pretty well (especially v2, I still
have to get up to speed with v3 though I'll add something on v3 at the
end of this message).

I would say that usually, in a big image, you can identify parts that
are pretty self-contained and those would not be "tainted" by the
GPL. But any piece of code that "exchanges objects with" and/or
"sends messages to" the GPLed code, would. With this provision,
Bruce's reasoning applies correctly: distribute files and not images,
and the GPL does not touch you. However, if your files are written to
talk explicitly to GPLed code, it would be hard to convince a court
that they are logically independent and not constitute a derivative
work *according to the GPL* (which is not the same thing as a
derivative work according to English dictionaries, mind).

> Also, use of LGPL code in an image would not exempt the rest of
> the image from being "captured" by the license - but that's RS's
> interpretation of LGPL.


For the LGPL, I would say that loading something in an image
constitutes static linking. The LGPL is a bit more restrictive on
statically linked libraries (basically you have to distribute .o or .a
files for your application) than it is on shared libraries.

However, note that the GPL/LGPL are distribution licenses, and so they
apply to software that is distributed. If software is used in-house,
you can do whatever you want and the FSF is not going to complain (or
at least, not going to bring you in court). Google does it all the
time. ;-)

> Attaching additional wording to express the
> author's interpretation of LGPL (as is done with GLORP), certainly
> helps


Yes, and since LGPLv3 is now written as a series of additional
permissions that apply on top of GPLv3, it may be better to turn the
GLORP-like additional wording into a similar *explicit* series of
additional permissions. However, that needs care and needs to be done
by a lawyer.

Paolo

Steven Kelly

2007-10-03, 7:14 pm

"Bruce Badger" <bbadger@openskills.com> wrote in message
news:M_SdnbtpWMnhi57anZ2dnUVZ_tGonZ2d@to
tallyobjects.com...
> IANAL, but nonetheless I have been thinking about the GPL in the
> context of Smalltalk.

....
> It seems to me, then, that GPLed Smalltalk libraries can be used in
> distributed (in the GPL sense) Smalltalk apps as long as the GPLed
> code is not distributed as part of an image. If the app files-in
> (or loads as a parcel) the GPLed library as part of it's
> installation or pulls it in at runtime then this is not a part of
> the distribution process (in the GPL sense).


My understanding is that if you don't separate in this way, even LGPL
infects the whole app.

If you do separate, you'll have to consider the security implications.
If your app loads Base64Encoding.pcl, that could easily be replaced by
a more sinister file of the same name. With Smalltalk's reflexive
nature, a normal RunTimePackaged image can be pretty completely
reconstructed into a development image with a little code --
effectively open sourcing your app after all :-).

This problem with parcels can be overcome by digital signatures if you
are the only one distributing the parcels (e.g. sending people just an
updated Base64Encoded.pcl rather than the whole image, which used to
be important but isn't so much nowadays with megabit connections
everywhere). In the LGPL case, however, signature checks can't be
used. Forcing a signature check would break the LGPL, since the end
user couldn't change the source of Base64Encoding and swap in his new
version of the parcel.

Steve


Thomas F. Burdick

2007-10-03, 7:14 pm

On Oct 3, 8:24 am, Yanni Chiu <ya...@rogers.com> wrote:
> Bruce Badger wrote:
>
> IIRC, it's been run by RS already, and his opinion was that pulling
> Smalltalk code into an image would constitute "linking" in the GPL
> sense. Also, use of LGPL code in an image would not exempt the rest of
> the image from being "captured" by the license - but that's RS's
> interpretation of LGPL. Attaching additional wording to express the
> author's interpretation of LGPL (as is done with GLORP), certainly
> helps, but the ultimate test would be an actual court case. IANAL.
>
> [I can try to dig up the reference. It came up in one of the numerous
> Squeak licensing threads.]


The problem with the GPL and LGPL wrt Smalltalk is that the licenses
use such C-specific terminology. Over in the Lisp world, the LGPL has
been largely supplanted by the LLGPL, which is really just a preamble
to the LGPL written by Franz, a major Lisp vendor, in order to define
how the terminology used in the license applies to Lisp. It's obvious
why a major commercial vendor would want to use a license where
everyone is clear on what's allowed under what conditions, as opposed
to the mess you get with the LGPL in a dynamic environment. I'd say
they did a very good job, and the license preserves the basic give-and-
take of the LGPL from static languages. The preamble lives here:
http://opensource.franz.com/preamble.html

The third paragraph, which discusses subclassing, adding methods, and
redefinition, is pretty clearly relevant to Smalltalk, as is the
discussion of the status of anonymous functions. It would probably be
easy for an interested party to adapt this preamble to Smalltalk.
Although just going through the text and changing things to make it
work for Smalltalk would of course be a (rather ironic) violation of
Franz's copyright of the license preamble. But it would be well worth
reading for any ST'ers who want to release a library under an LGPL-
like license.


Paolo Bonzini

2007-10-03, 7:14 pm


> This problem with parcels can be overcome by digital signatures if you
> are the only one distributing the parcels (e.g. sending people just an
> updated Base64Encoded.pcl rather than the whole image, which used to
> be important but isn't so much nowadays with megabit connections
> everywhere). In the LGPL case, however, signature checks can't be
> used. Forcing a signature check would break the LGPL, since the end
> user couldn't change the source of Base64Encoding and swap in his new
> version of the parcel.


You can use signature checks under the GPLv3 provided that you tell
users how they can break them ("Installation Instructions").

Paolo

Steven Kelly

2007-10-04, 8:09 am


"Paolo Bonzini" <bonzini@gnu.org> wrote in message
news:1191420462.550013.273570@r29g2000hsg.googlegroups.com...
>
>
> You can use signature checks under the GPLv3 provided that you tell
> users how they can break them ("Installation Instructions").


Thanks Paolo, that's good to know! Still, not much use if the reason
for signature checks is to stop anyone from being able to reverse
engineer your application...

Steve


Bruce Badger

2007-10-04, 7:13 pm

Paolo Bonzini wrote:

> Bruce's reasoning applies correctly: distribute files and not images,
> and the GPL does not touch you. However, if your files are written to
> talk explicitly to GPLed code, it would be hard to convince a court
> that they are logically independent and not constitute a derivative
> work *according to the GPL* (which is not the same thing as a
> derivative work according to English dictionaries, mind).


What would "talk" mean in this context?

I understood that closed-source software can safely talk to GPLed
software using a wire protocol (e.g. CORBA or HTTP) without there being
any possibility of it falling under the GPL.

I also understood that installing and running a program on a Linux
system would not make a closed-source program fall under the GPL.

In both cases the closed-source program is talking to GPLed code and,
unless I am mistaken, would both remain independent of the GPL.

Smalltalk is late-binding. The code in an .st or .pcl file is not bound
(or linked) to any other code until it is loaded into an image much the
same as a program starting to execute on a Linux host.

I can see that if I shipped my code and GPLed code in an image then that
could easily be seen as linking my code to the GPLed code. But I would
have thought it would be easy to convince a court that my code in an .st
or .pcl file was independent of the GPL, even if at run time my code
"talked" to GPLed code.

What am I missing here?

All the best,
Bruce
Jecel

2007-10-04, 7:13 pm

On Oct 4, 11:01 am, Bruce Badger wrote:
> What am I missing here?


You are technically correct, but are missing the historical context.
RMS wants 100% Free Software and wasn't happy that when you ran "less"
in Irix the linking (very dynamic through sytem calls, but linking
even so) to the non free OS had to be accepted. But being strict about
this would have made it just too hard to bootstrap Free Software into
the world and so he was forced to be pragmatic.

When asked what he thought about GPL and Smalltalk more than a decade
later he felt no need to comprise in any way - Free Software was
already a fact and the Smalltalk community was not an important part
of that.

What really matters, of course, is what some judge would say about
this. But only a fool would ignore what RMS thinks - imagine what
impact it would have to have him called as a witness about what the
GPL really means.

-- Jecel

Bruce Badger

2007-10-05, 4:26 am

Jecel wrote:

> When asked what he thought about GPL and Smalltalk more than a decade
> later he [RMS] felt no need to comprise in any way - Free Software was
> already a fact and the Smalltalk community was not an important part
> of that.


Is this documented anywhere?

As it happens I acted as a kind of minder for RMS while he was in Sydney
once, so I have chatted with him about this. I don't recall him saying
anything that led me to think that "linking" could happen between pieces
of source code. My understanding is that "linking" can only happen when
compiled programs are brought together in particular ways.

I take your point about the weight of what RMS might say in a court
room, but even he can't just say what he feels like on the day and
expect that to trump all other arguments.
Paolo Bonzini

2007-10-05, 8:11 am


> I understood that closed-source software can safely talk to GPLed
> software using a wire protocol (e.g. CORBA or HTTP) without there being
> any possibility of it falling under the GPL.


Yes. However, there are at least three cases to consider (from a
historic point of view; this is written nowhere in the GPL):

1) You just interpret a protocol (HTTP) where the data on the wire is
there "like magic", you don't care how and why it is produced. Might
be a monkey typing at a keyboard. In this case there is no doubt:
your code doesn't fall under the GPL.

2a) You speak to a known interface (CORBA, Smalltalk objects, dynamic
libraries, OS system calls, ...) and many special cases conspire
against you. There is only one program that happens to provide that
interface, and it is under the GPL. It is not commonly installed on
computers, so you run it locally wherever your program runs. It is a
central piece of your program. Then, you are probably having a hard
time convincing a court that you're not violating the GPL.

2b) On the other hand, for example, if there are multiple implementors
of that interface (possibly the proprietary ones were already there
before the free ones) you're on safer grounds. If there are
alternatives under BSD or MIT license, probably you're not because you
have to explain why you're not using them!

> I also understood that installing and running a program on a Linux
> system would not make a closed-source program fall under the GPL. [...]
> Smalltalk is late-binding. The code in an .st or .pcl file is not bound
> (or linked) to any other code until it is loaded into an image much the
> same as a program starting to execute on a Linux host.


Yes, but while the first case (as well as the CORBA example) most
likely fall under 2b, I would say that in the Smalltalk case the
special cases I listed above are quite common, so you fall under 2a.
True, the actual message sends are late bound, but the interface is
not because it is explicit in the program source code. It is up to
you to prove that your intentions were more generic than using a GPL
parcel.

(Again, IANAL).

RMS has always been extremely kind and open to me when discussing the
license of GNU Smalltalk. I think that "Free Software was
already a fact and the Smalltalk community was not an important part
of that" is not representing his point of view faithfully. For
example, he agreed that it is pointless to make the rules for using
GNU Smalltalk extensions stricter than what happens for Perl/Ruby/
Python extensions.

Paolo

Bruce Badger

2007-10-05, 7:14 pm


After further reading it appears that I was hoping that shipping the .st
or .pst files would be what is called "Mere Aggregation" by the FSF.
The GPL FAQ seems to clear this up:

http://www.fsf.org/licensing/licens...MereAggregation


The key bit for me is: "If modules are designed to run linked together
in a shared address space, that almost surely means combining them into
one program."

If I ship a CD with Sport and Hyper in .st form and my closed-source
library in a .pcl (without source) this may appear at first glance to be
"Mere Aggregation", but since the distributed software is indeed
"designed to run linked together in a shared address space" (in an
image) it is not "Mere Aggregation" after all in the eyes of the FSF.
Luckily Sport and Hyper are under the LGPL so I'm safe :-)

I still don't see your point about CORBA though, Paolo. A CORBA client
would be (typically) in a different address space from a CORBA server,
so a CD full of things that interacted using CORBA would be a matter of
"Mere Aggregation", surely.
Terry Raymond

2007-10-05, 7:14 pm

Bruce Badger <bbadger@openskills.com> wrote in
news:M_SdnbtpWMnhi57anZ2dnUVZ_tGonZ2d@to
tallyobjects.com:

> IANAL, but nonetheless I have been thinking about the GPL in the
> context of Smalltalk.

[stuff deleted]
> o The distributed app is clearly *not* linked to the GPLed code
>
> o the requirements to make the source of GPLed code available is
> addressed at the same time (as long as you don't ship "binary" parcel
> files, for example).
>
> o GPLed (rather than LGPLed) code can be used too
>
> o The GPLed libraries are obviously distinct within a distribution
> which means the recipient of the distribution can easily pick out and
> use the library in other contexts if they wish.
>
> But IANAL. It would be interesting to run this by a lawyer of my own
> and then run it by Richard Stallman and Eben Moglen too.
>
> There you go,
> Bruce


Bruce

Why use the GPL license anyway? Take the license text
and modify it to accomodate your concerns and use that
as your license.

--
Terry
========================================
===================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI 02878
(401) 624-4517 traymond at craftedsmalltalk nospam dot com
<http://www.craftedsmalltalk.com>
========================================
===================
Jecel

2007-10-05, 10:14 pm

On Oct 5, 5:08 am, Bruce Badger wrote:
> Jecel wrote:
>
> Is this documented anywhere?


Indirectly - in the archives of the squeak-dev mailing list you can
find people reporting private email exchanges with RMS about this
subject. It would be hard for me to point out the exact messages right
now since the bi-annual license discussions were often very extensive.

> As it happens I acted as a kind of minder for RMS while he was in Sydney
> once, so I have chatted with him about this. I don't recall him saying
> anything that led me to think that "linking" could happen between pieces
> of source code. My understanding is that "linking" can only happen when
> compiled programs are brought together in particular ways.


Exactly - when you load a GPLed Smalltalk source into your image it is
compiled to bytecodes. Due to late binding, it is only loosely linked
to the rest of your system (not counting globals), so logic would say
that this is like a C program making system calls to an OS which is
loaded into the same memory. He doesn't see it that way, but in any
case we are not talking about any sort of source level linking.

> I take your point about the weight of what RMS might say in a court
> room, but even he can't just say what he feels like on the day and
> expect that to trump all other arguments.


Certainly a document's author's opinion is important in any discussion
about what that document actually means, though the opinions of the
judge and jury are the ones that actually count.

-- Jecel

Paolo Bonzini

2007-10-06, 4:25 am


> I still don't see your point about CORBA though, Paolo. A CORBA client
> would be (typically) in a different address space from a CORBA server,
> so a CD full of things that interacted using CORBA would be a matter of
> "Mere Aggregation", surely.


The FAQ is just an exemplification of the common cases. If you wanted
to use CORBA's separate address spaces just as a way to circumvent the
GPL and make it look like "Mere Aggregation", it's not going to
fly. :-)

Paolo

Bruce Badger

2007-10-06, 4:25 am

Terry Raymond wrote:
> Why use the GPL license anyway? Take the license text
> and modify it to accomodate your concerns and use that
> as your license.


By using a well known license I make it that bit easier for people to
use my code. If I produce my own license it may not work as I expect
(because I am not a lawyer) and it places a burden on users since they
have yet another license to understand.

I rather like the GPL and what it is trying to do. The reason for my
post was to make sure I really understood it. Clearly I did not :-/

I'm learning, though!


Bruce Badger

2007-10-06, 4:25 am

On Sat, 06 Oct 2007 00:59:10 -0700, Paolo Bonzini wrote:
> The FAQ is just an exemplification of the common cases. If you wanted
> to use CORBA's separate address spaces just as a way to circumvent the
> GPL and make it look like "Mere Aggregation", it's not going to
> fly. :-)


My aim is to understand where the boundaries are, not to break them :-)
Paolo Bonzini

2007-10-06, 8:09 am

> Exactly - when you load a GPLed Smalltalk source into your image it is
> compiled to bytecodes. Due to late binding, it is only loosely linked
> to the rest of your system (not counting globals), so logic would say
> that this is like a C program making system calls to an OS which is
> loaded into the same memory. He doesn't see it that way, but in any
> case we are not talking about any sort of source level linking.


Note that Linus is giving his own interpretation of the GPL by
allowing non-GPL modules (that run in kernel space, and thus are not
necessarily a "Mere Aggregation") and by saying basically that he does
not care about what proprietary user-level programs do.

However, say you have a user program and a kernel module going hand-in-
hand to do something, as is the case for example of oprofile. Then it
is only for technical reasons that they run in separate address spaces
and use pipes or devices to communicate. It would be perfectly right
to claim that other users of the kernel module also have to fall under
the GPL, if the copyright holder was interested in enforcing that.

Paolo

Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com