Sort out license issues

[GoogleCodeExporter]

Not sure why I thought the BSD was fine. At least license each individual 
component under the appropriate license.

Original issue reported on code.google.com by baoille...@gmail.com on 8 Oct 2010 at 4:02

[GoogleCodeExporter]

I think at least obabel.py and its backends should be GPL, due to OpenBabel's 
GPL (any other license is violating it).

Original comment by ssorga...@gmail.com on 23 May 2011 at 6:05

[GoogleCodeExporter]

The main problem here is that I cannot find a reference that states this must 
be so.

...specifically that a Python script that imports a Python library that links 
to a GPLed C++ library is also required to be GPL even if distributed 
separately to the GPLed components.

Original comment by baoille...@gmail.com on 23 May 2011 at 6:28

[GoogleCodeExporter]

Something similar has been asked before by some people 
(http://stackoverflow.com/questions/999468/question-on-importing-a-gpled-python-
library-in-commercial-code)

As I understand it, the openbabel module and the OpenBabel bindings for all 
languages are GPL because they are directly derived from OpenBabel C++ 
libraries, which are GPL. Then, pybel, jybel and ironable rely unconditionally 
on their respective OpenBabel bindings, so they should be GPL'd as well. 

But then, cinfony as a whole, as it only optionally depends on 
pybel/ironable/jybel, is not affected by OpenBabel's license.

But maybe it would be easier just to ask the OpenBabel guys if they consider 
pybel et al. a derived work of Openbabel, and license it consequently.

Original comment by ssorga...@gmail.com on 23 May 2011 at 7:27

[GoogleCodeExporter]

The latter may in fact not be so easy: ask all OB developers... you'd have to 
ask all of them...

Original comment by egon.wil...@gmail.com on 23 May 2011 at 7:38

[GoogleCodeExporter]

From my experience, I've used PyQt4, which are GPL'd python bindings for the 
Qt4 libraries. It's author offered a free of charge GPL version and a paid 
proprietary license version of them, and claimed you couldn't distribute 
proprietary software which used the GPL'd version of the bindings.

They are licensed under a GPL with exceptions which made possible to license 
python scripts using them under some other open-source licenses, like BSD and 
MIT, IIRC.

Then Nokia licensed their Qt libraries under the LGPL and then they started to 
develop their own python bindings, but licensed under the LGPL to allow 
development of code using them to use any license.

So it looks like Nokia and the guy behind PyQt think that if a script 
inconditionally imports a GPL module, then it is subject to the GPL terms.

And they had to reinvent the wheel just to avoid the GPL and replace it with 
the LGPL.

Original comment by ssorga...@gmail.com on 23 May 2011 at 7:50

[GoogleCodeExporter]

The view of the FSF on this, as expressed in this FAQ entry:
http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL
is pretty unambiguous: 

"A consequence is that if you choose to use GPL'd Perl modules or Java classes 
in your program, you must release the program in a GPL-compatible way, 
regardless of the license used in the Perl or Java interpreter that the 
combined Perl or Java program will run on."

Note that this says "GPL Compatible", not "GPL". The new BSD is GPL compatible, 
so you should be fine distributing cinfony under a BSD license.

Original comment by greg.lan...@gmail.com on 24 May 2011 at 4:12

[GoogleCodeExporter]

I've updated the licenses for 1.1. May need more discussion, but it's a first 
step.

Original comment by baoille...@gmail.com on 30 Nov 2011 at 1:05

• Changed state: Fixed