subject:"\[web2py\] Re\: it case you missed it..."

On Dec 16, 2:09 am, Branko Vukelic branko.vuke...@gmx.com wrote:
  Yes, I agree, but all I said was that the concerns are not invalid (I
  also pointed out an issue that has not thus far been addressed --
  standalone DAL). I think we can decide to stick with GPL while still
  recognizing it may present a barrier for some (possibly simply due to
  confusion or risk aversion rather than a real legal threat). This
  issue is both complex and important, so a long discussion should not
  be surprising. I, for one, have learned a lot, and assuming we follow
  through, I believe the result of this long thread will be an
  improvement in the license and therefore the comfort of prospective
  users. Those uninterested in the topic can easily ignore the thread.

 You are missing the main point here, and that's software freedom and two 
 incompatible views regarding that. It's not by conincidence that there is a 
 commercial EXCEPTION to GPL in web2py. The reason it's called an exception is 
 that it is incompatible with the intent of GPL. Now consider that Massimo has 
 _chosen_ GPL with an intent, and that GPL aligns with that intent. Do I need 
 to go on?

I don't _think_ I'm missing the main point, as I agree with what you
state above.

Anthony

Re: [web2py] Re: it case you missed it...

 - Original Message -
 From: Anthony
 Sent: 12/16/10 05:02 PM
 To: web2py-users
 Subject: [web2py] Re: it case you missed it...
 I don't _think_ I'm missing the main point, as I agree with what you
 state above.

Then why are we discussing the license? If you understand that GPL is there to 
protect the freeness of the software, and that's why web2py uses it, then this 
discussion is pointless.

--
Branko Vukelic

branko.vuke...@gmx.com

http://www.brankovukelic.com/
http://flickr.com/photos/foxbunny

[web2py] Re: it case you missed it...

On Dec 16, 11:11 am, Branko Vukelic branko.vuke...@gmx.com wrote:
  I don't _think_ I'm missing the main point, as I agree with what you
  state above.

 Then why are we discussing the license? If you understand that GPL is there 
 to protect
 the freeness of the software, and that's why web2py uses it, then this 
 discussion is
 pointless.

Must just be some misunderstanding across the last few posts, probably
not worth dissecting. I think we're good now.

Cheers,
Anthony

Re: [web2py] Re: it case you missed it...

We are discussing the license because it hinders adoption...hardly a 
pointless topic. Anthony at least acknowledges this.

I posted the question on Quora and it got a reasonable first response:
http://www.quora.com/What-is-the-best-license-for-a-web-framework-ex-Cake-Rails-Django-GPL-BSD-or-MIT

[web2py] Re: it case you missed it...

2010-12-16 Thread Jos? L.



On Sunday, December 12, 2010 7:21:52 PM UTC+1, mdipierro wrote:

 I think we should close this discussion. It is not going anywhere. 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.


+1

Just a latest question: There are some files in gluon/contrib directory 
don't have a license header , some others have a mit license, so there is a 
little mess in this files that are distributed with web2py.

Also, is there any reason to stay in gpl v2 instead of moving to v3?

Regards.
José L.

Re: [web2py] Re: it case you missed it...

 - Original Message -
 From: =?ANSI_X3.4-1968?Q?Jos=3F_L=2E?=
 Sent: 12/16/10 07:23 PM
 To: web2py@googlegroups.com
 Subject: [web2py] Re: it case you missed it...

 Also, is there any reason to stay in gpl v2 instead of moving to v3?

I think someone already pointed out that GPLv3 could be an improvement over 
GPLv2. It closed many of the loopholes, and also became more compatible with 
other licenses such as MIT and BSD 3-clause. That's, I think, important since 
some libs do have code from those two licenses.

--
Branko Vukelic

branko.vuke...@gmx.com

http://www.brankovukelic.com/
http://flickr.com/photos/foxbunny

[web2py] Re: it case you missed it...

2010-12-16 Thread mdipierro

There is a reason I did not choose GPL3 and that it is that GPL3 tries
to close the SAAS loophole explained here:
http://ross.typepad.com/blog/2007/07/open-source-lic.html

I want the loophole to apply to web2py.

Let me explain.

GPL2 predates SAAS therefore running a web service based on GPL2
software is not considered distribution and not subject to the GPL2
limitations. I am fine with this. I do not want to put any limitation
on people running web2py as a service, not even modified/forked/closed
source versions of web2py. I just want to put limitations on people
trying to make forks of web2py and distribute them (in the most
conventional term) closed source.

If we were to move from GPL2 to GPL3 people would not be allowed to
modify web2py running on their servers without making available the
source code of their changes. I do not see any reason for requiring
this.

Massimo



On Dec 16, 12:30 pm, Branko Vukelic branko.vuke...@gmx.com wrote:
  - Original Message -
  From: =?ANSI_X3.4-1968?Q?Jos=3F_L=2E?=
  Sent: 12/16/10 07:23 PM
  To: web2py@googlegroups.com
  Subject: [web2py] Re: it case you missed it...
  Also, is there any reason to stay in gpl v2 instead of moving to v3?

 I think someone already pointed out that GPLv3 could be an improvement over 
 GPLv2. It closed many of the loopholes, and also became more compatible with 
 other licenses such as MIT and BSD 3-clause. That's, I think, important since 
 some libs do have code from those two licenses.

 --
 Branko Vukelic

 branko.vuke...@gmx.com

 http://www.brankovukelic.com/http://flickr.com/photos/foxbunny

Re: [web2py] Re: it case you missed it...

 - Original Message -
 From: mdipierro
 Sent: 12/16/10 07:56 PM
 To: web2py-users
 Subject: [web2py] Re: it case you missed it...

 If we were to move from GPL2 to GPL3 people would not be allowed to
 modify web2py running on their servers without making available the
 source code of their changes. I do not see any reason for requiring
 this.

What's AGPL for then? Wasn't _AGPL_ supposed to prevent that? Anyway, I think 
GPLv3 makes i possible to use code licensed under licenses like MIT and BSD in 
a GPLv3 project, which is otherwise a bit incompatible. Or did I miss something?

--
Branko Vukelic

branko.vuke...@gmx.com

http://www.brankovukelic.com/
http://flickr.com/photos/foxbunny

[web2py] Re: it case you missed it...

2010-12-16 Thread mdipierro

GPL2 creates the loophole. The AGPL closes the loophole. The GPL3 was
supposed to incorporate language from AGPL and close the loophole but
did not. It is not clear to me whether GPL3 closes the loophole or
not. If it does not (like GPL2 does not).

I have no objection to move to GPL3.

Yet that does not help in clarifying the web2py license.

As a hypothetical question. Who here would oppose to moving to BSD or
MIT or other more permissive license?

Massimo

On Dec 16, 2:54 pm, Branko Vukelic branko.vuke...@gmx.com wrote:
  - Original Message -
  From: mdipierro
  Sent: 12/16/10 07:56 PM
  To: web2py-users
  Subject: [web2py] Re: it case you missed it...
  If we were to move from GPL2 to GPL3 people would not be allowed to
  modify web2py running on their servers without making available the
  source code of their changes. I do not see any reason for requiring
  this.

 What's AGPL for then? Wasn't _AGPL_ supposed to prevent that? Anyway, I think 
 GPLv3 makes i possible to use code licensed under licenses like MIT and BSD 
 in a GPLv3 project, which is otherwise a bit incompatible. Or did I miss 
 something?

 --
 Branko Vukelic

 branko.vuke...@gmx.com

 http://www.brankovukelic.com/http://flickr.com/photos/foxbunny

[web2py] Re: it case you missed it...

2010-12-16 Thread Michael McGinnis

No opposition here. Like others, I was originally confused whether
using the web2py framework would force my web app to be open source.
I would welcome a change in license.

On Dec 16, 4:33 pm, mdipierro mdipie...@cs.depaul.edu wrote:
 GPL2 creates the loophole. The AGPL closes the loophole. The GPL3 was
 supposed to incorporate language from AGPL and close the loophole but
 did not. It is not clear to me whether GPL3 closes the loophole or
 not. If it does not (like GPL2 does not).

 I have no objection to move to GPL3.

 Yet that does not help in clarifying the web2py license.

 As a hypothetical question. Who here would oppose to moving to BSD or
 MIT or other more permissive license?

 Massimo

 On Dec 16, 2:54 pm, Branko Vukelic branko.vuke...@gmx.com wrote:







   - Original Message -
   From: mdipierro
   Sent: 12/16/10 07:56 PM
   To: web2py-users
   Subject: [web2py] Re: it case you missed it...
   If we were to move from GPL2 to GPL3 people would not be allowed to
   modify web2py running on their servers without making available the
   source code of their changes. I do not see any reason for requiring
   this.

  What's AGPL for then? Wasn't _AGPL_ supposed to prevent that? Anyway, I 
  think GPLv3 makes i possible to use code licensed under licenses like MIT 
  and BSD in a GPLv3 project, which is otherwise a bit incompatible. Or did I 
  miss something?

  --
  Branko Vukelic

  branko.vuke...@gmx.com

 http://www.brankovukelic.com/http://flickr.com/photos/foxbunny

Re: [web2py] Re: it case you missed it...

Here's an excerpt from Apache License 2.0:

``Derivative Works shall mean any work, whether in Source or Object form, 
that is based on (or derived from) the Work and for which the editorial 
revisions, annotations, elaborations, or other modifications represent, as a 
whole, an original work of authorship. For the purposes of this License, 
Derivative Works shall not include works that remain separable from, or merely 
link (or bind by name) to the interfaces of, the Work and Derivative Works 
thereof.``

This sounds like a hint for the exception we needed (unless you are serious 
about moving to BSD or MIT). Full text can be found here:

http://www.apache.org/licenses/LICENSE-2.0

so you can see the context. Reading the full text of the Apache license, I 
think dual-licensing web2py under GPLv2 and Apache License 2.0 would solve all 
of the problems except 1: reuse of web2py components and libraries for building 
closed-source software. For me, personally, that would not be fair game. If you 
are taking apart web2py and building something useful, you should share.



 - Original Message -
 From: mdipierro
 Sent: 12/16/10 11:33 PM
 To: web2py-users
 Subject: [web2py] Re: it case you missed it...
 
 GPL2 creates the loophole. The AGPL closes the loophole. The GPL3 was
 supposed to incorporate language from AGPL and close the loophole but
 did not. It is not clear to me whether GPL3 closes the loophole or
 not. If it does not (like GPL2 does not).
 
 I have no objection to move to GPL3.
 
 Yet that does not help in clarifying the web2py license.
 
 As a hypothetical question. Who here would oppose to moving to BSD or
 MIT or other more permissive license?
 
 Massimo
 
 On Dec 16, 2:54 pm, Branko Vukelic branko.vuke...@gmx.com wrote:
   - Original Message -
   From: mdipierro
   Sent: 12/16/10 07:56 PM
   To: web2py-users
   Subject: [web2py] Re: it case you missed it...
   If we were to move from GPL2 to GPL3 people would not be allowed to
   modify web2py running on their servers without making available the
   source code of their changes. I do not see any reason for requiring
   this.
 
  What's AGPL for then? Wasn't _AGPL_ supposed to prevent that? Anyway, I 
  think GPLv3 makes i possible to use code licensed under licenses like MIT 
  and BSD in a GPLv3 project, which is otherwise a bit incompatible. Or did I 
  miss something?
 
  --
  Branko Vukelic
 
  branko.vuke...@gmx.com
 
  http://www.brankovukelic.com/http://flickr.com/photos/foxbunny


--
Branko Vukelic

branko.vuke...@gmx.com

http://www.brankovukelic.com/
http://flickr.com/photos/foxbunny

[web2py] Re: it case you missed it...

+1 for permissive.

Seems unlikely anyone would want to close up the source of a framework and 
even if it happened, it shouldn't affect the project. And who would want to 
use closed source framework?

But it should eliminate one of the adoption hurdles which is a good thing.

Don't you all want to work on something that gets big!!

Re: [web2py] Re: it case you missed it...

branko, I'm curious why permissive licensing is a problem for you. is it a 
philosophical thing? what's the downside? wouldn't it be cool if your code 
was widely used? cake, django  rails are permissively licensed (as are most 
frameworks) and it doesn't seem to be a problem. people still seem excited 
to develop for those platforms.

Re: [web2py] Re: it case you missed it...

 - Original Message -
 From: pbreit
 Sent: 12/17/10 12:52 AM
 To: web2py@googlegroups.com
 Subject: Re: [web2py] Re: it case you missed it...

 branko, I'm curious why permissive licensing is a problem for you. is it a 
 philosophical thing? what's the downside? wouldn't it be cool if your code 
 was widely used? cake, django  rails are permissively licensed (as are most 
 frameworks) and it doesn't seem to be a problem. people still seem excited 
 to develop for those platforms.

Yes, it's a philosophical thing. I have participated in open-source projects 
before, always feeling inferior for not being able to code like a pro (since 
I'm a designer). I still managed to find a way to contribute (editing Wikis, 
contributing artwork, etc). Then I started programming (Ruby and Python), and I 
came to learn how great it is for developers to be able to share code freely.

Even though FSF was established just a few years after I was born, I learned 
about the history of the movement that kicked it off, because I respected and 
loved the kind of spirit I was discovering. And I believe that if it weren't 
for FSF and their stubborn insistence on free software, there would be no 
open-source the kind we know today. Today, people are starting to take it all 
for granted and say shit like BSD is better than GPL, etc, and FSF hardliners 
scares them. Why? Just to win the popularity award? But think about it: if it 
weren't for those hardliners, BSD would be worth precisly bollocks, too.

The only point where I possibly differ from FSF is that there should be a 
difference between normal usage (usage as intended including 
sharing/distribution) and modification. Modification should result in new free 
software, distribution should result merely in notification that the base 
software is free software. Free software should never become closed, that's my 
bottom line.

That fact that a bunch of people like something says precisely fuckall. Just 
count how many people get off using Windows. Does that tell you something about 
how great Windows is? I hope not. That's hardly a valid point. 

On the frameworks side, look at Django. So many bug-fix releases lately. And 
their TRUNK used to be awesome. Now you can't even trust the releases. And it's 
growing fatter by day, and loose coupling song is starting to get a different 
tune. At one time I wrote permanent redirection middleware for both Django and 
web.py. What took me a day to write on web.py took me a week on Django, and it 
was never as simple as I liked it to be, the main reason being that it involved 
at least 3 core components and the (then) nasty polymorphism framework called 
content type or something like that. Soon it'll be too bloated to support its 
own weight, and people will start looking for lightweight frameworks like 
werkzeug and node.js. But that has nothing to do with BSD. It's the price of 
having too many hands involved in the process without an adequate system to 
ensure quality.

--
Branko Vukelic

branko.vuke...@gmx.com

http://www.brankovukelic.com/
http://flickr.com/photos/foxbunny

Re: [web2py] Re: it case you missed it...

Fair enough, I respect that. Massimo has done a wonderful job of adding 
really good features while keeping web2py lean. As it gets more popular is 
there a concern that more people will lean on Massimo to add bloat? That 
would definitely be unfortunate.

Re: [web2py] Re: it case you missed it...

 - Original Message -
 From: pbreit
 Sent: 12/17/10 01:40 AM
 To: web2py@googlegroups.com
 Subject: Re: [web2py] Re: it case you missed it...

 Fair enough, I respect that. Massimo has done a wonderful job of adding 
 really good features while keeping web2py lean. As it gets more popular is 
 there a concern that more people will lean on Massimo to add bloat? That 
 would definitely be unfortunate.

At that point, I'd just conclude it's become too popular for its own good. But 
I doubt Massimo would just add in any kind of crap that flies in.

--
Branko Vukelic

branko.vuke...@gmx.com

http://www.brankovukelic.com/
http://flickr.com/photos/foxbunny

[web2py] Re: it case you missed it...

On Dec 16, 6:14 pm, Branko Vukelic branko.vuke...@gmx.com wrote:
 Reading the full text of the Apache license, I think dual-licensing web2py 
 under GPLv2
 and Apache License 2.0 would solve all of the problems except 1: reuse of 
 web2py
 components and libraries for building closed-source software. For me, 
 personally, that
 would not be fair game. If you are taking apart web2py and building something 
 useful,
 you should share.

Now that there's a truly standalone DAL, what if someone wants to use
that in an application? What about some of the other contrib modules,
like markmin?

Re: [web2py] Re: it case you missed it...

 - Original Message -
 From: Anthony
 Sent: 12/17/10 02:30 AM
 To: web2py-users
 Subject: [web2py] Re: it case you missed it...

 On Dec 16, 6:14 pm, Branko Vukelic branko.vuke...@gmx.com wrote:
  Reading the full text of the Apache license, I think dual-licensing web2py 
  under GPLv2
  and Apache License 2.0 would solve all of the problems except 1: reuse of 
  web2py
  components and libraries for building closed-source software. For me, 
  personally, that
  would not be fair game. If you are taking apart web2py and building 
  something useful,
  you should share.

 Now that there's a truly standalone DAL, what if someone wants to use
 that in an application? What about some of the other contrib modules,
 like markmin?

This is a question only Massimo can give a qualified answer to. The following 
is merely my opinion:

Yes, they should share the code. They wouldn't be _required_ (if you ask me), 
but they should. If they modify it in any way, or source the code from it, they 
should share both DAL _and_ their app.

--
Branko Vukelic

branko.vuke...@gmx.com

http://www.brankovukelic.com/
http://flickr.com/photos/foxbunny

[web2py] Re: it case you missed it...

On Dec 16, 8:47 pm, Branko Vukelic branko.vuke...@gmx.com wrote:
  Now that there's a truly standalone DAL, what if someone wants to use
  that in an application? What about some of the other contrib modules,
  like markmin?

 This is a question only Massimo can give a qualified answer to. The following 
 is merely
 my opinion:

 Yes, they should share the code. They wouldn't be _required_ (if you ask me), 
 but they
 should. If they modify it in any way, or source the code from it, they should 
 share both
 DAL _and_ their app.

I guess it seems odd to say if you build an app using the entire
web2py framework, then you can close source your app, but if you build
your app using only part of the web2py framework, you must share your
app. For example, suppose someone plugs the DAL into Flask and builds
an app, should they be required to make the app itself (not the DAL
part of it) open source? Doesn't seem consistent with the logic of the
general exception for applications.

Re: [web2py] Re: it case you missed it...

2010-12-16 Thread Bruno Rocha

I made this example (for teaching)
https://bitbucket.org/rochacbruno/dal_on_flask/src

I've been pointed to include this line:

#  NOTE: web2py is licensed under GPL2 and Flask is licensed under
BSD#  So, any derivative using both ['Flask','DAL'] should be GPL (not
BSD)


*https://bitbucket.org/rochacbruno/dal_on_flask/src/3131e4d261ea/dalFlask.py*


2010/12/17 Anthony abasta...@gmail.com

 On Dec 16, 8:47 pm, Branko Vukelic branko.vuke...@gmx.com wrote:
   Now that there's a truly standalone DAL, what if someone wants to use
   that in an application? What about some of the other contrib modules,
   like markmin?
 
  This is a question only Massimo can give a qualified answer to. The
 following is merely
  my opinion:
 
  Yes, they should share the code. They wouldn't be _required_ (if you ask
 me), but they
  should. If they modify it in any way, or source the code from it, they
 should share both
  DAL _and_ their app.

 I guess it seems odd to say if you build an app using the entire
 web2py framework, then you can close source your app, but if you build
 your app using only part of the web2py framework, you must share your
 app. For example, suppose someone plugs the DAL into Flask and builds
 an app, should they be required to make the app itself (not the DAL
 part of it) open source? Doesn't seem consistent with the logic of the
 general exception for applications.




-- 

Bruno Rocha
http://about.me/rochacbruno/bio

Re: [web2py] Re: it case you missed it...

 - Original Message -
 From: Anthony
 Sent: 12/17/10 03:33 AM
 To: web2py-users
 Subject: [web2py] Re: it case you missed it...

 I guess it seems odd to say if you build an app using the entire
 web2py framework, then you can close source your app, but if you build

Entire _unmodified_ web2py framework. Also, it's not 'build', but 'distribute'. 
Big difference. If you are not sharing it with anyone, you can do whatever you 
want.

 your app using only part of the web2py framework, you must share your
 app. For example, suppose someone plugs the DAL into Flask and builds

Ideally yes. But there's one catch. The keyword is _distribute_ not _build_. I 
hope it clears things up a bit. Someone has also cleverly noted tha if you 
build your app for your client using whatever GPL tools you stumbled upon, you 
are only required to share the source code with the client because you're 
distributing it to your client only. You don't actually have to put it some 
place where everyone can see. That's allowed. So, it's not like you have to 
share it with the rest of the world.

In case of web2py as a whole, with GPLv2 + commercial exception, you don't even 
have to do that, unless you've modified web2py somehow, or used pieces of it in 
your application code (where 'pieces of it' excludes the welcome app).

--
Branko Vukelic

branko.vuke...@gmx.com

http://www.brankovukelic.com/
http://flickr.com/photos/foxbunny

[web2py] Re: it case you missed it...

On Dec 16, 9:45 pm, Branko Vukelic branko.vuke...@gmx.com wrote:
  I guess it seems odd to say if you build an app using the entire
  web2py framework, then you can close source your app, but if you build

 Entire _unmodified_ web2py framework.

Well, it's not clear that your app can be closed sourced only when
using the unmodified framework. The exception simply states, You can
distribute web2py app under any license you like as long they do not
contain web2py code. The problem is, web2py app is not well-
defined. I assume that even if you modify the framework, your app is
still a web2py app and therefore not subject to the license. Though
it may depend on the nature of the modification (e.g., tweaking the
web2py code vs. swapping out some components, such as the DAL vs.
using only some components, such as the DAL). I think this really
needs to be cleared up.

  your app using only part of the web2py framework, you must share your
  app. For example, suppose someone plugs the DAL into Flask and builds

 Ideally yes. But there's one catch. The keyword is _distribute_ not _build_. 
 I hope it
 clears things up a bit. Someone has also cleverly noted tha if you build your 
 app for
 your client using whatever GPL tools you stumbled upon, you are only required 
 to share
 the source code with the client because you're distributing it to your client 
 only. You
 don't actually have to put it some place where everyone can see. That's 
 allowed. So,
 it's not like you have to share it with the rest of the world.

So, at least one advantage of BSD is it doesn't require all this
clearing up. ;)

As evidenced by this discussion, even some long-time users and
contributors aren't quite sure exactly what the web2py license allows
(e.g., [1]). That's not a good sign.

[1] http://groups.google.com/group/web2py-developers/msg/3cbb6720dadadd83

Re: [web2py] Re: it case you missed it...

 - Original Message -
 From: Anthony
 Sent: 12/17/10 04:22 AM
 To: web2py-users
 Subject: [web2py] Re: it case you missed it...

 So, at least one advantage of BSD is it doesn't require all this
 clearing up. ;)

How nice...


--
Branko Vukelic

branko.vuke...@gmx.com

http://www.brankovukelic.com/
http://flickr.com/photos/foxbunny

Re: [web2py] Re: it case you missed it...

2010-12-15 Thread Wikus van de Merwe

Why GPL is discouraging users? Is it the case that Drupal, Wordpress
or Joomla have no users? They are all released on GPL terms. Moreover,
they consider themes and plugins to be derivative work and as such
they have to be released on GPL terms if distributed. Still, thousands
of plugins and themes have been made.

Pay close attention here, *if* distributed. In common web development
scenario where expected end product is the working web application
deployed on some server, the application code is not distributed but
simply used and doesn't have to be released on GPL terms. In those
rare cases where client specifically require the source code as she
wants to deploy the application on her own, you release the code on
GPL terms but to her only. She paid for it's creation anyway right?

And with web2py, thanks to exceptions, you don't even have to do that.
Application code is not considered to be a derivative work. But
changes to the framework and works build on top of it are (that is,
*if* distributed). So again, you can have your own specialised version
of web2py running on some servers, but you cannot make a proprietary
fork of web2py. And this will be allowed by non-copyleft licences such
as modified BSD licence or X11 licence.

Now, those who would benefit from a proprietary fork are not the
users. And in that sense, by not allowing the community fragmentation
around a number of different less or more commercial oriented forks
the GPL helps to create a good framework, as it keeps the community
together.

So as I just showed to you, GPL is a non-issue for the users and
protects the freedom of the framework much better than non-copyleft
licences would. Your only argument being the other Python frameworks
use non-copyleft licences is not convincing. Statistic != merit.

Re: [web2py] Re: it case you missed it...

Don't start this discussion again. :) It's already soft-of decided
that web2py will remain GPL.

On Wed, Dec 15, 2010 at 1:36 PM, Wikus van de Merwe
dupakrop...@googlemail.com wrote:
 Why GPL is discouraging users? Is it the case that Drupal, Wordpress
 or Joomla have no users? They are all released on GPL terms. Moreover,
 they consider themes and plugins to be derivative work and as such
 they have to be released on GPL terms if distributed. Still, thousands
 of plugins and themes have been made.

 Pay close attention here, *if* distributed. In common web development
 scenario where expected end product is the working web application
 deployed on some server, the application code is not distributed but
 simply used and doesn't have to be released on GPL terms. In those
 rare cases where client specifically require the source code as she
 wants to deploy the application on her own, you release the code on
 GPL terms but to her only. She paid for it's creation anyway right?

 And with web2py, thanks to exceptions, you don't even have to do that.
 Application code is not considered to be a derivative work. But
 changes to the framework and works build on top of it are (that is,
 *if* distributed). So again, you can have your own specialised version
 of web2py running on some servers, but you cannot make a proprietary
 fork of web2py. And this will be allowed by non-copyleft licences such
 as modified BSD licence or X11 licence.

 Now, those who would benefit from a proprietary fork are not the
 users. And in that sense, by not allowing the community fragmentation
 around a number of different less or more commercial oriented forks
 the GPL helps to create a good framework, as it keeps the community
 together.

 So as I just showed to you, GPL is a non-issue for the users and
 protects the freedom of the framework much better than non-copyleft
 licences would. Your only argument being the other Python frameworks
 use non-copyleft licences is not convincing. Statistic != merit.



-- 
Branko Vukelić

bg.bra...@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

Re: [web2py] Re: it case you missed it...

2010-12-15 Thread Wikus van de Merwe

The discussion was started by the advocates of non-copyleft licences. I'm 
perfectly fine with web2py on GPL terms (even without exceptions), besides 
maybe I would like to see it upgraded to GPLv3. However, it is too often we 
see the attempts to frame the GPL as deterrent scary licence that limits the 
project adoption and nobody takes a strong stance against such unfair 
claims. Then this false image of what GPL is and how it works is spread, 
because people are lazy and they will rather accept anonymous comment on the 
Internet as true rather than check the GPL faq or the licence itself. This 
is why I replied. Who knows, maybe sombody will learn from it something new.

Re: [web2py] Re: it case you missed it...

2010-12-15 Thread pbreit

Sorry but this requires a response.

Django and Rails (frameworks!!) are *far* better examples than the CMSs you 
point out.

BSD/MIT are definitionally better for users than GPL because they are more 
permissive. You'd have to prove some sort of unintended circumstance to 
dispute that for which there is no evidence.

Django and Rails have not suffered whatever Massimo is worried about. Quite 
the opposite, they have very large and active user bases.

Re: [web2py] Re: it case you missed it...

On Wed, Dec 15, 2010 at 7:25 PM, pbreit pbreitenb...@gmail.com wrote:
 Sorry but this requires a response.

I was kind of hoping it did not, but there you go...

 You'd have to prove some sort of unintended circumstance to

No! YOU would have to give us a CONCRETE case where GPL+exception
setup may prevent someone adopting and using web2py. Otherwise, this
discussions previous conclusion (and that's that GPLv2 or GPLv3 will
be used in conjunction with a clearer, more precise exception clause)
still stands, and you may contribute usefully by answering Massimo's
request:

If you guys can come up with a better way to phrase the [exception
clause], and there is consensus, I will probably adopt it. I think we
all agree with the intended intentions.If you guys can come up with a
better way to phrase the license, and there is consensus, I will
probably adopt it. I think we all agree with the intended intentions.

That's the new topic right now, and please do not try to divert it
back to what's been already discussed for probably too long.

-- 
Branko Vukelić

bg.bra...@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

[web2py] Re: it case you missed it...

2010-12-15 Thread VP

I do not think that GPL is the determining factor of why Django or
Rails are popular.

It is not clear that GPL scares off potential users.   I will go out
on the limp to say that most potential users of web2py will be in the
capacity of app developers, not framework developers. They might be
scared if they don't understand it as intended, which is why some said
it needs to be clarified.   Once the licensing is clear, they have
nothing to be scared about.

As for framework developers, sure GPL is not permissive for commercial
intentions.  So, if you want to branch of web2py, customizing the
framework, possibly improving it, and want to close source, then no
you can't do that with GPL.   But those cases are few, and arguably
not what most potential users care about.


On Dec 15, 1:07 pm, pbreit pbreitenb...@gmail.com wrote:
 It's not worthwhile fiddling around with the exception since the GPL stigma
 will remain.

 It's clear that GPL scares off potential users.

 I come from a background of relentlessly lowering barriers to adoption. I
 would very much like to see Web2py usage go way up.

Re: [web2py] Re: it case you missed it...

2010-12-15 Thread pbreit

It's not worthwhile fiddling around with the exception since the GPL stigma 
will remain.

It's clear that GPL scares off potential users.

I come from a background of relentlessly lowering barriers to adoption. I 
would very much like to see Web2py usage go way up.

Re: [web2py] Re: it case you missed it...

2010-12-15 Thread Thadeus Burgess

An excerpt: I think this sums it up.

---

GPL is a tool that uses copyright to enforce software freedom, but… in order
to be able to enforce that there must be a copyright holder that can take
action. The FSF is aware of this and is carefully requiring contributors and
their employers (!) to sign legal papers of copyright transfer:
http://www.fsf.org/licensing/licenses/why-assign.html

The problem is that most GPL projects can not afford to force potential
contributors to get their employers to sign legal papers as it will reduce
the number of contributions to 0 and therefore the copyright to their
projects is either dispersed among the different contributors or even worse,
is questionably held by a single person or entity (with emphasis on
questionably).

-


Thadeus




On Wed, Dec 15, 2010 at 1:21 PM, VP vtp2...@gmail.com wrote:

 I do not think that GPL is the determining factor of why Django or
 Rails are popular.

 It is not clear that GPL scares off potential users.   I will go out
 on the limp to say that most potential users of web2py will be in the
 capacity of app developers, not framework developers. They might be
 scared if they don't understand it as intended, which is why some said
 it needs to be clarified.   Once the licensing is clear, they have
 nothing to be scared about.

 As for framework developers, sure GPL is not permissive for commercial
 intentions.  So, if you want to branch of web2py, customizing the
 framework, possibly improving it, and want to close source, then no
 you can't do that with GPL.   But those cases are few, and arguably
 not what most potential users care about.


 On Dec 15, 1:07 pm, pbreit pbreitenb...@gmail.com wrote:
  It's not worthwhile fiddling around with the exception since the GPL
 stigma
  will remain.
 
  It's clear that GPL scares off potential users.
 
  I come from a background of relentlessly lowering barriers to adoption. I
  would very much like to see Web2py usage go way up.

Re: [web2py] Re: it case you missed it...

On Wed, Dec 15, 2010 at 8:07 PM, pbreit pbreitenb...@gmail.com wrote:
 It's clear that GPL scares off potential users.

That bug is already marked invalid. You'd have to give us a stack
trace if you want to reopen it, and preferably attach a working patch.
Please also note the version of web2py that you are using.


-- 
Branko Vukelić

bg.bra...@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

Re: [web2py] Re: it case you missed it...

2010-12-15 Thread Anthony

On Wednesday, December 15, 2010 3:11:27 PM UTC-5, Branko Vukelic wrote:

On Wed, Dec 15, 2010 at 8:07 PM, pbreit wrote:

It's clear that GPL scares off potential users.

That bug is already marked invalid. You'd have to give us a stack trace if
you want to reopen it, and preferably attach a working patch. Please also
note the version of web2py that you are using.

I like GPL plus a (clarified) exception, but I wouldn't exactly say pbreit's
concerns are invalid. There clearly is some history of confusion and concern
among web2py users/developers and their clients:

https://groups.google.com/group/web2py/msg/ba5277320933a72a
https://groups.google.com/group/web2py/msg/de8b75aa2efe2fa5
http://groups.google.com/group/django-users/msg/87b5cfc637c55433
http://www.reddit.com/r/Python/comments/ddg79/can_web2py_applications_be_provided_to_end_users
http://www.reddit.com/r/Python/comments/ej0p1/new_standalone_web2py_database_abstraction_layer/c18grty
http://jacobian.org/writing/gpl-questions/ (not web2py-specific)

And of course, there's no telling how many potential users saw GPL and
just moved on, without asking a question on the list, reddit, etc. Although
the precise empirical impact of the GPL on adoption has not been
established, nor has the real risk of a commercial fork (mitigation of which
appears to be a primary motivation for using GPL).

Another consideration is the ability to use individual components of web2py
within commercial apps. For example, the new standalone DAL is GPL'ed. If
someone uses the DAL in an application that does not otherwise use the rest
of the web2py framework, would they have to GPL the application (the current
web2py license exception doesn't appear to cover that case)?

Of course, once we go more permissive (e.g., LGPL, BSD, MIT), it will be
hard to go back, so we should be cautious with any change. Trying to improve
the clarity of the current exceptions and the way we communicate them (e.g.,
explicitly and prominently stating it is dual licensed) is probably a good
first step. Maybe that will be enough to resolve the concerns without
resorting to a more permissive license.

Anthony

Re: [web2py] Re: it case you missed it...

 - Original Message -
 From: Anthony
 Sent: 12/15/10 10:54 PM
 To: web2py@googlegroups.com
 Subject: Re: [web2py] Re: it case you missed it...

 I like GPL plus a (clarified) exception, but I wouldn't exactly say pbreit's 
 concerns are invalid. There clearly is some history of confusion and concern 
 among web2py users/developers and their clients:

Point is, it's been discussed over and over, and over, and over... in a more-or 
less the same manner, too. Just saying BSD! won't make it BSD. I think that's 
become clear. And it's become painfully obvious that we are all divided between 
GPL and anything-but-GPL, and we have come to the conclusion that it's 
Massimo's call. Massimo called GPL, because we have also clarified that there 
isn't a technical threat to the end users. TECHNICALLY speaking, nobody should 
really be concerned as long as they are aware of the exception and agree to it. 
So, repeating discussion, using Gplophobia or Gnuphobia as the pivot is not 
productive, and it would go on like this forever.

Branko

p.s. Yes I've finally fully switched to my GMX account. It's the same me. :)

[web2py] Re: it case you missed it...

2010-12-15 Thread Anthony

On Dec 15, 6:25 pm, Branko Vukelic branko.vuke...@gmx.com wrote:
  I like GPL plus a (clarified) exception, but I wouldn't exactly say pbreit's
  concerns are invalid. There clearly is some history of confusion and concern
  among web2py users/developers and their clients:

 Point is, it's been discussed over and over, and over, and over... in a 
 more-or less the same manner, too. Just saying BSD! won't make it BSD. I 
 think that's become clear. And it's become painfully obvious that we are all 
 divided between GPL and anything-but-GPL, and we have come to the conclusion 
 that it's Massimo's call. Massimo called GPL, because we have also clarified 
 that there isn't a technical threat to the end users. TECHNICALLY speaking, 
 nobody should really be concerned as long as they are aware of the exception 
 and agree to it. So, repeating discussion, using Gplophobia or Gnuphobia as 
 the pivot is not productive, and it would go on like this forever.

Yes, I agree, but all I said was that the concerns are not invalid (I
also pointed out an issue that has not thus far been addressed --
standalone DAL). I think we can decide to stick with GPL while still
recognizing it may present a barrier for some (possibly simply due to
confusion or risk aversion rather than a real legal threat). This
issue is both complex and important, so a long discussion should not
be surprising. I, for one, have learned a lot, and assuming we follow
through, I believe the result of this long thread will be an
improvement in the license and therefore the comfort of prospective
users. Those uninterested in the topic can easily ignore the thread.

Cheers,
Anthony

[web2py] Re: it case you missed it...

2010-12-15 Thread pbreit

Anthony, thanks for keeping your posts reasonable and considerate.

[web2py] Re: it case you missed it...

2010-12-15 Thread Anthony

:)

On Dec 15, 10:11 pm, pbreit pbreitenb...@gmail.com wrote:
 Anthony, thanks for keeping your posts reasonable and considerate.

Re: [web2py] Re: it case you missed it...

 - Original Message -
 From: Anthony
 Sent: 12/16/10 03:01 AM
 To: web2py-users
 Subject: [web2py] Re: it case you missed it...
 Yes, I agree, but all I said was that the concerns are not invalid (I
 also pointed out an issue that has not thus far been addressed --
 standalone DAL). I think we can decide to stick with GPL while still
 recognizing it may present a barrier for some (possibly simply due to
 confusion or risk aversion rather than a real legal threat). This
 issue is both complex and important, so a long discussion should not
 be surprising. I, for one, have learned a lot, and assuming we follow
 through, I believe the result of this long thread will be an
 improvement in the license and therefore the comfort of prospective
 users. Those uninterested in the topic can easily ignore the thread.

You are missing the main point here, and that's software freedom and two 
incompatible views regarding that. It's not by conincidence that there is a 
commercial EXCEPTION to GPL in web2py. The reason it's called an exception is 
that it is incompatible with the intent of GPL. Now consider that Massimo has 
_chosen_ GPL with an intent, and that GPL aligns with that intent. Do I need to 
go on?


--
Branko Vukelic

branko.vuke...@gmx.com

http://www.brankovukelic.com/
http://flickr.com/photos/foxbunny

[web2py] Re: it case you missed it...

2010-12-14 Thread VP

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.

Maybe, it doesn't need to be rewritten (much), but needs an FAQ
attached to it.

Re: [web2py] Re: it case you missed it...

2010-12-14 Thread Branko Vukelic

On Tue, Dec 14, 2010 at 5:06 PM, VP vtp2...@gmail.com wrote:
 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.



-- 
Branko Vukelić

bg.bra...@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

[web2py] Re: it case you missed it...

2010-12-14 Thread mdipierro

I agree that we may need clarification because it does not state that
the scaffolding app is public domain (it now says it in trunk), and
it does not say that importing web2py modules from an app should not
be considered linking and therefore it does not violate the GPL.

If you guys can come up with a better way to phrase the license, and
there is consensus, I will probably adopt it. I think we all agree
with the intended intentions.

Massimo

On Dec 14, 11:10 am, Branko Vukelic bg.bra...@gmail.com wrote:
 On Tue, Dec 14, 2010 at 5:06 PM, VP vtp2...@gmail.com wrote:
  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.

 --
 Branko Vukelić

 bg.bra...@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 Guildhttp://bit.ly/gbg-group

[web2py] Re: it case you missed it...

On Monday, December 13, 2010 2:00:08 AM UTC-5, mdipierro wrote:  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.


Maybe I'm misunderstanding something. Earlier you said importing
modules in an interpreted language (like Python):

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.

Above, you mentioned distributing your app with web2py source, which
would appear to make the importing equivalent to linking, thereby
necessitating the exception to GPL. The exception is unnecessary only
if you distribute your app without including web2py at all (presumably
the user receiving the app woud have to obtain their own copy of web2py
in that case). Or am I missing something?

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?

At first glance this sounds pretty good, though we should probably
investigate the LGPL more to make sure it really does what we want.
Also, do we need a separate (possibly existing standard) freeware
license for the binaries? For that matter, what is the purpose of the
freeware exception for the binaries? I assume it's so applications can
be distributed along with the binaries for convenience. But I think the
GPL (and LGPL) already allow distributions of binaries (i.e.,
non-source code) as long as the source code is also made available
(even a written offer to provide it upon request satisfies the
license). So, if a developer wants to distribute the binaries, couldn't
they easily satisfy the license by also including the source in a zip
file along with the distribution (the end user doesn't ever have to
install or look at the source, but this would satisfy the license). If
that would be satisfactory for developers, then maybe all we really
need is the LGPL, with no exceptions, which would really make things
simple and clear.

Anyway, if we feel it is still helpful to have the freeware
alternative, maybe it would be more clear to describe it as a dual
license (LGPL for source and freeware for binaries) rather than LGPL
with a commercial exception (which could lead to confusion and
concern).

Anthony

Re: [web2py] Re: it case you missed it...

On Mon, Dec 13, 2010 at 8:00 AM, mdipierro mdipie...@cs.depaul.edu wrote:
 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 Vukelić

bg.bra...@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

Re: [web2py] Re: it case you missed it...

On Mon, Dec 13, 2010 at 9:11 AM, Anthony abasta...@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 Vukelić

bg.bra...@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

Re: [web2py] Re: it case you missed it...

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:

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.

On Mon, Dec 13, 2010 at 11:12 AM, Branko Vukelic bg.bra...@gmail.com wrote:
 On Mon, Dec 13, 2010 at 9:11 AM, Anthony abasta...@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 Vukelić

 bg.bra...@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




-- 
Branko Vukelić

bg.bra...@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

Re: [web2py] Re: it case you missed it...

On Monday, December 13, 2010 5:12:51 AM UTC-5, Branko Vukelic wrote: 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. :)


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 describe the license as GPL with a commercial
exception (the exception referring to the binary distribution
option), but it may be more clear to refer to it as a dual license
instead (above, I wrote LGPL with a commercial exception because I
was assuming Massimo's new proposal, which switches to LGPL but still
includes the freeware exception).

Re: [web2py] Re: it case you missed it...

On Mon, Dec 13, 2010 at 2:43 PM, Anthony abasta...@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, 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.


-- 
Branko Vukelić

bg.bra...@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

Re: [web2py] Re: it case you missed it...

On Monday, December 13, 2010 5:07:52 AM UTC-5, Branko Vukelic wrote: 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.


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

If this isn't the case, then web2py would already be in violation of
various contrib licenses, no?

 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.

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

 Is this more or less confusing?
Yes. It's the nature of the beast. :)

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

Anthony

Re: [web2py] Re: it case you missed it...

On Mon, Dec 13, 2010 at 4:13 PM, Anthony abasta...@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.

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

bg.bra...@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

Re: [web2py] Re: it case you missed it...

On Mon, Dec 13, 2010 at 4:29 PM, Branko Vukelic bg.bra...@gmail.com wrote:
Your app is GPL-free anyway

Because of the exception, to be precise, not according to GPL.


-- 
Branko Vukelić

bg.bra...@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

Re: [web2py] Re: it case you missed it...

On Monday, December 13, 2010 10:29:00 AM UTC-5, Branko Vukelic wrote:
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.

I'm not sure you can release a modified MIT program as GPL or closed
source, but I believe you can include it in a GPL or closed source
program -- this is according to the Wikipedia entry
(http://en.wikipedia.org/wiki/MIT_License). In any case, this wouldn't
apply to BSD, as BSD only requires inclusion of the copyright notice
(not the permission notice).

Closed-source means restriction, and so does GPL. So MIT is not
compatible. Afaik, GPL doesn't consider BSD as GPL-compatible, either.

The GNU website disagrees with you -- it lists both the modified BSD
and the MIT (Expat) license as GPL-compatible
(http://www.gnu.org/licenses/license-list.html). So do the Wikipedia
entries for BSD and MIT.
 If this isn't the case, then web2py would already be in violation of
various
 contrib licenses, no?
Yes.

Based on the above, it would appear not -- MIT/BSD programs can even be
included in closed source/proprietary software.
 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.

According to GPL, the Corresponding Source may be on a different
server (operated by you or a third party). You are obligated to make
sure it remains available, so relying on a third party may be risky,
but it appears to be allowed.

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.

I don't believe I have insisted nor even suggested that closed-source
web2py should be allowed. Massimo already allows it -- that's the
commercial exception. It says you can distribute the binary without the
source. I don't believe we should allow anyone to modify the web2py
framework itself and then make that closed source -- that's an entirely
different issue, and I'm not talking about that.

Anthony

Re: [web2py] Re: it case you missed it...

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

I'm not sure what you're asking about here. Thus far there has been
absolutely no mention of requiring payment for binary-only. Currently
the binary-only is free, and Massimo's suggested change keeps it free.
My comments merely assume the status quo (i.e., free binary). My point
was simply that if we want to offer the binaries as freeware, we should
probably describe that as a dual license rather than as a exception to
the GPL/LGPL license (simply for clarity).

Anthony


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

Re: [web2py] Re: it case you missed it...

On Monday, December 13, 2010 8:38:12 AM UTC-5, Branko Vukelic wrote:
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:

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:

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

Re: [web2py] Re: it case you missed it...

2010-12-13 Thread LightDot

To summarize:
- 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

[web2py] Re: it case you missed it...

2010-12-13 Thread Wikus van de Merwe

Before I dive into analysing the proposed licence changes in detail,
let me remind you one important thing: we are talking here about web
applications. Most of the time these applications are not distributed
as installable software but are deployed on servers. That is, the
distribution does not take place at all, the software is just use on
the server. So let's make this distinction very, very clear here. There
are two scenarios:
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

OK, now, how does the LGPL differs from the GPL? It allows a library to
be linked to proprietary applications. It lessens the GPL's
requirement of the derivative work to be distributed on GPL compatible
terms. It only requires distribution of the library source code and
permission to link new/modified versions of the library (including
allowance of reverse engineering to debug this) [8]. In essence it
works very similar to current GPL with exceptions.

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.

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

Re: [web2py] Re: it case you missed it...

On Mon, Dec 13, 2010 at 5:50 PM, Anthony abasta...@gmail.com wrote:
 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, --- licens...@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 Vukelić

bg.bra...@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

Re: [web2py] Re: it case you missed it...

On Mon, Dec 13, 2010 at 9:35 PM, Wikus van de Merwe
dupakrop...@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.

-- 
Branko Vukelić

bg.bra...@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

Re: [web2py] Re: it case you missed it...

2010-12-13 Thread pbreit

Unless there is a move away from GPL, I don't think it's worthwhile to
split hairs on all these intricacies. What is discouraging users
is GPL and I don't think adding more exceptions will avoid the
negative perception. If Massimo is married to GPL then there's probably
not much to discuss.


I don't buy that Massimo doesn't care about the number of users. He
promotes the heck out of Web2py. And frameworks benefit greatly from
usage. I also don't understand how GPL helps to create a good
framework. Does BSD/MIT somehow prevent that?

Re: [web2py] Re: it case you missed it...

On Monday, December 13, 2010 3:30:17 PM UTC-5, Branko Vukelic wrote:
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.

Thanks for investigating that. Reading their FAQ, it seems that GNU
doesn't generally want anyone to use LGPL at all, purely based on
principle. So their response may be more of a preference than a legal
opinion (i.e., even if we could use LGPL, they would prefer we don't).
If a web2py application doesn't count as an Application or Combined
Work under LGPL, then I don't know what does. In any case, this
discussion has convinced me that if we really want to get this right,
we would probably have to consult an intellectual property attorney
with open source experience. Maybe it's not worth the bother/cost right
now, though.

Anthony

Re: [web2py] Re: it case you missed it...

On Monday, December 13, 2010 3:58:09 PM UTC-5, Branko Vukelic wrote: 

  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.

 These are good points. It appears that the LGPL would probably be somewhat 
more liberal than the current GPL plus exceptions. The downside is that we 
might not want to allow that extra freedom. The upside is that it might be 
more clear and be perceived as less risky to some, which could promote 
greater usage of the framework. Certainly we don't want to promote more 
usage at all cost, but we don't want to impose unnecessary barriers to 
adoption either. Although the LGPL might allow someone to use all or part of 
web2py within a proprietary system, I don't think it would allow a 
commercial enterprise to modify web2py itself and then release the modified 
framework as a proprietary competitor to web2py, which I think is the 
scenario Massimo really wants to guard against. Ultimately, of course, it is 
up to Massimo to decide how he wants to trade off these various concerns. I 
for one am perfectly happy with the current license, but I'm open to change 
if it would be better for the framework and community as a whole (including 
those not yet part of the community).
 
Anthony

Re: [web2py] Re: it case you missed it...

On Mon, Dec 13, 2010 at 11:46 PM, Anthony abasta...@gmail.com wrote:
 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 Vukelić

bg.bra...@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

Re: [web2py] Re: it case you missed it...

On Mon, Dec 13, 2010 at 11:33 PM, pbreit pbreitenb...@gmail.com wrote:
 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.


-- 
Branko Vukelić

bg.bra...@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

Re: [web2py] Re: it case you missed it...

2010-12-13 Thread 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 -

On Mon, Dec 13, 2010 at 1:09 PM, --- lic...@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]http://www.gnu.org/licenses/why-not-lgpl.html%5D).

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.

Thanks for investigating that. Reading their FAQ, it seems that GNU doesn't
generally want anyone to use LGPL at all, purely based on principle. So
their response may be more of a preference than a legal opinion (i.e., even
if we could use LGPL, they would prefer we don't). If a web2py application
doesn't count as an Application or Combined Work under LGPL, then I
don't know what does. In any case, this discussion has convinced me that if
we really want to get this right, we would probably have to consult an
intellectual property attorney with open source experience. Maybe it's not
worth the bother/cost right now, though.

The manner in which the LGPL works when applied to a library actually
depends to a degree on more than just the function APIs the library may
expose.

Take C++ for example. You might think that the LGPL on a reusable class
library would be fine, but technically this may not be the case. The problem
with C++ is template classes. For these the code implementation is
effectively in the header files which get included into your application
code when compiled and the expansion of those templates against types within
your application ends up as part of your application binary, as opposed to
it being a part of the library. Thus technically the template code may be
construed as ending up as part of your application.

As such, the library API in C++ may not draw a distinct enough line whereby
that library could then be replaced with a distinct implementation of that
library and provide the same functionality without reliance on any of the
prior LGPL code. This being because the LGPL code is a part of your program
binary still.

Even with the C programming language you might have issues if you were using
preprocessor macros to do a poor mans version of C++ template.

So, it can depend not only on the specific language being used, but how that
language is used and how the language is implemented.

The LGPL and how it applies therefore isn't always clear cut and that is
possibly part of why they have a preference for it not being used.

This is why you always need to have lawyers who have some understanding of
how programming systems are implemented, or have had sufficient expert
advice on it, to make judgements and advise you. It is dangerous to simply
assume that something sounds okay.

Graham

Re: [web2py] Re: it case you missed it...

On Monday, December 13, 2010 6:18:24 PM UTC-5, Branko Vukelic wrote: 

 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. 

Agreed.
 

 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 FSF has a different agenda from people who want to distribute their 
web2py applications closed source. GPL plus exceptions certainly works, but 
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.

 The only thing that needs to change is to make the exceptions more
 prominent (FTR, I haven't seen them before this discussion started.)

I would say we might also want to work on the wording. For example, the 
exception for web2py applications simply says:
 
You can distribute web2py app under any license you like as long they do 
not contain web2py code.
 
First, let's fix the grammar and say web2py applications. Then, how do we 
define web2py application, and exactly what does it mean to contain 
web2py code? What if you import Auth or Mail? How are plugins treated? 
plugin_wiki? wizard code? A lawyer evaluating this one line exception might 
justifiably be concerned about exactly what it permits and prohibits. 
(There's some more explanation on the Download page in the License section, 
but it's not clear whether that is a legally binding part of the license, or 
just commentary on the license.)
 

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

Well, this is an empirical question. Intuition may not be a good guide to 
the answer.
 
Anthony

Re: [web2py] Re: it case you missed it...

On Tue, Dec 14, 2010 at 2:15 AM, Graham Dumpleton
graham.dumple...@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.


-- 
Branko Vukelić

bg.bra...@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

Re: [web2py] Re: it case you missed it...

2010-12-13 Thread Graham Dumpleton

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.

Another good example of why lawyers are a good idea. We all often go based 
on possibly out of date recollections. :-)

Graham

On Tuesday, December 14, 2010 2:03:59 PM UTC+11, Branko Vukelic wrote:

 On Tue, Dec 14, 2010 at 2:15 AM, Graham Dumpleton
 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.


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

Re: [web2py] Re: it case you missed it...

On Tue, Dec 14, 2010 at 4:14 AM, Graham Dumpleton
graham.dumple...@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 Vukelić

bg.bra...@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

Re: [web2py] Re: it case you missed it...

On Tue, Dec 14, 2010 at 3:43 AM, Anthony abasta...@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, 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

Re: [web2py] Re: it case you missed it...

On Monday, December 13, 2010 10:52:20 PM UTC-5, Branko Vukelic wrote: 

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

Yes, we're agreed on how we would like the _framework_ to be licensed -- GPL 
is great for that. The issue is how best to make it clear (both legally and 
in terms of marketing) that web2py _applications_ can be released under any 
license (including closed source). I think Massimo and most others are 
comfortable allowing developers to do what they want with their own 
applications. Empirically, I don't think we have a handle on the extent to 
which the current license might be a hindrance, or whether any reasonable 
alternative (LGPL?) would actually help.

 Rather than just switching licenses, why don't we just help Massimo
 clarify what he wanted to convey?

Sounds good. Though ideally we would get some expert advice at some point.
 
Anthony

Re: [web2py] Re: it case you missed it...

On Monday, December 13, 2010 10:17:39 PM UTC-5, Branko Vukelic wrote: 

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

Or the community could pitch in. :)

Re: [web2py] Re: it case you missed it...

On Tue, Dec 14, 2010 at 6:55 AM, Anthony abasta...@gmail.com wrote:
 Sounds good. Though ideally we would get some expert advice at some point.

Agreed.

-- 
Branko Vukelić

bg.bra...@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

Re: [web2py] Re: it case you missed it...

 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?


 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.

Re: [web2py] Re: it case you missed it...

2010-12-12 Thread LightDot

I was a bit at odds when I saw a framework with a GPL v2 license that
claims that the developed code doesn't need to be GPL v2 compatible.

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.

Re: [web2py] Re: it case you missed it...

On Sun, Dec 12, 2010 at 9:51 AM, pbreit pbreitenb...@gmail.com wrote:
 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 Vukelić

bg.bra...@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

Re: [web2py] Re: it case you missed it...

On Sun, Dec 12, 2010 at 11:09 AM, LightDot light...@gmail.com wrote:
 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 Vukelić

bg.bra...@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

Re: [web2py] Re: it case you missed it...

On Sun, Dec 12, 2010 at 2:03 PM, Branko Vukelic bg.bra...@gmail.com wrote:
 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?


-- 
Branko Vukelić

bg.bra...@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

Re: [web2py] Re: it case you missed it...

2010-12-12 Thread 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.

Agreed. I think the reason so many sites end up using the web2py
favicon is because they don't even think about changing or removing the
default. I think the most sensible default is probably simply no
favicon at all (the browser already has its own default).

Anthony

Re: [web2py] Re: it case you missed it...

2010-12-12 Thread Michele Comitini

Please keep GPL on the framework, web2py is not backed by a single
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 abasta...@gmail.com:

 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.


 Agreed. I think the reason so many sites end up using the web2py favicon is
 because they don't even think about changing or removing the default. I
 think the most sensible default is probably simply no favicon at all (the
 browser already has its own default).

 Anthony

Re: [web2py] Re: it case you missed it...

2010-12-12 Thread LightDot

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.

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


On Sunday, December 12, 2010 2:03:32 PM UTC+1, Branko Vukelic wrote:
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.
It's a no brainer. The license covers the platform, not the code

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

Re: [web2py] Re: it case you missed it...

The disadvantages of GPL are somewhat clear.


Are there any advantages of GPL (with respect to frameworks)?

Re: [web2py] Re: it case you missed it...

On Sun, Dec 12, 2010 at 5:08 PM, pbreit pbreitenb...@gmail.com wrote:
 Are there any advantages of GPL (with respect to frameworks)?

It depends.

-- 
Branko Vukelić

bg.bra...@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

[web2py] Re: it case you missed it...

2010-12-12 Thread mdipierro

It prevents a group of individuals or a company to make a better
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

On Dec 12, 10:08 am, pbreit pbreitenb...@gmail.com wrote:
 The disadvantages of GPL are somewhat clear.

 Are there any advantages of GPL (with respect to frameworks)?

[web2py] Re: it case you missed it...

I'm not sure you can make that generalization with frameworks. The
solid, widely used ones are all BSD/MIT (Rails, Django, Cake,
CodeIgniter, Pylons, Turbogears, Symfony, etc.).


But as you say, BSD/MIT are better for users.

[web2py] Re: it case you missed it...

2010-12-12 Thread mdipierro

I disagree. In the case of web2py it makes no difference to users
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


On Dec 12, 11:39 am, pbreit pbreitenb...@gmail.com wrote:
 I'm not sure you can make that generalization with frameworks. The
 solid, widely used ones are all BSD/MIT (Rails, Django, Cake,
 CodeIgniter, Pylons, Turbogears, Symfony, etc.).

 But as you say, BSD/MIT are better for users.

Re: [web2py] Re: it case you missed it...

On Sun, Dec 12, 2010 at 6:39 PM, pbreit pbreitenb...@gmail.com wrote:
 But as you say, BSD/MIT are better for users.

He didn't say that.


-- 
Branko Vukelić

bg.bra...@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

[web2py] Re: it case you missed it...

The evidence is overwhelmingly in the other direction both in terms of
what users want and what other frameworks offer. I don't think that's
disputable.

[web2py] Re: it case you missed it...

2010-12-12 Thread mdipierro

I think we should close this discussion. It is not going anywhere.
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




On Dec 12, 11:59 am, pbreit pbreitenb...@gmail.com wrote:
 The evidence is overwhelmingly in the other direction both in terms of
 what users want and what other frameworks offer. I don't think that's
 disputable.

Re: [web2py] Re: it case you missed it...

On Sun, Dec 12, 2010 at 7:21 PM, mdipierro mdipie...@cs.depaul.edu wrote:
 I think we should close this discussion. It is not going anywhere.
 The license of web2py is not up for discussion.

+1


-- 
Branko Vukelić

bg.bra...@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

[web2py] Re: it case you missed it...