Sorry Russ, I did not say nor implied that any of the points above were distinctive or unique. I just tried to clarify some issues raised by other users here.
I was careful to only make comparison that were favorable to Django (the admin for example). I realize I am a guest here. I do not think that web2py is fully PEP8 compliant and probably Django does a better job at that. About the license. We do not annotate GPL we just clarify that the license does not apply to applications that require web2py but only to products that contain web2py source. Very much like FreeBSD is BSD even if compiled with GCC which is GPL. If you bundle your app with web2py you just have to state which files belong to your app and which ones are web2py files. I did not mean say that the web2py license (GPL) is more permissive than Django's license (BSD). I meant to say that not enforcing any license on applications is more permissive then BSD. For example, web2py users can release their apps under any license they like and only need to say "requires web2py" while if they were to be bound by the BSD they would have to include the BSD copyright notice, the disclaimer, and comply with BSD advertisement requirements (even if the app itself may not be BSD). Notice I am not making any statement about Django here. These legal issue are beyond me. web2py would not have existed without Django so thank you all. Massimo On Feb 19, 2:41 am, Russell Keith-Magee <[email protected]> wrote: > On Fri, Feb 19, 2010 at 1:37 PM, mdipierro <[email protected]> > wrote: > > I apologize for intruding and try not to be partisan. I will not list > > pros and cons since this is not the place for me to do so. > > I would just like to make clarifications about things being said: > > And I would like to clarify some of your clarifications: > > > 2) In web2py we try to follow PEP8. PEP8 says about Constants > > So does Django. I'm not sure why you present this as a point of > difference -- PEP8 compliance is a documented part of our > contributions procedure [1]. > > [1]http://docs.djangoproject.com/en/dev/internals/contributing/#coding-s... > > I'm sure you will be able to point at places where we slip in this > particular claim. However, I would also point out that PEP 8 starts > with the admonition that "A foolish consistency is the hobgoblin of > little minds", and directs attention to PEP20 - specifically, the > directive that "Readability counts". > > > 3) web2py license is GPL but because web2py is not imported by apps, > > instead it executes apps, we made is very clear in the license that we > > make no claim or restriction on the license of the apps. Apps need > > web2py to run but you can distribute them under any license you like > > including closed source bundled with the official web2py binary. This > > is more permissive than BSD. Almost all the example of apps are > > released under BSD. The code itself is GPL to prevent developers from > > creating a closed source derivative instead of supporting the main > > branch (something that BSD would instead permit). > > Regarding licensing: I have no desire to get into a "whose license is > better" flamewar. You writes the code, you picks the license. > > That said: IANAL, but I would humbly suggest that the licensing > situation isn't anywhere near as simple as you think it is -- > especially if you're "modifying" the GPL with explanatory statements. > You may claim that your annotated GPL is "more permissive" than the > BSD. I wish you all the luck in the world convincing the lawyers of a > VC company of your claim when they come to do due diligence on the IP > of the closed source product you have just developed. > > Even if I am, in fact, completely wrong on this last point, the > *perception* that I *might* be right is an important consideration, > especially when dealing with corporate clients. > > And while your concern for the sanctity of the Django codebase is most > welcome, I would also humbly suggest that the risks presented by a > commercial fork are *much* lower that you think they are. The value of > Django isn't just the source code - it's in a recognizable trademark > (and everything that trademark stands for), the reputation of the core > team in maintaining the project, and in the community surrounding the > project. In fact, Django has already survived a commercial forking > attempt, and that attempt failed spectacularly -- both because they > weren't able to offer any of the benefits of the existing Django > community, and because they made a pigs ear in their use of trademarks > (for which they were soundly slapped). > > Yours, > Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
