| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 3 | |
On Tuesday 16 October 2007 09:08:05 Konrad Rosenbaum wrote: > The only exception in which GPL allows linking of non-GPL-compatible > libraries is when the library is a system library -- these are libraries > (as the name implies) that are typically delivered together with the > operating system, ie.: libc, libm, on some Linux-distributions xlib and > openssl. > So to the original poster: do those hardware libs usually come with the > operating system you are developing for? Although I'm not the OP, am I the only one who feels this is a very hard question ? As most free OS's can be rolled 'on your own' one could MAKE it a system library. For example Intel's NPE library (Network Processor Engine), used by the NSLU2 project (and of course, the original Linksys firmware which is also GPL now). It has a click-through non-GPL compatible license. Now, you could always skip that library (and forfeit much of the features until a GPL replacement is available) or include it with a GPL exception. Thus, on OpenSLUG and other linux derivatives for the NSLU2 it can be said that the OS 'usually' comes with that library (the original firmware is even worse off - it has a separate deal for a NTFS library, which is absolutely and totally commercial, without the option to be reincorporated into other Linux projects). But if I accept that argument of usualness, I can always dream up a MathLinux, which has BLAS/LAPACK/openGL components as system libraries which leads me to... >If you link A to B and B to C then A and C still end up in the same process. The difference being that C does not necessarily know about A. Sticking to a Qt example to stay on topic, I was surprised to see that for example on my debian lenny linux system the parts of OSS Qt give the following: ldd /usr/lib/libQtOpenGL.so linux-gate.so.1 => (0xffffe000) libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb7e26000) libGL.so.1 => /usr/lib/libGL.so.1 (0xb7d90000) libQtGui.so.4 => /usr/lib/libQtGui.so.4 (0xb75fa000) ... libnvidia-tls.so.1 => /usr/lib/tls/libnvidia-tls.so.1 (0xb6545000) Upon inspection, this libnvidia-tls.so.1 turns out to be libnvidia-tls.so.100.14.11, which is part of the nvidia-glx package, which again most definitely is NOT GPL compatible (being in the non-free repository is a dead giveaway on itself :) 2.1.3 Limitations. No Reverse Engineering. Customer may not reverse engineer, decompile, or disassemble the SOFTWARE, nor attempt in any other manner to obtain the source code. This would be the... >If you write something completely by yourself and you give it away under >GPL, then you are free to add exemptions to the GPL that explicitly or >implicitly say something like "it is also allowed to link XYZ to this >application although it is not GPL-compatible". ...part, I guess (although I can't actually find that exception in the libqt4-dev license, but let's blame that on gremlins and not trolls :) then this gets confusing real quick... >If you link something that you did not write yourself and it is GPL then >you have to obey the terms of the GPL (as you have to obey the terms of >commercial licenses of software you use). One of those terms happens to be >that you cannot link anything that is not GPL-compatible, except for >system libraries. ...if someone singlehandedly writes a _GPL_ library that depends on _other_ "system libraries" (let that be for arguments sake a GTK+ library that has libati-tls linked to be on par with the Qt-nvidia dependency), and notes it as an exception (qualifying into the first category), that would leave me where if I want to link to both ? They are GPL, but their exceptions are likely mutually exclusive, and my code does not link directly to any closed source software (I might not even KNOW what code is linked up against, indirectly, A->B->C style, f.e. the nvidia dependency in libQtOpenGL). The question is thus rather if A links to C, and B links to C too, and C satisfies both A and B's requirements (being GPL), does B need to satisfy A's license requirements, too ? >In the case of Qt: you have the choice of buying a commercial license >which lets you do almost anything. Considering the state of proprietary libraries in the mentioned math segment, for me the question is not whether I would need a commercial license to develop using both these libs and Qt, but rather if I can ALSO release MY code under GPL (with exceptions if neccessary) that can _potentially_ be used with these libraries, or it must simply remain completely proprietary for a long time (which would be a shame, IMHO). All of this stricly IANAL (at all), just want to know what my options with Qt are. As I got roughly the same number of interpretations as the number of legal folks I talked to, I tend to respect the intent of the original author/entity most, in this case Trolltech (another reason to ask this here and not on debian-legal or fsf forum). -- [ signature omitted ]
Hi, [deleted lots of stuff that I'm definitely not qualified to answer, ask Prof. Moglen or someone else at SFLC] On Tuesday 16 October 2007, Attila Csipa wrote: > >In the case of Qt: you have the choice of buying a commercial license > >which lets you do almost anything. > > Considering the state of proprietary libraries in the mentioned math > segment, for me the question is not whether I would need a commercial > license to develop using both these libs and Qt, but rather if I can ALSO > release MY code under GPL (with exceptions if neccessary) that can > _potentially_ be used with these libraries, or it must simply remain > completely proprietary for a long time (which would be a shame, IMHO). still IANAL... If you've got a commercial Qt license you could (as far as I have understood that license) give away your parts of the code under GPL plus exceptions for the math and Qt libs. It is very tricky to formulate those exceptions in a way that allows a clean conversion to GPL in case those libs become available under a GPL compatible license, so better ask at SFLC how to do this in a legally clean way. (Alternatively put your source under MIT license, if you can live with the risk of someone else grabbing your source and commercializing it.) Konrad
Attachment:
Attachment:
pgpFMre7jTrtd.pgp
Attachment:
signature.asc
Attachment:
signature.asc
Attachment:
signature.asc
Description: PGP signature
Message 18 in thread
On Wednesday 17 October 2007 08:41:11 Konrad Rosenbaum wrote:
> If you've got a commercial Qt license you could (as far as I have
> understood that license) give away your parts of the code under GPL plus
> exceptions for the math and Qt libs. It is very tricky to formulate those
That is actually the problem. Let's say I've got the Qt commercial license and
decide to GPL my code. Then I would be able to release my project as GPL (or
BSD, etc, doesn't really matter), but that could be used by only other owners
of the Qt commercial license (you couldn't link it to the proprietary libs
because the GPL flavour of Qt forbids that) and cannot be linked to any other
GPL software (as the linked libs GPL forbids you to use the non-GPL parts, be
it Qt, lib, whatever is in my exception). That smells to one stillborn OSS
project to me :(
As many have noted, all this protection is probably written in the GPL to
protect the GPL code from proprietary code disguised as free, but it is
dawning on me it just as well protects proprietary software from quality GPL
code that could drive a wedge in the coder-proprietary lib relation and open
the way to quality GPL libraries (and communities, of course) :( Admittedly,
in my case the libs are a bit specific, as the community has no way of
replicating the libs with free alternatives from the outside (as the
intricate hardware knowledge required is NDA- and miscellaneous magic license
agreements-ridden).
--
[ signature omitted ]
Message 19 in thread
Em Wednesday 17 October 2007 14:01:08 Attila Csipa escreveu:
> As many have noted, all this protection is probably written in the GPL to
> protect the GPL code from proprietary code disguised as free, but it is
> dawning on me it just as well protects proprietary software from quality
> GPL code that could drive a wedge in the coder-proprietary lib relation and
> open the way to quality GPL libraries (and communities, of course) :(
Are you saying that this GPL protection prevents people from using quality GPL
libraries with partially-closed (or wholly-closed) source code?
If so, then you're right and it's even intentional. See
http://www.gnu.org/licenses/why-not-lgpl.html
For Richard Stallman's position on the issue. He's basically saying, "if you
write this new cool library, make it GPL so that people are forced to open up
their source code in order to use it". He's got his agenda, which is to make
all software open and free.
But Qt falls into that category: it's licensed GPL, so you can only use the
Open Source version of it if you make a fully GPL (open and free) software.
But, unlike the GNU programs, Qt is also available under a commercial license
if you can't (or won't) GPL your code.
--
[ signature omitted ]
Description: This is a digitally signed message part.
Message 20 in thread
Foreword: this might seem as a GPL discussion, but it isn't really, as the
premise for my question is the (not unique, but rare option of) dual
licenceability (is that even a word ?) of Qt in the first place.
On Wednesday 17 October 2007 14:48:40 Thiago Macieira wrote:
> Are you saying that this GPL protection prevents people from using quality
> GPL libraries with partially-closed (or wholly-closed) source code?
Not quite. As it is now, there ARE no quality libraries in the field I'm
talking about. You can attack this problem from two sides - one is making
quality GPL libraries (which would then force the commercial ones to open up
due to competition) - this is what you suggest here, right ? Unfortunately,
the mentioned lack of HW driven math libraries is no fault of OSS developers,
but rather the general unavailability of hardware documentation. Without it,
the reality is that you won't be able to write really cutting edge math libs
no matter how GPL dedicated you are and how big your coding genius is. So,
what I'm trying to do is to attack this monolith from the other side -
provide GPLd applications/middleware and solutions that make it easy to
switch AWAY from your current locked-in library whether it be GPL or not,
provided by vendor X or community Y. If you have the option of easily
migrating (not even without recompiles !) from Intel to AMD to NVidia to any
GPL alternative, you are lifting the bar for everybody in the field, and that
just might heaten the competition and thus result in GPL slowly infiltrating
the previously strictly proprietary area (or having dual licensing on those
libraries as well, why not?). Which is rougly the case in the next example
scenario:
>I can't answer that. First and foremost because I don't understand what
>you're asking for.
Example setup is as follows. I have a commercial license for Qt. I also have
(arguably system) libraries that are mostly pay-for-commercial-use,
free-as-in-beer-for-noncommercial-use. I make a commercial product with Qt
using these commercial libraries and all is well. I come up with a strange
idea that (standalone !) parts of my product might be interesting community
wise, too, and wish to release it under the GPL. It turns out that while I
can do this by linking to the GPL version of Qt, I'm unable to link on the
other side to the free-as-in-beer-for-personal-use libraries, which, as it
is, cannot be replicated as quality GPL libraries (due to NDA, licenses,
etc). Note that this would be via plugin functionality, so I'm not
redistributing these libs, nor forcing them (or my commercial product!) on
the user, merely enabling them to the user if they can fulfill the license
requirements on their own. Barring this leaves me with 2 separate releases
that are incompatible (on one side you have the commercial, hardware
accelerated product, and on the other, the bastardized, dumbed down GPL
variant, and to make things worse the two have minimal overlap in
functionality (except maybe for some BSD stuff)). I simply don't want the GPL
version to be dumbed down, so that it actually does have a chance to spread
(source only releases that force you through gazillion click-through licenses
have a very slim chance at that, especially in a non-Linux world) and put
pressure on the library developers to move closer to the GPL universe. So,
I'm not trying to sneak commercial in the GPL world, but rather the other way
round, sneak GPL in the proprietary chain. If you say don't/you can't do
that, I can live with that, too, everything remains just as propritary/free
as it was before, and (in my case) the possibility of free (all meanings)
high performance computation remains off-limits to the GPL universe for now
(shame).
>And most importantly because I can't make any such decision on
>TT's behalf.
Sure, I didn't think a mailing list is the place to make such decisions by any
single person, just as a concept question as it seemed to me that other
participants might be interested in that, too.
--
[ signature omitted ]
Message 21 in thread
Attila Csipa schrieb:
>> ...
>> In the case of Qt: you have the choice of buying a commercial license
>> which lets you do almost anything.
>
> Considering the state of proprietary libraries in the mentioned math segment,
> for me the question is not whether I would need a commercial license to
> develop using both these libs and Qt, but rather if I can ALSO release MY code
> under GPL (with exceptions if neccessary) that can _potentially_ be used with
> these libraries, or it must simply remain completely proprietary for a long
> time (which would be a shame, IMHO).
Disclaimer: IDWTBAL (I don't want to be a lawyer)
And that's exactly the right question here to ask (see my other thread
"Commercial Qt and OSS" which has been answered for me): the Qt
commercial license does allow you to do /almost/ anything, but not
/everything/.
When it comes to GPL'ing your code the commercial license is only half
the answer (and actually that is valid for /any/ commercial product, not
just Qt, but still this is a good place to discuss here, since there is
also an OSS version of Qt which makes things relevant).
Assume that you were using a commercial Qt feature, e.g. a "Qt solution"
which would be crucial to your application to link and compile (more
comments on this later in(*)). Now if you want to GPL *your* code based
on top of the commercial Qt you would have to make an "exception", as
stated several times.
Nod the devil is in the details: if you *also* want to link against
another GPL library then you are stuck! Since this other GPL library
does most likely *not* have this exception that "you may link against
the commercial Qt (solution)".
Hence you would need to find another license than GPL (does LGPL help
here? BSD-license? huh... so many licenses to choose from ;) ), because
GPL clearly does not allow you to restrict an already existing GPL (of
the other library you are linking to).
The conclusion in the other thread "Commercial Qt and OSS" was that you
want to make sure that your code compiles with the OSS Qt and you may
GPL your code without problems, also linking with any other GPL library.
This is rather an absurd side of the GPL which I have never really
thought of: you actually *want* to make *your* code free, but you cannot
put it under the GPL when you link against another closed source and
another GPL library.
(*) I had this concrete issue with a little "Icon editor" which used the
Qt solution "QtIcoFormatReader". Now I thought if I make the code
containing and linking to the QtIcoFormatReader a *plugin*, that is the
actual application code does *not* technically require it to build and
link, what happens in this case? Am I then allowed to put the
application code under GPL (which would link against Qt OSS) and state
"You can compile and link the application, but oh... when you actually
want to make it *useful* you need a commercial Qt and solution as to
build the plugin which writes the actual icons?"
This would be an interesting case. Especially the comment by Adam is
interesting here:
Adam M once wrote:
> * You may not write a GPL app and use proprietary plugins to provide most of functionality. If you do, I don't think it would take much convincing for the judge to see that you are violating GPL.
Cleary my closed source icon format plugin would provide "most
functionality". Now interpreting Adam's point: would I now be violating
the GPL when I put my other application code under GPL, publish source
and binaries of it and also publish a link to the closed source plugin
which would actually make the application usable?
Now this seems absurd to me, but according Adam's point that would be
correct, no?
I clearly see the intents of the GPL (not to pollute the "GPL space"
with "half-free" applications) but this leads to the absurd situation
that if I want to make *my* sources free (GPL) then I actually can't. ;)
Cheers, Oliver
--
[ signature omitted ]
Message 22 in thread
Em Wednesday 17 October 2007 09:22:08 Till Oliver Knoll escreveu:
> I clearly see the intents of the GPL (not to pollute the "GPL space"
> with "half-free" applications) but this leads to the absurd situation
> that if I want to make *my* sources free (GPL) then I actually can't. ;)
The idea behind this is to avoid the situation you referred to before:
Application is GPLed and using GPL libraries, but there's one tiny piece of
GPL-incompatible software that binds everything together and makes it useful.
Under the GPL, you're not allowed to *ship* that application. But you can
make your source code available.
The reason for that is to take it to the other extreme: application is a very
small GPLed source code that links to GPL libraries but loads a huge
GPL-incompatible "plugin" where all the logic is. Obviously, in this case,
the small GPLed application doesn't do *anything* useful. You'd be using
a "loop hole" to write closed-source applications and use GPL libraries.
So this hole has been closed: if you want to ship your application in binary
form, you must provide the sources (in the format preferred for making
modifications to it) for all components, except system libraries.
[And under the GPLv3, you must also provide a way of replacing the existing
binary with the newly-compiled one on the device (the so-called
TiVo-article).]
But you can still publish your source code, even if it doesn't compile if you
don't have some third-party components. This is the situation where KDE 1.x
was in, when Qt 1.x wasn't licensed QPL or GPL.
--
[ signature omitted ]
Description: This is a digitally signed message part.
Message 23 in thread
Thiago Macieira schrieb:
> Em Wednesday 17 October 2007 09:22:08 Till Oliver Knoll escreveu:
>> I clearly see the intents of the GPL (not to pollute the "GPL space"
>> with "half-free" applications) but this leads to the absurd situation
>> that if I want to make *my* sources free (GPL) then I actually can't. ;)
>
> The idea behind this is to avoid the situation you referred to before:
>
> Application is GPLed and using GPL libraries, but there's one tiny piece of
> GPL-incompatible software that binds everything together and makes it useful.
> Under the GPL, you're not allowed to *ship* that application. But you can
> make your source code available.
You mean, I cannot ship (specific: put it on a web page for download)
the *binary* under the GPL (but under some other "take it or leave
it"-license), but I can (and have to) put my source code under GPL (and
make it available on the same web page)?
Or are you saying I must not even put the binary on the web page in case
I put my code under GPL (which I have to, when I link with other GPL
libs)? That would mean: I develop an application, I link to a
closed-source as well as a GPL library, I can publish *my* code (under
GPL, because I use another GPL library) and the GPL library code on a
web page but I cannot offer the binary on the web page, is that what
you mean?
>
> The reason for that is to take it to the other extreme: application is a very
> small GPLed source code that links to GPL libraries but loads a huge
> GPL-incompatible "plugin" where all the logic is. Obviously, in this case,
> the small GPLed application doesn't do *anything* useful. You'd be using
> a "loop hole" to write closed-source applications and use GPL libraries.
Yes, that makes perfectly sense - and so far I have always seen the GPL:
protect the work of others so that no one can exploit their work by
using it in his own closed-source software (and as you've mentioned
above, also by not mis-using the "plugin-loop hole".
But now that puts me in the absurd situation that I *want* to make my
sources available as much as possible (and off course also the binary
which can only be build with the closed source library), but obviously I
cannot ;)
Or simply put: I must not link to a closed source and another GPL'ed
library at the same time, because this prohibits to publish my work
(except if you meant in the first paragraph that I just cannot put the
*binary* under the GPL, but still I could put my sources under *GLP* and
publish both, but I'm not sure if this is what you meant).
>
> So this hole has been closed: if you want to ship your application in binary
> form, you must provide the sources (in the format preferred for making
> modifications to it) for all components, except system libraries.
So that would really mean: publish my sources under GPL yes, not publish
the binary at all, right? (Off course the sources would only be useful
if one has access to the closed-source library).
> [And under the GPLv3, you must also provide a way of replacing the existing
> binary with the newly-compiled one on the device (the so-called
> TiVo-article).]
Uh oh, so let's stick to v2 for now ;)
>
> But you can still publish your source code, even if it doesn't compile if you
> don't have some third-party components. This is the situation where KDE 1.x
> was in, when Qt 1.x wasn't licensed QPL or GPL.
But AFAIK KDE 1.x was distributed in binary form, no? So are you saying
that only the source was GPL'ed, but the binary was not, and that this
scenario is actually possible? Or did for example SuSE ship the KDE 1.x
binaries illegally? ;)
*confused*
Thanks, Oliver
--
[ signature omitted ]
Message 24 in thread
> But AFAIK KDE 1.x was distributed in binary form, no? So are you saying
> that only the source was GPL'ed, but the binary was not, and that this
> scenario is actually possible? Or did for example SuSE ship the KDE 1.x
> binaries illegally? ;)
>
> *confused*
I (topic starter) arleady feeling sorry for initiating such thread -:).
I find out many interesting things such as possibly illegality of KDE
1.x on SuSE
(another advantage of using Gentoo at home - they don't (usually)
distribute binaries) -:).
--
[ signature omitted ]
Message 25 in thread
On Wednesday 17 October 2007 10:14:55 Thiago Macieira wrote:
> You'd be using a > "loop hole" to write closed-source applications and use
> GPL libraries.
As a closing word (or rather question) on my part to Trolltech - would it be
possible, for accountable, registered, bona fide open source GPL projects (or
even registered Qt developers that wish to do dual licensing just as with Qt
itself !) to obtain a non-universal exception from Trolltech to make it
possible to link (or more precisely, distribute binaries linked) to
_precisely defined_ libraries that could/would be checked upon by Trolltech
if any suspicion of such loophole usage arises ?
--
[ signature omitted ]
Message 26 in thread
Em Wednesday 17 October 2007 14:13:25 Attila Csipa escreveu:
> On Wednesday 17 October 2007 10:14:55 Thiago Macieira wrote:
> > You'd be using a > "loop hole" to write closed-source applications and
> > use GPL libraries.
>
> As a closing word (or rather question) on my part to Trolltech - would it
> be possible, for accountable, registered, bona fide open source GPL
> projects (or even registered Qt developers that wish to do dual licensing
> just as with Qt itself !) to obtain a non-universal exception from
> Trolltech to make it possible to link (or more precisely, distribute
> binaries linked) to _precisely defined_ libraries that could/would be
> checked upon by Trolltech if any suspicion of such loophole usage arises ?
I can't answer that. First and foremost because I don't understand what you're
asking for. And most importantly because I can't make any such decision on
TT's behalf.
But I invite you to take a look at the GPL exception that appeared in Qt 4.3.1
and was updated in 4.3.2. It allows you to link to Qt code that isn't GPL
compatible, but is released under a number of known open source licenses.
In time: the GPL exception is an *optional* section of the GPL and it grants
you additional rights. So the licensing as GPL+exception is entirely GPL
compatible.
--
[ signature omitted ]
Description: This is a digitally signed message part.
Message 27 in thread
>
> Cleary my closed source icon format plugin would provide "most
> functionality". Now interpreting Adam's point: would I now be violating
> the GPL when I put my other application code under GPL, publish source
> and binaries of it and also publish a link to the closed source plugin
> which would actually make the application usable?
I'm aware about at least one application built in such way:Win4Lin Pro
use this scheme (using prop. dymaically loaded plugins to GPLed QEMU
core, plugins contains almost all functionality of Win4Lin Pro).They
don't use Qt though.
> I clearly see the intents of the GPL (not to pollute the "GPL space"
> with "half-free" applications) but this leads to the absurd situation
> that if I want to make *my* sources free (GPL) then I actually can't. ;)
Looks like intent here is to make developers fight for freedom of
those 'half-free' libs...-:(
--
[ signature omitted ]
Message 28 in thread
Hello all
Is there any direct way to create a tab widget which can also be docked.
(Dock + Tab) ????
thanks alot..
Ricky
--
[ signature omitted ]
Message 29 in thread
Quoting rohitj@xxxxxxxxxxxxxx:
> Hello all
>
> Is there any direct way to create a tab widget which can also be docked.
> (Dock + Tab) ????
>
> thanks alot..
> Ricky
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx
> with "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
Hi Ricky!
I guess QMainWindow::tabifyDockWidget() is what you need.This function
expects two QDockWidget as parameters and it tabs these two widgets.So
e.g. you just simply go through your previously created dock widgets
and then tabify each to the previous one.
Regards,
Greg
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
--
[ signature omitted ]
Message 30 in thread
That's why I asked this question for the first time.
Now for me it looks like it doesn't matter who is program and who is lib.
Copyleft virus is on march to world domination -:)
>
> >
> >
> >
> >
> > I thought the GPL was about applications that link TO a gpl application.
> A Qt application linking to another library if its BSD, closed, etc
> shouldn't matter because these are NOT derivatives of Qt.
> >
> > "system libs" such as glibc and family are usually LGPL and allow linking
> TO them from closed apps.
> >
> > the GPL would not allow a closed application to link to Qt. But a
> applicaion/library that has nothing to do with Qt cannot be a derivative
> work of Qt. So why couldn't you link to it? Just because you link to
> someone elses independant library doesn't mean that persons library has to
> become GPL.
> >
> > When talking about hardware drivers and linux, the linux kernel is GPL
> and the drivers link TO the GPL kernel. so the driver should be GPL.
> >
> >
> > I don't recall anything saying a GPL project could only link to other GPL
> projects. Only that if you Link to GPL, you have to be gpl. If you link to
> closed you need to be sure you don't violate your closed license. The
> closed doesn't have to become GPL.
> >
> >
> > right?
> > -- To unsubscribe - send a mail to
> qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the
> subject or the body. List archive and information:
> http://lists.trolltech.com/qt-interest/
>
>
>
p.s.in reality i dont understood why original SDK to which I want to link is
closed source at all -:(.
--
[ signature omitted ]