[squeak-dev] Swazoo - LGPL or MIT?

On 21/03/2008, Paolo Bonzini <[hidden email]> wrote:
>  If your changes are subclasses of something is clearly part of the
>  interface (you cannot use Swazoo without providing those subclasses, and
>  those subclasses are not important to other users of Swazoo), adding
>  your subclasses is not going to LGPL.

BTW, the later versions of the Swazoo http server I published to the
Cincom public Store repository did not have the requirement to
subclass Swazoo HTTP server classes.  The HTTP server and resource
management parts of Swazoo were distinct and the HTTP server was
started by giving it a block.  The block took a single argument (an
HTTP request) and was expected to return an HTTP response.  I never
used the resource management parts of Swazoo, but I did make sure that
all the tests passed for that part as I worked on the HTTP server.

I don't know if the older branch of Swazoo (which was announced as
Swazoo 1.0) included this work (I think it did not), nor if the work
has since been back-ported from Hyper, but it is there if you want to
pull it in from Store.  Alternatively you can just use Hyper which is
also under the LGPL but included the separation using blocks, though
it has moved on quite a bit since then (e.g. you can have the block
sent a stream instead of a pre-parsed request).

--
Make the most of your skills - with OpenSkills
http://www.openskills.org/

Bruce Badger wrote:

> All of the work that I contributed to the
> HTTP server was contributed under the LGPL, and Hyper (which is the
> current embodiment of that work) is under the LGPL.  I have no plans
> to change any of that.

Nice that now we know who is not willing (not even considering) to do
something and who is.

Janko.

--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

On 21/03/2008, Janko Mivšek <[hidden email]> wrote:
http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/665597fea7a67332/c769fb53823e1e94?lnk=st&q=#c769fb53823e1e94
>  > This is the first time I have heard anyone explicitly claim otherwise.
> See c.l.s thread above.

And later in that thread you said: "Hmm, I must admit that I see that
license statement for a first time.".  In the end of that thread it
was unchallenged that Swazoo was licensed under the LGPL.

The Swazoo SourceForge project was set up in March 2000.  Eight years
ago.  It clearly stated then that Swazoo was under the LGPL, and it
still does.

--
Make the most of your skills - with OpenSkills
http://www.openskills.org/

Andreas Raab wrote:
> Paolo Bonzini wrote:
>> If your changes are subclasses of something is clearly part of the
>> interface (you cannot use Swazoo without providing those subclasses,
>> and those subclasses are not important to other users of Swazoo),
>> adding your subclasses is not going to LGPL.
>
> I have always been wondering about this. Where exactly in the LGPL does
> it say that?

I think it is safe to interpret the LGPL in this way where it says:

1) "A program that contains no derivative of any portion of the Library,
but is designed to work with the Library by being compiled or linked
with it, is called a "work that uses the Library"."

2) "It is not the intent of [Section 2] to claim rights or contest your
rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Library".

Item 1 is respected, because subclassing leaves a clear separation
between the work and the library.  You can say that (the source of) a
subclass does not contain derivatives of any portion of the library.
Item 2 makes it clear what the spirit of Section 2 is, and the fact that
"subclasses are not important to other users of Swazoo" (as I wrote
above) qualifies them as "work written entirely" by the user, that is
simply "designed to work with the Library".

I also see a parallel with the equivalent of subclassing in C, which is
function pointers (and to vtables).  Overriding methods is basically
equivalent to passing a different function pointer table in a C library.
  Not overriding methods is equivalent to specifying a function exported
by the library in the table.

This, in principle, does not even exclude adding support for adding new
HTTP header fields and adding a single method that allows you to
register new HTTPHeaderField subclasses.  In that case however I'd be
careful because you are walking a finer line -- in Smalltalk everything
exported must be public, but that's not necessarily the case in other
languages, and it could be seen as exploiting "weaknesses" of a language
in order to circumvent the license.

If a package had a decent documentation, I think that could provide a
way to understand what is public just because of Smalltalk's lack of
private interfaces, and what is private.  Using private stuff or
subclassing it would be problematic.  *Modifying code always places the
result under the LGPL*.

That said, IANAL and I don't think a case like this has ever been tested
in court, not even for other languages than C/C++.

Paolo

Paolo Bonzini wrote:
I was going to argue that whether or not you can interpret the LGPL in
this way depends on whether or not you consider subclassing to be
creating a derivative work or not and was wondering whether the FSF has
ever had commented on that when, much to my suprise, a quick Google
search found the following statement in LGPL v3:

0. Additional Definitions.

[...]

An “Application” is any work that makes use of an interface provided by
the Library, but which is not otherwise based on the Library. Defining a
subclass of a class defined by the Library is deemed a mode of using an
interface provided by the Library.

A “Combined Work” is a work produced by combining or linking an
Application with the Library. The particular version of the Library with
which the Combined Work was made is also called the “Linked Version”.

[...]

So it appears that this issue has been settled with a more lenient
interpretation of subclassing than what I would have expected. The above
says that when you subclass you create a combined work, not a derivative
work. Section 4 of the LGPL still applies of course which effectively
means you have to provide source code (or a "suitable linking
mechanism") but you *can* use any license you want for your part of the
combined work.

Cheers,
   - Andreas

On 21/03/2008, Janko Mivšek <[hidden email]> wrote:

> Nice that now we know who is not willing (not even considering) to do
>  something and who is.

Well, barbs aside I think it would be helpful if the *current*
situation was clear.  So, are you willing to acknowledge that Swazoo
is indeed under the LGPL and update the information presented by
Squeak?

No matter which license is "best" for Swazoo, uncertainty is much worse.

--
Make the most of your skills - with OpenSkills
http://www.openskills.org/

On Fri, Mar 21, 2008 at 5:36 PM, Bruce Badger <[hidden email]> wrote:
> On 21/03/2008, Janko Mivšek <[hidden email]> wrote:
>  > Well, Swazoo license is still not seriously defined IMO
>
>  You can't change the license by just announcing that you have.
>
>  If you manage to persuade the people who contributed to Swazoo to
>  switch the license, then fair enough.  Until then, Swazoo is 100%
>  under the LGPL, no ifs no buts no doubt.

This is exactly the kind of situation Squeak needs to stay far away
from.  How much infected code are we talking about here?  Personally I
was considering going with Swazoo for some business websites I'm
doing, but this answers that question for me.

>  >  If you manage to persuade the people who contributed to Swazoo to
>  >  switch the license, then fair enough.  Until then, Swazoo is 100%
>  >  under the LGPL, no ifs no buts no doubt.
>
> This is exactly the kind of situation Squeak needs to stay far away
>  from.  How much infected code are we talking about here?  Personally I
>  was considering going with Swazoo for some business websites I'm
>  doing, but this answers that question for me.

This is the same for Seaside. All packages in the Seaside 2.9
repository are MIT licensed, including the Seaside-Swazoo adapters. If
there is the slightest doubt on one of the packages in there, we have
to move it somewhere else.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

Lukas Renggli wrote:
There is none, see the discussion between me and Andreas (I audited the
code in Seaside-Swazoo).

Paolo

What a sad day....Ready such license shit... It is amazing how laywers  
polute our life.
And this will continue endlessly.

I think that we should really be  strong about code license in the  
future.
It is a question of freedom and gain of energy: we should really stick  
to MIT.

This is amazing that license have to become so technical subclassing  
vs.... interface.
I hope that the release team is really make sure that no code without  
a clear license is
introduced in the image.


Stef

On Mar 22, 2008, at 8:05 AM, Lukas Renggli wrote:

On Sat, Mar 22, 2008 at 8:05 AM, Lukas Renggli <[hidden email]> wrote:
>
>  This is the same for Seaside. All packages in the Seaside 2.9
>  repository are MIT licensed, including the Seaside-Swazoo adapters. If
>  there is the slightest doubt on one of the packages in there, we have
>  to move it somewhere else.
>
>  Lukas

Personally I would move it.  I know there has been a discussion on
here about what is affected, but afaik not by lawyers.  And even they
are lawyers, until this part of the license has a precedence set in
court I think it's still a risk.  For example, if Seaside got popular
enough to pop up on the FSF radar, how do we know they wouldn't argue
from another angle that makes Seaside appear in violation.

It's best to avoid extremists from *either* side. :)

Just wondering how all of this fits in to the work that VisualWorks is doing with Seaside since it is a commercial product, and they have already started...

> Just wondering how all of this fits in to the work that VisualWorks is doing
> with Seaside since it is a commercial product, and they have already
> started...

I don't think that VisualWorks is using Swazoo code. They have their
own web server.

Squeak doesn't depend on Swazoo as well, so it is not really an issue
for anybody. These are just some optional server-adapter packages that
have to be moved somewhere else.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

AFAIK the ported seaside code should not be part of the commercially licenced VW
code. It should be a MIT piece of software running on top of a commercial one
(like Squeak runing on Win32/Mac). But I'm not an expert, just common sense.

        cheers,
 
Sebastian Sastre

 

 


________________________________

        De: [hidden email]
[mailto:[hidden email]] En nombre de Rob Rothwell
        Enviado el: Sábado, 22 de Marzo de 2008 13:45
        Para: The general-purpose Squeak developers list
        Asunto: Re: [squeak-dev] Re: Swazoo - LGPL or MIT?
       
       
        Just wondering how all of this fits in to the work that VisualWorks is
doing with Seaside since it is a commercial product, and they have already
started...

        Rob
       
       
        On Sat, Mar 22, 2008 at 12:40 PM, Jason Johnson
<[hidden email]> wrote:
       

                On Sat, Mar 22, 2008 at 8:05 AM, Lukas Renggli
<[hidden email]> wrote:
                >
                >  This is the same for Seaside. All packages in the Seaside 2.9
                >  repository are MIT licensed, including the Seaside-Swazoo
adapters. If
                >  there is the slightest doubt on one of the packages in there,
we have
                >  to move it somewhere else.
                >
                >  Lukas
               
                Personally I would move it.  I know there has been a discussion
on
                here about what is affected, but afaik not by lawyers.  And even
they
                are lawyers, until this part of the license has a precedence set
in
                court I think it's still a risk.  For example, if Seaside got
popular
                enough to pop up on the FSF radar, how do we know they wouldn't
argue
                from another angle that makes Seaside appear in violation.
               
                It's best to avoid extremists from *either* side. :)
               
               

> Personally I would move it.  I know there has been a discussion on
> here about what is affected, but afaik not by lawyers.  And even they
> are lawyers, until this part of the license has a precedence set in
> court I think it's still a risk.  For example, if Seaside got popular
> enough to pop up on the FSF radar, how do we know they wouldn't argue
> from another angle that makes Seaside appear in violation.

I don't understand why I am still subscribed to this mailing list if all
I can read here is shit like this.  Why should the FSF give a damn about
Seaside?  They are not the copyright holders of Swazoo.

True, I and Andreas are not lawyers (and even if I were, the legal
system in my country is completely different), but at least we try to
make sense.

Paolo

On Sat, Mar 22, 2008 at 7:04 PM, Paolo Bonzini <[hidden email]> wrote:
>
>  I don't understand why I am still subscribed to this mailing list if all
>  I can read here is shit like this.  Why should the FSF give a damn about
>  Seaside?

I don't know, but I don't know why they would care about CLISP either:

http://clisp.cvs.sourceforge.net/*checkout*/clisp/clisp/doc/Why-CLISP-is-under-GPL

I don't know what makes RMS want to go after someone but I find it
best to simply avoid these kinds of situations.  (Also note the
extreme views by the FSF founder in this email exchange do not seem to
agree with what has been said in this thread).

On 22-Mar-08, at 10:05 AM, Sebastian Sastre wrote:

> AFAIK the ported seaside code should not be part of the commercially  
> licenced VW
> code. It should be a MIT piece of software running on top of a  
> commercial one
> (like Squeak runing on Win32/Mac). But I'm not an expert, just  
> common sense.

Not necessarily.  The MIT license allows Cincom to do pretty much  
whatever they want with Seaside, including sublicensing it to their  
customers under a comercial license. As long as Cincom isn't charging  
extra for Seaside, It probably doesn't matter much, because you can't  
run Seaside on VW without a license from Cincom anyway, but it's  
probably worth clarifying.

Colin

> I don't know, but I don't know why they would care about CLISP either:
>
> http://clisp.cvs.sourceforge.net/*checkout*/clisp/clisp/doc/Why-CLISP-is-under-GPL
>
> I don't know what makes RMS want to go after someone

Infringing his own copyright.  CLISP was using a *GPL* library (not
LGPL) copyrighted by the FSF, namely GNU Readline.

Paolo

On Sat, Mar 22, 2008 at 7:35 PM, Paolo Bonzini <[hidden email]> wrote:
Right, but the point is the behavior, not the specific license.  CLISP
was barely using readline (just an unnecessary dress up of the UI) and
even after the maintainer offered to repackage CLISP not to use it,
RMS still wanted CLISP to be GPL'ed because it *could* be used with
readline.

2008/3/22, Colin Putney <[hidden email]>:
I don't see how money has anything to do with with. Even charging for
GPL software is ok by anybody including the FSF.

Cheers
Philippe


> It probably doesn't matter much, because you can't
>  run Seaside on VW without a license from Cincom anyway, but it's
>  probably worth clarifying.
>
>
>  Colin
>
>