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 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. [1] http://www.gnu.org/licenses/gpl-faq.html#UnreleasedMods [2] http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem [3] http://www.gnu.org/licenses/gpl-faq.html#OOPLang [4] http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins [5] http://www.web2py.com/AlterEgo/default/show/47 [6] http://web2py.com/book/default/chapter/01#License [7] http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF [8] http://www.gnu.org/licenses/lgpl-java.html [9] http://www.gnu.org/licenses/why-not-lgpl.html [10] http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem [11] http://creativecommons.org/about/cc0
