Which Python web framework is most like Ruby on Rails?

Paul Rubin http
Wed Dec 21 22:40:07 CET 2005


(Responding to several posts)

"Ben Sizer" <kylotan at gmail.com> writes:
> > 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....

> "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.

Hmmm.  I seem to remember RMS saying that the GPL didn't extend to
Emacs Lisp functions that the user writes, even though those call
various built-in Emacs functions, as long as they use the documented
API.  Those certainly run in the same address space as Emacs.  This is
the closest thing I can think of to the Karrigell situation.

    [Alex Martelli re triple-licensing BSD/GPL/LPGL]

    > 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...).

The resulting combined program could be distributed only under the
GPL, not the BSD license.  A single-licensed BSD app already allows
distributing modified versions under the GPL (or even proprietary).

    [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?

I'm not sure exactly how py2exe works.  If it's basically just a
self-extracting archive, it doesn't sound like a problem, it's like
many distros that include the Linux kernel plus some applications.
(Although, I have to say, I've never really liked that practice and am
not sure why it's allowed, but it's done all the time).  If it's a
more complex integration, you may need to make two separate
installers, where the first one would install Python and Karrigell,
and the second one would add your application files.  There are
various technical advantages to that anyway (makes it easier to
incrementally upgrade your application, etc).  

    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.

OK, I'm no longer so terribly confident that there isn't a problem.
Again though, I see this as similar to the Emacs Lisp situation.  I
wonder if that Emacs Lisp situation is considered a GPL exception.  I
might ask RMS about this sometime.

GNU Classpath has an explicit exception:

  http://www.gnu.org/software/classpath/license.html

but I'd think that would prevent merging parts of (say) GCC into GNU
Classpath.

    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?

Yes, that's the point of using the GPL on a library instead of the
LGPL.  So the Emacs example, if it doesn't rely on an exception, must
rely on the notion that Emacs isn't a library.



More information about the Python-list mailing list