| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 3 | |
Hi, If I want to use Open-source version of Qt (and publish my sources under GPL) and some libs to which I haven't sources (I can redistribute those 3rd party libs and their headers. They are basically compose driver to some specific hardware devices). Is it possible to use OSS Qt in such case? -- [ signature omitted ]
Hi, > If I want to use Open-source version of Qt (and publish my sources under > GPL) and some libs to which I haven't sources (I can redistribute those > 3rd party libs and their headers. They are basically compose driver to > some specific hardware devices). Is it possible to use OSS Qt in such > case? So you intend to link you program both to Qt (licensed under GPL) and to these 3rd party libraries? Then I'm afraid the answer is clearly no. If you're linking to Qt (licensed under the GPL) then the whole program must be redistributed under the GPL - which it can't if the libraries it links to are not available under the GPL license. You need a commercial license. -- [ signature omitted ]
On October 15, 2007 01:20:00 pm Dimitri wrote: > Hi, > > > If I want to use Open-source version of Qt (and publish my sources under > > GPL) and some libs to which I haven't sources (I can redistribute those > > 3rd party libs and their headers. They are basically compose driver to > > some specific hardware devices). Is it possible to use OSS Qt in such > > case? > > So you intend to link you program both to Qt (licensed under GPL) and to > these 3rd party libraries? Then I'm afraid the answer is clearly no. If > you're linking to Qt (licensed under the GPL) then the whole program must > be redistributed under the GPL - which it can't if the libraries it links > to are not available under the GPL license. > > You need a commercial license. Dimitri's point is valid but you are also free to use GPL-compatible components. LGPL, public domain, and there are a number of other compatible licenses. Sounds like this is not the case here, though. -- [ signature omitted ]
Dimitri <dimitri@xxxxxxxxxxxxx> wrote on 10/15/2007 01:20:00 PM: # So you intend to link you program both to Qt (licensed under GPL) # and to these 3rd party libraries? Then I'm afraid the answer is # clearly no. If you're linking to Qt (licensed under the GPL) then # the whole program must be redistributed under the GPL - which it # can't if the libraries it links to are not available under the # GPL license. IANAL - far from it - but this is true even for dynamic linking? I'm asking genuinely; I've never seen that particular scenario (GPL software dynamically linking to non-GPL'ed libraries) discussed. Wouldn't that cause issues for (e.g.) MPlayer, which is GPL and can use Win32 binary codecs? -- [ signature omitted ]
Quoting Gordon.Schumacher@xxxxxxxxxxx: > Dimitri <dimitri@xxxxxxxxxxxxx> wrote on 10/15/2007 01:20:00 PM: > > # So you intend to link you program both to Qt (licensed under GPL) > # and to these 3rd party libraries? Then I'm afraid the answer is > # clearly no. If you're linking to Qt (licensed under the GPL) then > # the whole program must be redistributed under the GPL - which it > # can't if the libraries it links to are not available under the > # GPL license. > > IANAL - far from it - but this is true even for dynamic linking? > > I'm asking genuinely; I've never seen that particular scenario > (GPL software dynamically linking to non-GPL'ed libraries) > discussed. > > Wouldn't that cause issues for (e.g.) MPlayer, which is GPL and > can use Win32 binary codecs? > Probably MPlayer dlopen's the codecs -- [ signature omitted ]
Pau Garcia i Quiles wrote: > Quoting Gordon.Schumacher@xxxxxxxxxxx: >> Wouldn't that cause issues for (e.g.) MPlayer, which is GPL and >> can use Win32 binary codecs? >> > > Probably MPlayer dlopen's the codecs That doesn't matter. "Linking" doesn't mean at-build-time or at-run-time or whatever. It just means one code uses another code. dlopen is just one method for linking. You may build and link any code with anything else, be it GPL or otherwise, you just cannot redistribute the built binary. GPL is a redistribution license for the source code not a EULA. For a long discussion(s) on this, you may view debian-legal mailing list. - Adam -- [ signature omitted ]
Dimitri wrote: > Hi, > >> If I want to use Open-source version of Qt (and publish my sources >> under GPL) and some libs to which I haven't sources (I can >> redistribute those 3rd party libs and their headers. They are >> basically compose driver to some specific hardware devices). Is it >> possible to use OSS Qt in such case? > > So you intend to link you program both to Qt (licensed under GPL) and to > these 3rd party libraries? Then I'm afraid the answer is clearly no. If He indicated the 3rd party non-GPL stuff is hardware interface driver. In this case, I think that depends whether the GPL software is inherently linked to the hardware in question or the hardware driver can be considered a "System Library". For example, if the GPL code (with Qt library) uses a common middle layer (like MIDI interface), then there is no problem with using GPL. But if GPL code is directly controlling the hardware, and hardware interface is not public, then one can argue that GPL is not being followed. But then how far does one go with the GPL enforcement? Can anyone distribute Qt because it links with non-free Windows API or OS X? Those are clearly not GPL compatible libraries. The muddy waters of GPL, - Adam PS. Keep in mind Dmitriy indicated that resulting application will be under GPL. Hence I think the litmus test is just if the close source library license allow the library to be redistributed (by end-user) and the GPL application re-linked or new ones created. If that is the case, one may argue that the close source library is just a system library (actually, more free than today's OS libraries) and may be used by GPL code. -- [ signature omitted ]
Hi, Adam M wrote: > He indicated the 3rd party non-GPL stuff is hardware interface driver. > In this case, I think that depends whether the GPL software is > inherently linked to the hardware in question or the hardware driver can > be considered a "System Library". Dmitriy, could you give some details on these 3rd party libraries? -- [ signature omitted ]
Hi, I wrote: > Dmitriy, could you give some details on these 3rd party libraries? I got some details in a private email. The DLL doesn't look like a "System library" to me. -- [ signature omitted ]
On Monday 15 October 2007 21:20:00 Dimitri wrote: > > If I want to use Open-source version of Qt (and publish my sources under > > GPL) and some libs to which I haven't sources (I can redistribute those > > 3rd party libs and their headers. They are basically compose driver to > > some specific hardware devices). Is it possible to use OSS Qt in such > > case? > > So you intend to link you program both to Qt (licensed under GPL) and to > these 3rd party libraries? Then I'm afraid the answer is clearly no. If > you're linking to Qt (licensed under the GPL) then the whole program must > be redistributed under the GPL - which it can't if the libraries it links > to are not available under the GPL license. > You need a commercial license. I'm a bit puzzled here... Does this mean that for example I cannot write any Qt based, GPL software that uses GPGPU, or say, NVidia CUDA, or libraries like Intel's MKL (math kernel library) or AMD's ACML (core math library) as they are not released under GPL compatible licenses (this would be a MAJOR setback in use of Qt in high-perfomance computing environments which happens to be my project ATM) ? > IANAL - far from it - but this is true even for dynamic linking? I highly (IANAL) doubt it, if it isn't, dancing around Qt GPL requirements is trivial - just hide your code in plugins and nobody could touch you. -- [ signature omitted ]
Attila Csipa wrote: > I'm a bit puzzled here... Does this mean that for example I cannot write any > Qt based, GPL software that uses GPGPU, or say, NVidia CUDA, or libraries > like Intel's MKL (math kernel library) or AMD's ACML (core math library) as > they are not released under GPL compatible licenses (this would be a MAJOR > setback in use of Qt in high-perfomance computing environments which happens > to be my project ATM) ? Yes you can use Qt GPL to write stuff. What you cannot do is write stuff with GPL license, link (static or dynamic, doesn't matter) and release under a non-GPL license. If you write apps that use libraries not considered a system library (eg. the MKL or ACML are not), then you just have to specify an exemption in your GPL such that the binaries may still be distributed. >> IANAL - far from it - but this is true even for dynamic linking? > > I highly (IANAL) doubt it, if it isn't, dancing around Qt GPL requirements is > trivial - just hide your code in plugins and nobody could touch you. Legal stuff is never white/black so one has to go to the *intent* of GPL. It is clear that the purpose of GPL is to allow free (GNU definition here), GPL software to be developed. Another purpose of GPL is to prevent proprietary, closed source software developers from using GPL in their application. That means, (my interpretation of GPL), * You *may* use Intel closed-source libraries in your GPL app that uses Qt provided you add an exemption that allows linking to Intel closed-source libraries. Intel libraries may be considered "system libraries". * You may *NOT* write a closed source library, then write a GPL app that uses Qt even if you write the exemption above. You have an obligation to release all the source code used in the application that you created under GPL compatible license. Hence you cannot close part of the application (libraries, once linked, are part of the application). * 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. The issue is whether you are trying to get a "free ride" on GPL. This was the case with software patents and hence GPLv3 (release code under GPL, but require people to pay royalties on patents on the GPL software). My advice for GPL, is treat is as any other software license. Don't push it too far. And when in doubt, ask the copyright holders (and your lawyers, if stuff is that important). Intent of what you are doing is as important, if not more so, than the actual method of linking. - Adam -- [ signature omitted ]
On Tuesday 16 October 2007 01:06:33 Adam M wrote: > write apps that use libraries not considered a system library (eg. the > MKL or ACML are not), then you just have to specify an exemption in your > GPL such that the binaries may still be distributed. > > The issue is whether you are trying to get a "free ride" on GPL. This > was the case with software patents and hence GPLv3 (release code under > GPL, but require people to pay royalties on patents on the GPL software). The idea is that, for example, by default GPL math libraries like ATLAS would be used, but at the same time, if a license is obtained for a free-as-in-beer or proprietary math library (like the MKL, ACML or CUDA) the user should be free to choose it (an openssl-like exception is fine, as there are no copyright issues with unknown contributors on my part), which makes the whole thing not unlike the situation with openGL and vendor specific implementations on linux (only with the BLAS/CLAPACK API) . -- [ signature omitted ]
On Tuesday 16 October 2007, Adam M wrote: > * You *may* use Intel closed-source libraries in your GPL app that > uses Qt provided you add an exemption that allows linking to Intel > closed-source libraries. Intel libraries may be considered "system > libraries". IANAL, but I think this is wrong: GPL+Exemption is not compatible with plain GPL, since GPL(v2) does not allow any additional restrictions (like the dependency on a proprietary library). Qt is under plain GPL, thus you cannot add any Exemption to code that links Qt. 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? Konrad
Attachment:
Attachment:
pgpUj5JbeifKN.pgp
Description: PGP signature
Message 14 in thread
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Konrad Rosenbaum wrote:
<blockquote cite="mid:200710160908.09422@xxxxxxxxxxxxxxxxxxxxxxx";
type="cite">
<pre wrap="">On Tuesday 16 October 2007, Adam M wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> * You *may* use Intel closed-source libraries in your GPL app that
uses Qt provided you add an exemption that allows linking to Intel
closed-source libraries. Intel libraries may be considered "system
libraries".
</pre>
</blockquote>
<pre wrap=""><!---->
IANAL, but I think this is wrong: GPL+Exemption is not compatible with plain
GPL, since GPL(v2) does not allow any additional restrictions (like the
dependency on a proprietary library). Qt is under plain GPL, thus you
cannot add any Exemption to code that links Qt.
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?
Konrad
</pre>
</blockquote>
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. <br>
<br>
"system libs" such as glibc and family are usually LGPL and allow
linking TO them from closed apps.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
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.<br>
<br>
<br>
right?<br>
</body>
</html>
--
[ signature omitted ]
Message 15 in thread
On Tue, October 16, 2007 10:15, Tom Bruno wrote:
> Konrad I thought the GPL was about
> applications that link TO a gpl application.
The GPL does not care whether it is an application, a library, a pluging,
a song, a manual or a droplet of water.
> A Qt application
> linking to another library if its BSD, closed, etc shouldn't
> matter because these are NOT derivatives of Qt.
It matters. GPL-compatible (everything that poses no more restrictions on
the user) is allowed, GPL-incompatible is not allowed.
> "system libs" such as glibc and family are usually LGPL and allow linking
> TO them from closed apps.
Actually: libc on MacOS, Solaris or whatever the equivalent on Win32 is
not LGPL. Yet you are allowed to link them because they are "system libs".
> 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.
If you link A to B and B to C then A and C still end up in the same process.
> 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.
Linus has a bit different view about that - talk to him about his
interpretation about what is allowed in the kernel.
> 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?
Wrong.
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".
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.
In the case of Qt: you have the choice of buying a commercial license
which lets you do almost anything.
BTW: even if I developed GPL software for a living I would still buy that
commercial license - it comes with a support contract that is worth more
than you pay for the license... ;-)
Konrad
PS.: please move the detailed questions about what should be interpreted
how on the GPL to some legal maillist of the FSF.
PPS.: IANALAIWNBO - I Am Not A Lawyer And I Will Never Become One
--
[ signature omitted ]