On Mon, 25 Sep 2006 08:01:46 -0700, Ed Suominen 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.

On Tue, 26 Sep 2006 11:49:47 +0200, Tristan Seligmann wrote:

* David Pratt [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 Tue, 26 Sep 2006 11:42:18 -0400, James Y Knight 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.

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 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 9/26/06, Bob Ippolito 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 Tue, 26 Sep 2006 13:01:50 -0400, James Y Knight 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 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 ;-).

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

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 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.

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