Re: use of Python bindings to GPL library from within non-GPL Python toolkit
In message [EMAIL PROTECTED], Yaroslav Halchenko [EMAIL PROTECTED] writes Thank you Anthony for a detailed explanation, but I am still lacking a clear view here since you are talking about mixing-in GPL code within non-GPLed project, and in our case it is not quite the case: ATM all code in our project is non-GPLed, including some code which makes use of external GPL library through python bindings. So, technically speaking we are not mixing the code, and we do not redistribute GPL code within our project (that dependency on GPLed library is optional). But if I get it right -- it doesn't really matter, since GPL doesn't allow external non-GPLed software to use GPLed library (for such scenarios there is LGPL), am I right? If it's external non-GPL, you can't change its licence. So *YOU* *CAN* mix it with both GPL and your own software. But you CAN'T then DISTRIBUTE the result. The GPL says you must distribute the non-GPL code as if it were GPL, but you don't own that code and can't change the licence. So you can't comply with both licences at the same time, so you can't distribute. Cheers, Wol -- Anthony W. Youngman - [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: use of Python bindings to GPL library from within non-GPL Python toolkit
Anthony W. Youngman [EMAIL PROTECTED] writes: If it's external non-GPL, you can't change its licence. So *YOU* *CAN* mix it with both GPL and your own software. But you CAN'T then DISTRIBUTE the result. The GPL says you must distribute the non-GPL code as if it were GPL Not quite: the GPL says only that you may not impose *additional* restrictions beyond those in the GPL. There are a number of non-GPL licenses that, because their restrictions are a subset of those in the GPL, are thus compatible with the GPL. I believe the original poster spoke of an MIT-style license; this term could refer to any of a number of different licenses, so I'll assume they mean instead terms equivalent to the Expat license. The terms of the Expat license is one example of a license that is not GPL but is GPL-compatible. A work derived both from works licensed GPL and Expat can be redistributed under the GPL. but you don't own that code and can't change the licence. So you can't comply with both licences at the same time, so you can't distribute. If that were true, then it would indeed make the work non-redistributable. If both licenses *can* be satisfied (as in the case of GPL and Expat, by redistributing under the terms of the GPL), then that would be okay. -- \ “About four years ago, I was — no, it was yesterday.” —Steven | `\Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: use of Python bindings to GPL library from within non-GPL Python toolkit
Thank you Anthony for a detailed explanation, but I am still lacking a clear view here since you are talking about mixing-in GPL code within non-GPLed project, and in our case it is not quite the case: ATM all code in our project is non-GPLed, including some code which makes use of external GPL library through python bindings. So, technically speaking we are not mixing the code, and we do not redistribute GPL code within our project (that dependency on GPLed library is optional). But if I get it right -- it doesn't really matter, since GPL doesn't allow external non-GPLed software to use GPLed library (for such scenarios there is LGPL), am I right? -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: use of Python bindings to GPL library from within non-GPL Python toolkit
In message [EMAIL PROTECTED], Yaroslav Halchenko [EMAIL PROTECTED] writes Hi Guys, I am sorry that I am following up on this dead thread I started long ago [1], and which Francesco was kind to follow up to. Now I've got another project to package and got the same issue, and I am not clear if I have the right understanding of GPL-compatibility. AFAIK it means that you can use GPL-compatible licensed project within GPL-ed project, and not vise-versa! Am I correct? Yes. And actually if I am reading it right, wikipedia says the same: Many of the most common free software licenses, such as the original MIT/X license, the BSD license (in its current 3-clause form), and the LGPL, are GPL-compatible. That is, their code can be combined with a program under the GPL without conflict (the new combination would have the GPL applied to the whole). so -- combination has to be GPLed! Sort of yes ... If I am not right -- then Francesco is right and I can easily use GPLed project (and don't even ask for LGPL) from anything which is 'GPL-compatible'. That's not impossible ... but if I understand you aright, then the GPL is intended to hinder/prevent that. The GPL does not allow you to mix GPL'd code in non-gpl'd projects. The proper way to look at it is: If you distribute someone else's code you have to abide by their licence that they put on it. If that licence allows you to relicence the code then you can, otherwise you can't. Let's say you mix three code bases into one project, one is GPL, one is GPL-compatible, and one is your own code. Your own code, you can do what you like with - apply ANY licence to it. The GPL code, you cannot relicence it, so you have to distribute it under the GPL only. The GPL-compatible code can also be distributed under the GPL. But because you're distributing your code mixed with GPL code, the GPL demands that either you dual-licence your code as GPL, or you let the recipients of the code relicence. Otherwise you can't distribute the GPL code. Your recipients now can treat the entire project as if was GPL (that's the point of GPL-compatible). They can strip out your code and use it under whatever other licence you put it. And they can strip out the GPL-compatible code and use it under the GPL-compatible licence. The thing is, you CAN NOT (without the copyright holder's permission) relicence any third-party code. The GPL says you must pass on ALL the rights that the GPL grants to ALL the code to ALL the recipients. If you can't do that you can't distribute the GPL code. And if the 3rd-party licence didn't give you those rights to pass on, you can't mix that code with GPL code and pass it on because the two licences conflict - the GPL says you MUST pass on the rights, the 3rd-party licence says you CAN'T pass on the rights, and the only option left open to you is to NOT DISTRIBUTE. Cheers, Wol -- Anthony W. Youngman - [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: use of Python bindings to GPL library from within non-GPL Python toolkit
Hi Guys, I am sorry that I am following up on this dead thread I started long ago [1], and which Francesco was kind to follow up to. Now I've got another project to package and got the same issue, and I am not clear if I have the right understanding of GPL-compatibility. AFAIK it means that you can use GPL-compatible licensed project within GPL-ed project, and not vise-versa! Am I correct? And actually if I am reading it right, wikipedia says the same: Many of the most common free software licenses, such as the original MIT/X license, the BSD license (in its current 3-clause form), and the LGPL, are GPL-compatible. That is, their code can be combined with a program under the GPL without conflict (the new combination would have the GPL applied to the whole). so -- combination has to be GPLed! If I am not right -- then Francesco is right and I can easily use GPLed project (and don't even ask for LGPL) from anything which is 'GPL-compatible'. If I am right -- then I guess we might have quite a few packages in debian already which would need a closer look. And what could be a possible work-around? double-licensing? search for exceptions from GPLed project authors (release it under LGPL for use in a specific project etc) Thanks in advance! [1] http://lists.debian.org/debian-legal/2008/04/msg5.html On Wed, 02 Apr 2008, Yaroslav Halchenko wrote: Dear Legal People, I am one of the developers of PyMVPA toolbox [1], which we currently distribute under MIT License. It is written in Python and is actually a framework either to create scripts for the analysis or just perform analysis interactively within python (ipython) shell environment. Recently we decided to make use of shogun library inside of PyMVPA, which has python bindings available. Shogun is distributed under GPL (not LGPL). IIRC Python itself, since it is simply a programming language, is not limited in licensing terms to what libraries are allowed to be used (not shipped) within Python, thus it is ok to use shogun within Python. But do we have to double-license PyMVPA for people to be legally able to use shogun functionality within PyMVPA? or since we don't explicitly link to shogun, neither bundle it together we are ok? We don't want to switch to GPL completely since we don't want to limit MIT-compatible licensed software to absorb/use our (non-GPLed) code. If we do have to release it under GPL as well, would it be ok to distribute entire PyMVPA in a single package and just mention that some parts of PyMVPA (which make use of GPL) cannot be distributed/used under MIT license and are distributed solely under GPL? Thank you in advance for clarifications [1] http://pkg-exppsy.alioth.debian.org/pymvpa/ -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] signature.asc Description: Digital signature
use of Python bindings to GPL library from within non-GPL Python toolkit
Dear Legal People, I am one of the developers of PyMVPA toolbox [1], which we currently distribute under MIT License. It is written in Python and is actually a framework either to create scripts for the analysis or just perform analysis interactively within python (ipython) shell environment. Recently we decided to make use of shogun library inside of PyMVPA, which has python bindings available. Shogun is distributed under GPL (not LGPL). IIRC Python itself, since it is simply a programming language, is not limited in licensing terms to what libraries are allowed to be used (not shipped) within Python, thus it is ok to use shogun within Python. But do we have to double-license PyMVPA for people to be legally able to use shogun functionality within PyMVPA? or since we don't explicitly link to shogun, neither bundle it together we are ok? We don't want to switch to GPL completely since we don't want to limit MIT-compatible licensed software to absorb/use our (non-GPLed) code. If we do have to release it under GPL as well, would it be ok to distribute entire PyMVPA in a single package and just mention that some parts of PyMVPA (which make use of GPL) cannot be distributed/used under MIT license and are distributed solely under GPL? Thank you in advance for clarifications [1] http://pkg-exppsy.alioth.debian.org/pymvpa/ -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik signature.asc Description: Digital signature
Re: use of Python bindings to GPL library from within non-GPL Python toolkit
On Wed, 2 Apr 2008 14:20:23 -0400 Yaroslav Halchenko wrote: Dear Legal People, I am one of the developers of PyMVPA toolbox [1], Interesting project. Thanks for developing it as free software! :) which we currently distribute under MIT License. Which is better named the Expat license, in order to avoid ambiguities with other licenses that are called MIT License as well... It is written in Python and is actually a framework either to create scripts for the analysis or just perform analysis interactively within python (ipython) shell environment. Recently we decided to make use of shogun library inside of PyMVPA, which has python bindings available. Shogun is distributed under GPL (not LGPL). No problems so far, since the Expat license is GPL-compatible. IIRC Python itself, since it is simply a programming language, is not limited in licensing terms to what libraries are allowed to be used (not shipped) within Python, thus it is ok to use shogun within Python. Without even entering the linking-vs.-licensing technicalities, it is OK either way, since the Expat license is compatible with the GNU GPL. More knowledgeable people will explain whether using a GPLed library through Python bindings creates any licensing compatibility requirements (I tend to think it doesn't, since you do not distribute any bit coming or derived from the library). However the point is moot, since the two licenses are compatible anyway! But do we have to double-license PyMVPA for people to be legally able to use shogun functionality within PyMVPA? You don't have to dual-license anything, since, even in the case you have to comply with GPL requirements for works based on the Program, you only need to make sure your license is GPL-compatible, but the Expat license is already GPL-compatible! or since we don't explicitly link to shogun, neither bundle it together we are ok? You're probably OK for this reason too. If this is the case, you're OK for two reasons! [...] Thank you in advance for clarifications [1] http://pkg-exppsy.alioth.debian.org/pymvpa/ You're welcome, but please note my usual disclaimers: IANAL, TINLA, IANADD, TINASOTODP. -- http://frx.netsons.org/progs/scripts/refresh-pubring.html New! Version 0.6 available! What? See for yourself! . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgptc1i8KLPYF.pgp Description: PGP signature
