[Twisted-Python] Twisted & Qt
I'm using the qtreactor in a GPL-but-unreleased PyQt 4.1 application of my own, and have not found any problems whatsoever with the integration of the Qt Twisted event loops. It's really a pretty slick combination. As an example and a contribution, I offer the following (GPL'd) module: http://deadbeefbabe.org/paste/1996 (syntax-highlighted version), http://foss.eepatents.com/misc/qt-twisted-dialog.py (source). It allows you to construct a non-blocking modal dialog, immediately obtaining a deferred to the user's eventual input. As an aside, I would be interested in people's viewpoints about whether the Qt reactor is suitable for Twisted's MIT-style license, given that it doesn't actually import any Qt code itself. It leaves that step up to the user with the installation of a reactor into the Qt application object. As every Qt user probably knows, the Qt library itself is dual-licensed under either the GPL or Trolltech's proprietary license. Best regards, Ed
Hi Ed. Let's please leave the licensing issues of Twisted alone. This change was made quite some time ago as a license that would encourage developers to use Twisted. I think this should be respected and the licensing of code you are willing to commit, committed at MIT, so we don't need to open this debate. It is a reasonable and open license for this type of framework and there is no point in cutting off commercial developers that wish to use it by inserting GPL code. The point is that there are those who do in fact obtain a license from Trolltech and will not wish to mix GPL with a proprietary app, thus the MIT works well for this. Many thanks. Regards, David Ed Suominen wrote:
I'm using the qtreactor in a GPL-but-unreleased PyQt 4.1 application of my own, and have not found any problems whatsoever with the integration of the Qt Twisted event loops. It's really a pretty slick combination.
As an example and a contribution, I offer the following (GPL'd) module: http://deadbeefbabe.org/paste/1996 (syntax-highlighted version), http://foss.eepatents.com/misc/qt-twisted-dialog.py (source). It allows you to construct a non-blocking modal dialog, immediately obtaining a deferred to the user's eventual input.
As an aside, I would be interested in people's viewpoints about whether the Qt reactor is suitable for Twisted's MIT-style license, given that it doesn't actually import any Qt code itself. It leaves that step up to the user with the installation of a reactor into the Qt application object. As every Qt user probably knows, the Qt library itself is dual-licensed under either the GPL or Trolltech's proprietary license.
Best regards, Ed
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
On Mon, 25 Sep 2006 08:01:46 -0700, Ed Suominen <general@eepatents.com> wrote:
As an example and a contribution, I offer the following (GPL'd) module: http://deadbeefbabe.org/paste/1996 (syntax-highlighted version), http://foss.eepatents.com/misc/qt-twisted-dialog.py (source). It allows you to construct a non-blocking modal dialog, immediately obtaining a deferred to the user's eventual input.
Thanks very much for that pointer. I knew this was possible but it is the first working example I've seen of it!
As an aside, I would be interested in people's viewpoints about whether the Qt reactor is suitable for Twisted's MIT-style license, given that it doesn't actually import any Qt code itself. It leaves that step up to the user with the installation of a reactor into the Qt application object. As every Qt user probably knows, the Qt library itself is dual-licensed under either the GPL or Trolltech's proprietary license.
It does "import" qt in the sense that there is an import line at the top of the file which will load the library. IANAL, but as far as I know it is a matter of debate whether this sort of reference constitutes a "derivative work" under copyright law. As such, it would be best to get Riverbank and Trolltech on the record as to their respective opinions on whether licensing such code as MIT is a GPL violation, since I believe PyQt is clearly a derivative work of Qt itself, and therefore both companies are potential enforcers of the license in this case. Is anyone aware of the correct point of contact for these inquiries? If they do indeed consider it a violation, we'd have to remove it from Twisted. However, in that case, I would be happy to contribute the qt reactor to Riverbank and have them distribute it (under the GPL) with PyQt rather than us distributing it together with Twisted. This might be a good excuse to finally make reactors properly pluggable. As for this thread, I'd appreciate it if only people with relevant legal expertise and/or information from a responsible party at Trolltech or Riverbank would reply. I know license debates are always fun to get involved in, but this is not the appropriate forum. Twisted's MIT license is a matter of policy and is not open to debate.
* David Pratt <fairwinds@eastlink.ca> [2006-09-25 13:00:31 -0300]:
Hi Ed. Let's please leave the licensing issues of Twisted alone. This change was made quite some time ago as a license that would encourage developers to use Twisted. I think this should be respected and the licensing of code you are willing to commit, committed at MIT, so we don't need to open this debate.
I was not under the impression that he was suggesting that Twisted's license be changed; instead I believe he was merely trying to point out that since Twisted code is MIT-licensed as a matter of policy, having code that possible constitutes a derivative work of Qt may be legally problematic. Please note that I'm not trying to suggest an informed opinion on whether or not this is true; IANAL etc. Also see glyph's post in this thread for a reasonable course of action to clear this potential issue up. -- mithrandi, i Ainil en-Balandor, a faer Ambar
On Tue, 26 Sep 2006 11:49:47 +0200, Tristan Seligmann <mithrandi-twisted-python@mithrandi.za.net> wrote:
* David Pratt <fairwinds@eastlink.ca> [2006-09-25 13:00:31 -0300]:
Hi Ed. Let's please leave the licensing issues of Twisted alone. This change was made quite some time ago as a license that would encourage developers to use Twisted. I think this should be respected and the licensing of code you are willing to commit, committed at MIT, so we don't need to open this debate.
I was not under the impression that he was suggesting that Twisted's license be changed; instead I believe he was merely trying to point out that since Twisted code is MIT-licensed as a matter of policy, having code that possible constitutes a derivative work of Qt may be legally problematic.
That's what I took away from it as well, and it turns out that he was correct. There is a problem. I've gotten in touch with Riverbank Computing, the copyright holders on PyQt, and they are of the opinion that any Python code that imports "qt" is, in fact, a derivative work and therefore beholden to the GPL. I'll be removing it from the Twisted repository and contributing it to Riverbank for inclusion in PyQt at my next available opportunity. This is probably going to require an immediate addition of a plugin API for reactors, so it can be loaded externally.
On Sep 26, 2006, at 9:45 AM, glyph@divmod.com wrote:
I've gotten in touch with Riverbank Computing, the copyright holders on PyQt, and they are of the opinion that any Python code that imports "qt" is, in fact, a derivative work and therefore beholden to the GPL.
The only issue here is that we don't want to confuse people by having part of Twisted (qtreactor) be GPL. But wait, the MIT license is compatible with the GPL. It is perfectly acceptable to write a work under the MIT license (qtreactor) which links to a GPLd work (pyqt). I've never seen anybody say that's illegal. The only issue here is that you cannot write a proprietary program using qtreactor (even though qtreactor itself is MIT), because pyqt is still licensed under the GPL, and anything linking with the GPL program must be *GPL-compatible*. But even though you cannot take advantage of all the permissions of the MIT license when using qtreactor, our code, itself, is not under the GPL. You could take the qtreactor, make a derivative of it which doesn't use qt, and have that be MIT. I really think there's no problem here.
I'll be removing it from the Twisted repository and contributing it to Riverbank for inclusion in PyQt at my next available opportunity. This is probably going to require an immediate addition of a plugin API for reactors, so it can be loaded externally.
I strongly object to this, regardless of the outcome of the above. The internal reactor supporting APIs (posixbase etc) are not stable enough that I'm at all comfortable with giving a reactor over to external maintenance. If we have to, please instead let's segment it into a separate distributable, but still develop and release it in lockstep with twisted core. James
On Tue, 26 Sep 2006 11:42:18 -0400, James Y Knight <foom@fuhm.net> wrote:
On Sep 26, 2006, at 9:45 AM, glyph@divmod.com wrote:
I've gotten in touch with Riverbank Computing, the copyright holders on PyQt, and they are of the opinion that any Python code that imports "qt" is, in fact, a derivative work and therefore beholden to the GPL.
The only issue here is that we don't want to confuse people by having part of Twisted (qtreactor) be GPL.
Twisted is ostensibly a derivative work of all of the parts of Twisted.
But wait, the MIT license is compatible with the GPL.
And that's your professional legal opinion? It may be that riverbank and trolltech agree with this interpretation. The response I received wasn't entirely clear. However, you are making a number of assumptions about intellectual propertly law which are both outside your expertise and, to my knowledge, still undecided by any case law. I've asked the fellow at Riverbank for a clarification of his intent before reviewing and committing the removal. However, the impression I got from my first exchange is that Trolltech regards the QT API as their intellectual property, so the presence of phrases like "QObject.connect" and "QSocketNotifier.__init__" would make qtreactor a derivative work of their intellectual property, much like simple mentions of a fictional character's name in a short story can also classify as a derivative work.
I'll be removing it from the Twisted repository and contributing it to Riverbank for inclusion in PyQt at my next available opportunity. This is probably going to require an immediate addition of a plugin API for reactors, so it can be loaded externally.
I strongly object to this, regardless of the outcome of the above. The internal reactor supporting APIs (posixbase etc) are not stable enough that I'm at all comfortable with giving a reactor over to external maintenance. If we have to, please instead let's segment it into a separate distributable, but still develop and release it in lockstep with twisted core.
If we distribute it separately, I believe it will create license confusion due to the interaction of Qt and PyQt commercial licenses. However, I'll let the people who are actually interested in Twisted and Qt integration work this out with the PyQt maintainer; I don't care, personally.
On 9/26/06, glyph@divmod.com <glyph@divmod.com> wrote:
On Tue, 26 Sep 2006 11:49:47 +0200, Tristan Seligmann <mithrandi-twisted-python@mithrandi.za.net> wrote:
* David Pratt <fairwinds@eastlink.ca> [2006-09-25 13:00:31 -0300]:
Hi Ed. Let's please leave the licensing issues of Twisted alone. This change was made quite some time ago as a license that would encourage developers to use Twisted. I think this should be respected and the licensing of code you are willing to commit, committed at MIT, so we don't need to open this debate.
I was not under the impression that he was suggesting that Twisted's license be changed; instead I believe he was merely trying to point out that since Twisted code is MIT-licensed as a matter of policy, having code that possible constitutes a derivative work of Qt may be legally problematic.
That's what I took away from it as well, and it turns out that he was correct. There is a problem.
I've gotten in touch with Riverbank Computing, the copyright holders on PyQt, and they are of the opinion that any Python code that imports "qt" is, in fact, a derivative work and therefore beholden to the GPL.
I'll be removing it from the Twisted repository and contributing it to Riverbank for inclusion in PyQt at my next available opportunity. This is probably going to require an immediate addition of a plugin API for reactors, so it can be loaded externally.
Maybe this is a good time to consider setuptools support? Entry points are the external plug-in API that everyone else uses. Also, the fact that Twisted can't be listed as a dependency in any setuptools-using projects due to its non-standard setup.py is one huge pain in the ass. -bob
Not that I mean to beat a dead horse, but the use of a single word or phrase in a document doesn't fall under the derivative work clause of copyright. Instead in comes from trademark law. For instance to xerox something is one of those cases where the mark Xerox was lost to the common use of to copy something. Google is undergoing just such an issue right now. At no point can't you use one word or phase in an document and have it magically copyrighted. On the other hand using a trademark means you have to acknowledge ownership. Now this isn't to say that you can use the idea of Professor X in a document - a story - and not run into problems. That is a totally different beast and isn't covered by Trademark or Copyright law. Instead it is a part of intellectual property law. But none of this applies to QT. You can easily use a library - with an MIT license or not - to link to a GPL'ed library. What you can't do is assume the entire work produce as the lesser of the two libraries. This means that you can link something with Twisted's QT reactor and still link it with PyQT or QT. The heart of the issue is that the entire product will fall under the more restrictive of the libraries, in this case GPL. GPL doesn't say you can't link with anything other than GPL; it only says the resulting work must be GPL. Since neither the MIT or BSD licenses say that you must have a resulting work product of MIT or BSD, you are safe. In no case, do I believe you need to remove the QT reactor from the Twisted. It has no impact other than to make things more difficult to use. Is this what is really wanted here? FWIW, Chuck Wegrzyn glyph@divmod.com wrote:
On Tue, 26 Sep 2006 11:42:18 -0400, James Y Knight <foom@fuhm.net> wrote:
On Sep 26, 2006, at 9:45 AM, glyph@divmod.com wrote:
I've gotten in touch with Riverbank Computing, the copyright holders on PyQt, and they are of the opinion that any Python code that imports "qt" is, in fact, a derivative work and therefore beholden to the GPL.
The only issue here is that we don't want to confuse people by having part of Twisted (qtreactor) be GPL.
Twisted is ostensibly a derivative work of all of the parts of Twisted.
But wait, the MIT license is compatible with the GPL.
And that's your professional legal opinion?
It may be that riverbank and trolltech agree with this interpretation. The response I received wasn't entirely clear. However, you are making a number of assumptions about intellectual propertly law which are both outside your expertise and, to my knowledge, still undecided by any case law.
I've asked the fellow at Riverbank for a clarification of his intent before reviewing and committing the removal. However, the impression I got from my first exchange is that Trolltech regards the QT API as their intellectual property, so the presence of phrases like "QObject.connect" and "QSocketNotifier.__init__" would make qtreactor a derivative work of their intellectual property, much like simple mentions of a fictional character's name in a short story can also classify as a derivative work.
I'll be removing it from the Twisted repository and contributing it to Riverbank for inclusion in PyQt at my next available opportunity. This is probably going to require an immediate addition of a plugin API for reactors, so it can be loaded externally.
I strongly object to this, regardless of the outcome of the above. The internal reactor supporting APIs (posixbase etc) are not stable enough that I'm at all comfortable with giving a reactor over to external maintenance. If we have to, please instead let's segment it into a separate distributable, but still develop and release it in lockstep with twisted core.
If we distribute it separately, I believe it will create license confusion due to the interaction of Qt and PyQt commercial licenses. However, I'll let the people who are actually interested in Twisted and Qt integration work this out with the PyQt maintainer; I don't care, personally.
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
On Sep 26, 2006, at 12:12 PM, glyph@divmod.com wrote:
On Tue, 26 Sep 2006 11:42:18 -0400, James Y Knight <foom@fuhm.net> wrote:
On Sep 26, 2006, at 9:45 AM, glyph@divmod.com wrote:
I've gotten in touch with Riverbank Computing, the copyright holders on PyQt, and they are of the opinion that any Python code that imports "qt" is, in fact, a derivative work and therefore beholden to the GPL.
The only issue here is that we don't want to confuse people by having part of Twisted (qtreactor) be GPL.
Twisted is ostensibly a derivative work of all of the parts of Twisted.
More than ostensibly, since code has been _literally_ copied all around the codebase from file to file.
But wait, the MIT license is compatible with the GPL.
And that's your professional legal opinion?
It is a statement of indisputable fact that you can take MIT licensed source code and combine with GPL licensed source code and create a GPL licensed executable. We distribute MIT licensed source code. Apparently RMS said the following to a gnome mailing list circa 2003. I can't find the original message, but I have no reason to doubt its authenticity:
This exception would be redundant, because simple non-copyleft licenses such as X11 and BSD are compatible with the GPL already.
So if you want to write a non-copylefted application, release it under the X11 license, and link it with a GPL-covered library, that is allowed. The linked executable would be covered by the GPL, of course, but the app source code would be covered by the X11 license alone.
And let's take the example of Python itself, which has a readline module, distributed under the python license. Again, similar circumstance. If you actually make use of the readline module, your program will need to be distributed under the GPL. But the source code is still Python licensed.
It may be that riverbank and trolltech agree with this interpretation. The response I received wasn't entirely clear. However, you are making a number of assumptions about intellectual propertly law which are both outside your expertise and, to my knowledge, still undecided by any case law.
If you think that twisted is in imminent danger of a lawsuit from Riverbank or Trolltech, then by all means simply remove qtreactor completely. Even presuming we are not doing anything wrong, it would still not be worth a lawsuit to determine that. However, I don't think anybody is about to sue Twisted for including qtreactor. But, if we're not about to be sued, case law is much less important than accepted existing practice in the open source world.
I've asked the fellow at Riverbank for a clarification of his intent before reviewing and committing the removal. However, the impression I got from my first exchange is that Trolltech regards the QT API as their intellectual property, so the presence of phrases like "QObject.connect" and "QSocketNotifier.__init__" would make qtreactor a derivative work of their intellectual property, much like simple mentions of a fictional character's name in a short story can also classify as a derivative work.
Please don't use the phrase "intellectual property". It is dangerously misleading and worse than meaningless. I assume you mean copyright, in which it is my unprofessional opinion that it is ridiculous to talk about copyright in the phrase QSocketNotifier.__init__. If it is truly their position that the textual source code of qtreactor is a derivative work of PyQT, I think they are quite confused. There are numerous instances of programs using Qt (take KDE for example!) licensed under non-GPL terms. Parts of KDE are under LGPL, BSD, and Artistic licenses. See http://developer.kde.org/ documentation/books/kde-2.0-development/ch19.html If it's good enough for KDE, I don't see how it's not good enough for us. I'm sure many more people with actual legal experience have looked over the situation with KDE. James
On 9/26/06, Bob Ippolito <bob@redivi.com> wrote:
Maybe this is a good time to consider setuptools support? Entry points are the external plug-in API that everyone else uses. Also, the fact that Twisted can't be listed as a dependency in any setuptools-using projects due to its non-standard setup.py is one huge pain in the ass.
it was considered, and there were no objections (and many people who would like it): http://twistedmatrix.com/trac/ticket/1533 someone just has to actually implement it. I'd like to sprint on this Friday (At Rochester DevHouse, http://xkfm.com/wiki) assuming the buildslave is up by then. I'm completely mac-ignorant, how is our installation on that platform?
On 9/26/06, Timothy Fitz <TimothyFitz@gmail.com> wrote:
On 9/26/06, Bob Ippolito <bob@redivi.com> wrote:
Maybe this is a good time to consider setuptools support? Entry points are the external plug-in API that everyone else uses. Also, the fact that Twisted can't be listed as a dependency in any setuptools-using projects due to its non-standard setup.py is one huge pain in the ass.
it was considered, and there were no objections (and many people who would like it): http://twistedmatrix.com/trac/ticket/1533
someone just has to actually implement it. I'd like to sprint on this Friday (At Rochester DevHouse, http://xkfm.com/wiki) assuming the buildslave is up by then.
Awesome.
I'm completely mac-ignorant, how is our installation on that platform?
Same as any other *nix. -bob
On Tue, 26 Sep 2006 13:01:50 -0400, James Y Knight <foom@fuhm.net> wrote:
On Sep 26, 2006, at 12:12 PM, glyph@divmod.com wrote:
On Tue, 26 Sep 2006 11:42:18 -0400, James Y Knight <foom@fuhm.net> wrote:
On Sep 26, 2006, at 9:45 AM, glyph@divmod.com wrote:
And that's your professional legal opinion?
We distribute MIT licensed source code.
That is the question, isn't it :).
So if you want to write a non-copylefted application, release it under the X11 license, and link it with a GPL-covered library, that is allowed. The linked executable would be covered by the GPL, of course, but the app source code would be covered by the X11 license alone.
The GPL license text doesn't refer to "linking", there's really practically no such thing as "linking" in Python, so this is RMS's opinion of how the license should work in a different context than the one we're talking about. What's interesting is to what extent the copyright holders in this situation agree, and when (and where) they think this "linking" happens.
And let's take the example of Python itself, which has a readline module, distributed under the python license. Again, similar circumstance. If you actually make use of the readline module, your program will need to be distributed under the GPL. But the source code is still Python licensed.
Python is a C program, where the conventional understanding of "linking" makes sense, and readline is copyrighted by the FSF, which makes RMS's interpretation relevant. This is not the same situation.
It may be that riverbank and trolltech agree with this interpretation. The response I received wasn't entirely clear.
If you think that twisted is in imminent danger of a lawsuit from Riverbank or Trolltech, then by all means simply remove qtreactor completely.
Obviously not. The question here is one of intent, not punitive damages. In Riverbank/Trolltech's case, the license is used as a means to deter commercial users from using the software unless they pay a licensing fee. Lawsuits, and the threat thereof, are the weapon used to enforce that intent. I don't think that we should wait until they actually start threatening us with legal action before we do something to put the situation with respect to their code more in line with their intent with their licenses.
Please don't use the phrase "intellectual property".
I wish I didn't even *know* the phrase, but I was quoting Phil Thompson (Riverbank) directly. He wrote: """ Trolltech will have the same view. As far as they are concerned their intellectual property is the API and it doesn't matter how it is accessed. """ This is probably, as you say, legal nonsense. I don't think Mr. Thompson is a lawyer either, nor is he speaking authoritatively for trolltech's lawyers. But, he is a copyright holder in this case, and therefore entitled to certain outlandish opinions.
If it is truly their position that the textual source code of qtreactor is a derivative work of PyQT, I think they are quite confused.
If it is your opinion that the "textual source code" is not a derivative work because it merely refers to, but does not incorporate, the text of qtreactor or qt, then the GPL is completely meaningless in the context of Python and there was no point in licensing it that way in the first place. Python bytecode does not make any additional references to the code it is importing beyond what Python source code does. In that case the GPL can not apply to Python in any practical way. I suspect that someone applying the GPL license to a bunch of Python code *would* disagree with that interpratation.
If it's good enough for KDE, I don't see how it's not good enough for us. I'm sure many more people with actual legal experience have looked over the situation with KDE.
Oh yeah, and KDE has never had any problems with licensing ;-).
On Tue, 26 Sep 2006 10:18:50 -0700, Bob Ippolito <bob@redivi.com> wrote:
On 9/26/06, Timothy Fitz <TimothyFitz@gmail.com> wrote:
On 9/26/06, Bob Ippolito <bob@redivi.com> wrote:
Maybe this is a good time to consider setuptools support? Entry points are the external plug-in API that everyone else uses. Also, the fact that Twisted can't be listed as a dependency in any setuptools-using projects due to its non-standard setup.py is one huge pain in the ass.
it was considered, and there were no objections (and many people who would like it): http://twistedmatrix.com/trac/ticket/1533
That ticket doesn't seem to refer to setuptools at all, just distutils. I certainly haven't seen a discussion of removing twisted.plugin and switching to entry points.
someone just has to actually implement it. I'd like to sprint on this Friday (At Rochester DevHouse, http://xkfm.com/wiki) assuming the buildslave is up by then.
Awesome.
I'm completely mac-ignorant, how is our installation on that platform?
Same as any other *nix.
... except for the parts that aren't :). You can find some packages for different styles of Mac installation at http://twistedmatrix.com/trac/wiki/Packages#MacOSX
glyph@divmod.com ha scritto:
[...]
Please don't use the phrase "intellectual property".
I wish I didn't even *know* the phrase, but I was quoting Phil Thompson (Riverbank) directly. He wrote:
""" Trolltech will have the same view. As far as they are concerned their intellectual property is the API and it doesn't matter how it is accessed. """
This is probably, as you say, legal nonsense. I don't think Mr. Thompson is a lawyer either, nor is he speaking authoritatively for trolltech's lawyers. But, he is a copyright holder in this case, and therefore entitled to certain outlandish opinions.
It seems they are in good company with MySQL AB: http://dev.mysql.com/doc/internals/en/licensing-notice.html """ The MySQL Protocol is part of the MySQL Database Management System. As such, it falls under the provisions of the GNU Public License (GPL). A copy of the GNU Public License is available on MySQL's web site, and in the product download. Because this is a GPL protocol, any product which uses it to connect to a MySQL server, or to emulate a MySQL server, or to interpose between any client and server which uses the protocol, or for any similar purpose, is also bound by the GPL. Therefore if you use this description to write a program, you must release your program as GPL. """ ;-) Regards Manlio Perillo
if this helps at all: http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL Both copied below. ------ If a library is released under the GPL (not the LGPL), does that mean that any program which uses it has to be under the GPL? Yes, because the program as it is actually run includes the library. If a programming language interpreter is released under the GPL, does that mean programs written to be interpreted by it must be under GPL- compatible licenses? When the interpreter just interprets a language, the answer is no. The interpreted program, to the interpreter, is just data; a free software license like the GPL, based on copyright law, cannot limit what data you use the interpreter on. You can run it on any data (interpreted program), any way you like, and there are no requirements about licensing that data to anyone. However, when the interpreter is extended to provide "bindings" to other facilities (often, but not necessarily, libraries), the interpreted program is effectively linked to the facilities it uses through these bindings. So if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL- compatible way. The JNI or Java Native Interface is an example of such a binding mechanism; libraries that are accessed in this way are linked dynamically with the Java programs that call them. These libraries are also linked with the interpreter. If the interpreter is linked statically with these libraries, or if it is designed to link dynamically with these specific libraries, then it too needs to be released in a GPL-compatible way. Another similar and very common case is to provide libraries with the interpreter which are themselves interpreted. For instance, Perl comes with many Perl modules, and a Java implementation comes with many Java classes. These libraries and the programs that call them are always dynamically linked together. 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.
On Tue, 26 Sep 2006 14:14:24 -0400, glyph@divmod.com wrote:
On Tue, 26 Sep 2006 13:01:50 -0400, James Y Knight <foom@fuhm.net> wrote:
If it is truly their position that the textual source code of qtreactor is a derivative work of PyQT, I think they are quite confused.
If it is your opinion that the "textual source code" is not a derivative work because it merely refers to, but does not incorporate, the text of qtreactor or qt, then the GPL is completely meaningless in the context of Python and there was no point in licensing it that way in the first place. Python bytecode does not make any additional references to the code it is importing beyond what Python source code does.
I've got what I believe is the final word on this. Phil Thompson (again, Riverbank) says: """ The reactor must be licensed under the GPL, but the rest of Twisted doesn't. A Twisted application that doesn't use the reactor can be licensed under the Twisted license. A Twisted application that uses the reactor must be licensed under the GPL. """ The best course of action, then, would be to distribute qtreactor separately, since we can no longer say that Twisted is all MIT licensed if we do not. The practical ramifications of this are not earth-shattering, so I think that we do not need to, e.g. release a 2.4.1 which does not include qtreactor, but 2.5+ should definitely not include it. I also asked specifically about not interfering with the PyQt/Qt commercial license, and Mr. Thompson suggested wording like this: """ This code is licensed under either the Twisted license or the GPL depending on the license of the copy of PyQt being used. If the GPL version of PyQt is being used then this code is also licensed under the GPL. Given the viral nature of the GPL this means that any application must also be licensed under the GPL. If any other version of PyQt is being used (eg. commercial, evaluation, educational) then this code is licensed under the Twisted license. """ I suggest that we leave that wording mostly unchanged.
This is bunk. Any application that uses the GPL'ed Qt (or any other GPL noise) is subject to the terms of the GPL. This, of course, includes the Qt reactor. I'm find will pulling the reactor if you think it's creating confusion, but there are no circumstances under which the reactor itself must be licensed under the GPL. It must be licensed under a GPL-compatible license in order to be used with Qt, and I agree that without that, the reactor is rather uninteresting in a practical sense. The Qt reactor can be MIT licensed, if for no other reason than the MIT license is GPL-compatible. See "X11 License" here: http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses The GPL is stupid. There is no need to become stupid along with it. The language below is misleading. Instead say something like "If you use Qt in your application (which is likely, if you use this reactor), beware that you are subject to the license of Qt, which is, for some users, the GPL, which stupidly taints your code, and the reason people pay for Qt or use truly free software (like Twisted) instead." Feel free to edit the pissy parts out. Anyway, short version: we don't redistribute GPL software, so we aren't bound to its terms, and neither is our software. Any fool who does is. -wsv On Sep 30, 2006, at 2:54 AM, glyph@divmod.com wrote:
On Tue, 26 Sep 2006 14:14:24 -0400, glyph@divmod.com wrote:
On Tue, 26 Sep 2006 13:01:50 -0400, James Y Knight <foom@fuhm.net> wrote:
If it is truly their position that the textual source code of qtreactor is a derivative work of PyQT, I think they are quite confused.
If it is your opinion that the "textual source code" is not a derivative work because it merely refers to, but does not incorporate, the text of qtreactor or qt, then the GPL is completely meaningless in the context of Python and there was no point in licensing it that way in the first place. Python bytecode does not make any additional references to the code it is importing beyond what Python source code does.
I've got what I believe is the final word on this. Phil Thompson (again, Riverbank) says:
""" The reactor must be licensed under the GPL, but the rest of Twisted doesn't. A Twisted application that doesn't use the reactor can be licensed under the Twisted license. A Twisted application that uses the reactor must be licensed under the GPL. """
The best course of action, then, would be to distribute qtreactor separately, since we can no longer say that Twisted is all MIT licensed if we do not. The practical ramifications of this are not earth-shattering, so I think that we do not need to, e.g. release a 2.4.1 which does not include qtreactor, but 2.5+ should definitely not include it.
I also asked specifically about not interfering with the PyQt/Qt commercial license, and Mr. Thompson suggested wording like this:
""" This code is licensed under either the Twisted license or the GPL depending on the license of the copy of PyQt being used.
If the GPL version of PyQt is being used then this code is also licensed under the GPL. Given the viral nature of the GPL this means that any application must also be licensed under the GPL.
If any other version of PyQt is being used (eg. commercial, evaluation, educational) then this code is licensed under the Twisted license. """
I suggest that we leave that wording mostly unchanged.
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
On Oct 5, 2006, at 2:08 PM, Wilfredo Sánchez Vega wrote:
This is bunk.
Yes, I agree (again). Look at KDE. If it's okay for the library parts of KDE to be licensed under the LGPL (which they are)...how can it be improper for qtreactor to be licensed under the MIT license. If the argument is that qtreactor is a derivative work of Qt, firstly, that's utterly insane, and secondly, KDE is *much* more arguably a derivative work than qtreactor. In addition, the proposed "license" terms:
""" This code is licensed under either the Twisted license or the GPL depending on the license of the copy of PyQt being used.
If the GPL version of PyQt is being used then this code is also licensed under the GPL. Given the viral nature of the GPL this means that any application must also be licensed under the GPL.
If any other version of PyQt is being used (eg. commercial, evaluation, educational) then this code is licensed under the Twisted license. """
make very little sense. The license under which we make the code available shouldn't depend on something the user does with it. What I think he's trying to say there is that the code is available under the MIT license, but if you're putting it together with a GPL'd qt, you have to treat it as GPLd as well. Which is necessarily the case (because of the GPL), whether or not *we* say that. If it would make people happy, we could say something like: "This module may be used under either the MIT or GPL license, at your option. However, note that your license of the underlying PyQt and Qt libraries may influence which you may use. (in particular, when using the GPL version of Qt, this module in turn must be treated under the GPL as well, as per Qt's GPL license)." That is, of course, identical to the MIT license in actual meaning, but might make things clearer for people. Yes, you cannot really take advantage of its non-GPLness unless you pay for a commercial license of PyQt and Qt, but that's not our problem. We have no interest in forcing people to abide by the GPL with regards to the code in qtreactor, and the license should make that clear (by remaining an MIT license). In addition, I think this whole thing has been a waste of time. Nobody was upset by qtreactor's license, there was no reason to even worry about it in the first place. James
Are we all forgetting how copyright works? The GPL only applies if copyright applies. Copyright only applies if you're making copies of someone else's materials. The qtreactor does not do that, because we don't include anyone else's files or distribute them. Someone writing an application *might* be, but that's their problem. qtreactor should remain plain old MIT, or it should be dropped and left for someone else to maintain, because frankly this whole issue has become radioactive. C On 10/8/06, James Y Knight <foom@fuhm.net> wrote:
On Oct 5, 2006, at 2:08 PM, Wilfredo Sánchez Vega wrote:
This is bunk.
participants (12)
-
Bob Ippolito -
Chaz. -
Cory Dodt -
David Pratt -
Ed Suominen -
glyph＠divmod.com -
James Y Knight -
Jonathan -
Manlio Perillo -
Timothy Fitz -
Tristan Seligmann -
Wilfredo Sánchez Vega