2010/10/28 Marcos Elgueta Soulat <m.a.elguetasou...@gmail.com> > On 28 October 2010 07:00, <pythonocc-users-requ...@gna.org> wrote: > > Send Pythonocc-users mailing list submissions to > > pythonocc-users@gna.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://mail.gna.org/listinfo/pythonocc-users > > or, via email, send a message with subject or body 'help' to > > pythonocc-users-requ...@gna.org > > > > You can reach the person managing the list at > > pythonocc-users-ow...@gna.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Pythonocc-users digest..." > > > > > > Today's Topics: > > > > 1. Re: Discussion about moving from GPL to, LGPL (Oliver Borm) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Wed, 27 Oct 2010 13:59:10 +0200 > > From: Oliver Borm <oli.b...@web.de> > > Subject: Re: [Pythonocc-users] Discussion about moving from GPL to, > > LGPL > > To: pythonocc-users@gna.org > > Message-ID: <4cc8140e.6030...@web.de> > > Content-Type: text/plain; charset=UTF-8 > > > > >From my point of view, I don't think that you will more contributions, > > if you are moving to the LGPL. > > > > You'll get maybe more users, but then they are allowed to use pythonOCC > > in their proprietary projects. This means, then there is no reason for > > them, to publish their source codes and make some contributions. Maybe a > > dual-licensing, like Qt, would be an option in order to satisfy the > > needs for commercial companies. > > > > So in essence, you should just stay with the GPL. I'm fine with it. > > > > > > > I'm agree with Oliver Borm, but it is not an easy issue to resolve, > I've been thinking about since developers announced the possibility of > change. > > I see advantages and disadvantages to both licenses, but I would like > to know the following: > > What is the advantage of the change for developers and contributors to > this list of e-mails? > > > Best regards! > > Marcos Elgueta S. > > > Hi Marcos,
I agree with most of the arguments from Oliver. The Qt example is good, but there is also another interesting example : PyQt, from Riverbank computing (a python binding to Qt). PyQt is distributed under a dual license GPL/commercial and Riverbank do not want to release the software under the LGPL license so that it can be included into proprietary software. As a consequence, a new project is recently born, named pyside ( http://www.pyside.org) to develop a python wrapper to Qt under the LGPL license. The set of features is exactly the same, and the work is going on quickly. No doubt that Riverbank Computing will soon have to revise its strategy/business model in a midterm. Both these examples lead me to the following conclusions: - dual license is suitable for "big" projects : the cost of a LGPL fork is much higher than the commercial license price (Qt, CGAL etc.). So developers pay the license ; - on the opposite, dual license is not suitable for "smaller" projects with less resources : the cost of a LGPL fork is lower than the license price (PyQt/pyside). I mean, developing a python wrapper to a C++ library is not that difficult. And what a loss of energy to redevelop something that is already available! So, in my opinion, a dual licensing policy (GPL/commercial) for pythonOCC would not be a good choice : selling commercial licenses has a cost, the fork risk is high. As Nikki Spahiev wrote, this can lead developers to prototype their software with pythonOCC and then use the C++ OpenCascade library (which is LGPL like and can be included into proprietary software). That's why we recently discussed, with Jelle, the opportunity to move to the LGPL. We could additionally provide consulting services for developers with specific needs. I mean, it would be an acceptable compromise for everybody (developers of the library/contributors/users). So here are my answers to Marcos (advantages to move from GPL to LGPL): 1. Main advantage for pythonOCC users : they are not required to redistribute their source code under the terms of the GPL. I mean, moving to LGPL could overcome the issue related to the 'viral' aspect of GPL. I especially think about big projects relying on many open source libraries. An additional dependency to a GPL library can lead to a be a big problem if the GPL is not compliant with other licenses (Jelle talked about FreeCad, but we could also think about Salomé). At last, LGPLed libraries can be included into proprietary programs (note that if you modify the library source code, your modifications have to be released under the LGPL). 2. Advantage for contributors : the question. There are, according to me, two different cases that can occur with a GPL project: 2.1 Additional code is contributed under the GPL. As a consequence, the whole library is still under the GPL. If ever the project wants to move to LGPL (see point 1.), then *all* the developers must agree or some contributed code be has to be removed from the project ; 2.2 Code is contributed under a more permissive license (MIT for instance) that makes it compliant with the GPL license. The project is then under a mixed GPL/MIT license. Another possibility is to receive contributions with a signed contributor agreement. These are both license policies used by companies distributing their software under a dual license. Bad news for the contributor : the project leader makes money with your contribution by selling commercial licenses (enabling the use of the library in closed source programs). At some point, it's not really a fair deal. As a conclusion, the move from GPL to LGPL is a major advantage for users, and does not really change anything for members of the project or contributors. Licensing issues are a nightmare! Regards, Thomas
_______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
