Which Python web framework is most like Ruby on Rails?

[Paul Rubin]

Indeed. But most software authors aren't lawyers and aren't likely to
trust their own judgment about these matters unless the situation is
pretty unambiguous. I suspect this may be evidence that Microsoft's
"viral" propaganda has had some effect.

Hmm, good point.

In this case I agree there's likely to be a clear separation between
server and content that will allow Kent to distribute an unmodified
Karrigell and a separate proprietary content bundle without
interference, but it's too late (at least for that project) now.

Oh well.

 

[Pierre Quentel]

I definitely don't want to invent another licence, there are enough of
them already !
Pierre

 

[Ben Sizer]

My own hope (not shared by everyone obviously) is that you will stay
with the GPL, but make clear that applications that simply run under
Karrigell but don't modify the Karrigell code aren't subjected to the
GPL. That should satisfy Kent's concerns.

Unfortunately, that doesn't really satisfy the GPL's concerns. The work
arguably "contains or is derived from" Karrigell, which is explicitly
covered in section 2b of the GPL. If you start excluding key clauses
from the GPL, then there's little point using it.

To cut a long story short, and to avoid quibbling over the details of
how a license designed with the low-level mechanics of C-style programs
and libraries in mind actually applies to a language like Python with
very loose coupling, I'll just say that this sort of situation is
exactly what the LGPL exists for. I would suggest the author adopts the
LGPL as a good compromise between the community benefits of GPL and the
user benefits of, say, BSD or zlib licenses.

 

[Paul Rubin]

Unfortunately, that doesn't really satisfy the GPL's concerns. The work
arguably "contains or is derived from" Karrigell,

I don't see that. The web app gets run by Karrigell like a CGI script
is run by Apache, like a Linux app is run by the Linux kernel. The
Linux kernel is GPL but that doesn't mean every Linux app that calls
through the kernel through its documented API is affected. The Linux
kernel GPL only comes into play if you start modifying the kernel, not
writing programs that use it.

which is explicitly covered in section 2b of the GPL. If you start
excluding key clauses from the GPL, then there's little point using it.

There should be no exclusion.

To cut a long story short, and to avoid quibbling over the details of
how a license designed with the low-level mechanics of C-style programs
and libraries in mind actually applies to a language like Python with
very loose coupling, I'll just say that this sort of situation is
exactly what the LGPL exists for.

The LGPL has fallen into some disfavor at the FSF, and I don't see
Karrigell as a library. The application is not an integrated blob
combining Karrigell and user code, from what I can tell. Rather, the
user code is run under Karrigell's control, like Karrigell itself
is run under the Python interpreter.

I would suggest the author adopts the LGPL as a good compromise
between the community benefits of GPL and the user benefits of, say,
BSD or zlib licenses.

But that doesn't gain the community benefits of the GPL since it
foregoes the possibility of users improving Karrigell by incorporating
other GPL'd code into it and distributing the improved version.

 

[Richie Hindle]

[Pierre]

I am Karrigell's author. I have chosen the GPL licence almost at random
(I saw that the Python licence was GPL-compatible), so I don't mind
switching to another Open Source licence if the GPL is liable to cause
problems. Which one would you advice : BSD ? Python licence ? another ?

Well done on being open-minded!

You will hear valid arguments for GPL, LGPL, BSD and other licenses (though
the Python license is unsuitable for anything other than Python - see
http://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq)

A good solution would be multiple-licensing. You state that the code is
(for example) triple-licensed under the GPL, LGPL and BSD licenses. The
user of your code decides which license to obey. It's no more work for you,
and you can please almost everyone (the only people you won't please are
those who believe that there is One True License, and frankly you should
ignore them - it's your code).

The only downside of allowing people to choose the BSD license rather than
the GPL is that potentially someone can choose the BSD license, improve
Karrigell, ship their product based on the improved code, and not give those
improvements back to the community. But the Python license allows for this
too, and Python hasn't suffered for it. IMO choosing a BSD license will get
you more users than GPL, and the benefits of that will outweigh the
potential downside.

 

[Paul Rubin]

A good solution would be multiple-licensing. You state that the
code is (for example) triple-licensed under the GPL, LGPL and BSD
licenses. The user of your code decides which license to obey.
It's no more work for you, and you can please almost everyone (the
only people you won't please are those who believe that there is One
True License, and frankly you should ignore them - it's your code).

That's silly, you might as well just use BSD instead of triple
licensing like that.

The only downside of allowing people to choose the BSD license
rather than the GPL is that potentially someone can choose the BSD
license, improve Karrigell, ship their product based on the improved
code, and not give those improvements back to the community.

Another downside to BSD is that it becomes impermissible to improve
Karrigell by transplanting GPL code into it from other programs. Yet
another downside is that it leads some potential contributors to not
bother getting involved with such projects. (On the other hand, it
possibly attracts some different potential contributors).

But the Python license allows for this too, and Python hasn't
suffered for it.

That Python hasn't suffered for it is a questionable assertion.

IMO choosing a BSD license will get you more users than GPL, and
the benefits of that will outweigh the potential downside.

Of course anyone is entitled to hold any opinion they choose. I have
to say both notions expressed there (that BSD will attract more users,
and that merely attracting more users produces such big benefits) are
questionable. As for me, for something like this, I'd be more
interested in attracting more contributors than in merely attracting
more users with me doing all the work. But what Karrigell's author
wants is of course purely up to the him.

 

[Kent Johnson]

You may be right, I honestly don't know. Would your interpretation change if I wanted to
distribute an app built with py2exe that bundles Karrigell and my code?

Indeed. But most software authors aren't lawyers and aren't likely to
trust their own judgment about these matters unless the situation is
pretty unambiguous.

That really is the issue as much as anything. Paul has raised some good questions for
which I don't have good answers. Maybe using Karrigell is analogous to writing an app to
run on Linux. OTOH maybe it is more like linking to a library. I could ask the author for
clarification - which I would then have to document in a form acceptable to my own
company's lawyers. Or I could choose to use a product that doesn't leave any doubt that I
can distribute it as I like in a proprietary product.

I suspect this may be evidence that Microsoft's
"viral" propaganda has had some effect.

Not in my case, at least. I have been avoiding GPL products at work for many years, much
longer than Microsoft has been telling me to do so.

In this case I agree there's likely to be a clear separation between
server and content that will allow Kent to distribute an unmodified
Karrigell and a separate proprietary content bundle without
interference, but it's too late (at least for that project) now.

Maybe next time...

Kent

 

[Raffaele Salmaso]

Pierre Quentel ha scritto:

Hello all,

I am Karrigell's author. I have chosen the GPL licence almost at random
(I saw that the Python licence was GPL-compatible), so I don't mind
switching to another Open Source licence if the GPL is liable to cause
problems. Which one would you advice : BSD ? Python licence ? another ?

I think you should use the BSD or the Python License.
I've choose the BSD for my works, with these clauses (my intentions are
clearly stated, so no misinterpretation should be done):

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. If the binary program depends on a modified version of this package,
you are encouraged to publicly release the modified version of this
package.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
HOLDERS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

And it is almost the same of CherryPy, which you use.

--
()_() | Ho un cervello, non sono analfabeta e non sento | +----
(o.o) | l'irrefrenabile bisogno di deturpare la mia lingua | +---+
'm m' | madre con "K" ed abbreviazioni... | O |
(___) | K.K.K (Kill the "Key" Klub)|
raffaele punto salmaso at gmail punto com

 

[Arthur Clune]

OK I'll try. First let me say I have no interest in a licensing flame war, there are valid
reasons why an author might prefer one license over another and certainly there are good
reasons to choose GPL. However the work I do is commercial and proprietary and I doubt I
could get approval to release it under GPL. So I am restricted to projects with more
liberal licenses such as MIT, BSD and Apache licenses. These allow closed-source
distribution of products based on them.

As long as the author holds copyright on all the code, he can release it to you under
any license he wants, as well as via GPL to the world (this is how MySQL and SleepyCat
opterate).

So you could, for example, offer him X pounds/dollars/euros for a BSD version + support
etc.

Arthur

 

[Fuzzyman]

BSD license is good. It requires that your copyright notice be included
with any derivative works - but otherwise lets users create and
distribute derivatives how they see fit. The version I use is at
http://www.voidspace.org.uk/python/license.shtml (which links to the
version at the OSI).

The MIT license is even *less* restrictive. I would use one or other of
these two.

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

 

[Kent Johnson]

Let me ask it this way: suppose you used ASP instead. As I understand
ASP, it's like PHP except it's proprietary. Would ASP's license be a
problem?

Maybe you're using "the server" to encompass too much. If I have an
Apache-based web site, then the web server is Apache. If I have a
Python CGI script that the Apache server runs, the CGI script is not
"the server"--it's an application running under the server. It would
not be affected by the GPL if Apache used the GPL. Karrigell scripts
seem to me to work out about the same way.

You may be right, I don't know. In the case of CherryPy, my code is a bit more intimate
with CP than a CGI is with Apache - I import CP modules, subclass CP classes and make
calls to CP functions from my code. My guess is a Karrigell-based server would be similar.

Where would you draw the line? Suppose I want to use a GPLed library in my Python code,
does that mean I have to distribute my code under the GPL if I distribute them together?

Kent

 

[Ben Sizer]

I don't see that. The web app gets run by Karrigell like a CGI script
is run by Apache, like a Linux app is run by the Linux kernel.

The web app uses parts of Karrigell though - things like the QUERY
variable or or Session object. That is analogous to linking with
Karrigell as a library.

The LGPL has fallen into some disfavor at the FSF, and I don't see
Karrigell as a library.

The LGPL ultimate subverts the intent of the GPL in that it lets people
use open source code without having to give much back. Still, it is
'better' in that regard than BSD or zlib. The only practical difference
in this case would be that the LGPL makes it clear that there's a
separation between your code and Karrigell code.

The application is not an integrated blob
combining Karrigell and user code, from what I can tell. Rather, the
user code is run under Karrigell's control, like Karrigell itself
is run under the Python interpreter.

I see your point, but I think 95% of Karrigell apps will end up making
calls back into the framework. The intent of the GPL is arguably that
if you rely directly upon some GPL code for your application, your app
falls under the license.

From: http://www.gnu.org/licenses/gpl-faq.html#MereAggregation :

"What constitutes combining two parts into one program? This is a legal
question, which ultimately judges will decide.[...] If modules are
designed to run linked together in a shared address space, that almost
surely means combining them into one program.

By contrast, pipes, sockets and command-line arguments are
communication mechanisms normally used between two separate programs.
So when they are used for communication, the modules normally are
separate programs. But if the semantics of the communication are
intimate enough, exchanging complex internal data structures, that too
could be a basis to consider the two parts as combined into a larger
program. "

This is largely academic since the author seems willing to reconsider
the license; but it's an interesting point for applications like this
generally, especially in Python where 'linking' is a little less
stringently defined than in C/C++.

 

[Scott David Daniels]

You will hear valid arguments for GPL, LGPL, BSD and other licenses (though
the Python license is unsuitable for anything other than Python - see
http://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq)

A good solution would be multiple-licensing. You state that the code is
(for example) triple-licensed under the GPL, LGPL and BSD licenses.

One lawyer I talked to (who could not understand why I wanted to
open-source any code), claimed that the MIT license is better
written (legally) to protect the author from acquiring legal
liability.

--Scott David Daniels
(e-mail address removed)

 

[Martin Christensen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kent> [Karrigell is GPL'ed] Unfortunately this makes it impossible for
Kent> me to consider using Karrigell in my work. I recently needed a
Kent> stand-alone web server for a small in-house project that might
Kent> possibly be distributed to business partners or become a product
Kent> some day. I chose CherryPy in part because its license allows
Kent> this. I would have considered Karrigell if it had a different
Kent> license.

None of this really matters, you know. The GPL only requires that you
share your source code if you _distribute_ your modifications. Since
you make your modifications exclusively for your own (your company's)
use, you are not required to share anything. Thus the whole debate is
pretty much moot if I am not much mistaken.

Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAkOpbaUACgkQYu1fMmOQldUR/QCffOi9bYnmUeEcT8zdvF60voah
cy4AoIb69dAv6dr6WmpaIZPipq1xZbF0
=/eTj
-----END PGP SIGNATURE-----

 

[Pierre Quentel]

In Karrigell the scripts are executed in a namespace prepared by the
framework, with HTTP environment, form data, the functions and
exceptions for authentication, session management, redirection etc.
I suppose that this falls into the first category above, "modules
(that) are designed to run linked together in a shared address space" ;
the link between the framework and the scripts is certainly much
tighter than between a web server and a CGI script

Pierre

 

[Martin Christensen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ben> Unfortunately, that doesn't really satisfy the GPL's concerns.
Ben> The work arguably "contains or is derived from" Karrigell, which
Ben> is explicitly covered in section 2b of the GPL. If you start
Ben> excluding key clauses from the GPL, then there's little point
Ben> using it.

You will also notice that section 2b of the GPL only applies to works
that are published or distributed, and if a company bases its web site
on Karrigell or any other GPL'ed web framework but does not share the
code with anyone, it cannot be considered to be published nor
distributed. Hence the GPL is a perfectly fine license for this kind
of use.

Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAkOpb34ACgkQYu1fMmOQldUApQCgxPvp3ozRGo+/J5kJlY+htd4T
F/IAoLBlMz0Z9eamIDqsInaa4bPyxgyd
=UXUa
-----END PGP SIGNATURE-----

 

[Kent Johnson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Kent> [Karrigell is GPL'ed] Unfortunately this makes it impossible for
Kent> me to consider using Karrigell in my work. I recently needed a
Kent> stand-alone web server for a small in-house project that might
Kent> possibly be distributed to business partners or become a product
Kent> some day. I chose CherryPy in part because its license allows
Kent> this. I would have considered Karrigell if it had a different
Kent> license.

None of this really matters, you know. The GPL only requires that you
share your source code if you _distribute_ your modifications. Since
you make your modifications exclusively for your own (your company's)
use, you are not required to share anything. Thus the whole debate is
pretty much moot if I am not much mistaken.

In the text you quoted I said, "a small in-house project that might
possibly be distributed to business partners or become a product
some day." Sounds like distribution to me.

Kent

 

[Robert Kern]

Kent> [Karrigell is GPL'ed] Unfortunately this makes it impossible for
Kent> me to consider using Karrigell in my work. I recently needed a
Kent> stand-alone web server for a small in-house project that might
Kent> possibly be distributed to business partners or become a product
Kent> some day. I chose CherryPy in part because its license allows
Kent> this. I would have considered Karrigell if it had a different
Kent> license.

None of this really matters, you know. The GPL only requires that you
share your source code if you _distribute_ your modifications. Since
you make your modifications exclusively for your own (your company's)
use, you are not required to share anything. Thus the whole debate is
pretty much moot if I am not much mistaken.

Did you read anything Kent wrote?

Specifically: "project that might possibly be distributed to business partners
or become a porduct some day."

--
Robert Kern
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

 

[Alex Martelli]

That's silly, you might as well just use BSD instead of triple
licensing like that.

You're pointing out yourself, a few lines lower, while this isn't so:

Another downside to BSD is that it becomes impermissible to improve
Karrigell by transplanting GPL code into it from other programs. Yet

....which obviously is not a problem if K is available under either GPL
or BSD at the user's choice: anybody wanting to transplant GPL code into
it will pick the GPL side of the dual-licensing (I don't see any further
advantage in adding LGPL to the mix, maybe I'm missing s/thing...).

That Python hasn't suffered for it is a questionable assertion.

Feel free to question it, then -- but "the burden of proof is on the
positive", by normal rules of debate. Where are the versions of Python
made proprietary by exploiting its unGPLness? OTOH, I don't consider it
a "suffering to Python" that it gets embedded for scripting tasks in
such closed-source apps as Poser or Civilization IV: I believe (and you
can check with the respective companies) that since those companies had
chosen closed-source as their main business strategy, if embedding
Python had forced them to opensource their "engines" they'd simply have
chosen another language for their scripting part (indeed, too many
proprietary apps already use proprietary scripting languages for the
silliest reasons -- giving them another reason would be a disaster).
At the same time Python also thrives in open-source apps such as O,
just about all Linux distros, and so on, and so forth.


Alex

 

[Ben Sizer]

Ben> Unfortunately, that doesn't really satisfy the GPL's concerns.
Ben> The work arguably "contains or is derived from" Karrigell, which
Ben> is explicitly covered in section 2b of the GPL. If you start
Ben> excluding key clauses from the GPL, then there's little point
Ben> using it.

You will also notice that section 2b of the GPL only applies to works
that are published or distributed, and if a company bases its web site
on Karrigell or any other GPL'ed web framework but does not share the
code with anyone, it cannot be considered to be published nor
distributed. Hence the GPL is a perfectly fine license for this kind
of use.

You're right, but, Kent said earlier in the thread that "Most of my
projects at least have the potential of being distributed to customers
and GPL is not an option." I was addressing this concern specifically.