Which Python web framework is most like Ruby on Rails?

[Robert Kern]

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


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

If K were to be dual licensed GPL/BSD, Pierre could not take some GPLed third
party code, incorporate it into K, and distribute K+3rdparty under both
licenses. 3rdparty would always be under the GPL, and the GPL conditions would
apply to the combination as a whole. That's the scenario Paul is referring to.

Of course, someone who is not Pierre who wants to distribute a web app with K
and some third party GPL module can do so just as well if K is only BSD-licensed
since BSD is compatible with the GPL. Dual licensing would only be necessary if
the alternative licenses were incompatible, e.g. Artistic/GPL like Perl or
MPL/GPL like Mozilla.

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

 

[Fredrik Lundh]

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 ?

see the section "Which open source license should I use?" on this page
for some solid advice, from a Python perspective:

http://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq

</F>

 

[Dennis Lee Bieber]

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.

<heh> You haven't seen the thread that formed on comp.lang.ada a few
months ago -- when AdaCore released its latest GNAT/GPS system and
changed the license on the runtime from GMGPL to plain GPL... I believe
the consensus was that the current GNAT can not be used for closed
distribution of applications unless it can run without linking the
runtime library (at which point, one may as well code raw assembly to
the hardware level).
--

 

[Martin Christensen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kent> In the text you quoted I said, "a small in-house project that
Kent> might possibly be distributed to business partners or become a
Kent> product some day." Sounds like distribution to me.

My bad. I somehow managed to miss that.

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

iEYEARECAAYFAkOplbwACgkQYu1fMmOQldXsSwCg0TRh98gcr+0xzhN4mKFCq3y8
SScAoICVaFIStF6PWfo+DZKo/v+WRicc
=69ov
-----END PGP SIGNATURE-----

 

[Paul Rubin]

(Responding to several posts)

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.

 

[Pierre Quentel]

Just to add some more confusion to the discussion, here is what I've
found about other web frameworks :
CherryPy : BSD
Django : BSD
Jonpy : Python licence
Quixote : CNRI
Skunkweb : GPL or BSD
Snakelets : MIT
Subway : ? + licence of the components
PythonWeb : LGPL (will consider BSD-Style or Python if LGPL is a
problem)
Turbogears : MIT + licence of the components
Twisted : LGPL
Webware : Python licence
Zope : ZPL (Zope Public Licence)

There doesn't seem to be an obvious choice, but the GPL isn't used much
here

Regards,
Pierre

 

[Kent Johnson]

[Kent Johnson]
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.

It's not clear to me how my use of CherryPy as a web app framework is different, from the
point of view of the GPL, from how I might use something that we both would call a
library. From the client code it is pretty similar. In both cases I might import modules,
instantiate and subclass classes and call functions and methods from the library. If there
is a difference it seems the GPL is relying on pretty subtle distinctions to determine
whether my code is a "work based on the Program."

Kent

 

[Richie Hindle]

[Paul]

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.

Paul, you keep making comparisons between Python web frameworks and the
Linux kernel. Are you aware that there is a special note attached to the
Linux GPL[1] explaining that user-space code is not considered a derived
work of the Linux kernel? Without that note, user-space code *could* be
considered a derived work of the kernel (obviously, or Linus Torvalds would
not have included the note). Unless a GPL web framework carries a similar
notice, the comparison doesn't hold up.

[1] http://www.linux-m32r.org/lxr/http/source/COPYING

 

[Paul Rubin]

Paul, you keep making comparisons between Python web frameworks and the
Linux kernel. Are you aware that there is a special note attached to the
Linux GPL[1] explaining that user-space code is not considered a derived
work of the Linux kernel? Without that note, user-space code *could* be
considered a derived work of the kernel (obviously, or Linus Torvalds would
not have included the note).

I don't think that note is part of the license. It just clarifies
what's already inherent, since probably a lot of people asked. If the
note were really necessary, then the license would not be GPL, it
would be "GPL plus note". In that case it would be impermissible to
insert any strict-GPL code into the kernel and distribute it. Since
there is such code in the kernel (FSF code even), I think there's no
problem even without the note.

 

[A.M. Kuchling]

Python people don't really think that way. As a community we really
seem to inherit the open source dysfunction of trying harder to impress
each other than to reach out to the rest of the world. The problem is

Yes; I've long worried about this, but have no idea how to fix the
problem. Python users largely talk to other Python users, not to the
world at large.

--amk

 

[Ed Singleton]

Yes; I've long worried about this, but have no idea how to fix the
problem. Python users largely talk to other Python users, not to the
world at large.

A good start would be for there to be a way for newbies to get heard
more easily.

Newbies were all quite recently nonPythonPeople, and as such have some
very valuable insights into what it is like being a normal,
nonPythonPerson.

They normally get told they aren't pythonic yet, or that they should
write a PEP, or some such.

Ed

 

[A.M. Kuchling]

A good start would be for there to be a way for newbies to get heard
more easily.

I don't see the connection between "Python users talk too much to
other Python users" and "newbies don't get heard".

--amk

 

[Ed Singleton]

I don't see the connection between "Python users talk too much to
other Python users" and "newbies don't get heard".

I wasn't particularly saying that there was a direct connection. You
said you had been worrying about the problem of Python suffering from
the "open source dysfunction" and had no idea how to fix it. I was
suggesting one of the main ways of fixing it.

In a little greater depth:

Open source suffers from insularity because the community places a
huge emphasis on reputation. Reputation is necessarily built-up over
time and once people have reputation they tend to forget what it is
like to not have it. (Additionally the type of person required to
expend that much effort in building up reputation tends not to spend
much time doing other, more "normal" things).

Thus the people who are listened to the most in any OSS community are
those who tend to know less about what it is like completely outside
of the OSS world.

These people tend to naturally gather to talk to each other, and they
tend to stratify themselves, generally paying good attention to those
above them and (in better communities like this one) those on the same
level and just below.

This leads to them insulating themselves even more from "reaching out
to the real world".

Luckily there is a large group of people who are involved in the
community but have recently been participating in the real world.
They have a strong understanding of what needs to be done to "reach
out to the real world", because they themselves have just recently
been reached out to.

They are the newbs.

Ed

PS If you don't know how to reach out to the real world, then by
definition you are not listening to newbs.

PPS Some cool sayings about newbs:

"The newbs shall inherit the earth"

"The future's bright; the future's newb"

"We don't inherit the OSS community from it's leaders; we merely
borrow it from the newbs"

 

[Kent Johnson]

Yes; I've long worried about this, but have no idea how to fix the
problem. Python users largely talk to other Python users, not to the
world at large.

I've talked to plenty of non-Python people about Python. The hard part for me is getting
them to believe me enough to try Python for themselves.

Kent

 

[Gregory Petrosyan]

+1 for Kid -- it's more pythonic IMHO.

 

[Jeff Rush]

Luis M. Gonzalez wrote:


From my point of view the biggest problem with Karrigell is that it is released under the
GPL. Most of my projects at least have the potential of being distributed to customers and
GPL is not an option.

I don't understand your issue, as it applies to Python programs.

The GPL would (a) require you to supply the source to your customers,
and (b) allow them
to pass it on to others. But since Python programs are delivered as
source (.py files), or easily
decompiled bytecode (.pyc file), they have the source anyway, as well as
the static HTML
files for your app.

Python doesn't have a secure binary-only distribution format, so the
question of protecting
your IP via an obscurement mechanism is moot.

And using a BSD-like license doesn't help since they still have the
source in Python, and
BSD allows them to redistribute that.

Your only solution would be a proprietary license that states you
purchased this program
and don't have the right to pass it on to others, similar to ActiveState
or somesuch.

The real hook would seem to be the social one that you provide support
and improvements
so they need to keep you in business.

-Jeff

 

[Paul Rubin]

Your only solution would be a proprietary license that states you
purchased this program and don't have the right to pass it on to
others, similar to ActiveState or somesuch.

It sounds like that's what Kent wants to do with the apps that he's
building. That's not permitted under the GPL, if the apps contain or
are based on GPL code. What's not totally clear is whether that
affects Karrigell apps (apps that run under Karrigell and call
Karrigell functions but don't modify Karrigell itself).

 

[Robert Kern]

It sounds like that's what Kent wants to do with the apps that he's
building. That's not permitted under the GPL, if the apps contain or
are based on GPL code. What's not totally clear is whether that
affects Karrigell apps (apps that run under Karrigell and call
Karrigell functions but don't modify Karrigell itself).

I believe that it's the FSF's view that importing a GPLed module triggers the
GPL conditions in analogy with dynamic linking for C and other such languages
(presuming the code is being distributed at all). I think it's reasonably safe
to say that most authors who choose the GPL deliberately also assume the FSF's
interpretation. Debian, for example, also holds to this interpretation and will
reject a GPL-incompatible Python package that imports a GPLed Python package as
not legal to distribute.

No court has ever ruled on the issue, and some people, like Larry Rosen, think
it's likely that a judge would not choose the FSF's interpretation. I think
Rosen is probably correct. However, I always assume that the author intends the
FSF's interpretation unless they make an explicit exception, and I respect that
intention.

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

 

[Robert Kern]

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.

RMS has said precisely the opposite, in fact.

http://lists.debian.org/debian-legal/2002/11/msg00217.html

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

 

[Paul Rubin]

RMS has said precisely the opposite, in fact.
http://lists.debian.org/debian-legal/2002/11/msg00217.html

I guess you mean:

[RMS:]
As for the more general question, we think that a program that uses
Emacs facilities needs to be GPL-covered, but a program that just uses
the Lisp language could have any license--it is not affected by the
license of Emacs.

Hmmm. That seems to say that calling Emacs-specific editing
functions, doing stuff with buffers, etc. implicates the GPL, but
writing a general purpose Lisp program (non-Emacs-specific) and
running it under Emacs does not. That's different from what I'd
thought he'd said about it before, which was that Lisp code that only
used the documented Emacs API didn't implicate the GPL. Thanks for
the link.