Which Python web framework is most like Ruby on Rails?

[seberino]

I'm interested in knowing which Python web framework is most like Ruby
on Rails.

I've heard of Subway and Django.
Are there other Rails clones in Python land I don't know about?

Which one has largest community/buzz about it?
Chris

[Paul Rubin]

Paul Rubin <http://ph****@NOSPAM.invalid> writes:

If the transactions are simple and low-latency, then it can be enough
to have a single process own the whole database, and have every client
send all its requests to the db process.

Meant to say: it can be enough to let the clients lock the database,
do their thing quickly, and release the lock. What I described is of
course how it's usually done with SQL. Sigh. Other approaches
include running the whole app in one process (asyncore/twisted),
having a multi-threaded app where one thread owns the db and
serializes requests through Queues, etc.

[Dave Benjamin]

On Mon, 19 Dec 2005, Paul Rubin wrote:

"Russell E. Owen" <ro***@cesmail.net> writes:

I disagree. Once you've picked a database (not trivial in itself, of
course), you typically only have a few options for talking to in in
Python. Also, typically either:
- One stands out (because others have been abandoned or whatever), so
there's an easy answer, or

But none of them stand out, the way the ones in PHP stand out, by
being included in the standard library.

Well, even with PHP there are several ways to talk to a given database,
and the library du jour has changed a few times. When I first learned PHP,
it was pretty standard to use the mysql_* functions (and for another
database, a set of functions specific to that database). Then, PEAR DB
came out, which wrapped around these functions and provided some database
abstraction for portability. This is the direction I went, but I don't
know many others that followed.

PEAR is distributed with PHP, so it's basically standard, but in the early
days it wasn't in the library path by default so it didn't stick out as
the obvious way to talk to a database. Also, ADOdb was around at the time,
which was (and still is) a pretty popular third-party interface -- maybe
more popular than PEAR DB. And now there's the new "mysqli" interface,
which is yet another (this time object-oriented) alternative to the
mysql_* functions, but once again tied specifically to MySQL.

So, PHP has had the same kind of problems, even with database functions in
the core. There's more than one way to do it, even with standard
functions. Same with Java -- should we use the native Type 3 driver or the
pure-Java Type 4 driver? Scrap JDBC and go with JDO or EJB? Hibernate?

I'm not saying it's necessarily a good thing to have all these options,
but it's not atypical, especially considering how many database users are
out there and how different their needs are. In the Java world, commercial
vendors actually compete to produce better JDBC driver implementations,
which increases the number of options even more but results in some
wickedly fast and advanced drivers.

I do agree that the "obsolete" MySQLdb page needs a makeover, or to be
removed entirely. Also, getting psycopg to install on Windows involves
hunting around for some magic installers, and I'm afraid to delete them
off of my hard drive because I'm not sure I'll be able to find them again.
Perhaps all that is needed is some better organization.

Dave

[Scott David Daniels]

Mike Meyer wrote:

Benji York <be***@benjiyork.com> writes:

Perhaps it's off-topic for this thread, but I think "picking a
database" is the first mistake most people make. It's a form of
premature optimization.

For lots of problems, that's true. But not for all of them.

If the data you store and update is sufficiently valuable to your
enterprise, picking a database may be vital. Transactions guarantee
every update either happens or not, and infrastructure is provided
for you to be able to backup and restore the data you've obtained.
If you don't get transaction guarantees, your applications will have
to deal with all kinds of inconsistent data (either by ignoring the
problem or guessing the best answer).

--Scott David Daniels
sc***********@acm.org

[Alex Martelli]

Scott David Daniels <sc***********@acm.org> wrote:

Mike Meyer wrote:

Benji York <be***@benjiyork.com> writes:

Perhaps it's off-topic for this thread, but I think "picking a
database" is the first mistake most people make. It's a form of
premature optimization.

For lots of problems, that's true. But not for all of them.

If the data you store and update is sufficiently valuable to your
enterprise, picking a database may be vital. Transactions guarantee
every update either happens or not, and infrastructure is provided
for you to be able to backup and restore the data you've obtained.

A good point, but there are others. If the data is valuable, there WILL
be requests from parts of the enterprise to use that data in other ways
that were originally not anticipated. If you keep the data in a
relational DB with any kind of sensible schema, then the data IS
reusable, including in impromptu exploratory ways from interactive
prompts of many kinds -- you don't necessarily need "programmers" to
enable such reuse.

Picking ONE database engine may well be premature nevertheless --
perhaps the small amounts of data you have today make SQLite ideal, but
tomorrow there will be many more data, and you'll want PostgreSQL, or
whatever; which is why maintaining portability among different databases
may well be a great choice, even when it requires the overhead of a
"database independence layer". But being able to rely on a relational
underlying model remains an excellent idea in many cases, even when
minute details of SQL dialects &c require such a layer...
Alex

[Scott David Daniels]

Alex Martelli wrote:

Scott David Daniels <sc***********@acm.org> wrote:

If the data you store and update is sufficiently valuable to your
enterprise, picking a database may be vital. Transactions guarantee
every update either happens or not, and infrastructure is provided
for you to be able to backup and restore the data you've obtained.
A good point, but there are others. If the data is valuable, there WILL
be requests from parts of the enterprise to use that data in other ways
that were originally not anticipated. If you keep the data in a
relational DB with any kind of sensible schema, then the data IS
reusable, including in impromptu exploratory ways from interactive
prompts of many kinds -- you don't necessarily need "programmers" to
enable such reuse.

We are in violent agreement here. My contention is that you need a
_real_ relational database here, not that you need to pick a vendor.
MySQL vs. Pick vs. ... should be shut out early. A truly relational DB
has value, picking a particular one early does not. The attributes I
describe are available from any reputable relational DB vendor, and make
no mistake, PostgreSQL is what I consider a vendor -- a provider of a
fully thought-out and implemented solution.
... maintaining portability among different databases may well be a
great choice, even when it requires the overhead of a "database
independence layer".

Yup. I think you should choose a vendor, but not in the sense of buying
lock-in; in the sense of accepting a data model.

--Scott David Daniels
sc***********@acm.org

[Ben Sizer]

Paul Rubin wrote:

"Russell E. Owen" <ro***@cesmail.net> writes:

I disagree. Once you've picked a database (not trivial in itself, of
course), you typically only have a few options for talking to in in
Python. Also, typically either:
- One stands out (because others have been abandoned or whatever), so
there's an easy answer, or
But none of them stand out, the way the ones in PHP stand out, by
being included in the standard library.

I think that's a very good reason to include them in the standard
library.
With Python's web template systems, there's a real set of distinct
ones and it's maybe still too early to say there's an easy answer.
Hopefully there will eventually be one.
I think we're talking very small values of 'distinct' here. Arguably
the biggest difference between ASP and PHP is the language, then the
libraries and objects you use. Python already has a separate language
and libraries - does it really need a multitude of syntaxes for
embedding it in HTML? Obviously some people think so, but I wonder if
this isn't just because of the ease with which an enterprising web
developer can roll their own and release it, rather than there being
any significant benefits to any individual package over the others.
With db modules, if there's an easy answer, then I can't understand
why that easy answer isn't incorporated into the stdlib so people can
stop having to research it.

I think there's an easy answer in most cases. Who is responsible for
making the decision though?

--
Ben Sizer

[Paul Boddie]

Paul Rubin wrote:

It's been a long-time source of puzzlement to me why so many web sites
are so slow, and RDBMS overhead is an obvious candidate. So the rant
seems appropriate even in the case of web apps where clients can cause
db updates.

Indeed. Large portions of a lot of Web sites could actually be deployed
statically, rather than hitting a database several times a page to
retrieve stuff which changes once in a blue moon. Moreover, static page
hosting is generally a lot cheaper than dynamic program hosting.

On the subject of requiring an RDBMS, though, whilst there are various
kinds of applications which benefit overwhelmingly from using such a
system, my experience with Web frameworks that have such prerequisites
suggests that new users either have to slog through the setup process
and take it on trust that installing and/or configuring an RDBMS is a
good and necessary thing, or they question the relevance of having to
set such a thing up.

Certainly, for general Web programming, every time I see some Web
framework which just ploughs straight forward with the "and now you'll
need to set up MySQL" catchphrase for "our simple Wiki application", I
can't help feeling that today's letters are W, T and F.

Paul

[paron]

Wow! You´re right, at least at first reading. It looks REALLY simple,
and almost anything you can dream up will work. Python scripts,
python-in-html, html-in-python, and "karrigell services" ( based on
CherryPy). Seems to support smart urls, sessions, authentication, and
internationalization out-of-the-box. Documentation seems clean, short,
and to the point.

Has anyone other than Kerrigell himself used it? I think I will use it
around the shop for a desktop project just to get the feel of it. I am
not sure about the Gadfly db -- fine as a default for development; but
I'd need other options for production.

My answer to the perennial Python newbie question, "What do I use for a
GUI (please-please-please-I-hope NOT Tkinter or any derivative
thereof)?" may change to, "Just say 'Kerrigell' and do it in the
browser."

Ron

[paron]

Oops! Second line on the home page:

<snip>With Karrigell you have

. . .
* a pure-Python database engine : KirbyBase

Karrigell can also work with . . . all the databases for which a Python
API exists (sqlite, mySql, PostGreSQL, ZODB, etc). </snip>

Well, off to reread and work the tut! My apologies!

Ron

[Luis M. Gonzalez]

> Karrigell can also work with . . . all the databases for which a Python

API exists (sqlite, mySql, PostGreSQL, ZODB, etc). </snip>

Well, that's exactly what makes KARRIGELL so especial.
It is very flexible and lets you use whatever database or component you
want. It doesn't force you to use an specific package for each task.
It doesn't force you either to learn and use any templating language
(you don't need it!), although you can do it if you want.

The traditional "Hello world" page, can be coded like this:

print "Hello World"

No boilerplate code, no need to write a class or to fidle with strange
configurations.
It's simply python!
The only problem with KARRIGELL, I guess, is that its creator is very
humble and doesn't like to advertise his creature. He is not very fond
of "marketing" ...
This is too bad because I feel that other frameworks are getting a lot
of the attention that Karrigells deserve...

Luis

[Mike Meyer]

"Paul Boddie" <pa**@boddie.org.uk> writes:

Paul Rubin wrote:

It's been a long-time source of puzzlement to me why so many web sites
are so slow, and RDBMS overhead is an obvious candidate. So the rant
seems appropriate even in the case of web apps where clients can cause
db updates.

Indeed. Large portions of a lot of Web sites could actually be deployed
statically, rather than hitting a database several times a page to
retrieve stuff which changes once in a blue moon. Moreover, static page
hosting is generally a lot cheaper than dynamic program hosting.

And with the proper technology, you can get the best of both
worlds. You build the site as dynamically genrated, then "compile" it
to get the static pages you actually serve. That way you get all the
benefits you listed of serving static pages, plus the ability to use a
database and all it's associated tools for maintaining your data (if
you consider that an advantage, anyway).

<mike

--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Steve Holden]

Mike Meyer wrote:

"Paul Boddie" <pa**@boddie.org.uk> writes:

Paul Rubin wrote:

It's been a long-time source of puzzlement to me why so many web sites
are so slow, and RDBMS overhead is an obvious candidate. So the rant
seems appropriate even in the case of web apps where clients can cause
db updates.

Indeed. Large portions of a lot of Web sites could actually be deployed
statically, rather than hitting a database several times a page to
retrieve stuff which changes once in a blue moon. Moreover, static page
hosting is generally a lot cheaper than dynamic program hosting.

And with the proper technology, you can get the best of both
worlds. You build the site as dynamically genrated, then "compile" it
to get the static pages you actually serve. That way you get all the
benefits you listed of serving static pages, plus the ability to use a
database and all it's associated tools for maintaining your data (if
you consider that an advantage, anyway).

That's an approach I'm currently experimenting with - the content of
www.holdenweb.org is mostly static but generated from a database, and
the current tasks include completing a wxPython database maintenance
GUI, incorporating various ways to generate scripted content that
matches the look and feel of the rest of the site and adding more and
more ways to generate the interior content.

It's obvious by comparison with www.holdenweb.com that there's a good
deal of design commonality.

I'll be looking for beta testers eventually ...

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Kent Johnson]

Luis M. Gonzalez wrote:

The only problem with KARRIGELL, I guess, is that its creator is very
humble and doesn't like to advertise his creature. He is not very fond
of "marketing" ...

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.

Kent

[Russell E. Owen]

In article <ma***************************************@python. org>,
Benji York <be***@benjiyork.com> wrote:

Russell E. Owen wrote:

I disagree. Once you've picked a database (not trivial in itself, of
course), you typically only have a few options for talking to in in
Python.

Perhaps it's off-topic for this thread, but I think "picking a database"
is the first mistake most people make. It's a form of premature
optimization.

I just wanted to point out that I was responding to somebody who
complained that the database interface situation on python was somewhat
fragmented.

Also, when I was looking at web frameworks, I was doing so *precisely*
to serve one or more databases of information (read only to the users,
but occasionally loaded with more info as it became available). So it
happened to be the first question I asked (at the same time as "and how
do I talk to it?").

Anyway, you did warn that your message was possibly off-topic, so I
guess I'm agreeing with you and perhaps being overly defensive. It was
an interesting message.

-- Russell

[Luis M. Gonzalez]

I don't think Pierre (Karrigell's creator) is awared of licenses and
legal issues.
Perhaps you can tell us what's the problem with GPL and, if possible,
propose an alternative...

[Luis M. Gonzalez]

> 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 think Pierre (Karrigell's creator) is awared of licenses and
legal issues.
Perhaps you can tell us what's the problem with GPL and, if possible,
propose an alternative...

[Paul Rubin]

"Luis M. Gonzalez" <lu*****@gmail.com> writes:

Perhaps you can tell us what's the problem with GPL and, if possible,
propose an alternative...

See:
http://www.gnu.org/philosophy/pragmatic.html

[Michael Tobis]

Clearly the Ruby/Rails folks are making an effort to place themselves
as an easy-to-learn first language for people who might otherwise drift
into the rather awkward template-first way of thinking that is PHP.

I note that the Rails people are closely affiliated with the 37signals
people who in turn are closely linked with some advertising
professionals.

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
that this makes for amazing brilliance that is more or less invisible
to most of the world.

This leaves me believing that the commercial future is probably
brighter for Ruby vs Python. This won't affect the fact that Python is
probably still going to prevail in the scientific community, since
scientists aren't all that susceptible to promotion. That being the
case I don't think I myself will jump ship.

Since I am casting my lot with Python rather than Ruby, I think we
should take the friendly rivalry seriously rather than just shrugging
it off. Python MUST attract some of the most promising novice
programmers, and I believe that was part of its original design.

As a consequence Python MUST settle on a strong web framework that
includes the best of the existing frameworks, and polish it for maximum
accessibility as well as power.

Just on the basis of momentum rather than any strong technical argument
(which I am not well-qualified to make) I suggest we consider settling
on Django and doing what we can to improve it and its documentation.

mt

[Kent Johnson]

Luis M. Gonzalez wrote:

I don't think Pierre (Karrigell's creator) is awared of licenses and
legal issues.
Perhaps you can tell us what's the problem with GPL and, if possible,
propose an alternative...

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.

Certainly it is within an author's rights to prohibit use of his code in closed source
products, as the author of Karrigell has done by choosing GPL and I respect this decision.
Unfortunately this makes it impossible for me to consider using Karrigell in my work. I
recently needed a stand-alone web server for a small in-house project that might possibly
be distributed to business partners or become a product some day. I chose CherryPy in part
because its license allows this. I would have considered Karrigell if it had a different
license.

Kent

[Paul Rubin]

Kent Johnson <ke**@kentsjohnson.com> writes:

I chose CherryPy in part because its license allows this. I
would have considered Karrigell if it had a different license.

Have you had to modify CherryPy in some substantive way that you
needed to keep proprietary, as opposed to simply developing content
that CherryPy serves but is completely independent of CherryPy's
license?

I notice that a heck of a lot of commercial users are using completely
proprietary packages like ASP, whose licenses are far more restrictive
than the GPL. They don't seem to think it's a problem. So for most
such users, Karrigell shouldn't be a problem either. Remember that
the GPL only applies to the code of Karrigell itself, not to stuff
that you write using it.

[Kent Johnson]

Paul Rubin wrote:

Kent Johnson <ke**@kentsjohnson.com> writes:

I chose CherryPy in part because its license allows this. I
would have considered Karrigell if it had a different license.

Have you had to modify CherryPy in some substantive way that you
needed to keep proprietary,

I did make some changes to CherryPy. I wouldn't mind sharing those changes back with the
CherryPy community. But the product was the server itself, not the web site. As I
understand the GPL the server software would be a "work based on the [GPL-licensed]
Program" and thus subject to the GPL itself.
as opposed to simply developing content
that CherryPy serves but is completely independent of CherryPy's
license?
I'm not sure what you mean by "simply developing content". I was developing a web
application, not a web site serving static HTML. The bulk of the development work was
writing Python code that worked with CherryPy.

I notice that a heck of a lot of commercial users are using completely
proprietary packages like ASP, whose licenses are far more restrictive
than the GPL. They don't seem to think it's a problem. So for most
such users, Karrigell shouldn't be a problem either.
Building a website using Karrigell is not a problem because the work is not distributed.
Distributing a webserver based on Karrigell as a product would require the server to be
GPL licensed.
Remember that
the GPL only applies to the code of Karrigell itself, not to stuff
that you write using it.

IANAL but that is not my understanding of the GPL. GPL version 2 section 2.b) reads, "You
must cause any work that you distribute or publish, that in whole or in part contains or
is derived from the Program or any part thereof, to be licensed as a whole at no charge to
all third parties under the terms of this License." My server would certainly be a work
that in part contains Karrigell.

Kent

[Paul Rubin]

Kent Johnson <ke**@kentsjohnson.com> writes:

I did make some changes to CherryPy. I wouldn't mind sharing those
changes back with the CherryPy community. But the product was the
server itself, not the web site. As I understand the GPL the server
software would be a "work based on the [GPL-licensed] Program" and
thus subject to the GPL itself.
Yes, correct. I'm not sure what you mean by "simply developing content". I was
developing a web application, not a web site serving static HTML.
Yes, that is content.
The bulk of the development work was writing Python code that worked
with CherryPy.

And also with the Python interpreter. If the Python interpreter were
GPL'd, would that have been an issue?

Remember that the GPL only applies to the code of Karrigell
itself, not to stuff that you write using it.

IANAL but that is not my understanding of the GPL. GPL version 2
section 2.b) reads, "You must cause any work that you distribute or
publish, that in whole or in part contains or is derived from the
Program or any part thereof, to be licensed as a whole at no charge to
all third parties under the terms of this License." My server would
certainly be a work that in part contains Karrigell.

Your web app and html files would IMO be considered a separate work,
like C programs that you compile with GCC. If they don't contain actual
Karrigell code and they're not derived from Karrigell code, then I'd
think 2.b) doesn't apply. The test I'd use is, imagine you don't have
the Karrigell distro and you only have a printout of the documentation.
Can you write your app from just the docs? IANAL, etc., and to be
safe, you could simply ask the Karrigell author.

[Mike Meyer]

Paul Rubin <http://ph****@NOSPAM.invalid> writes:

IANAL but that is not my understanding of the GPL. GPL version 2
section 2.b) reads, "You must cause any work that you distribute or
publish, that in whole or in part contains or is derived from the
Program or any part thereof, to be licensed as a whole at no charge to
all third parties under the terms of this License." My server would
certainly be a work that in part contains Karrigell.

Your web app and html files would IMO be considered a separate work,
like C programs that you compile with GCC. If they don't contain actual
Karrigell code and they're not derived from Karrigell code, then I'd
think 2.b) doesn't apply. The test I'd use is, imagine you don't have
the Karrigell distro and you only have a printout of the documentation.
Can you write your app from just the docs? IANAL, etc., and to be
safe, you could simply ask the Karrigell author.

That's one test. Another one is whether you can distribute your app as
one piece and let them get Karrigell from somewhere else to put things
together. If they can set up your app without copying parts of
Karrigel into it (and you didn't do that for them), then you're
ok. You can even bundle Karrigel into the distribution for them.

While them having to modify Karrigel extensively to work with your app
- for instance, if you distributed patch files - is within the letter
of the license, the FSF considers such a violation. IIRC, they gave
NeXT shit for doing this.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Kent Johnson]

Paul Rubin wrote:

Kent Johnson <ke**@kentsjohnson.com> writes:

Remember that the GPL only applies to the code of Karrigell
itself, not to stuff that you write using it.

IANAL but that is not my understanding of the GPL. GPL version 2
section 2.b) reads, "You must cause any work that you distribute or
publish, that in whole or in part contains or is derived from the
Program or any part thereof, to be licensed as a whole at no charge to
all third parties under the terms of this License." My server would
certainly be a work that in part contains Karrigell.

Your web app and html files would IMO be considered a separate work,
like C programs that you compile with GCC. If they don't contain actual
Karrigell code and they're not derived from Karrigell code, then I'd
think 2.b) doesn't apply. The test I'd use is, imagine you don't have
the Karrigell distro and you only have a printout of the documentation.
Can you write your app from just the docs? IANAL, etc., and to be
safe, you could simply ask the Karrigell author.

You've lost me here. The server certainly would contain Karrigell code, it wouldn't
function without it. I don't understand the analogy to GCC, the web site is not something
that is compiled with Karrigell. Karrigell is a library or framework that is an essential
part of the server. I don't know how I would write the app without Karrigell.

A FAQ entry attempts to shed light on the question but just confuses me more. "If the two
programs remain well separated ... then you can treat them as two separate programs--but
you have to do it properly. The issue is simply one of form." WTF?
http://www.gnu.org/licenses/gpl-faq....prietarySystem

I confess, one reason I stay away from the GPL and even LGPL is because no matter how many
times I read them I'm not sure what they really say. FAQs like the above certainly don't
help much. In contrast the (BSD-style) CherryPy license is crystal clear.

Kent

[Paul Rubin]

Kent Johnson <ke**@kentsjohnson.com> writes:

You've lost me here. The server certainly would contain Karrigell
code, it wouldn't function without it. I don't understand the analogy
to GCC, the web site is not something that is compiled with
Karrigell. Karrigell is a library or framework that is an essential
part of the server. I don't know how I would write the app without
Karrigell.

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.

[Steve Holden]

Kent Johnson wrote:

Luis M. Gonzalez wrote:

I don't think Pierre (Karrigell's creator) is awared of licenses and
legal issues.
Perhaps you can tell us what's the problem with GPL and, if possible,
propose an alternative...

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.

I see the GPL is a problem in this environment, and you are clearly
aware of the issues it raises. Do be aware, though, that not all GPL
authors are rabid communists, and some will consider licensing to you
under other licenses if you ask them. It's always worth asking, as some
authors have chosen GPL in a somewhat uninformed way rather than as a
political statement (you'll notice I too am trying to avoid the flame wars).
Certainly it is within an author's rights to prohibit use of his code in closed source
products, as the author of Karrigell has done by choosing GPL and I respect this decision.
Unfortunately this makes it impossible for me to consider using Karrigell in my work. I
recently needed a stand-alone web server for a small in-house project that might possibly
be distributed to business partners or become a product some day. I chose CherryPy in part
because its license allows this. I would have considered Karrigell if it had a different
license.

As we say in Yorkshire, "You get nowt if you don't ask".

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Paul Rubin]

Steve Holden <st***@holdenweb.com> writes:

However the work I do is commercial and proprietary and I doubt
I could get approval to release it under GPL.

I see the GPL is a problem in this environment, and you are clearly
aware of the issues it raises. Do be aware, though, that not all GPL
authors are rabid communists, and some will consider licensing to you
under other licenses if you ask them. It's always worth asking, as
some authors have chosen GPL in a somewhat uninformed way rather than
as a political statement (you'll notice I too am trying to avoid the
flame wars).

I'm trying to avoid flame wars too, but my take on this is that Kent's
reading is a little too restrictive and the GPL isn't really a problem
in this situation unless he's actually modifying Karrigell itself,
rather than writing applications that run under it. I'm not trying to
advocate Karrigell (I browsed the docs for a minute and it looks nice
but I have no experience with it) but I don't see the GPL as an
obstacle to that type of usage. All kinds of proprietary applications
are written and distributed all the time to run under the GPL'd Linux
kernel and Karrigell apps don't seem too terribly different from that.

[Pierre Quentel]

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 ?

Regards,
Pierre

[Paul Rubin]

"Pierre Quentel" <qu************@wanadoo.fr> writes:

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 ?

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.

See http://www.gnu.org/philosophy/pragmatic.html for some reasons to
use the GPL.

French version: http://www.gnu.org/philosophy/pragmatic.fr.html

[Steve Holden]

Paul Rubin wrote:

Steve Holden <st***@holdenweb.com> writes:

However the work I do is commercial and proprietary and I doubt
I could get approval to release it under GPL.

I see the GPL is a problem in this environment, and you are clearly
aware of the issues it raises. Do be aware, though, that not all GPL
authors are rabid communists, and some will consider licensing to you
under other licenses if you ask them. It's always worth asking, as
some authors have chosen GPL in a somewhat uninformed way rather than
as a political statement (you'll notice I too am trying to avoid the
flame wars).

I'm trying to avoid flame wars too, but my take on this is that Kent's
reading is a little too restrictive and the GPL isn't really a problem
in this situation unless he's actually modifying Karrigell itself,
rather than writing applications that run under it. I'm not trying to
advocate Karrigell (I browsed the docs for a minute and it looks nice
but I have no experience with it) but I don't see the GPL as an
obstacle to that type of usage. All kinds of proprietary applications
are written and distributed all the time to run under the GPL'd Linux
kernel and Karrigell apps don't seem too terribly different from that.

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.

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.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Paul Rubin]

Steve Holden <st***@holdenweb.com> writes:

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]

Paul Rubin wrote:

"Pierre Quentel" <qu************@wanadoo.fr> writes:

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 ?

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.

--
Ben Sizer

[Paul Rubin]

"Ben Sizer" <ky*****@gmail.com> writes:

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/PythonSo...tionLicenseFaq)

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.

--
Richie Hindle
ri****@entrian.com

[Paul Rubin]

Richie Hindle <ri****@entrian.com> writes:

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]

Steve Holden wrote:

Paul Rubin wrote:

I'm trying to avoid flame wars too, but my take on this is that Kent's
reading is a little too restrictive and the GPL isn't really a problem
in this situation unless he's actually modifying Karrigell itself,
rather than writing applications that run under it. I'm not trying to
advocate Karrigell (I browsed the docs for a minute and it looks nice
but I have no experience with it) but I don't see the GPL as an
obstacle to that type of usage. All kinds of proprietary applications
are written and distributed all the time to run under the GPL'd Linux
kernel and Karrigell apps don't seem too terribly different from that.

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]

Kent Johnson wrote:

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

--
Arthur Clune

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

Paul Rubin wrote:

Kent Johnson <ke**@kentsjohnson.com> writes:

You've lost me here. The server certainly would contain Karrigell
code, it wouldn't function without it. I don't understand the analogy
to GCC, the web site is not something that is compiled with
Karrigell. Karrigell is a library or framework that is an essential
part of the server. I don't know how I would write the app without
Karrigell.

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]

Paul Rubin wrote:

"Ben Sizer" <ky*****@gmail.com> writes:

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 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....ereAggregation :

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

--
Ben Sizer

[Scott David Daniels]

Richie Hindle wrote:

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/PythonSo...tionLicenseFaq)

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
sc***********@acm.org

[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

> "Kent" == Kent Johnson <ke**@kentsjohnson.com> writes:

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

[Martin Christensen]

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

> "Ben" == Ben Sizer <ky*****@gmail.com> writes:

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]

Martin Christensen wrote:

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

>>"Kent" == Kent Johnson <ke**@kentsjohnson.com> writes:

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]

Martin Christensen wrote:

>>>"Kent" == Kent Johnson <ke**@kentsjohnson.com> writes:

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
ro*********@gmail.com

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

[Alex Martelli]

Paul Rubin <http://ph****@NOSPAM.invalid> wrote:

Richie Hindle <ri****@entrian.com> writes:

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.

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

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.

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 OO.o,
just about all Linux distros, and so on, and so forth.
Alex

[Ben Sizer]

Martin Christensen wrote:

>> "Ben" == Ben Sizer <ky*****@gmail.com> writes:

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.

--
Ben Sizer