Re: Big development in the GUI realm
Arich Chanachai wrote: I have never seen a commercial license for a library which stated that you did not have to pay the license fee until you have made that much money in sales from the software which you created, in part, from that library. I would be in favor of such a license, but I haven't seen anything of the sort. http://www.fastio.com/licensePlain.html See their license option for shareware developers. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
Jeremy Bowers wrote: On Fri, 11 Feb 2005 14:45:09 -0800, Robert Kern wrote: Until such matters are unequivocally determined in a court that has jurisdiction over you, do you really want to open yourself to legal risk and certain ill-will from the community? Huh? What are you talking about? I'm just pointing out the inability of the law to handle it. I have no intention of doing anything with it, except inasmuch as it makes it difficult to license my own works since I don't believe any license works. (But I use the LGPL anyways.) Sorry, it seemed like you were proposing a method to get around the intention of the copyright holder. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
Jeremy Bowers wrote: On Fri, 11 Feb 2005 18:24:22 +0100, Damjan wrote: What you described is not ok according to the GPL - since you distributed a binary thats derived from GPL software (and you didn't publish it source code under the GPL too). No you didn't. You distributed a binary completely free of any GPL code whatsoever. The *user* combined your binary and the GPL to produce another binary, which will never be distributed at all. In copyright terms, which is what the GPL works under since that is the law it has, what you distributed is completely unrelated to the GPL'ed program; there's no grounds to call it derived. You might be on firmer ground if it were legally clear exactly what derived work means. Unfortunately, the courts have been skirting around the issue of defining derived work particularly as it pertains to software. It is entirely possible that a judge would conclude that your software is a derived work of the GPL software. Until such matters are unequivocally determined in a court that has jurisdiction over you, do you really want to open yourself to legal risk and certain ill-will from the community? I'll reiterate my strategy: follow the intentions of the copyright owner unless if I have actual case law on my side. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
Robert Kern wrote: Arich Chanachai wrote: I have never seen a commercial license for a library which stated that you did not have to pay the license fee until you have made that much money in sales from the software which you created, in part, from that library. I would be in favor of such a license, but I haven't seen anything of the sort. http://www.fastio.com/licensePlain.html See their license option for shareware developers. I stand corrected. Nevertheless, my point stands as this is rare. In fact, this thread began as a result of Trolltech releasing PyQt for windows with a GPL license option in addition to the commercial one, and you will notice that there is no special *deferment provision for shareware developers *in the specification of commercial license.* *It would be a grand aid to developers if more companies took this noble and perhaps more effective approach (versus the gimme-money-now alternative which is quite dominant). I would argue that such a provision is in the interests of the toolkit/library developer as this would allow fellows to adopt their technology (and eventually pay for this adoption), fellows who otherwise could not. -Arich -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
Jorge Luiz Godoy Filho wrote: Max M wrote: GPL is not suitable for all kinds of software. It's nice if you are sharing code with others, but if you are developing something like a desktop application that you want to sell for money, using the GPL is a bad idea. If you're earning money, why not pay for the libraries that allowed you to do so? Exactly. But what about those who know how to program but have not a cent of money? I have never seen a commercial license for a library which stated that you did not have to pay the license fee until you have made that much money in sales from the software which you created, in part, from that library. I would be in favor of such a license, but I haven't seen anything of the sort. Be seeing you, Godoy. Be seeing you too, lol. - Arich -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
On Fri, 11 Feb 2005 14:45:09 -0800, Robert Kern wrote: Until such matters are unequivocally determined in a court that has jurisdiction over you, do you really want to open yourself to legal risk and certain ill-will from the community? Huh? What are you talking about? I'm just pointing out the inability of the law to handle it. I have no intention of doing anything with it, except inasmuch as it makes it difficult to license my own works since I don't believe any license works. (But I use the LGPL anyways.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
You can distribute GPL'ed code in binary form, you just have to make the sources available as well. And, yes I would use this as a test: if your program needs gpl-ed code for some of it's functionality, you have to licence your program according to the GPL - unless you distribute the GPL'ed parts separately and your program is still basically functioning without the GPL'ed code. Now, if you are unsure about these questions and are serious about writing a program using GPL'ed code, the FSF is probably willing to help you with your questions. Besides this, why not putting your code under the GPL? - Josef -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
Josef Dalcolmo wrote: You can distribute GPL'ed code in binary form, you just have to make the sources available as well. And, yes I would use this as a test: if your program needs gpl-ed code for some of it's functionality, you have to licence your program according to the GPL - unless you distribute the GPL'ed parts separately and your program is still basically functioning without the GPL'ed code. Besides this, why not putting your code under the GPL? GPL is not suitable for all kinds of software. It's nice if you are sharing code with others, but if you are developing something like a desktop application that you want to sell for money, using the GPL is a bad idea. -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
On Fri, 11 Feb 2005 13:57:47 +0100, Josef Dalcolmo wrote: You can distribute GPL'ed code in binary form, you just have to make the sources available as well. And, yes I would use this as a test: if your program needs gpl-ed code for some of it's functionality, you have to licence your program according to the GPL - unless you distribute the GPL'ed parts separately and your program is still basically functioning without the GPL'ed code. The problem with this is what I've called the patch hole in another context [1]. The problem with this definition is that I can *always* distribute GPL'ed parts separately and re-combine them arbitrarily upon execution, and it's not even particularly hard. Write your code with the GPL'ed code embedded. At the end, before you distribute, extract it and record the extraction so your program can rewind it; you're left with nothing in your code that is GPLed. Later, the user will go get the GPL software, and you software rewinds the extraction process, and the user is left with something that is byte-for-byte identical to what you weren't allowed to distribute by the GPL so what good was the GPL? (Compiling issues can of course be extracted away, which is what a linker does.) If this is all the protection that the GPL provides, than it is utterly useless. But truly nailing down what it means is even harder. Nobody really knows what the GPL means when it gets down to it; the entire copyright-based model is broken and unrepairable in a software context. It's like nailing jello to a wall, you just can't hold it up there. [1]:http://www.jerf.org/writings/communicationEthics/node10.html#SECTION000105000 -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
The problem with this is what I've called the patch hole in another context [1]. The problem with this definition is that I can *always* distribute GPL'ed parts separately and re-combine them arbitrarily upon execution, and it's not even particularly hard. Write your code with the GPL'ed code embedded. At the end, before you distribute, extract it and record the extraction so your program can rewind it; you're left with nothing in your code that is GPLed. Later, the user will go get the GPL software, and you software rewinds the extraction process, and the user is left with something that is byte-for-byte identical to what you weren't allowed to distribute by the GPL so what good was the GPL? What you described is not ok according to the GPL - since you distributed a binary thats derived from GPL software (and you didn't publish it source code under the GPL too). Nobody really knows what the GPL means when it gets down to it; If you don't know, you should ask the person whose GPL code you are using. -- damjan -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
On Fri, 11 Feb 2005 18:24:22 +0100, Damjan wrote: What you described is not ok according to the GPL - since you distributed a binary thats derived from GPL software (and you didn't publish it source code under the GPL too). No you didn't. You distributed a binary completely free of any GPL code whatsoever. The *user* combined your binary and the GPL to produce another binary, which will never be distributed at all. In copyright terms, which is what the GPL works under since that is the law it has, what you distributed is completely unrelated to the GPL'ed program; there's no grounds to call it derived. You may need to re-read the sequence more carefully, or I may have gotten it wrong. -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
Max M wrote: GPL is not suitable for all kinds of software. It's nice if you are sharing code with others, but if you are developing something like a desktop application that you want to sell for money, using the GPL is a bad idea. If you're earning money, why not pay for the libraries that allowed you to do so? Be seeing you, Godoy. -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
Alex Martelli wrote: Dennis Lee Bieber [EMAIL PROTECTED] wrote: hassle to code, but if your application could dynamically select from whatever toolkit is available on the machine, you (and I should emphasis that this is an impersonal/generic you I reference) might be able to argue an exemption from the QT license. So maybe it's time to resurrect anygui, maybe in a simplified version which can only interface to, say, PyQt or Tkinter -- 'eithergui' maybe. Alex Done already: 'Twilight GUI'! http://students.ceid.upatras.gr/~sxanth/twgui/ However, it's very furstrating working on 4 toolkits in parallel and because some of the don't have good documentation, I'm doing other things right now:) Stelios -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
Jeremy Bowers schreef: Copyright-based models can't handle modern computer programs, Most countries have computer program specific parts in their copyright laws... -- JanC Be strict when sending and tolerant when receiving. RFC 1958 - Architectural Principles of the Internet - section 3.9 -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
Francis Girard schreef: Did some law court, over the past decade, had to make a decision about GPL on some real issue ? netfilter vs. Sitecom ? -- JanC Be strict when sending and tolerant when receiving. RFC 1958 - Architectural Principles of the Internet - section 3.9 -- http://mail.python.org/mailman/listinfo/python-list
RE: Big development in the GUI realm
Title: RE: Big development in the GUI realm [Carlos Ribeiro] #- 'onegui' to rule them all... I would really love to use a GUI made by elves... . Facundo Bitácora De Vuelo: http://www.taniquetil.com.ar/plog PyAr - Python Argentina: http://pyar.decode.com.ar/ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ADVERTENCIA. La información contenida en este mensaje y cualquier archivo anexo al mismo, son para uso exclusivo del destinatario y pueden contener información confidencial o propietaria, cuya divulgación es sancionada por la ley. Si Ud. No es uno de los destinatarios consignados o la persona responsable de hacer llegar este mensaje a los destinatarios consignados, no está autorizado a divulgar, copiar, distribuir o retener información (o parte de ella) contenida en este mensaje. Por favor notifíquenos respondiendo al remitente, borre el mensaje original y borre las copias (impresas o grabadas en cualquier medio magnético) que pueda haber realizado del mismo. Todas las opiniones contenidas en este mail son propias del autor del mensaje y no necesariamente coinciden con las de Telefónica Comunicaciones Personales S.A. o alguna empresa asociada. Los mensajes electrónicos pueden ser alterados, motivo por el cual Telefónica Comunicaciones Personales S.A. no aceptará ninguna obligación cualquiera sea el resultante de este mensaje. Muchas Gracias. -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
On Mon, 07 Feb 2005 20:56:44 -0800, Courageous [EMAIL PROTECTED] wrote: OK, so according to Linus, the GPL allows No. Pay attention. Linus has his own revised version, to clarify this point, and in fact /overruling/ the GPL if the point is clarified differently by RMS or others. That's the right of their community, it's /their/ code. make calls to the kernel, but TrollTech says the GPL doesn't allow a proprietary program to make calls to the Qt library. That's their prerogative, although TrollTech's authority as an /interpretational/ entity over the GPL means precisely zero. I wouldn't push this, though, unless you've got a big litigation budget. It should also be pointed out that the FSF's interpretation of the GPL with respect to Qt means absolutely zero. If TrollTech publishes an interpretation of the GPL and announces it to any interested in licensing their software, I suspect that the courts will take that into consideration. This won't help that at all if it isn't a legally valid interpretation, but it establishes that you *knew* what their interpretation was when you agreed to the terms to distribute their copyrighted software. It's this double-standard that I find confusing, since both projects are said to be based on the same license. Linus doesn't use the GPL, he uses his GPL, version-whatever. Anyway, your safe bet: Follow the copyright holder's wishes. That's fair. After all, it's free, so they're doing you a damn big favor. C// Scott Robinson -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
It should also be pointed out that the FSF's interpretation of the GPL with respect to Qt means absolutely zero. Indeed. It would be the court that would have to decide what the language of the GPL means, given the substantial body of case law as the court sees it. ... but it establishes that you *knew* what their interpretation ... But it doesn't. They'd really need to put it into their license expressly. Anyway, we digress, and are in agreement. C// -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
Luke Skywalker wrote: OK, so according to Linus, the GPL allows a proprietary program to make calls to the kernel, As I understand things, it's not the GPL which allows this, it's Linus himself who allows it. If Linus hadn't explicitly said that, the GPL might be interpreted as disallowing it. -- Greg Ewing, Computer Science Dept, University of Canterbury, Christchurch, New Zealand http://www.cosc.canterbury.ac.nz/~greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
Damjan wrote: For all you GUI developers, things just got a little more interesting. Trolltech will soon be offering the QT GUI toolkit for Windows under the GPL license. That means that PyQt may become a much more popular option in the near future. This applies to QT-4 only. I wonder how much of PyQT is ready for QT4? Anyway its time for a PyQT based VB-killer [ a GPL one :) ]. Anyway its time for a PyQT based VB-killer [ a GPL one :) ]. I aggree, and for now, it's Eric3, AND it can be compiled run under windows, without Cygwin. Ok, it's not exactly a VB-Killer, but it's the closest thing for now. VB has it's drawbacks, but can you image the how much more acceptance python would get, if we had *more* a VB-like designer, for multiple GUI toolkits, no less? -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Big development in the GUI realm
Courageous [EMAIL PROTECTED] wrote: It should also be pointed out that the FSF's interpretation of the GPL with respect to Qt means absolutely zero. Indeed. It would be the court that would have to decide what the language of the GPL means, given the substantial body of case law as the court sees it. ... but it establishes that you *knew* what their interpretation ... But it doesn't. They'd really need to put it into their license expressly. Indeed. The GPL itself says: The precise terms and conditions for copying, distribution and modification follow. ... END OF TERMS AND CONDITIONS It's what is between those sentences which counts when to comes to governing the use of the covered software. There is no mention of And also see the FAQs on the GPL on the FSF Web site to understand what we really mean by the GPL. Tim C -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
Francis Girard wrote: [I wrote:] In any case, he may be right, and the FSF, Trolltech, and you could all be wrong. Your intention when you use the GPL may be moot if a judge determines that the text itself and copyright law does not support your interpretation. I'm sorry to jump into this thread without any knowledge of these issues. I was just wondering if it did happen. Did some law court, over the past decade, had to make a decision about GPL on some real issue ? Not about this issue, I don't believe. There was some flap between MySQL AB and NuSphere Corporation concerning *static* linking, but that case was settled before the judge ruled on whether static linking creates a derivative work[1]. Larry Rosen's book _Open Source Licensing_ covers these issues (and their lack of case law) pretty thoroughly[2]. [1] http://www.mysql.com/news-and-events/press-release/release_2002_14.html [2] http://www.rosenlaw.com/oslbook.htm -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
Robert Kern wrote: Believe me, I share your frustration every time this issue comes up. However, I think it's best to follow Robert Heinlein's maxim: Never attribute to malice what can adequately be explained by stupidity. that's Hanlon, not Heinlein. to be on the safe side, I won't attempt to attribute your mistake to anything. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
Robert Kern [EMAIL PROTECTED] said : that's Hanlon, not Heinlein. to be on the safe side, I won't attempt to attribute your mistake to anything. Fair enough. The only time I've seen it in dead-tree print was in Heinlein's _Time Enough For Love_, unattributed to anyone else. Googlespace seems to be not entirely sure whether Hanlon is real or is a corruption of Heinlein. Googling for quote attributions is a tricky proposition at best, though. I don't know who Mr Hanlon is, but I've previously seen it attributed to Napoleon Buonaparte. Never been able to verify that either, though. -- YAFAP : http://www.multimania.com/fredp/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
Robert Kern wrote: Fair enough. The only time I've seen it in dead-tree print was in Heinlein's _Time Enough For Love_, unattributed to anyone else. if that's true, it would seem that it predates the Hanlon reference by a couple of years: http://www.statusq.org/archives/2001/12/04 on the other hand, Google tells me that Time Enough For Love con- tains a couple of other famous stupidity quotes, including: Never underestimate the power of human stupidity do you still have a copy of the book? (preferrably a version printed before 1980...) /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
On Tue, 8 Feb 2005 10:01:51 +0100, Fredrik Lundh [EMAIL PROTECTED] wrote: except that if *you* set things up so the code is combined when run, *you* are copying, distributing, and/or modifying the program in order to mix, include and/or combine your work with the GPL:ed work. if you leave all that to the user, you're clear. Mmm... I'm not playing games here, no matter what some seem to think. It's obvious that the GPL doesn't say precisely whether it's OK to use an _independent_ library or EXE, ie. a file that is physically different from the calling EXE, as oppposed to either copy/pasting the code as is into a program, or statically linking a library into an EXE. Until now, I understood the GPL to be a way to make sure no one stole code (hence, no static linking or copy/pasting code), and with or without giving back any change they made. OTOH, I though it was OK to use the by code shipping whatever standard binary file was downloaded from the project's site, ie. MYEXE.EXE calling YOURCODE.DLL was OK, when this code was the standard version, untampered, and clearly indicated as not the EXE's work (as shown by the file name and version infos). Hence, either the GPL was not precise enough, or TrollTech should use a different license that specifically prohibits even using Qt through dynamic linking. Conclusion from what I read above: As of now, no court in any country has settled this issue by specifying whether making use of a GPLed program _in any way_ requires the calling program to be GPLed as well, or if there are cases where the EXE can remain closed-source. I'm fine with TT's intentions, though. Joe (no, I don't want whatever stuff I post on the Net to possibly bite me years from now, hence the anonymous posting. Nothing personal.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
Fredrik Lundh wrote: Robert Kern wrote: Fair enough. The only time I've seen it in dead-tree print was in Heinlein's _Time Enough For Love_, unattributed to anyone else. Amazon.com search inside the book finds no hits for malice in this book. http://www.amazon.com/gp/reader/0441810764/102-7636110-6481700?v=search-insidekeywords=malice if that's true, it would seem that it predates the Hanlon reference by a couple of years: http://www.statusq.org/archives/2001/12/04 on the other hand, Google tells me that Time Enough For Love con- tains a couple of other famous stupidity quotes, including: Never underestimate the power of human stupidity Search inside the book finds this *twice* in Time Enough For Love. Kent -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
users. For example, from their FAQ, it seems that no precompiled binaries will be provided. Support for comercial compilers will not be built in, only for gcc (through Cygwin?). Isn't this just the same thing with a different spin. There was always an available distribution for linux for non-commercial use. Windows was always the problem. You still can't use it for windows without knowing how to compile the thing on windows. Well, if it's GPLed, can't i simply compile it and distribute a GPLed .DLL with the source code for everyone? -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
Tim Churches wrote: except that if *you* set things up so the code is combined when run, *you* are copying, distributing, and/or modifying the program in order to mix, include and/or combine your work with the GPL:ed work. if you leave all that to the user, you're clear. Yes, that is what I, and others, have been saying, and doing, all along. Our Mozilla Public Licensed Python application imports (but contains no code from) a GPLed third-party Python module at runtime, but we don't distribute that module, we just tell users to obtain it independently and install it on their systems. does your program work (in any way) without this module? (relying on word games is a lousy legal strategy in most parts of the world) (Gee, I thought that word games were the entire basis of much legal endeavour in most parts of the world. Patent specifications in particular spring to mind.) yeah, but you shouldn't base your entire game on a specific word play. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
On Tue, 08 Feb 2005 19:55:01 +0100, Maciej Mrz wrote: Unfortunately, GPL faq is extremely vague on such border cases, instead of simple yes/no answers faq is filled with some advocacy talks ... To re-iterate a point I made on a thread last week, nobody really knows what the GPL says and means on this topic. We can *barely* outline our ignorance, but even our ignorance is pretty fuzzy. Copyright-based models can't handle modern computer programs, and the GPL is still copyright-based. As such, it is hosed. (For an expansion of that idea, see http://www.jerf.org/writings/communicationEthics/node7.html ; note the next chapter tries to solve this problem in the context of more conventional communication, but even with my refinements I'm *still* not sure how to handle something like the GPL reasonably. I think you'd have to re-define what the GPL covers almost from scratch; I think it could be done, but I'm not sure you can fully rationally create an LGPL that doesn't have critical exceptions.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
However, imagine simple situation: 1. I write proprietary program with open plugin api. I even make the api itself public domain. Program works by itself, does not contain any GPL-ed code. 2. Later someone writes plugin using the api (which is public domain so is GPL compatible), plugin gets loaded into my software, significantly affecting its functionality (UI, operations, file formats, whatever). 3. Someone downloads the plugin and loads it into my program I don't think it is legal to distribute the plugin in binary form. OTOH it should be legal to distribute it as source code. Am I bound by GPL? Certainly not, I did not sign or agree to it in way. correct -- damjan -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
Fredrik Lundh wrote: Tim Churches wrote: except that if *you* set things up so the code is combined when run, *you* are copying, distributing, and/or modifying the program in order to mix, include and/or combine your work with the GPL:ed work. if you leave all that to the user, you're clear. Yes, that is what I, and others, have been saying, and doing, all along. Our Mozilla Public Licensed Python application imports (but contains no code from) a GPLed third-party Python module at runtime, but we don't distribute that module, we just tell users to obtain it independently and install it on their systems. does your program work (in any way) without this module? Yes. Tim C -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
Maciej Mróz wrote: However, imagine simple situation: 1. I write proprietary program with open plugin api. I even make the api itself public domain. Program works by itself, does not contain any GPL-ed code. 2. Later someone writes plugin using the api (which is public domain so is GPL compatible), plugin gets loaded into my software, significantly affecting its functionality (UI, operations, file formats, whatever). 3. Someone downloads the plugin and loads it into my program I believe that in this case, the key is *distribution*. You are not violating the GPL, because you are not distributing a program that is derived (according to the GPL's definition of derived) from GPL code. The plugin author *is* distributing GPL-derived code, but is doing so under a GPL license. That's fine too. The end user is now linking (dynamically) GPL code with your proprietary code. However, he is *not* distributing the linked assemblage. This is allowed under the GPL; its terms only apply when distribution takes place. If the end user is a repackager, and then turns around and distributes both sets of code together, then that would (potentially) violate GPL terms. But as long as they're not distributed together, then it's okay. This should even extend to distributing a basic (proprietary) plugin and including a document describing where how to get the more-featureful GPL replacement plugin. (Distributing both programs as separate packages on a single installation medium would be a tricky edge case. I suspect it *could* be done in a GPL-acceptable way, but one would need to take care about it.) Of course, this is only my own personal interpretation and opinion -- IANAL, TINLA, YMMV, etc, etc. Jeff Shannon Technician/Programmer Credit International -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
However, imagine simple situation: 1. I write proprietary program with open plugin api. I even make the api itself public domain. Program works by itself, does not contain any GPL-ed code. No need to continue. You write something that uses a plugin, Eolas sues you. Don't have to mind about trolltech -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
On Tue, Feb 08, 2005 at 09:19:58PM -0200, Gabriel B. wrote: However, imagine simple situation: 1. I write proprietary program with open plugin api. I even make the api itself public domain. Program works by itself, does not contain any GPL-ed code. No need to continue. You write something that uses a plugin, Eolas sues you. Don't have to mind about trolltech not if you live in a sane country. -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Preserve wildlife -- pickle a squirrel today! signature.asc Description: Digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
Kent Johnson wrote: Fredrik Lundh wrote: Robert Kern wrote: Fair enough. The only time I've seen it in dead-tree print was in Heinlein's _Time Enough For Love_, unattributed to anyone else. Amazon.com search inside the book finds no hits for malice in this book. http://www.amazon.com/gp/reader/0441810764/102-7636110-6481700?v=search-insidekeywords=malice Hooray for technology! In that case, I have no idea why I thought it was from Heinlein. The similar quote[1] that *is* from Heinlein, but an entirely different formulation, is from Logic of Empire, which I know I have not read. [1] http://en.wikipedia.org/wiki/Hanlon's_Razor -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
On Monday 07 February 2005 17:52, RM wrote: For all you GUI developers, things just got a little more interesting. Trolltech will soon be offering the QT GUI toolkit for Windows under the GPL license. That means that PyQt may become a much more popular option in the near future. Unfortunately, some things available for the commercial customers of Trolltech are not available to the GPL users. For example, from their FAQ, it seems that no precompiled binaries will be provided. Support for comercial compilers will not be built in, only for gcc (through Cygwin?). Also, their database drivers will not be available. Oh, well, I guess you can't have it all. Good news though! See more here: www.trolltech.com I wonder how this is going to affect the GUI landscape. Not 100% right. Only drivers for commercial databases will not be included, mysql and co. are available. -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
On Mon, 7 Feb 2005 19:41:11 +0100, Fredrik Lundh [EMAIL PROTECTED] wrote: Am I totally off-target? yes. for details, see the Combining work with code released under the GPL section on this page: Mmmm.. The FAQ isn't very clear about whether it's allowed to write a proprietary EXE that calls a GPLed DLL: However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and non-free programs communicate at arms length, that they are not combined in a way that would make them effectively a single program. The difference between this and incorporating the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing. Considering the fact that the Qt DLL exist by themselves, that the version used is the one provided by Qt, and that the EXE uses a standard, open way to communicate with it, the above does seem to say this use would be valid. Anybody knows of a similar case and the output? Luke. -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
Luke Skywalker wrote: Considering the fact that the Qt DLL exist by themselves, that the version used is the one provided by Qt, and that the EXE uses a standard, open way to communicate with it, the above does seem to say this use would be valid. http://www.gnu.org/licenses/gpl-faq.html#MereAggregation /.../ If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program. By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
On 2005-02-07, Luke Skywalker [EMAIL PROTECTED] wrote: On Mon, 7 Feb 2005 19:41:11 +0100, Fredrik Lundh [EMAIL PROTECTED] wrote: Am I totally off-target? yes. for details, see the Combining work with code released under the GPL section on this page: Mmmm.. The FAQ isn't very clear about whether it's allowed to write a proprietary EXE that calls a GPLed DLL: Yes it is allowed. You are always allowed to write proprietary programs that incorporate GPL code. What you are not allowed to do is distribute those programs under a license that's not the GPL. Considering the fact that the Qt DLL exist by themselves, that the version used is the one provided by Qt, and that the EXE uses a standard, open way to communicate with it, the above does seem to say this use would be valid. Anybody knows of a similar case and the output? My understanding is that what you propose is not valid. An EXE that uses a GPL'd DLL must be distributed according to the terms of the GPL. Were that not the case, the LGPL would not have been needed. -- Grant Edwards grante Yow! Yow! Maybe I should at have asked for my Neutron visi.comBomb in PAISLEY-- -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
Fredrik Lundh wrote: Luke Skywalker wrote: Considering the fact that the Qt DLL exist by themselves, that the version used is the one provided by Qt, and that the EXE uses a standard, open way to communicate with it, the above does seem to say this use would be valid. http://www.gnu.org/licenses/gpl-faq.html#MereAggregation /.../ If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program. By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program. /F Yes, that is what the FSF GPL FAQ says. However, the GPL itself says: [Section 0] Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. There is not, AFAICS, any formal definition of what is meant by modification in the GPL. Section 2.b of the GPL says: b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. and Section 2 goes on to say: These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it seems to me, and to the expert legal advice which we sought (note the scope of the advice was Australian law only) that provided no GLPed source or object code is mixed, included or combined with non-GPLed code, and that the GPLed and non-GPLed code are distributed or otherwise made available in packages which are very clearly separate works, and that any interaction between the two is restricted to runtime, then the GPL does not require that non-GPLed code to be distributed under the GPL. It is arguable whether that opinion is at odds with the sentiments expressed in the FSF GPL FAQ - it depends whether importing two python modules into the same namespace is considered equivalent to, as the FAQ says, run linked together in a shared address space, but ultimately, it is what the GPL license text says, not what the FSF FAQ says, which matters. Note that I am not in favour of or advocating any attempt to circumvent or undermine the GPL. I just think it is important to be guided by what software licenses actually say, rather than by what the authors of the licenses wished they had said in retrospect. Tim C -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
For all you GUI developers, things just got a little more interesting. Trolltech will soon be offering the QT GUI toolkit for Windows under the GPL license. That means that PyQt may become a much more popular option in the near future. This applies to QT-4 only. I wonder how much of PyQT is ready for QT4? Anyway its time for a PyQT based VB-killer [ a GPL one :) ]. -- damjan -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
Luke Skywalker wrote: On Mon, 7 Feb 2005 18:30:18 +0100, Michael Goettsche. [EMAIL PROTECTED] wrote: Not 100% right. Only drivers for commercial databases will not be included, mysql and co. are available. What I find weird, is that I always understood the GPL meaning that you must give back any contribution you made to the source code of the GPLed code, but not if you're just using either a binary distribution (eg. a DLL) or if you copy/pasted the code as is, with no changes on your own. If this is true, then the fact that Qt is now GPLed for Windows means that I should be able to use this widget set even in commercial apps since I'm not making any change to Qt, just using it. Am I totally off-target? Yes. The GPL only dictates what you *must* do when you re-distribute GPL'd code, or code derived from GPL'd code - and there's substantial room for disagreement about what is and what is';t a derived product, with a recent opinion suggesting that the FSF would regard importing a GPL'd Python module as making your Python program constitute a derived product. As long as you don't redistribute anything you are free to do whatever you want with GPL'd code. The intent of the license is essentially to stop proprietary freeloaders from benefiting from GPL'd code without giving anything back to the community. Microsoft choose to call this viral, but as usual they are talking out of their wallet. regards Steve -- Meet the Python developers and your c.l.py favorites March 23-25 Come to PyCon DC 2005 http://www.pycon.org/ Steve Holden http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
RM wrote: For all you GUI developers, things just got a little more interesting. Trolltech will soon be offering the QT GUI toolkit for Windows under the GPL license. That means that PyQt may become a much more popular option in the near future. Unfortunately, some things available for the commercial customers of Trolltech are not available to the GPL users. For example, from their FAQ, it seems that no precompiled binaries will be provided. Support for comercial compilers will not be built in, only for gcc (through Cygwin?). Isn't this just the same thing with a different spin. There was always an available distribution for linux for non-commercial use. Windows was always the problem. You still can't use it for windows without knowing how to compile the thing on windows. huy -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
Is there a GPL for Dummies out there??? :-) Sorry if I am asking a question that has already been asked/answered in another form. In any case, let's say I use Python to create an application that uses some module that is GPL. So what are my options? 1. Distribute my app as closed source but with source, available upon request and clearly stated so in my license, for the GPL'ed module. But the code to my app only is not available as it is closed source. 2. Distribute my app with the source code available upon request, along with the code of any other GPL'ed modules that my app uses. I don't know if any other option is possible. Do my stated options cover the possibilities and if so, which of these are the correct legal one that I would follow? Thanks, -Kartic -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
On Tue, 08 Feb 2005 07:57:51 +1100, Tim Churches [EMAIL PROTECTED] wrote: Thus, it seems to me, and to the expert legal advice which we sought (note the scope of the advice was Australian law only) that provided no GLPed source or object code is mixed, included or combined with non-GPLed code, and that the GPLed and non-GPLed code are distributed or otherwise made available in packages which are very clearly separate works, and that any interaction between the two is restricted to runtime, then the GPL does not require that non-GPLed code to be distributed under the GPL. That's how I understood things, ie. calling a standard, clearly independent (ie. EXE or DLL) binary downloaded from the project's web site and just calling it is not covered by the GPL since no change has been made whatsoever to the original work. Which makes sense, since the goal of the GPL is to make sure that no one can steal the code, correct bugs or add features without redistributing those changes. Muddy waters, indeed :-) Luke. -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
Tim Churches wrote: Thus, it seems to me, and to the expert legal advice which we sought (note the scope of the advice was Australian law only) that provided no GLPed source or object code is mixed, included or combined with non-GPLed code and how exactly are you going to load a DLL from an EXE file with- out mixing, including, or combining the two? I don't see how the legal advice you got is incompatible with the FAQ; they both say that as long as you keep things separate, you're in the clear. but as soon as you mix things, the GPL applies. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Big development in the GUI realm
Fredrik Lundh [EMAIL PROTECTED] wrote:
Tim Churches wrote:
Thus, it seems to me, and to the expert legal advice which we sought
(note the scope of the advice
was Australian law only) that provided no GLPed source or object code
is mixed, included or
combined with non-GPLed code
and how exactly are you going to load a DLL from an EXE file with-
out mixing, including, or combining the two?
You can't, but as long as that mixing, including, or combining only occurs at
runtime,
the GPL itself specifically says that is out of scope and the GPL does not
apply. Their
words, not mine - to quote (yet again):
Activities other than copying, distribution and modification are not covered
by this
License; they are outside its scope. The act of running the Program is not
restricted,...
No argument from me that combination of source code or static linking is
covered by
the GPL, but runtime(-only) linking of two programmes which do not share any
code
and which are distributed as clear separate packages would seem to be out of
scope
of the GPL. Note that deeming the making of runtime calls on a GPLed library
as modification of that GPLed library would be drawing a very long bow
indeed, given
that elsewhere in the GPL it says (as included commentary):
Thus, it is not the intent of this section to claim rights or contest your
rights to work
written entirely by you; rather, the intent is to exercise the right to control
the
distribution of derivative or collective works based on the Program.
Now, I concede that the use of the adjective collective in the above
commentary does
make things even less clear. However, Section 0 of the GPL specifically defines
what
is meant by a work based on the {GPLed] Program, to wit:
The 'Program', below, refers to any such program or work, and a 'work based on
the
Program' means either the Program or any derivative work under copyright law:
that is
to say, a work containing the Program or a portion of it, either verbatim or
with
modifications and/or translated into another language.
So there you have it: there must be some portion of the GPLed Program contained
in
the other work for it to fall under the scope of the GPL, and/or as defined as
a
derivative work in local copyright law (local because the GPL does not nominate
a
particular jurisdiction for covering law).
Clear as mud.
Tim C
--
http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
Isn't this just the same thing with a different spin. There was always an available distribution for linux for non-commercial use. Windows was always the problem. You still can't use it for windows without knowing how to compile the thing on windows. There'll be people that know how to compile :), and they'll be able to release distibute binaries... Previously you couldn't even compile the GPL QT on windows, since it lacks the low-level win32 api calls that do all the work. -- damjan -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
On Tue, 08 Feb 2005 10:47:25 +1100, Tim Churches [EMAIL PROTECTED] wrote: So there you have it: there must be some portion of the GPLed Program contained in the other work for it to fall under the scope of the GPL, and/or as defined as a derivative work in local copyright law (local because the GPL does not nominate a particular jurisdiction for covering law). Has someone worked with Qt for Windows before, and could tell us whether it involves static or dynamic linking? If dynamic, then, it doesn't make sense that an EXE that builds on Qt should also be GPLed. Luke. -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Big development in the GUI realm
Luke Skywalker [EMAIL PROTECTED] wrote: On Tue, 08 Feb 2005 10:47:25 +1100, Tim Churches [EMAIL PROTECTED] wrote: So there you have it: there must be some portion of the GPLed Program contained in the other work for it to fall under the scope of the GPL, and/or as defined as a derivative work in local copyright law (local because the GPL does not nominate a particular jurisdiction for covering law). Has someone worked with Qt for Windows before, and could tell us whether it involves static or dynamic linking? If dynamic, then, it doesn't make sense that an EXE that builds on Qt should also be GPLed. Well you do need to consider whether any headers or declarations from the GPLed library need to be included in the source code of your non-GPLed programme - if so, then the latter also needs to be GPLed (if you distribute it to thers). There is also the issue of whether you can directly include the names of the functions being called from the GPLed library (and the signatures of those functions) in your non-GPLed programme without your programme then being considered a derivative work. This comes back to the definition of derivative work, which I understands differs in different national copyright laws. One commonly adopted tactic is to write a dual-licensed wrapper around the GPLed library. I am unable to comment on whether that is a legally sound or morally justifiable strategy. Tim C -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
Kartic schreef: In any case, let's say I use Python to create an application that uses some module that is GPL. So what are my options? For your own personal use: doesn't mather. If you want to distribute it, your application must be GPL'ed, so *all* source code must be made available for those you distribute it to. -- JanC Be strict when sending and tolerant when receiving. RFC 1958 - Architectural Principles of the Internet - section 3.9 -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
If dynamic, then, it doesn't make sense that an EXE that builds on Qt should also be GPLed. I'm hoping you're referring to the owners choice of license. For example, if someone, owning rights to a thing that was a dynamic library, decided to have a license akin to the GPL, it would easily qualify. It's a question of /distribution/. If you copy parts of the work, and redestribute those copies, you are caught by the rule of law. After that the license is a matter of reduction to practice. C// -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
Luke Skywalker wrote: On Tue, 08 Feb 2005 10:47:25 +1100, Tim Churches [EMAIL PROTECTED] wrote: So there you have it: there must be some portion of the GPLed Program contained in the other work for it to fall under the scope of the GPL, and/or as defined as a derivative work in local copyright law (local because the GPL does not nominate a particular jurisdiction for covering law). Has someone worked with Qt for Windows before, and could tell us whether it involves static or dynamic linking? If dynamic, then, it doesn't make sense that an EXE that builds on Qt should also be GPLed. *shrug* To my knowledge, no court has ruled either way on the issue. The FSF holds the position that the new program *should* have a GPL-compatible license and that the GPL terms hold for the program as a whole. Trolltech also holds this position, I believe (and this is the important point if you want to avoid being sued, regardless of how a court would decide). Now, that's not to say that they are correct in their interpretation of the GPL's terms. In fact, if I had to bet on an outcome, I'd probably wager that the court would hold that only static linking would force the program as a whole to follow the GPL terms. However, I certainly don't have the money to pony up to run a test case. Consequently, I try to follow the wishes of the copyright holder. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Big development in the GUI realm
Luke Skywalker [EMAIL PROTECTED] wrote: On Mon, 07 Feb 2005 17:47:30 -0800, Robert Kern [EMAIL PROTECTED] wrote: Now, that's not to say that they are correct in their interpretation of the GPL's terms. In fact, if I had to bet on an outcome, I'd probably wager that the court would hold that only static linking would force the program as a whole to follow the GPL terms. However, I certainly don't have the money to pony up to run a test case. Consequently, I try to follow the wishes of the copyright holder. It's strange that something so central hasn't been clarified yet, but maybe it's part of the changes meant for V.3. When you think about it, it'd be like banning any closed-source apps from being developed for Linux, since any application makes syscalls to the kernel and its libraries. But the fact is that there are now closed-source apps for that platform, and are considered legit since those apps don't include code from the kernel, but instead, merely make calls to binary objects. I fail to see the difference between making calls to the kernel API and making calls to Qt libraries. The COPYING file for the Linux kernel includes this note: Linux main COPYING: : NOTE! This copyright does *not* cover user programs that use kernel : services by normal system calls - this is merely considered normal use : of the kernel, and does *not* fall under the heading of derived work. : Also note that the GPL below is copyrighted by the Free Software : Foundation, but the instance of code that it refers to (the Linux : kernel) is copyrighted by me and others who actually wrote it. : : Also note that the only valid version of the GPL as far as the kernel : is concerned is _this_ particular version of the license (ie v2, not : v2.2 or v3.x or whatever), unless explicitly otherwise stated. : : Linus Torvalds Tim C Luke. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
On 2005-02-08, Luke Skywalker [EMAIL PROTECTED] wrote: Now, that's not to say that they are correct in their interpretation of the GPL's terms. In fact, if I had to bet on an outcome, I'd probably wager that the court would hold that only static linking would force the program as a whole to follow the GPL terms. However, I certainly don't have the money to pony up to run a test case. Consequently, I try to follow the wishes of the copyright holder. It's strange that something so central hasn't been clarified yet, but maybe it's part of the changes meant for V.3. It's been made quite clear what the intention of the FSF is in regard to static linking. Trolltech also made their intentions crystal clear. When you think about it, it'd be like banning any closed-source apps from being developed for Linux, since any application makes syscalls to the kernel Wrong. The kernel license _explicitly_ allows non GPL'd programs to make calles via the published syscall API. and its libraries. Wrong again. First, the kernel does own any libraries. Second, the libraries to which you refer are under the LGPL and other licenses which explicitly allows distribution of non-GPL'd programs that are linked dynamically with the libraries. But the fact is Fact? You seem to be very short on facts and are mostly just making up shit as you go. that there are now closed-source apps for that platform, and are considered legit since those apps don't include code from the kernel, but instead, merely make calls to binary objects. True, but moot. I fail to see the difference between making calls to the kernel API and making calls to Qt libraries. BECAUSE IN THE KERNEL KERNEL COPYING FILE LINUS SAYS: NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of derived work. Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the Linux kernel) is copyrighted by me and others who actually wrote it. AND TROLLTECH SAYS: Users who want to donate their source code to the Open Source community can use the Open Source version and must license their software under the GPL. Users who write commercial proprietary software must purchase a license and may freely choose how to license and profit from their software. Spare us your clueless, junior-high legal analyses and just do what's right: obey the wishes of the owners of the copyrights in question. They've made their intentions 100% clear, and if you try to worm your way around them, you're dishonorable, theiving scum. -- Grant Edwards grante Yow! I know things about at TROY DONAHUE that can't visi.comeven be PRINTED!! -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
On Tue, 08 Feb 2005 13:24:35 +1100, Tim Churches [EMAIL PROTECTED] wrote: : NOTE! This copyright does *not* cover user programs that use kernel : services by normal system calls - this is merely considered normal use : of the kernel, and does *not* fall under the heading of derived work. OK, so according to Linus, the GPL allows a proprietary program to make calls to the kernel, but TrollTech says the GPL doesn't allow a proprietary program to make calls to the Qt library. It's this double-standard that I find confusing, since both projects are said to be based on the same license. I wouldn't have any problem if Qt had built its own GPL-derived, custom license, but they claim it's the same ol' GPL. Hence the questioning. Luke. -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Big development in the GUI realm
Luke Skywalker [EMAIL PROTECTED] wrote: On Tue, 08 Feb 2005 13:24:35 +1100, Tim Churches [EMAIL PROTECTED] wrote: : NOTE! This copyright does *not* cover user programs that use kernel : services by normal system calls - this is merely considered normal use : of the kernel, and does *not* fall under the heading of derived work. OK, so according to Linus, the GPL allows a proprietary program to make calls to the kernel, but TrollTech says the GPL doesn't allow a proprietary program to make calls to the Qt library. No. Linus is providing a specific **extension** to the GPL which excludes calls to kernel services from the scope of the GPL. Whether he needs to do that is, as we have seen, debatable, but he is making the situation crystal clear. Tim C -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
On 2005-02-08, Robert Kern [EMAIL PROTECTED] wrote: Grant Edwards wrote: Spare us your clueless, junior-high legal analyses [etc.] Hey! There's no need for name-calling. This is a tricky legal area that can be very confusing even to the most legal-minded of us. While I think Luke is incorrect in several respects and is somewhat uninformed about others, he doesn't deserve this vitriol. Sorry if I was a bit blunt, but I'm sick of people trying to weasle their way around a license by creative interpretation of the license terms when the licensors made their intentions as clear as possible. I've released software under the GPL, and I really pisses me off when I see people trying to violate the spirit and intent of the license becuase they want to use GPL'ed software but they don't want to abide by the terms of the license. If you want to use one of my libraries that's under the GPL and you don't want to release your source code, then do the right thing: 1) Release your code under the GPL. 2) Write your own library. 3) Ask me to let you use it under the LGPL or a different license. [I've agreed everytime the request has been made.] I've got no patience at all for people who sit around playing word games and coming up with bad analogies to try to justify using somebody else's software without author's permission. I don't _care_ why somebody thinks they should be able to use Trolltech's software for a non-GPL'ed program without paying for it when Trolltech has stated explicitly that they're not allowed to do that. -- Grant Edwards grante Yow! I'm DESPONDENT... I at hope there's something visi.comDEEP-FRIED under this miniature DOMED STADIUM... -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
Grant Edwards wrote: Sorry if I was a bit blunt, but I'm sick of people trying to weasle their way around a license by creative interpretation of the license terms when the licensors made their intentions as clear as possible. Believe me, I share your frustration every time this issue comes up. However, I think it's best to follow Robert Heinlein's maxim: Never attribute to malice what can adequately be explained by stupidity. And I think we can also replace the word stupidity with ignorance if you like. It seems to me that Luke is confused and ignorant. He has shown no indication that he intends to write proprietary software using Qt. In any case, he may be right, and the FSF, Trolltech, and you could all be wrong. Your intention when you use the GPL may be moot if a judge determines that the text itself and copyright law does not support your interpretation. I think that it is almost always best to obey the intentions of the copyright holder and to ask for clarification when it is unclear. On the other hand, if the copyright holder is *clearly* off-base with his interpretation (and to me this would require actual case law, not just the opinion of a lawyer), then I might consider disregarding the author's interpretation and going with what case law and my lawyer suggests. I don't believe that this situation holds with respect to this issue, of course. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
OK, so according to Linus, the GPL allows No. Pay attention. Linus has his own revised version, to clarify this point, and in fact /overruling/ the GPL if the point is clarified differently by RMS or others. That's the right of their community, it's /their/ code. make calls to the kernel, but TrollTech says the GPL doesn't allow a proprietary program to make calls to the Qt library. That's their prerogative, although TrollTech's authority as an /interpretational/ entity over the GPL means precisely zero. I wouldn't push this, though, unless you've got a big litigation budget. It's this double-standard that I find confusing, since both projects are said to be based on the same license. Linus doesn't use the GPL, he uses his GPL, version-whatever. Anyway, your safe bet: Follow the copyright holder's wishes. That's fair. After all, it's free, so they're doing you a damn big favor. C// -- http://mail.python.org/mailman/listinfo/python-list
