it case you missed it...
mdipierro
http://www.reddit.com/r/Python/comments/ej0p1/new_standalone_web2py_database_abstraction_layer/
I am emailing you because you have asked in the past and because other
people felt the need to tweet about their own comments:
http://friendfeed.com/ericflo/e28441ba/ericflo-on-new-stand-alone-web2py-database
I am not asking nor encouraging you to post. I just thought you would
be interested about the ongoing discussion.
Massimo
Bruno Rocha
Branko Vukelic
web2py. I just cannot wrap my brain around it. Could be some
malfunction on my part, but still. I'm much happier typing away SQL or
having wrapper functions that work almost as if you're typing SQL. The
perfect thing for me was web.py's web.db. :)
--
Branko Vukelić
bg.b...@gmail.com
stu...@brankovukelic.com
Check out my blog: http://www.brankovukelic.com/
Check out my portfolio: http://www.flickr.com/photos/foxbunny/
Registered Linux user #438078 (http://counter.li.org/)
I hang out on identi.ca: http://identi.ca/foxbunny
Gimp Brushmakers Guild
http://bit.ly/gbg-group
cjrh
> But, I like the fact DAL is a single file, for me it is better to be a
> single file, better to maintain and keep my projects updated. I have a PyGTK
> program running with SQL.py and I will update this to the new dal.py this
> weekend, I prefer to update a single file.
rests solely on the degree of inter-dependence of the file contents,
not some kind of subjective idea of maximum lines of code. There
are source files that are too long at 10 lines (containing multiple
disjointed functions) and there are source files that are correctly
single-file at 20KLOC (strong inter-dependence). So it depends on
the nature of the file contents.
Tom Atkins
Bruno Rocha
Albert Abril
mdipierro
list.
On Dec 10, 7:23 am, Albert Abril <albert.ab...@gmail.com> wrote:
> Agree too, 'old web2py blog' and the 'flash' informing that the info could
> be oudated...
> ..If we're linking to the new DAL, recently wrote. :D
>
> Hopefully this is constructive criticism too ;)
>
pbreit
Bruno Rocha
Is there a decent Web2py-based blogging appliance?
It would be great to have some good implementations of some core apps like blog, forums, CRM, etc.
Bruno Rocha
pbreit
G. Clifford Williams
On Fri, Dec 10, 2010 at 06:31:15PM -0800, pbreit spake:
mdipierro
Web2py imposes no restriction on their code. I an write a letter to
this effect if at all necessary.
Massimo
On Dec 11, 10:11 am, "G. Clifford Williams" <g...@notadiscussion.com>
wrote:
Branko Vukelic
about. I acutally like GPL more than BSD and other crap. Viral
licenses are much better for upstream.
--
G. Clifford Williams
The bottom line is that many commercial entities frown on GPL licensed software. Legal departments go ape when someone brings in new software and 1) it's "free" and 2) it's "GPL'd".
For one particular client I'd built a front-end management interface to some system configs (firewalls, software packages, etc... ). This was something they were distributing to their clients as part of a bundle. When told that it would be built with a Python web framework, they assumed it would be Django. When I was done with it and had turned in my documentation they had a fit. I got calls from the CTO asking why I would put them in such a position. They didn't know whether I'd modified anything that was "...part of web2py", and if I had they wanted to know whether it was "...configuration or code". The only GPL'd apps they ship to customers are compiled binaries. They wanted me to 'decouple' what I'd done and submit it for review by their one internal python guy so that he could determine whether anything in my code was 'stolen' from web2py.
I was asked to rewrite everything in Django, Pylons or RoR.
I'm not saying they were either right or wrong. It's just an ongoing battle and one more headache that I could really do without.
On Sat, Dec 11, 2010 at 08:17:23AM -0800, mdipierro spake:
Branko Vukelic
<g...@notadiscussion.com> wrote:
> Thanks I appreciate that and I'll surely take you up on that it I think it'll help me win one of these battles.
>
> The bottom line is that many commercial entities frown on GPL licensed software. Legal departments go ape when someone brings in new software and 1) it's "free" and 2) it's "GPL'd".
> For one particular client I'd built a front-end management interface to some system configs (firewalls, software packages, etc... ). This was something they were distributing to their clients as part of a bundle. When told that it would be built with a Python web framework, they assumed it would be Django. When I was done with it and had turned in my documentation they had a fit. I got calls from the CTO asking why I would put them in such a position. They didn't know whether I'd modified anything that was "...part of web2py", and if I had they wanted to know whether it was "...configuration or code". The only GPL'd apps they ship to customers are compiled binaries. They wanted me to 'decouple' what I'd done and submit it for review by their one internal python guy so that he could determine whether anything in my code was 'stolen' from web2py.
The legal guys at my company are not able to vet 2 GPL and 2 BSD apps
for corporate use after 2 months of research. People are stupid like
that. I'm actually quite fascinated about how stupid they get
sometimes. You know. M$ gives you a long-ass EULA, and most of it is
mumbo-jumbo, and nobody ever questions it. If you look at the EULA for
Corel Draw, for example, you find out that you aren't even permitted
to use the software for "any purpose". It's clearly defined what's
allowed and what's not. I'm not talking about where you can or cannot
install. It covers shit like what you can DRAW with it. Yet this type
of BS makes perfect sense to them. And GPL doesn't. Nobody ever
checked stuff I was drawing and vetted them with the legal. And
they're taking 2 months just to decide whether I can have Blender and
Inkscape installed on my workstation.
VP
not have to be GPL, and can be licensed in any way you want. (I am
unsure if this violates GPL's terms or not, but this is what I think
how web2py's licensing permits).
What is GPL is the web2py framework itself. So, as long as your app
does not touch web2py's core and stay within web2py/applications/
yourapp directory, that should be okay. On the other hand, if you
want to take web2py add features to it, modify it, then it will have
to be GPL.
On Dec 11, 2:23 pm, "G. Clifford Williams" <g...@notadiscussion.com>
wrote:
>
> The bottom line is that many commercial entities frown on GPL licensed software. Legal departments go ape when someone brings in new software and 1) it's "free" and 2) it's "GPL'd".
> For one particular client I'd built a front-end management interface to some system configs (firewalls, software packages, etc... ). This was something they were distributing to their clients as part of a bundle. When told that it would be built with a Python web framework, they assumed it would be Django. When I was done with it and had turned in my documentation they had a fit. I got calls from the CTO asking why I would put them in such a position. They didn't know whether I'd modified anything that was "...part of web2py", and if I had they wanted to know whether it was "...configuration or code". The only GPL'd apps they ship to customers are compiled binaries. They wanted me to 'decouple' what I'd done and submit it for review by their one internal python guy so that he could determine whether anything in my code was 'stolen' from web2py.
>
> I was asked to rewrite everything in Django, Pylons or RoR.
>
> I'm not saying they were either right or wrong. It's just an ongoing battle and one more headache that I could really do without.
>
> On Sat, Dec 11, 2010 at 08:17:23AM -0800, mdipierro spake:
>
> > are you talking about the web2py license? Why would a client care?
> > Web2py imposes no restriction on their code. I an write a letter to
> > this effect if at all necessary.
>
> > Massimo
>
> > wrote:
> > > �I hope so. A different license would certainly help with my fight for adoption by a few clients
Branko Vukelic
> My understanding is this. The apps that you develop with Web2py does
> not have to be GPL, and can be licensed in any way you want. (I am
> unsure if this violates GPL's terms or not, but this is what I think
> how web2py's licensing permits).
>
> What is GPL is the web2py framework itself. So, as long as your app
> does not touch web2py's core and stay within web2py/applications/
> yourapp directory, that should be okay. On the other hand, if you
> want to take web2py add features to it, modify it, then it will have
> to be GPL.
There's one catch, though. If a piece of code is a template that comes
with web2py (which means the template code is also GPL), does the
template, which is covered by GPL, also prevent you from distributing
templates as binary-only.
I don't mean HTML etc. Those are static files anyway. I mean the .py
templates like the db.py template that is included in the welcome app.
When you start off, 100% of your app is comprised of GPL'd code from
the welcome app.
mdipierro
pubic domain (no license whatsoever).
I have said that before but it is not explicitly stated in the
license.
I will add a statement to the top of each .py file in the welcome app.
Massimo
On Dec 11, 2:52 pm, Branko Vukelic <bg.bra...@gmail.com> wrote:
> > My understanding is this. The apps that you develop with Web2py does
> > not have to be GPL, and can be licensed in any way you want. (I am
> > unsure if this violates GPL's terms or not, but this is what I think
> > how web2py's licensing permits).
>
> > What is GPL is the web2py framework itself. So, as long as your app
> > does not touch web2py's core and stay within web2py/applications/
> > yourapp directory, that should be okay. On the other hand, if you
> > want to take web2py add features to it, modify it, then it will have
> > to be GPL.
>
> There's one catch, though. If a piece of code is a template that comes
> with web2py (which means the template code is also GPL), does the
> template, which is covered by GPL, also prevent you from distributing
> templates as binary-only.
>
> I don't mean HTML etc. Those are static files anyway. I mean the .py
> templates like the db.py template that is included in the welcome app.
> When you start off, 100% of your app is comprised of GPL'd code from
> the welcome app.
>
> --
> Branko Vukelić
>
Bruno Rocha
mdipierro
phrase a little more professionally. ;-)
On Dec 11, 3:16 pm, Bruno Rocha <rochacbr...@gmail.com> wrote:
> http://sam.zoy.org/wtfpl/
>
> 2010/12/11 mdipierro <mdipie...@cs.depaul.edu>
Branko Vukelic
Bruno Rocha
DO WHAT WHATEVER YOU WANT TO PUBLIC LICENSE
Version 1, December 2010
Everyone is permitted to copy and distribute verbatim or modified
copies of this, and changing it is allowed as long
as the name is changed.
DO WHATEVER YOU WANT TO PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. You just DO WHATEVER FUCK YOU WANT TO.
Branko Vukelic
> 0. You just DO WHATEVER FUCK YOU WANT TO.
Missed one FUCK there. Anyway, I'd edit out the word 'public' also.
Maybe replace it with 'user'. Public still smells like General
_public_ license.
--
Branko Vukelić
pbreit
Branko Vukelic
> For what it's worth, I believe the following is accurate:
> 1. GPL is more objectionable than BSD/MIT
Both GPL and BSD are not well suited to template code, that's the point.
> 2. Frameworks tend not to use GPL
So?
Anthony
Bruno Rocha
> as long as the name is changedWhen using the welcome app, we should require that the web2py favicon be removed -- I keep running into web2py powered sites that display the web2py favicon. Actually, maybe it would be a better idea to simply not include the web2py favicon with the welcome app -- it usually doesn't make sense for sites based on the welcome app to have the web2py favicon.Anthony
Branko Vukelic
is just as bad as having a web2py logo.
--
Branko Vukelić
pbreit
>> 1. GPL is more objectionable than BSD/MIT
> Both GPL and BSD are not well suited to template code, that's the point.
>> 2. Frameworks tend not to use GPL
> So?
LightDot
Has this scenario been looked over by a lawyer? Any such document would enable us to put customers at ease.
We have used CakePHP for our PHP projects for years now and license was never an issue (MIT license). But with web2py, customers always bring this up when the application needs to be closed source. And there isn't much we can tell them other than they should read the site and decide for themselves.
Branko Vukelic
>>> 1. GPL is more objectionable than BSD/MIT
>
>> Both GPL and BSD are not well suited to template code, that's the point.
>
> So which one would you suggest?
It's already been suggested (with a minor wording problem). Look at
the other posts in the topic..
>>> 2. Frameworks tend not to use GPL
>
>> So?
>
> So if many/most other frameworks do not use GPL, maybe not using GPL is
> worth considering for the Web2py framework. That seems a reasonable
> conclusion or at least a basis for consideration.
Well, most people use PHP. Shall we consider using PHP then? ;)
Branko Vukelic
> Has this scenario been looked over by a lawyer? Any such document would
> enable us to put customers at ease.
It's a no brainer. The license covers the platform, not the code
written _using_ that platform. It's not like Microsoft EULA and other
commercial user licenses that also cover what you can produce on the
platform, mind you. GPL strictly covers the code that you have
_received_ not the one you've produced yourself.
GPL is only relevant in cases where the code you've produces contains
the code directly taken from the platform (and that's what we've been
discussing here). For example, if welcome app were GPL (and it's not),
you'd be forced to release your work as GPL unless you removed
significant portions of the welcome app from your own application (and
'significant' depends on jurisdiction). However, according to Massimo,
welcome app is _not_ GPL, so you don't have a problem with this. The
only problem with the welcome app is that it's 'public domain', which
is a concept that may not apply in all jurisdictions (especially
outside US). Despite that, rest assured that the author of the welcome
app will not sue your clients. ;)
Branko Vukelic
> platform, mind you. GPL strictly covers the code that you have
> _received_ not the one you've produced yourself.
Speaking of which, many developers use Linux, and many more sites are
served off Linux boxes. And Linux is GPL. And that doesn't seem to
bother anyone, right?
Anthony
On Saturday, December 11, 2010 11:37:23 PM UTC-5, Branko Vukelic wrote:
I think it's better to just remove the favicon. Having a default logo
is just as bad as having a web2py logo.
Michele Comitini
commercial company, it is free!
I think that it would be much better that templates and static files
of welcome app (and admin app?) must be distributed with
a more liberal license.
We should eventually ask suggestions to FSF.
mic
2010/12/12 Anthony <abas...@gmail.com>:
LightDot
Don't know if the analogy of linux OS / webservers completely applys here. I'm writing this from a laptop running Fedora 14 and we run CentOS on all our severs, but web2py application and it's relation to web2py could be a different thing.
Nego, srdačan pozdrav iz Šapca :)
Branko Vukelic
> Companies don't really care if I tell them that it's a no brainer, they look
> at this issues trough the eyes of a business risk and consult lawyers to
> minimize them. There are some who get cold feet when they see GPL but can
> live with MIT or BSD.
Oh, you mean THOSE companies. I say fuck 'em. ;)
@others: he knows what I mean.
> Don't know if the analogy of linux OS / webservers completely applys here.
> I'm writing this from a laptop running Fedora 14 and we run CentOS on all
> our severs, but web2py application and it's relation to web2py could be a
> different thing.
Not really. web2py is just a platform. As long as the platform doesn't
inject its own code into your code, you can think of it as of a web
server or anything like that. It just runs your code.
> Nego, srdačan pozdrav iz Šapca :)
@others: Sorry about off-languag here. Just saying hi to the Serbian buddy.
Pozdrav. :) Inace, pravna kod nas vec 2 meseca razmatra da li Inkscape
i Blender (GPL) mogu da se koriste u komercijalne svrhe, iako sam im
dao odlomke i iz GPL-a i iz FAQ-a koji pokazuju da to moze. Toliko o
nasim pravnicima i njihovoj kompetenciji.
pbreit
Branko Vukelic
> Are there any advantages of GPL (with respect to "frameworks")?
It depends.
mdipierro
closed source derivative, and screw the original project.
In my experience, MIT/BSD projects tend to be smaller, fragmented and
with a lot of incompatible forks when compared with GPL projects. Of
course there are exceptions.
Massimo
pbreit
mdipierro
since the web2py license clearly states it does not apply to them.
Users of the framework can release their code under any license they
like.
Massimo
Branko Vukelic
> But as you say, BSD/MIT are better for users.
He didn't say that.
pbreit
mdipierro
The license of web2py is not up for discussion.
I say (and said) that the GPL license applies to derivative work only.
Applications built with web2py and distributed with web2py (compiled
or not) are not derivative work therefore the license does not apply.
My statement has a legal validity because I have complete copyright on
web2py.
Having as many users as possible is not a goal. The goal is to have
the best web2py framework and not fragment the community. The GPL
license, in my view, helps to keep the community together.
Massimo
Branko Vukelic
> I think we should close this discussion. It is not going anywhere.
> The license of web2py is not up for discussion.
+1
pbreit
Michele Comitini
Sorry I have to disagree with this, many users are developers and
contributors. They agreed to share
their work with GPL by contract. GPL grants that credit is due to
developers and contributors.
It is simple: individuals and corporations that invest in web2py *are
users* and agree to share all modifications to the framework
with other individuals or corporations that use them. It is a matter
of *fair competition*.
VP
think it's important to clarify the issues surrounding the license so
people are clear.
The question is "can a web2py app be not GPL when the framework is
GPL?". I don't think it's as clear cut as someone might suggest. At
least it is controversial in a similar way as using GPL libraries or
linking to GPL code (ref: http://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works)
Clearly an app developed by web2py framework is separate from the
framework, but at the same time, it cannot run without using the
framework. Especially when the app is compiled, it could be
considered a case of "static linking" (??).
The other issue is even if this scenario isn't quite kosher with
respect to how GPL works, but if web2py (Massimo) explicitly permits
it to be non-GPL, will that still be okay?
I don't mean to beat a dead horse, but I think it is quite important
for people what are interested in developing commercial apps using
web2py.
mdipierro
paid for them. All web2py contributors sign a contributors agreement
which gives me permissions to use the code as I see fit (and they also
retain full rights on the contributed code), independently on the GPL.
This means I can release the code under GPL, I can change the license,
I can add licenses, etc. For example I offer the "commercial
exception" which allows you to distribute your apps with official
web2py binaries. That is not compatible with the GPL but I can do it
(it is an example of dual license).
If a user needs something that is incompatible with the GPL, I can
offer a customized license (although this never came up so far).
You need to make a distinction. I am not claiming thatm for other
frameworks which are GPL, software developed by with framework is not
bound by the GPL. I am not making any statement about the validity of
GPL. I am making a specific statement about web2py and I can do so
because I have more rights than GPL grants because I am not bound by
the GPL myself. I have full copyright.
The web2py license says that applications built with web2py (.w2p
apps) are not derivative work and GPL does not apply. Instead, if you
build a derivative framework or if you use Flask and import dal.py,
than GPL applies. Again, this is not a statement about the GPL, this
is the web2py license.
If you feel that the web2py license is not clean enough in this
regard, that can be rephrased better.
Massimo
On Dec 12, 4:07 pm, VP <vtp2...@gmail.com> wrote:
> While I don't necessarily advocate for changing web2py's license, I
> think it's important to clarify the issues surrounding the license so
> people are clear.
>
> The question is "can a web2py app be not GPL when the framework is
> GPL?". I don't think it's as clear cut as someone might suggest. At
> least it is controversial in a similar way as using GPL libraries or
pbreit
mdipierro
derivative of the framework. That is exactly what this community wants
to protect against. That is something that can kill an open source
project and the reason GPL was invented.
This discussion has nothing to do with users who are not affected.
Please contact me privately about what you want to do. Perhaps you
need a special license. Depending on what you need to do I may provide
such license to you.
Massimo
Branko Vukelic
Branko Vukelic
Q. Does prelinking a GPLed binary to various libraries on the system,
to optimize its performance, count as modification?
A. No. Prelinking is part of a compilation process; it doesn't
introduce any license requirements above and beyond what other aspects
of compilation would. If you're allowed to link the program to the
libraries at all, then it's fine to prelink with them as well. If you
distribute prelinked object code, you need to follow the terms of
section 6.
I think this answers the original question. You do not violate GPL by
having import statements in your code, as you can safely detach your
code from web2py and reattach to another copy running somewhere else.
Branko Vukelic
Q. In what cases is the output of a GPL program covered by the GPL too?
A. Only when the program copies part of itself into the output.
Graham Dumpleton
On Monday, December 13, 2010 1:39:57 PM UTC+11, Branko Vukelic wrote:
Since someone mentioned linking, etc, here's an exceprt from the GNU FAQ:Q. Does prelinking a GPLed binary to various libraries on the system,
to optimize its performance, count as modification?A. No. Prelinking is part of a compilation process; it doesn't
introduce any license requirements above and beyond what other aspects
of compilation would. If you're allowed to link the program to the
libraries at all, then it's fine to prelink with them as well. If you
distribute prelinked object code, you need to follow the terms of
section 6.I think this answers the original question. You do not violate GPL by
having import statements in your code, as you can safely detach your
code from web2py and reattach to another copy running somewhere else.
Branko Vukelic
<graham.d...@gmail.com> wrote:
> As such, you can't rely on what you quote above. The only way is an
> exception statement to the GPL and even then that would need to be very
> carefully worded. In all this you really need a lawyer to look at the
> situation and draft that exception. If that hasn't been done and some legal
> evidence provided to show that the way the exception is done is valid and
> will stand up in a court of law, it is very easy to see why companies, who
> are going to be very risk averse, would be hesitant to use software that
> relies on the GPL but with some sort of stated exception where the latter is
> of unknown validity and with no legal precedent to support it.
> Graham
You keep forgetting that 1. such an exception exists, and 2. Massimo
is the only person that can exercise GPL in this case, since all
contributors specifically signed such a contract.
Anyway, I've already asked GNU to advise. I'll let you know what they say.
LightDot
I can perhaps relate my experience with CakePHP (using it since the middle of 2006). Every once in a while I see a published code snippet/module/plugin saying something like "this was a part of our closed source application and we are now making it public..." etc. The MIT license of Cake PHP enables this without any question. But apparently so does the license of web2py. We are talking about the application side of the things here...
I have never either wanted or needed to fork the CakePHP framework and make it de facto closed source. I'm not saying it hasn't been done (MIT license and all), but I've never seen it or done it.
So if the end result is the same (one can freely produce open or closed source applications, modules, etc.), i'm all for the GPLv2 license. It is clearly better for the community.
Branko Vukelic
> and all), but I've never seen it or done it.
Which is also the point of MIT. And exactly why massimo insists on
GPL, which forbids this.
> So if the end result is the same (one can freely produce open or closed
> source applications, modules, etc.), i'm all for the GPLv2 license. It is
> clearly better for the community.
There's a difference between GPLv2 and Massimo. Massimo specifically
allows creating closed-source software that runs on web2py despite the
possibility that GPL itself may not necessarily allow this. Regardless
of the conclusion of this GPL agenda, the bottom line is you are free
to create closed-source web2py apps (as long as you don't publish
binary-only web2py modifications, that is). ;)
mdipierro
languages) when you link a library the compiled code of the library
becomes part of the executable. In the case of Python and interpreted
languages you have import, which is not the same as linking. It is
equivalent to linking IF and only IF, the py or the pyc files of the
imported module are distributed with the compiled app (case 1). It is
not linking if the py or pyc modules are not distributed together
(case 2). In case 2 the GPL does not apply. Case 1 is not allowed by
the GPL and that is why have the commercial exception.
There are three cases:
1) you distribute your app open or closed source with web2py source
(allowed by GPL)
2) you distribute your app open or closed source with web2py binary
(not allowed by GPL but allowed by the web2py commercial exception
which treats the web2py binaries not as GPL but as freeware)
3) you distribute your app closed source with part of web2py or with a
modified version of web2py (this is not allowed by the current license
but it would be allowed if the license was MIT/BSD or LGPL).
I do not know of any "standard" license that allows 1,2 but not 3.
Massimo
On Dec 12, 10:01 pm, Branko Vukelic <bg.bra...@gmail.com> wrote:
> > and all), but I've never seen it or done it.
>
> Which is also the point of MIT. And exactly why massimo insists on
> GPL, which forbids this.
>
> > So if the end result is the same (one can freely produce open or closed
> > source applications, modules, etc.), i'm all for the GPLv2 license. It is
> > clearly better for the community.
>
> There's a difference between GPLv2 and Massimo. Massimo specifically
> allows creating closed-source software that runs on web2py despite the
> possibility that GPL itself may not necessarily allow this. Regardless
> of the conclusion of this GPL agenda, the bottom line is you are free
> to create closed-source web2py apps (as long as you don't publish
> binary-only web2py modifications, that is). ;)
>
> --
> Branko Vukelić
>
Branko Vukelic
> imported module are distributed with the compiled app (case 1). It is
> not linking if the py or pyc modules are not distributed together
> (case 2). In case 2 the GPL does not apply. Case 1 is not allowed by
> the GPL and that is why have the commercial exception.
There's an exception clause in LGPL that allows you to do 1 provided
that the vendor makes an explicit offer of source code for the
portions covered by LGPL and explains to the users that the portions
are covered by LGPL in the first place.
--
Branko Vukelić
mdipierro
On Dec 12, 11:07 pm, Branko Vukelic <bg.bra...@gmail.com> wrote:
> > imported module are distributed with the compiled app (case 1). It is
> > not linking if the py or pyc modules are not distributed together
> > (case 2). In case 2 the GPL does not apply. Case 1 is not allowed by
> > the GPL and that is why have the commercial exception.
>
> There's an exception clause in LGPL that allows you to do 1 provided
> that the vendor makes an explicit offer of source code for the
> portions covered by LGPL and explains to the users that the portions
> are covered by LGPL in the first place.
>
> --
> Branko Vukelić
>
Christopher Steel
bring our game up to a higher level.
It seems to me that if the scaffolding app (welcome) is copyright
Massimo and owned by him and/or Web2py then he/web2py have the legal
right to do with it what they will.
If we feel like making Massimo work some more and he is willing (or
the Web2py legal entity) then we could do something like this:
Create Application [ ]
Target License [ ] Drop Down or cool
search function
Where the "Target License" could come from the list at
http://www.opensource.org/licenses/alphabetical or some other trusted
source of software licenses. So when I am doing an app for my
commercial client he chooses MIT cause he knows he can resell it and
so on and when I create his app appname/LICENSE gets populated with
the content at
http://www.opensource.org/licenses/mit-license.php
In addition to keeping lawyers happy about the target application by
forcing indecisive and/or procrastinating developers (is this not the
one requirement for being Pythonic?) to decide on an "official"
license for their application up front it also gives the client, the
developer and anyone following in their footsteps clear legal footing
which in turns allows for a greater adoption of Web2py applications
and the code included in the application.
I think that providing for a mechanism that gives a high level of
clarity right at the initial creation of an application will go a long
way towards resolving this issue for legal entities and in the minds
of developers as well.
On Dec 11, 4:02 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> You have a good point. The welcome scaffolding app is not GPL. It is
> pubic domain (no license whatsoever).
> I have said that before but it is not explicitly stated in the
> license.
> I will add a statement to the top of each .py file in the welcome app.
>
> Massimo
>
> On Dec 11, 2:52 pm, Branko Vukelic <bg.bra...@gmail.com> wrote:
>
> > On Sat, Dec 11, 2010 at 9:49 PM, VP <vtp2...@gmail.com> wrote:
> > > My understanding is this. The apps that you develop with Web2py does
> > > not have to be GPL, and can be licensed in any way you want. (I am
> > > unsure if this violates GPL's terms or not, but this is what I think
> > > how web2py's licensing permits).
>
> > > What is GPL is the web2py framework itself. So, as long as your app
> > > does not touch web2py's core and stay within web2py/applications/
> > > yourapp directory, that should be okay. On the other hand, if you
> > > want to take web2py add features to it, modify it, then it will have
> > > to be GPL.
>
> > There's one catch, though. If a piece of code is a template that comes
> > with web2py (which means the template code is also GPL), does the
> > template, which is covered by GPL, also prevent you from distributing
> > templates as binary-only.
>
> > I don't mean HTML etc. Those are static files anyway. I mean the .py
> > templates like the db.py template that is included in the welcome app.
> > When you start off, 100% of your app is comprised of GPL'd code from
> > the welcome app.
Anthony
There are three cases:
1) you distribute your app open or closed source with web2py source
(allowed by GPL)
2) you distribute your app open or closed source with web2py binary
(not allowed by GPL but allowed by the web2py commercial exception
which treats the web2py binaries not as GPL but as freeware)
3) you distribute your app closed source with part of web2py or with a
modified version of web2py (this is not allowed by the current license
but it would be allowed if the license was MIT/BSD or LGPL).
I do not know of any "standard" license that allows 1,2 but not 3.
Anthony
Massimo
On Dec 12, 10:01 pm, Branko Vukelic <bg.b...@gmail.com> wrote:
> On Mon, Dec 13, 2010 at 4:53 AM, LightDot <ligh...@gmail.com> wrote:
> > and all), but I've never seen it or done it.
>
> Which is also the point of MIT. And exactly why massimo insists on
> GPL, which forbids this.
>
> > So if the end result is the same (one can freely produce open or closed
> > source applications, modules, etc.), i'm all for the GPLv2 license. It is
> > clearly better for the community.
>
> There's a difference between GPLv2 and Massimo. Massimo specifically
> allows creating closed-source software that runs on web2py despite the
> possibility that GPL itself may not necessarily allow this. Regardless
> of the conclusion of this GPL agenda, the bottom line is you are free
> to create closed-source web2py apps (as long as you don't publish
> binary-only web2py modifications, that is). ;)
>
> --
> Branko Vukelić
>
> bg.b...@gmail.com
mdipierro
> On Sunday, December 12, 2010 11:46:38 PM UTC-5, mdipierro wrote: There
> are three cases:
> 1) you distribute your app open or closed source with web2py source
> (allowed by GPL)
>
> Doesn't the GPL by itself actually prohibit distributing a closed
> source web2py app because of the linking issue? I thought the following
> explicit exception is what allows that, no?
>
> "You can distribute web2py app under any license you like as long they
> do not contain web2py code."
Anyway, let's take a poll. What if we do the following?
1) all web2py/*.py and web2py/gluon/*py files are LPGL
2) all web2py/gluon/contrib/* files are LGPL unless specified
otherwise (MIT or BSD are possible for third party contributions)
3) the official web2py binaries for Mac and Windows are freeware
4) the scaffolding app is public domain except for images/css/js files
which may have their own licenses.
Is this more or less confusing?
How can we make it more clear?
Would any of the major contributors strongly oppose?
If so, why?
Massimo
ron_m
JBOSS the RedHat JEE platform also states that although JBOSS is GPL there is no requirement for applications written to run on the app server be GPL unless they take a piece of the platform that is under GPL and modify it for their own purposes and then include that as part of their work.
for web2py I can live with GPL with the statement from Massimo or LGPL.
Ever look at the Python license? Listed as GPL compatible, but allows derived works that embed the interpreter. That is a hard to figure one.
http://docs.python.org/license.html
Anthony
> On Sunday, December 12, 2010 11:46:38 PM UTC-5, mdipierro wrote: There
> are three cases:
> 1) you distribute your app open or closed source with web2py source
> (allowed by GPL)
>
> Doesn't the GPL by itself actually prohibit distributing a closed
> source web2py app because of the linking issue? I thought the following
> explicit exception is what allows that, no?
>
> "You can distribute web2py app under any license you like as long they
> do not contain web2py code."
Not quite because importing is not the same as linking.
Anyway, let's take a poll. What if we do the following?
1) all web2py/*.py and web2py/gluon/*py files are LPGL
2) all web2py/gluon/contrib/* files are LGPL unless specified
otherwise (MIT or BSD are possible for third party contributions)
3) the official web2py binaries for Mac and Windows are freeware
4) the scaffolding app is public domain except for images/css/js files
which may have their own licenses.
Is this more or less confusing?
How can we make it more clear?
Would any of the major contributors strongly oppose?
If so, why?
Branko Vukelic
> 1) all web2py/*.py and web2py/gluon/*py files are LPGL
+1
> 2) all web2py/gluon/contrib/* files are LGPL unless specified
+1
> otherwise (MIT or BSD are possible for third party contributions)
3rd party contributions that were released as MIT or BSD cannot be
licensed under LGPL because they're incompatible. e.g., BSD says
"shall not place any more limitations yada yada" or something like
that, and LGPL does just that: place limitations on what you can do by
telling you not to close-source, etc.
> 3) the official web2py binaries for Mac and Windows are freeware
There's no need. You just have to point to the source code and you can
still distrubite Win/Mac as binary-only even, under LGPL.
> 4) the scaffolding app is public domain except for images/css/js files
> which may have their own licenses.
I dunno about PD. It doesn't exist everywhere. :) A better solution
would be to offer unrestricted use provided intellectual property
(logos and web2py name) is removed etc etc.
> Is this more or less confusing?
Yes. It's the nature of the beast. :)
> How can we make it more clear?
A FAQ that explains what you can do with the stuff.
Branko Vukelic
> source and freeware for binaries) rather than "LGPL with a commercial
> exception" (which could lead to confusion and concern).
LGPL _is_ the commercial exception. That's why they call it "lesser". :)
Branko Vukelic
way Python does is considered creating derivative work, and LGPL would
not, in their view, except the vendor from the obligation to release
their apps under the terms of (L)GPL (which is kinda surprising). As
solution to this they suggested two things:
1. make dual license, of which the commercial license would be for-pay
and would allow companies to make closed-source derivatives or
distribution of web2py and/or web2py apps
2. make an exeption clause under GPL for the apps (which is what
Massimo does and is perfectly ok)
I think it'd be best that the source version of web2py be covered by
the 2., and that the 'freeware' version be made 'shareware' (pay to
bundle the binary, that is) as an option 1. At any rate, the
conclusion is that the exception does cover the proprietary
distribution of web2py apps and does not violate GPL.
Anthony
On Mon, Dec 13, 2010 at 9:11 AM, Anthony <abas...@gmail.com> wrote:
> source and freeware for binaries) rather than "LGPL with a commercial
> exception" (which could lead to confusion and concern).LGPL _is_ the commercial exception. That's why they call it "lesser". :)
Branko Vukelic
> Yes, LGPL (I think) allows the exception to distribute the source along with
> an application that links/imports the source. I was talking about the other
> web2py exception, which allows distribution of the binaries without the
> source at all (i.e., the freeware license for the binaries). Currently, we
Why? I don't think it would be too much to ask companies to pay for
binary-only bundling. If you can distribute with the sources (meaning
either put sources in the bundle, or offer sources some other way,
mind you), why not? I have absolutely nothing against that. If a
company is not prepared to do that, they should use a closed-source
product that allows this.
Anthony
On Mon, Dec 13, 2010 at 8:00 AM, mdipierro <mdip...@cs.depaul.edu> wrote:
> otherwise (MIT or BSD are possible for third party contributions)
3rd party contributions that were released as MIT or BSD cannot be
licensed under LGPL because they're incompatible. e.g., BSD says
"shall not place any more limitations yada yada" or something like
that, and LGPL does just that: place limitations on what you can do by
telling you not to close-source, etc.
There's no need. You just have to point to the source code and you can
still distrubite Win/Mac as binary-only even, under LGPL.
> Is this more or less confusing?
Yes. It's the nature of the beast. :)
Branko Vukelic
> Hmm, I thought it was just the opposite -- people like MIT/BSD because they
> don't place any restrictions on how you license a modified/derived work. So,
> you can take an MIT/BSD licensed program, modify/combine it, and then
> release the modified/combined version as LGPL, GPL, or even closed source.
MIT does not permit that, as far as I can tell. "to deal in the
Software without restriction", which invalidates your claim because
"The above copyright notice and this permission notice shall be
included in
all copies or substantial portions of the Software."
Closed-source means restriction, and so does GPL. So MIT is not
compatible. Afaik, GPL doesn't consider BSD as GPL-compatible, either.
> You can't go the other way, though (i.e., you can't modify/combine a
> GPL/LGPL program and release it as MIT/BSD). The GNU website lists both the
> modified BSD and the MIT (Expat) licenses as GPL-compatible
> (http://www.gnu.org/licenses/license-list.html).
Yes, in a way they are. MIT is even viral, like GPL.
> If this isn't the case, then web2py would already be in violation of various
> contrib licenses, no?
Yes.
> Yes, I think that's right (if you just "point" to the source rather than
> actually include it, you might have to make sure you point to the originally
> distributed version, not just the current version at web2py.com). We might
> simplify this by (a) including a link to the appropriate source version
That won't do. According to GNU, you have to host the sources
yourself, and ensure that it is available at least 3 years after
you've stopped distributing the binaries. I think there is a loophole
for this in v2, though, but v3 definitely plugged it. The Arch linux
community was forced to start hosting the entire corpus of sources
they were building on to get into compliance.
> right in the license document of the binary version, or (b) including a zip
> file with the source right in the binary version -- so any distribution of
> the binary version would automatically satisfy the GPL/LGPL license without
> any further effort by the developer/distributor.
That's reasonable, yeah.
> Are you saying yes, it's more confusing? Whether or not it's confusing, I
> think it may be less confusing than the current license because it removes
> one of the exceptions (for web2py applications) by switching to the LGPL. If
According to GNU, it does not. So an exception is the best solution. A
more hussle-free option could be offered as a second license, whether
for pay or free of charge, although I think for-pay would just be
being fair to the project.
> we can also remove the binary distribution exception (and rely on the
> GPL/LGPL provision for binary distribution), it would become simpler still.
> I guess the only issue is whether people would readily understand that the
> LGPL wouldn't apply to web2py apps and would allow binary distribution --
> you have to read through the license carefully to figure that out (unless
> you're already familiar with the LGPL). So, if we switch to LGPL, it would
> probably be worth pointing this out in a FAQ, and maybe even including an
> explanation with the license, just so it's very clear what is permitted.
I think there need not be any provisions for using or distributing
web2py itself except those that are offered by the GPL. In fact, I'd
go as far as to make web2py AGPL isntead. The problem was this forced
app developers to develop under GPL. And that's what the exception is
about. GPL does NOT prevent you from distributing binary-only web2py
with your proprietary binary-only app as long as you comply to GPL for
the web2py part. Your app is GPL-free anyway. I just don't understand
why you insist that closed-source web2py should be allowed. I don't
think it should be, and Massimo has also stated to that effect.
Branko Vukelic
>Your app is GPL-free anyway
Because of the exception, to be precise, not according to GPL.
Anthony
On Mon, Dec 13, 2010 at 4:13 PM, Anthony <abas...@gmail.com> wrote:
> Hmm, I thought it was just the opposite -- people like MIT/BSD because they
> don't place any restrictions on how you license a modified/derived work. So,
> you can take an MIT/BSD licensed program, modify/combine it, and then
> release the modified/combined version as LGPL, GPL, or even closed source.MIT does not permit that, as far as I can tell. "to deal in the
Software without restriction", which invalidates your claim because
"The above copyright notice and this permission notice shall be
included in
all copies or substantial portions of the Software."
Closed-source means restriction, and so does GPL. So MIT is not
compatible. Afaik, GPL doesn't consider BSD as GPL-compatible, either.
> If this isn't the case, then web2py would already be in violation of various
> contrib licenses, no?Yes.
> Yes, I think that's right (if you just "point" to the source rather than
> actually include it, you might have to make sure you point to the originally
> distributed version, not just the current version at web2py.com). We might
> simplify this by (a) including a link to the appropriate source versionThat won't do. According to GNU, you have to host the sources
yourself, and ensure that it is available at least 3 years after
you've stopped distributing the binaries.
I just don't understand
why you insist that closed-source web2py should be allowed. I don't
think it should be, and Massimo has also stated to that effect.
Anthony
On Monday, December 13, 2010 9:36:37 AM UTC-5, Branko Vukelic wrote:
On Mon, Dec 13, 2010 at 2:43 PM, Anthony <abas...@gmail.com> wrote:
> Yes, LGPL (I think) allows the exception to distribute the source along with
> an application that links/imports the source. I was talking about the other
> web2py exception, which allows distribution of the binaries without the
> source at all (i.e., the freeware license for the binaries). Currently, weWhy? I don't think it would be too much to ask companies to pay for
binary-only bundling. If you can distribute with the sources (meaning
either put sources in the bundle, or offer sources some other way,
mind you), why not? I have absolutely nothing against that. If a
company is not prepared to do that, they should use a closed-source
product that allows this.
Anthony
Ok, so I got word from GNU. What they say is that using "imports" the
way Python does is considered creating derivative work, and LGPL would
not, in their view, except the vendor from the obligation to release
their apps under the terms of (L)GPL (which is kinda surprising). As
solution to this they suggested two things:
LightDot
- a python framework licensed under a pure GPLv2 would not allow for a closed source application development, so Massimo's exception is crucial for such projects
- changing the license from the current GPLv2 with en exception to the LGPL brings no improvement
- changing from GPLv2 with an exception to BSD/MIT is not an option.
I also see that the license for the Welcome application has been added in the default branch (public domain license). That's great, thanks. I also warmly appreciate Massimo's statements in this thread in regards to the possibility of individual licensing, should the need arise.
So, it seems that my original questions and our customer's concerns in regards to licensing were more than valid. I would suggest creating a separate and prominent LICENSE page with the exact information, preferably looked over by an experienced lawyer.
If that's possible, of course. I do understand that this entire project depends on it's community and a lot of work is done here on a purely volunteer basis.
I would like to emphasise again, our only concern is about the web2py applications, not the web2py itself. It is not our wish to fork web2py under any license, nor has anyone approached us with such an idea.
Warm regards to all
Wikus van de Merwe
1) I write a web app for a client and *use* it (run) on a server
2) I write a web app and *distribute* it to a client so that he can run it himself
In first scenario, as GPL allows me to *use* the software for any purpose I can mix it with my proprietary code. Not only the application code but I can even change the web2py code, as GPL allows me to *modify* the software to my needs. I don't distribute any of my code and I'm not required to provide it source code to anyone. This would be the case only if web2py would be covered by AGPL [1].
In the second scenario, as long as you choose to *distribute* your code, it has to be released on a GPL compatible terms (note, not a GPL itself!) as it makes use of GPL modules (web2py). You could argue that a web application is separated from the framework, but in fact the code of both is run by the same process and shares several data structures in memory (see [2-4]). According to GPL this constitutes a derived work. Note, however, that the code distribution on GPL terms only happens between me and my client (she gets the freedom to modify and distribute it under the same license) and I don't have to create a website and put the application code for everybody in the world to download.
Yet, web2py does not use the verbatim GPL but adds 2 special exceptions to it [6]:
1) applications written for web2py are not considered derivative works as long as they do not share web2py code
2) I can distribute the unmodified web2py binary with my application as long as it is properly attributed
Now, if for some reason I want to *distribute* my web application to a client (not *use*/deploy it on a server) in a binary form without providing the source code (i.e. in a GPL incompatible way) I can do it because such a special permission from the web2py author have been granted (and GPL allows such exceptions [7]).
So as you see, the GPL alone as well as the special case of licensing of web2py and application written for it is quite complex. I believe we all would benefit from having all this explained in a separate section of the website, to avoid confusion.
> 1) all web2py/*.py and web2py/gluon/*py files are LPGL
There are 2 differences though. First, minor, the binary distribution of LGPL code has to be accompanied with source. Second, major, parts of the web2py code such as DAL could be used independently on LGPL terms, while now they are covered by GPL so that non-free derivatives of DAL are not allowed.
"Proprietary software developers, seeking to deny the free competition an important advantage, will try to convince authors not to contribute libraries to the GPL-covered collection. For example, they may appeal to the ego, promising 'more users for this library' if we let them use the code in proprietary software products. Popularity is tempting, and it is easy for a library developer to rationalize the idea that boosting the popularity of that one library is what the community needs above all." [9]
"The goal of the GPL is to grant everyone the freedom to copy, redistribute, understand, and modify a program. If you could incorporate GPL-covered software into a non-free system, it would have the effect of making the GPL-covered software non-free too." [10]
And I believe this is a major point in the discussion. Special privileges for distribution of the application code is one thing, and allowing proprietary derivative works of the framework itself is another. To be honest I don't see any benefits of such a licence change.
> 2) all web2py/gluon/contrib/* files are LGPL unless specified otherwise (MIT or BSD are possible for third party contributions)
> 3) the official web2py binaries for Mac and Windows are freeware
> 4) the scaffolding app is public domain except for images/css/js files which may have their own licenses.
[1] http://www.gnu.org/licenses/gpl-faq.html#UnreleasedMods
[2] http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem
[3] http://www.gnu.org/licenses/gpl-faq.html#OOPLang
[4] http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins
[5] http://www.web2py.com/AlterEgo/default/show/47
[6] http://web2py.com/book/default/chapter/01#License
[7] http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF
[8] http://www.gnu.org/licenses/lgpl-java.html
[9] http://www.gnu.org/licenses/why-not-lgpl.html
[10] http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem
[11] http://creativecommons.org/about/cc0
Branko Vukelic
> On Monday, December 13, 2010 8:38:12 AM UTC-5, Branko Vukelic wrote:
> Sorry, I missed this post. Would you mind sending the exact question you
> asked and the full response from GNU? I'm surprised because I would think a
> web2py app would qualify as an "Application" or a "Combined Work" under
> LGPL:
Start verbatim copy ---------------------------------
> On Mon, Dec 13, 2010 at 1:09 PM, --- <lice...@fsf.org> wrote:
> > Importing code and sharing namespaces would most probably be creating a
> > derivative work and would need to be licensed under GPLv2 as well.
> Ok, so let me clarify a bit. By importing code, we mean (since this is
> a Python library) that the application framework will execute parts of
> the application, and that the application in turn may execute parts of
> the framework. It is a fact that the application may not execute
> properly without the presence of the framework, but the framework
> authors do not consider applications derivative work because of this.
> Could you please advise on this position?
The answer would be the same. These activities would create a derivative
work.
> Would releasing the framework under the terms of LGPL allow
> proprietary software vendors to
If the goal is to allow proprietary software vendors to do certain
things you should just say so. There are ways of doing this without
harming the free software community. The LGPL isn't recommended in this
case (see: [http://www.gnu.org/licenses/why-not-lgpl.html]).
One way is to dual-license the code. Release the code under a strong
copyleft license such as the GPL and if a company wishes to distribute
it under proprietary terms sell them a copy of the software under a
suitable license. Done right this is a great way of funding the
development of free software. This was everyone always has access to a
copy of the code under a free software license and proprietary software
companies fund your development efforts.
Another way is to Release the code under a strong copyleft license such
as the GPL and to add narrowly defined exceptions which would allow
proprietary software to interact with your software in particular
ways. See:
[http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs]
End verbatim copy ---------------------------------
Judge for yourself if I understood correctly what the guy says.
> "An “Application” is any work that makes use of an interface provided by the
> Library, but which is not otherwise based on the Library. Defining a
> subclass of a class defined by the Library is deemed a mode of using an
> interface provided by the Library."
>
> "A “Combined Work” is a work produced by combining or linking an Application
> with the Library. The particular version of the Library with which the
> Combined Work was made is also called the “Linked Version”.
>
Well, yes. That's exactly why I considered LGPL a good option for us.
But apparently GNU differs on this.
Branko Vukelic
<dupak...@googlemail.com> wrote:
> So as you see, the GPL alone as well as the special case of licensing of
> web2py and application written for it is quite complex. I believe we all
> would benefit from having all this explained in a separate section of the
> website, to avoid confusion.
Massimo is not available atm for health reasons, but he has already
considered doing this, and I'm sure he will make it very clear that
web2py is, indeed, dual-licensed.
>> 1) all web2py/*.py and web2py/gluon/*py files are LPGL
> "The goal of the GPL is to grant everyone the freedom to copy, redistribute,
> understand, and modify a program. If you could incorporate GPL-covered
> software into a non-free system, it would have the effect of making the
> GPL-covered software non-free too." [10]
>
> And I believe this is a major point in the discussion. Special privileges
> for distribution of the application code is one thing, and allowing
> proprietary derivative works of the framework itself is another. To be
> honest I don't see any benefits of such a licence change.
Thank you for summing that up. :) I also believe people are missing
the main point here, and that is Massimo is fully commited to the
points above. That is the first reason why he chose GPL as the license
in the first place. To go against the authors' wishes just to change
the license to the one someone feels more comfortable with is unfair
to say the least. As Massimo said once, web2py is not about creating a
mass-consumption framework. There are plenty of those to go around.
His wish is to create a good framework that does its job well, and I
think GPL license can only help that.
> This is what we currently have, with except to LGPL for files in contrib, so
> I guess there is not much to discuss here. As long as contrib files are
> optional and their licence is GPL compatible, everything is fine here.
> Binaries under the GPL exception are effectively freeware. And the template
> app will work best as public domain as the licensing issues won't get in the
> way. It might be good though to explicitly state the permissions (e.g. as in
> CC0 [11])as in some countries such as France, work can't be put into the
> public domain voluntarily.
Again, even the welcome app can be GPL as long as there is an
exception clause similar to the one used for web2py apps. For
instance, if you consider welcome app as part of web2py (because it
uses it to scaffold new applications via the wizard, for instance),
all development on the welcome app should contribute back to upstream,
and GPL ensures this. However, the actual use of the welcome app for
scaffolding your apps can be liberated from the terms of GPL. It all
depends on whether you consider it worthwhile to do that.
pbreit
Anthony
Anthony
> 1) all web2py/*.py and web2py/gluon/*py files are LPGL
> "The goal of the GPL is to grant everyone the freedom to copy, redistribute,
> understand, and modify a program. If you could incorporate GPL-covered
> software into a non-free system, it would have the effect of making the
> GPL-covered software non-free too." [10]
>
> And I believe this is a major point in the discussion. Special privileges
> for distribution of the application code is one thing, and allowing
> proprietary derivative works of the framework itself is another. To be
> honest I don't see any benefits of such a licence change.Thank you for summing that up. :) I also believe people are missing
the main point here, and that is Massimo is fully commited to the
points above. That is the first reason why he chose GPL as the license
in the first place. To go against the authors' wishes just to change
the license to the one someone feels more comfortable with is unfair
to say the least. As Massimo said once, web2py is not about creating a
mass-consumption framework. There are plenty of those to go around.
His wish is to create a good framework that does its job well, and I
think GPL license can only help that.
Branko Vukelic
> intellectual property attorney with open source experience. Maybe it's not
> worth the bother/cost right now, though.
First, technically, GPL license is totally ok if we look at web2py on
its own. It gets the job done. Releasing web2py under LGPL
accomplishes nothing for the framework that GPL hasn't already. We
were actually discussing applications built to run on top of web2py.
That's covered by the exceptions, and imho, they should be enough. No
change is required, since FSF's suggestions are already implemented.
The only thing that needs to change is to make the exceptions more
prominent (FTR, I haven't seen them before this discussion started.)
On the psychological level, I doubt it would accomplish much in the
way of changing people's perception of 'evilness' of the GPL and its
derivatives (like LGPL). I am more and more convinced of this
observing some of the reactions in this discussion. For those cases, I
don't think there is a straightforward solution, other than
counselling maybe.
Having a concrete need for which GPL+exception poses a _real_ obstacle
(and not 'what if, omg, wtf, bbq' FUD) is one thing. Massimo has
already demonstrated that he is open to custom licensing should the
need arise (and FTR, I think he should charge for it, too, but I also
think he would not). If that is not good enough, then maybe web2py
isn't for them after all.
Branko Vukelic
> Unless there is a move away from GPL, I don't think it's worthwhile to split
Absolutely. You do not have to discuss the LGPL/GPL licensing issue if
it offends you so much. Especially if you cannot refrain from
name-calling during the process.
Graham Dumpleton
On Tuesday, December 14, 2010 9:46:09 AM UTC+11, Anthony wrote:
On Monday, December 13, 2010 3:30:17 PM UTC-5, Branko Vukelic wrote:
Start verbatim copy ---------------------------------
Anthony
First, technically, GPL license is totally ok if we look at web2py on
its own. It gets the job done. Releasing web2py under LGPL
accomplishes nothing for the framework that GPL hasn't already.
We were actually discussing applications built to run on top of web2py.
That's covered by the exceptions, and imho, they should be enough. No
change is required, since FSF's suggestions are already implemented.
The only thing that needs to change is to make the exceptions more
prominent (FTR, I haven't seen them before this discussion started.)
On the psychological level, I doubt it would accomplish much in the
way of changing people's perception of 'evilness' of the GPL and its
derivatives (like LGPL).
Branko Vukelic
<graham.d...@gmail.com> wrote:
> it being a part of the library. Thus technically the template code may be
> construed as ending up as part of your application.
FSF specifically allows this in LGPL, if I'm not mistaken:
"The object code form of an Application may incorporate material from
a header file that is part of the Library. You may convey such object
code under terms of your choice, provided that, if the incorporated
material is not limited to numerical parameters, data structure
layouts and accessors, or small macros, inline functions and templates
(ten or fewer lines in length), you do both of the following:
a) Give prominent notice with each copy of the object code that the
Library is used in it and that the Library and its use are
covered by this License.
b) Accompany the object code with a copy of the GNU GPL and this license
document."
Graham Dumpleton
Branko Vukelic
<graham.d...@gmail.com> wrote:
> They may have clarified it then. I am only going by what problems I knew
> came up many many many years ago, ie., early 90s.
However, web2py is still using GPLv2 :P That ought to be fixed. GPLv3
is both more liberal about some things, and fixes lots of loopholes
from GPLv2, so it's basically 'better', depending on where you come
from, that is.
> Another good example of why lawyers are a good idea. We all often go based
> on possibly out of date recollections. :-)
Well, that's something Massimo's wallet has to decide. :)
Branko Vukelic
> The FSF has a different agenda from people who want to distribute their
> web2py applications closed source. GPL plus exceptions certainly works, but
However, FSF's agenda also aligns with that of Massimo and some of us,
contributors. We DO go by the spirit in which GPL was created
(incidentally, I also license my open-source code under GPL/LGPLv3
lately). If exception works, than I think it's good enough.
> apparently it does create an obstacle for some (at least 3 people in this
> thread, and several on reddit, who presumably are representative of some
> segment of the potential user population). Is it worth catering to this
> segment of the population? Perhaps not, but I don't necessarily want to
> dismiss them as in need of counseling. Most other frameworks are indeed
> MIT/BSD, so these people aren't crazy.
I don't know about Massimo, but to me, potential user facing a real
trouble would be someone like LightDot, who found Massimo's statements
and the exception good enough. You should also look at others who have
already created commercial applications under the provided terms with
no legal consequence. Perhaps these things are underexposed, but
nevertheless it looks to me like there is a way for people to get
informed and start hacking at their own business.
Rather than just switching licenses, why don't we just help Massimo
clarify what he wanted to convey?
> "You can distribute web2py app under any license you like as long they do
> not contain web2py code."
Yes, but that is not entirely correct. Your application will contain
some scaffolding code. It is extremely important that the scaffolding
code be either liberated from the terms of GPL via an exception. I
think I've already mentioned this early on in this thread.
Anyway, here's the excerpt from the book:
"web2py is open source and released under the GPL2.0 license, but
applications developed with web2py are not subject to any license
constraint. In fact, as long as they do not contain web2py source
code, they are not considered "derivative works". web2py also allows
the developer to bytecode-compile applications and distribute them as
closed source, although they will require web2py to run. The web2py
license includes an exception that allows web developers to ship their
products with original pre-compiled web2py binaries, without the
accompanying source code."
The actual commercial exception clause states the following:
"We allow the redistribution of unmodified binary versions of web2py provided
that they contain a link to the official web2py site.
This means you can redistribute web2py in binary or other closed source form
together with the applications you develop as long as you acknowledge the
author. If you make any modification to web2py you must distribute it together
with the modified source code according to GPLv2.0.
You can distribute web2py app under any license you like as long they do not
contain web2py code."
Maybe something like this would be better (optionally vetted by a lawyer):
"binary version" means byte code version of web2py or your application
"application" or "app" is software that is written specifically to run
on web2py framework
"scaffolding" is a process of setting up the necessary directory
structure and files as the initial state of your application source
code
"template code" includes content in HTML and/or CSS and/or plain text
format, placeholder text, images, and Python and/or JavaScript code to
create the initial state of the application source code
"copyrighted template material" includes images and copyright notices
that appear in template content.
"you" means licensee, and may be an individual or a company
"bundling" means distributing an application along with web2py either
as source code or as binary version in unmodified form
A You hare hereby granted non-exclusive and non-perpetual license to:
1. Freely distribute or modify the template code to create an application.
2. Distribute the application under a license of your choosing for
commercial and/or personal use.
3. Distribute the application as source code and/or as binary version.
4. Bundle the binary version of web2py with your application
5. Deploy your application on a web server, or as a service on an
operating system using either the source code or a binary version of
web2py.
B Following restriction apply to above usage:
1. Your application may not include copyrighted template material.
2. Your application may not include web2py source code in either
modified or unmodified form except under the terms of GNU General
Public license, version 2 or any later version (at your option).
3. If your application includes portions of web2py source code, GNU
General Public License shall apply only to the portions of the source
code described under B/2
4. If you bundle the binary version of web2py, you must clearly note
the current web address (URL) of web2py homepage and keep that
information current in all distributed copies of your application.
5. If you bundle the binary version of web2py, you must clearly
reproduce web2py's original copyright notice
I mean something along those lines. Of course, IANAL, etc etc.
Anthony
On Tue, Dec 14, 2010 at 3:43 AM, Anthony <abas...@gmail.com> wrote:
> The FSF has a different agenda from people who want to distribute their
> web2py applications closed source. GPL plus exceptions certainly works, butHowever, FSF's agenda also aligns with that of Massimo and some of us,
contributors. We DO go by the spirit in which GPL was created
(incidentally, I also license my open-source code under GPL/LGPLv3
lately). If exception works, than I think it's good enough.
Rather than just switching licenses, why don't we just help Massimo
clarify what he wanted to convey?
Anthony
On Tue, Dec 14, 2010 at 4:14 AM, Graham Dumpleton
> Another good example of why lawyers are a good idea. We all often go based
> on possibly out of date recollections. :-)Well, that's something Massimo's wallet has to decide. :)
Branko Vukelic
> Sounds good. Though ideally we would get some expert advice at some point.
Agreed.
VP
a lot of people are too. App developers should not have to worry
about the licensing issues. I think the license should be precise and
concise. Further because it combines two types of licenses into one,
it should not be contradicting each other in some way.
Maybe, it doesn't need to be rewritten (much), but needs an FAQ
attached to it.
Branko Vukelic
> I am happy with what Massimo intends web2py's license to be. I think
> a lot of people are too. App developers should not have to worry
> about the licensing issues. I think the license should be precise and
> concise. Further because it combines two types of licenses into one,
> it should not be contradicting each other in some way.
It does need a little bit of clarification, though, especially in the
are of what is considered "including web2py source in your app", and
what is meant by "acknowledging the author" etc.
> Maybe, it doesn't need to be rewritten (much), but needs an FAQ
> attached to it.
Most certainly. I've checked the FAQ and there's no mention of the
commercial exception.