Which Python web framework is most like Ruby on Rails?
sebe...@spawar.navy.mil
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
Jorge Godoy
> Are there other Rails clones in Python land I don't know about?
>
> Which one has largest community/buzz about it?
--
Jorge Godoy <go...@ieee.org>
bon...@gmail.com
brief browse and don't like any of them) and it has a very helpful
community.
gene tani
Subway and Django are *exactly* like rails, and they have buzz. And
have you looked at slashdot codebase?
Seriously, these frameworks are broad and deep, write more about your
app, platform, databases and DBMS and you'll get a better anwer, e.g.
you like has_and_blongs_to_many, you want an ActiveRecord clone, or you
like the naming defaults in rails' scaffolding, you like the DSL
quality of the rails code, ...
sebe...@spawar.navy.mil
Thanks for your kind email. I am a newbie web developer that just was
hoping
*any* framework was bubbling to surface to standout amongst all the
rest.
I don't know /why/ Rails is getting buzz. I've just heard some good
things
about it but don't want to switch to Ruby.
My main goal is to support any framework that looks like it has a
chance
of taking over the marketspace Rails is competing in. Hence, I want
to avoid any "also rans" aka "Yet Another Python Web Framework".
Chris
gene tani
I realized the first line of my post was pretty evil. *Don't* look at
the slashdot (200+k lines of perl). What i suggested to a friend who
recently asked the same thing is to pull up tags like "rails python" in
del.icious, furl and digg, see what other people like. That's a pretty
good way to measure buzz, actually. (My friend chose PHP, even tho i
told him he'd have unmaintainable, easily defaced code.)
sebe...@spawar.navy.mil
Dody Suria Wijaya
Alex Martelli
...
> the slashdot (200+k lines of perl). What i suggested to a friend who
> recently asked the same thing is to pull up tags like "rails python" in
> del.icious, furl and digg, see what other people like. That's a pretty
> good way to measure buzz, actually. (My friend chose PHP, even tho i
Alternatively, counting Google hits:
rails python django 112,000
rails python subway 81,600
rails python turbogears 32,000
This isn't exactly "buzz", of course, but it's SOME measure of "critical
mass" -- and with django about equal to subway+turbogears, it does not
appear to show any emerging dominance. A significant measure of "buzz"
might be obtained by redoing the same search in, say, two weeks, and
noticing the deltas...
Alex
Luis M. Gonzalez
But it is a project that unifies many different third party components
into one integrated package.
Its main component is CherryPy, which is a known python web framework.
DH
> Alternatively, counting Google hits:
>
> rails python django 112,000
> rails python subway 81,600
> rails python turbogears 32,000
>
> This isn't exactly "buzz", of course, but it's SOME measure of "critical
> mass" -- and with django about equal to subway+turbogears, it does not
> appear to show any emerging dominance. A significant measure of "buzz"
> might be obtained by redoing the same search in, say, two weeks, and
> noticing the deltas...
Actually the turbogears mailing list has ~850 subscribers while
the django one has ~650. I don't think that should be interpreted
as anything, but it does show the opposite of what you found with
the google search. They both have "buzz".
Also others are working on another rails-like framework
called pylons: http://pylons.groovie.org/project
Because of course if other languages have 1 or two frameworks, python
needs a dozen.
gene tani
DH wrote:
> Alex Martelli wrote:
> Because of course if other languages have 1 or two frameworks, python
> needs a dozen.
["there are still fewer %s than py keywords"%x for x in ["IDEs","web
app frameworks","GUI frameworks"]]
and 37000 google hits for "Snakes and Rubies"?!
Mike Meyer
> Alex Martelli wrote:
> Because of course if other languages have 1 or two frameworks, python
> needs a dozen.
People keep talking about Python's wealth of web frameworks as if it
were a bad thing. I just don't see it. Just like I like to have more
than 1 or 2 languages available for programming, I like to have more
than 1 or 2 web frameworks available for building web sites. That I
can get the flexibility I want in this area *without* having to
abandon Python is a plus for Python.
Or are the web frameworks for the languages with an impoverished
selection really that flexible? Is Ruby on Rail, for instance, really
going to do the things that Zope does well almost as well as Zope does
them, and the things that Cheetah does well almost as well as Cheetah
does them, and the things that web.py does well almost as well as
web.py does them? If that's the case, the complaint isn't "Python has
to many web frameworks", it's "Python doesn't have a good web
framework."
Thanks,
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Ben Sizer
> [Not sure if this attribution is correct.]
> > Alex Martelli wrote:
> > Because of course if other languages have 1 or two frameworks, python
> > needs a dozen.
>
> People keep talking about Python's wealth of web frameworks as if it
> were a bad thing. I just don't see it. Just like I like to have more
> than 1 or 2 languages available for programming, I like to have more
> than 1 or 2 web frameworks available for building web sites. That I
> can get the flexibility I want in this area *without* having to
> abandon Python is a plus for Python.
Flexibility is good, but personally I think the problem is that instead
of useful variety, we have redundant overlap. How many different
templating systems, sql<-->object mappings, and URL dispatch schemes do
we need? And what exactly is the difference between them all, except
for slightly different syntax?
One major benefit of reducing the number of such frameworks is that a
larger community would form around each product, meaning better
documentation and examples. Also, it would be easier to know which one
to recommend for a given task, when there are fewer available and they
are more distinct. In particular, it would be helpful to have something
simple in the standard library, as currently there's a large barrier to
entry for the Python newbie who wants to get into web programming,
compared to ASP or PHP, or even Java servlets.
--
Ben Sizer
gene tani
Ben Sizer wrote:
> Mike Meyer wrote:
> > [Not sure if this attribution is correct.]
> > > Alex Martelli wrote:
> > > Because of course if other languages have 1 or two frameworks, python
> > > needs a dozen.
> >
woops, that attribution is absolutely *wrong*, DH said that, sorry Alex
gene tani
as to the actual substance of this thread, i searched and couldn't find
the number of committers for rails, django, zope, subway etc, anybody
know?
Alex Martelli
NP, I noticed but decided not to comment, particularly since I roughly
agree with the spirit of DH's comment. Graham and Norvig, among others,
have often argued that there are parallels between Lisp and Python; the
proliferation of frameworks for a given task, I think, is one of them.
Good thing we have more things "nailed down" in the standard library...
but even then, e.g. with asyncore vs Twisted, there's no holding down a
different [here, better] implementation of similar ideas from emerging
as a third-party framework, anyway.
Alex
Mike Meyer
> Mike Meyer wrote:
>> [Not sure if this attribution is correct.]
And it was apparently wrong. Apologies to both DH and AM.
>> > Alex Martelli wrote:
>> > Because of course if other languages have 1 or two frameworks, python
>> > needs a dozen.
>> People keep talking about Python's wealth of web frameworks as if it
>> were a bad thing. I just don't see it. Just like I like to have more
>> than 1 or 2 languages available for programming, I like to have more
>> than 1 or 2 web frameworks available for building web sites. That I
>> can get the flexibility I want in this area *without* having to
>> abandon Python is a plus for Python.
> Flexibility is good, but personally I think the problem is that instead
> of useful variety, we have redundant overlap. How many different
> templating systems, sql<-->object mappings, and URL dispatch schemes do
> we need? And what exactly is the difference between them all, except
> for slightly different syntax?
Well, they come in at least three major variants: complete publishing
system (ake zope), templating system (aka psp), and modules (aka
cgi). Each of these is focused on a different level of the problem,
and hence is suitable for different things.
Syntax can be very important, especially for templating
systems. Typically, those are used in situations where you have a lot
of X/HTML and want a bit of dynamic content. Ideally, you want to be
able to treat this just like a static HTML page. If the syntax of a
templating system makes your standard web tools puke, you probably
want to avoid it.
chuck
> were a bad thing.
I disagree somewhat. While variety and choice are nice, sometimes
having too many choices may inhibit people from trying the language
because they don't know where to start in terms of framworks. Maybe
I'm wrong but if there is an element of truth what I suggest then that
would be a terrible shame since Python is such a great language.
Python's popularity might improve if there were a bit more unity within
the Python community with regards to (web) frameworks.
Alex Martelli
I agree with chuck. I've seen excellent programmers explain why for
some urgent problem they chose Ruby on Rails rather than Java or Python:
Ruby has ONE web framework (that matters), so the choice was finished
there; to evaluate properly 50 frameworks for Java or 20 for Python
would have taken weeks or months...
Alex
Robert Kern
> I agree with chuck. I've seen excellent programmers explain why for
> some urgent problem they chose Ruby on Rails rather than Java or Python:
> Ruby has ONE web framework (that matters), so the choice was finished
> there; to evaluate properly 50 frameworks for Java or 20 for Python
> would have taken weeks or months...
That doesn't make much sense, no matter how excellent those programmers were. If
Java and Python were ever on the table, then those 50 or 20 other frameworks
would still need to be evaluated *with* RoR.
Picking RoR because you want to do the project in Ruby makes sense. Picking Ruby
because it only has one web framework is as silly as picking one Python web
framework at random. Just because RoR is the only Ruby web framework around
doesn't mean it's suitable for every project.
--
Robert Kern
rober...@gmail.com
"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
Alex Martelli
...
> Picking RoR because you want to do the project in Ruby makes sense.
> Picking Ruby because it only has one web framework is as silly as picking
> one Python web framework at random. Just because RoR is the only Ruby web
> framework around doesn't mean it's suitable for every project.
If you claim there's a web project that's unfeasible to do in Ruby,
you'd better come up with a strong example. If you're making no such
claim, which would be counter to the claims of the Ruby community, then
there aren't gonna be any web projects unfeasible with Rails, either.
The multiplicity of frameworks in Python obviously makes the situation
very different: there might well be projects for which Python's quite
suitable IF a fairy godmother pointed you to just the right framework...
but lacking a fairy godmother, you're out of luck.
To put it another way: one reason I love Python is that I strongly
subscribe to the idea that there should preferably be only one obvious
way to do something. Unfortunately, this principle is very badly broken
by the multiplicity of Python web frameworks.
Alex
Paul Rubin
> To put it another way: one reason I love Python is that I strongly
> subscribe to the idea that there should preferably be only one obvious
> way to do something. Unfortunately, this principle is very badly broken
> by the multiplicity of Python web frameworks.
This also has to be a big part of why PHP is kicking the pants off of
Python for popularity in web development.
Alex Martelli
Sure, that's possible. Differently from Ruby (which is quite a
reasonable language, so I can see how some might prefer it to Python),
it would IMNSHO be unreasonable to claim *language* preference for that
case;-).
Alex
Robert Kern
> Robert Kern <rober...@gmail.com> wrote:
> ...
>
>>Picking RoR because you want to do the project in Ruby makes sense.
>>Picking Ruby because it only has one web framework is as silly as picking
>>one Python web framework at random. Just because RoR is the only Ruby web
>>framework around doesn't mean it's suitable for every project.
>
> If you claim there's a web project that's unfeasible to do in Ruby,
> you'd better come up with a strong example. If you're making no such
> claim, which would be counter to the claims of the Ruby community, then
> there aren't gonna be any web projects unfeasible with Rails, either.
Since web programming isn't my bailywick, I'll back off any specific claim about
unsuitability. That said, I am always suspicious about such claims of
universality in what seems to be a relatively broad field. It seems to me that
such claims bear a greater burden of proof. I recall such rhetoric in the early
days of Zope. It didn't quite pan out that way.
> The multiplicity of frameworks in Python obviously makes the situation
> very different: there might well be projects for which Python's quite
> suitable IF a fairy godmother pointed you to just the right framework...
> but lacking a fairy godmother, you're out of luck.
We've got a few fairy godmothers.
http://pyre.third-bit.com/pyweb/index.html
http://colorstudy.com/docs/shootout.html
My question is this: Why doesn't one need a fairy godmother to pick from the set
{RoR, Zope, TurboGears, CherryPy, ...}? Or rather, why is "Here's a framework
which is the only one to be implemented in a particular language," a good fairy
godmother? Why doesn't *that* process take a few months of evaluation?
> To put it another way: one reason I love Python is that I strongly
> subscribe to the idea that there should preferably be only one obvious
> way to do something. Unfortunately, this principle is very badly broken
> by the multiplicity of Python web frameworks.
Believe me, I'm all in favor of condensing the number of Python web frameworks
or making the currently available fairy godmothers better. I'm not arguing
against that. It's just that the decision process that you described seemed to
me to be flawed.
Mike Meyer
> Robert Kern <rober...@gmail.com> wrote:
> ...
>> Picking RoR because you want to do the project in Ruby makes sense.
>> Picking Ruby because it only has one web framework is as silly as picking
>> one Python web framework at random. Just because RoR is the only Ruby web
>> framework around doesn't mean it's suitable for every project.
> If you claim there's a web project that's unfeasible to do in Ruby,
> you'd better come up with a strong example. If you're making no such
> claim, which would be counter to the claims of the Ruby community, then
> there aren't gonna be any web projects unfeasible with Rails, either.
There's a difference between "feasible" and "suitable". The claim that
everything is feasible with RoR is trivially true because Ruby - and
hence RoR - is presumably turing complete. But this claim is
uninteresting.
The *interesting* claim is "RoR is suitable for all web projects."
That's not trivially true. My experience with other web platforms -
both built around Python and not - is that this claim has very much in
common with the claim "X is suitable for all programming projects",
for some programming language X. I don't believe such a programming
language exists (though proving that is well-nigh impossible), and I'm
pretty confident that such a web platform doesn't exist, though the
problem space hasn't existed for long enough to be sure.
Of course, I don't know RoR. If you've got a pointer to a discussion
of the kinds of things RoR is good for, I'd appreciate it. Googling
turns up tutorials, and that's all.
> The multiplicity of frameworks in Python obviously makes the situation
> very different: there might well be projects for which Python's quite
> suitable IF a fairy godmother pointed you to just the right framework...
> but lacking a fairy godmother, you're out of luck.
I did a fairly thorough investigation of web frameworks that let us
write Python (we didn't care what the framework was written in; merely
that it interfaced with Python) for one of the systems I've built this
year. I wouldn't call the evaluation of web frameworks a problem - we
met our schedules, and the tool evaluation phase was by *far* the
shortest phase in the project, taking less than a week. Most of the
evaluations were easy - read the description of the framework, and
decide that we're working outside the problem space it's desinged
for. It certainly wasn't wasted time - I found a tool that I hadn't
heard of previously that was nearly perfectly suited to the job at
hand.
> To put it another way: one reason I love Python is that I strongly
> subscribe to the idea that there should preferably be only one obvious
> way to do something. Unfortunately, this principle is very badly broken
> by the multiplicity of Python web frameworks.
The problem is that "building a web site" is a single "something" in
the same way that "writing a computer program" is a single
"something". Each represents a wide range of different problems, and
the obvious way to do one of those something may not be the obvious
way to do another of them.
gene tani
Robert Kern wrote:
>
> http://pyre.third-bit.com/pyweb/index.html
> http://colorstudy.com/docs/shootout.html
>
i started flipping thru "Snakes and rubies" google hits now at 127k,
waaay up from yesterday's 37k. The 2nd hit is Adrian Holovaty's which
has a good link to Zrusilla's summary. Adrian: "Python as a saner
ruby..." Anyway,
anybody else found good substantive writeups? There's a lot of
bloggery reminding us that PHP is "evil",horrible, that projectors
don't work very easily. ONe blogger ran out of lead for his mechanical
pencil and couldn't take notes anymore...
http://www.livejournal.com/users/zrusilla/337117.html
http://lxer.com/module/newswire/lf/view/49281/
http://www.inkdroid.org/journal/2005/12/04/snakes-and-rubies/
http://www.loudthinking.com/arc/000545.html
The last is DHH, who started rails project, I can't spell his name.
chuck
> write Python (we didn't care what the framework was written in; merely
> that it interfaced with Python) for one of the systems I've built this
> year. I wouldn't call the evaluation of web frameworks a problem - we
> met our schedules, and the tool evaluation phase was by *far* the
> shortest phase in the project, taking less than a week. Most of the
> evaluations were easy - read the description of the framework, and
> decide that we're working outside the problem space it's desinged
> for. It certainly wasn't wasted time - I found a tool that I hadn't
> heard of previously that was nearly perfectly suited to the job at
> hand.
As I read through this thread I can't say that I disagree that having
more choices is a 'good thing'. However in your example here - I
suspect that you are a bit sharper and have a bit more guts than your
average code slinger since you appear to be an independent. You've got
to remember that your average corporate programmer - which are the
folks driving the popularity of programming languages - isn't that
sharp/confident. (I don't mean to insult anyone but that just the
facts.) They don't do things like evaluate frameworks and make smart
choices. This is why there needs to be obvious and singularly popular
frameworks and IDE's for Python so that people don't have to think that
hard about it. Take Java for example - for the most part its Eclipse
and Struts. I know there are many other choices (I've used them), but
even the managers know these terms. Very, very few people I know in
the IT world know of 'Python', let alone the name of any web framework
or an IDE for Python.
One of the great things about Python is its simplicty/clarity. Its a
shame that there doesn't also exist a clarity of choice for a web
framework for Python or an IDE for that matter. Both of these would go
a long way in motivating people to take a look at Python and realizing
what great value it has to offer the IT world in solving problems.
A.M. Kuchling
Alex Martelli <al...@mail.comcast.net> wrote:
> If you claim there's a web project that's unfeasible to do in Ruby,
> you'd better come up with a strong example. If you're making no such
> claim, which would be counter to the claims of the Ruby community, then
> there aren't gonna be any web projects unfeasible with Rails, either.
I believe Rails assumes you're using a relational database, not an
object database like Durus or the ZODB. It seems to me Django is
similarly focused; are there hooks that would allow replacing an RDBMS
commit with a custom commit callback?
--amk
Ben Sizer
> "Ben Sizer" <kyl...@gmail.com> writes:
> > Flexibility is good, but personally I think the problem is that instead
> > of useful variety, we have redundant overlap. How many different
> > templating systems, sql<-->object mappings, and URL dispatch schemes do
> > we need? And what exactly is the difference between them all, except
> > for slightly different syntax?
>
> Well, they come in at least three major variants: complete publishing
> system (ake zope), templating system (aka psp), and modules (aka
> cgi). Each of these is focused on a different level of the problem,
> and hence is suitable for different things.
I see what you mean, but unfortunately I think there is a lot more
fuzziness than that. If the separate parts were clearly delineated
things would be a lot better. I look to the Database API Specification
as a great example of how this could (should?) be done, allowing for
easy interchangeability while still providing a well-documented
standard, and the opportunity to bundle a basic module with the
standard library without raising the difficulty level for those who
wish to use other frameworks. A PyWebForm API and a PyWebSession API
would be fairly easy to create, for example. Templating maybe less so,
but not much.
> Syntax can be very important, especially for templating
> systems. Typically, those are used in situations where you have a lot
> of X/HTML and want a bit of dynamic content. Ideally, you want to be
> able to treat this just like a static HTML page. If the syntax of a
> templating system makes your standard web tools puke, you probably
> want to avoid it.
I think templating syntax is very important, but with something like
Python I think the future is in modules like HTMLTemplate rather than
the ASP/PHP model. When you're working with a valid XML page in the
first place, all your tools should work adequately.
--
Ben Sizer
Alia Khouri
"Subway has a lot of ideas TurboGears lacks. Everything from the
@client ajax-in-python to CherryFlow. On technical merits, Subway
should eat TurboGears' dinner.
But we all know market outcomes are not based on technical merit.
They're based on marketing. And as an open-source marketing project,
TurboGears is eating Subway's dinner. And not just those low-fat subs,
either - they're pouring it on thick!
It is a truism that python is the language with more web app frameworks
than keywords. Of this LaoTse wrote, "Conquest is a method of union.
The smaller submits to the larger to obtain custom. The larger submits
to the smaller to obtain service. If both would endure, both must
submit."
So it's time to stop trumpeting subway as "the best framework", and by
uniting with TurboGears definitively create the best web app framework.
The combination of the two would become an unstoppable juggernaut of
python mindshare, and all the rest of the frameworks would either
componentize or be dismissed as toys.
If Subway does not unite, chaos will continue in python web app land,
and ruby will become ascendant. This is more than a critical issue -
don't dismiss it without understanding that doing so will have severe
repercussions for subway (and by a process of horsshoe nail extraction,
the whole world!)"
All I can say is HEAR HEAR!!!!
AK
gene tani
Alia Khouri wrote:
> In http://subway.python-hosting.com/ticket/216 Peter Mere writes:
>
>
> "Conquest is a method of union.
> unstoppable juggernaut of
> chaos will continue in python web app land,
> and ruby will become ascendant. This is more than a critical issue -
> don't dismiss it without understanding that doing so will have severe
> repercussions for subway (and by a process of horsshoe nail extraction,
> the whole world!)"
>
> All I can say is HEAR HEAR!!!!
>
> AK
I feel like i'm being indoctrinated for a cult that won't let you eat
or go to the bathroom
Mike Meyer
> As I read through this thread I can't say that I disagree that having
> more choices is a 'good thing'. However in your example here - I
> suspect that you are a bit sharper and have a bit more guts than your
> average code slinger since you appear to be an independent. You've got
> to remember that your average corporate programmer - which are the
> folks driving the popularity of programming languages - isn't that
> sharp/confident. (I don't mean to insult anyone but that just the
> facts.) They don't do things like evaluate frameworks and make smart
> choices.
Let's just note that sturgeon's law applies to all programmers, and
let it go at that. I'll get back to this.
And thank you.
> One of the great things about Python is its simplicty/clarity. Its a
> shame that there doesn't also exist a clarity of choice for a web
> framework for Python or an IDE for that matter. Both of these would go
> a long way in motivating people to take a look at Python and realizing
> what great value it has to offer the IT world in solving problems.
I'm not a big fan of popularity for the sake of popularity. While
there's nothing wrong with popularity, and it does have it's
advantages, "it would make Python more popular" isn't an adequate
justification for a change, and *certainly* not for a change that is
otherwise undesirable. After all, sturgeon's law applies to the
populace, so "the populace's" skill at judging languages/IDEs/etc. is
debatable at best.
If having to many web frameworks is a real problem, let's work on
it. If not - well, we'll suffer with the consequences of using
high-quality, if obscure, tools.
And, to head off the obvious complaints, "not being designed by the
populate" does not imply "hard for the populace to use". With Lehrer's
comments on folk music in mind, I'd argue that the reverse implication
is more likely true.
Mike Meyer
> I see what you mean, but unfortunately I think there is a lot more
> fuzziness than that. If the separate parts were clearly delineated
> things would be a lot better. I look to the Database API Specification
> as a great example of how this could (should?) be done, allowing for
> easy interchangeability while still providing a well-documented
> standard
Constant queries on c.l.python for "Which DB module should I use"
would indicate that having a standard and to many choices isn't really
better than having no standard and to many choices.
> and the opportunity to bundle a basic module with the standard
> library without raising the difficulty level for those who wish to
> use other frameworks.
Marking one web framework - or one DB module - as blessed would
certainly ease the problem. I don't have a problem with that, but I
don't build a Python distribution.
> A PyWebForm API and a PyWebSession API
> would be fairly easy to create, for example. Templating maybe less so,
> but not much.
I'm not convinced these would be fairly easy to cerate. If you think
that's the case, please take a shot at it, as I think such a standard
would be a good thing.
chuck
> let it go at that. I'll get back to this.
fine
> And thank you.
you are welcome
> I'm not a big fan of popularity for the sake of popularity.
neither am I
> "it would make Python more popular" isn't an adequate
> justification for a change
I disagree. The world desperately needs programming languages,
frameworks, etc. that allow for the more efficient creation and
maintenance of software application - web or otherwise. I happen to
think that Python is something that could help. With this regard the
popularity of Python seems relevant to me.
>and *certainly* not for a change that is
> otherwise undesirable.
please explain
Mike Meyer
> If Subway does not unite, chaos will continue in python web app land,
> and ruby will become ascendant. This is more than a critical issue -
> don't dismiss it without understanding that doing so will have severe
> repercussions for subway (and by a process of horsshoe nail extraction,
> the whole world!)"
Um - why should I switch to subway?
Mike Meyer
>> "it would make Python more popular" isn't an adequate
>> justification for a change
> I disagree. The world desperately needs programming languages,
> frameworks, etc. that allow for the more efficient creation and
> maintenance of software application - web or otherwise. I happen to
> think that Python is something that could help. With this regard the
> popularity of Python seems relevant to me.
I think Python is popular enough that it's not going to
vanish. Once you've reached that point, further popularity doesn't
helop your cause.
>>and *certainly* not for a change that is
>> otherwise undesirable.
> please explain
It's conceivable that a change might make Python more popular and also
detract from the language in some way. For a ridiculous example,
making Python interpret Perl 6 would certainly make it more popular,
but I would argue that would seiously detract from the language.
bon...@gmail.com
Mike Meyer wrote:
> It's conceivable that a change might make Python more popular and also
> detract from the language in some way. For a ridiculous example,
> making Python interpret Perl 6 would certainly make it more popular,
> but I would argue that would seiously detract from the language.
>
Mike Meyer
So you could have a perl 6 interpreter, of course. Assuming you
wanted one, of course.
floyd...@gmail.com
I am all for it. TG would have to change a couple of things IMHO, but I
think it would be a great idea.
If we were to merge projects, we would have to get a serious
TurbowaySubgears blogging hype train going.
- Peter Hunt
John J. Lee
> I'm the founder and lead developer of Subway.
>
> I am all for it. TG would have to change a couple of things IMHO, but I
> think it would be a great idea.
+100
> If we were to merge projects, we would have to get a serious
> TurbowaySubgears blogging hype train going.
Be big and use the 'TurboGears' name. It has good PR.
crackajax is *so* cool :-) How is it coming along?
John
floyd...@gmail.com
iterators, but it still needs work.
I would plan on sticking with the Turbogears name if we were to merge.
My real worries are the controller styles (functions vs classes) and
the templating language (Cheetah vs Kid). Those will be points of
conflict between the two projects, but I hope we would be able to solve
them.
Thoughts?
Pete
Jan Niklas Fingerle
> My real worries are the controller styles (functions vs classes) and
You can wrap those quite easily, but ...
> the templating language (Cheetah vs Kid). Those will be points of
... how should the user base of one migrate to the other? I depend on
(as far as "depend" might go) the Kid funtionality (i.e. importing
ElementTree-s as sub-trees, and ElementTree is part of the heart of my
application logics).
> conflict between the two projects, but I hope we would be able to solve
> them.
Use Kid ;-) Well, no, make it easy to change templating engines,
whatever you ship as included engine.
Cheers,
--Jan Niklas
Luis M. Gonzalez
Has anyone tried KARRIGELL??
I find hard to believe there is any easier python framework than this
one.
It's incredibly flexible, very fun, very powerful and with an almost
flat learning curve.
Go check it out (NOW!)
http://karrigell.sourceforge.net/
Russell E. Owen
Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
I agree. It's sad to see such a terrible language as PHP so popular, and
such a complicated mess in python, my language of choice.
I love python and am lucky enough to be able to do almost all my coding
in it. Yet even I use PHP to serve a database. I loathe PHP, but:
- it came preinstalled on my system (MacOS X 10.3.x).
- I found a nice simple intro to it (a quickstart guide, which taught me
all I needed to know for my simple needs).
- I started out by looking at the choices in python. Of course. I read
the shootout. I asked for help. But the results were utterly
overwhelming.
I wanted (and I am guessing this isn't too far off for most users -- at
least most non-web-gurus) a framework that was:
- Well designed, robust, "finished" (i.e. not alpha).
- Easy to use, especially for simple, basic tasks. (And not a toy, of
course -- powerful enough to handle reasonable traffic and tasks.)
- Easy to install.
- Well documented, with a good introduction or tutorial.
- Likely to be around for awhile. The plethora of options on Python do
NOT inspire confidence in that area.
Some choice is good -- especially if the choices solve obviously
different problems. But too much choice is paralyzing and fragments the
community.
Anyway, thanks for holding this discussion. Django and TurboGears were
both new to me. I hope something finally gets popular enough to be worth
betting on.
-- Russell
Russell E. Owen
wrote:
>"Ben Sizer" <kyl...@gmail.com> writes:
>> I see what you mean, but unfortunately I think there is a lot more
>> fuzziness than that. If the separate parts were clearly delineated
>> things would be a lot better. I look to the Database API Specification
>> as a great example of how this could (should?) be done, allowing for
>> easy interchangeability while still providing a well-documented
>> standard
>
>Constant queries on c.l.python for "Which DB module should I use"
>would indicate that having a standard and to many choices isn't really
>better than having no standard and to many choices.
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
- They all work about the same, so even if you decide to switch for some
reason it makes little difference.
SQLObject breaks that mold, but for excellent reasons. It's nice to
start from a standard and then maybe somebody figures out a really nifty
way to do things. (I haven't used SQLObject yet, but I plan to try it
out when things calm down a bit).
If we had a standard basic web framework or a standard template language
it would really help (more folks using it, more folks who can help folks
learning it, better documentation, more focused development). Something
better might come along, and then it'd be easier to evaluate and more
appreciated.
-- Russell
Paul Rubin
> 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.
> - They all work about the same, so even if you decide to switch for some
> reason it makes little difference.
You should not even have to spend one millisecond of your attention
thinking about it then.
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.
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. If there's no easy answer, then maybe the
dbapi standardization process hasn't worked so well after all.
Benji York
> 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.
Just like any other component in a system, develop your app without a
database until you see that you need one, don't just assume you do from
the beginning.
I was listening to an interview with Ron Jeffries the other day, and
when asked what he considers one of his greatest accomplishments (as a
software developer), he told a story about working on a large
development project for a system that was going to process large amounts
of data.
At the beginning of the project he was asked what database they should
use, he said (something like) "wait until we need one". During
development several people asked what database they were going to use,
he reiterated: "wait until we need one". After the system went into
production (without a database) he eventually left the company. Years
later he found out that they still hadn't "chosen a database" because
they had yet to need one. Sounds like a pretty good application of
YAGNI to me. http://xp.c2.com/YouArentGonnaNeedIt.html
That's also why I don't see much point to the
relational-database-centric web frameworks that are all the rage today,
but I'll save that rant for another day.
--
Benji
Mike Meyer
> 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.
For lots of problems, that's true. But not for all of them.
> Just like any other component in a system, develop your app without a
> database until you see that you need one, don't just assume you do
> from the beginning.
What makes me think "I need a database" is a requirement that says
"multiple simultaneous writers". Yes, it's possible to deal with the
data locking and the like on your own - but this tends to be
system-dependent, and hard to get right except in the simple
cases. It's also one of the things that databases are *really* good
at. In this case, using a database isn't a performance optimization,
it's a code simplification optimization, sort of like using
Queue.Queue to do threading.
> That's also why I don't see much point to the
> relational-database-centric web frameworks that are all the rage
> today, but I'll save that rant for another day.
If your web clients can write data, then you've got multiple
simultaneous writers - which means you probably want a database. Of
course, people like to build web apps that don't write data on top of
relational databases, which I think are well deserving of your rant.
Paul Rubin
> What makes me think "I need a database" is a requirement that says
> "multiple simultaneous writers".
I'd go a little further and say "multiple simultaneous writers doing
multi-step transactions with steps that can have high latency",
e.g. transactions that have to wait for user input while the
transaction is in progress.
> Yes, it's possible to deal with the data locking and the like on
> your own - but this tends to be system-dependent, and hard to get
> right except in the simple cases.
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.
> If your web clients can write data, then you've got multiple
> simultaneous writers - which means you probably want a database. Of
> course, people like to build web apps that don't write data on top of
> relational databases, which I think are well deserving of your rant.
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.
Paul Rubin
> 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
> "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
> 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
scott....@acm.org
Alex Martelli
> 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
> Scott David Daniels <scott....@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.
_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
scott....@acm.org
Ben Sizer
> "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
> 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
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
<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
> 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 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).
Steve Holden
> "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).
>
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 +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/
Kent Johnson
> 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
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
> 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
> Perhaps you can tell us what's the problem with GPL and, if possible,
> propose an alternative...
Michael Tobis
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
> I don't think Pierre (Karrigell's creator) is awared of licenses and
> legal issues.
> 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
> 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
> 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
> 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
>> 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.
Kent Johnson
> 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.html#GPLInProprietarySystem
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
> 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
> 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.
>
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".
Paul Rubin
> > However the work I do is commercial and proprietary and I doubt
> > I could get approval to release it under GPL.
> 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
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
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
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.
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
them already !
Pierre
Ben Sizer
> "Pierre Quentel" <quentel...@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
> 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]
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.
--
Richie Hindle
ric...@entrian.com
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
> 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
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
--
Arthur Clune
Fuzzyman
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,
Kent Johnson
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
> "Ben Sizer" <kyl...@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.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++.
--
Ben Sizer
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
scott....@acm.org
Pierre Quentel
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
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
Hash: SHA1
>>>>> "Ben" == Ben Sizer <kyl...@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
> -----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
>
>>>>>>>"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
rober...@gmail.com
"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
Alex Martelli
> Richie Hindle <ric...@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
> >>>>> "Ben" == Ben Sizer <kyl...@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