| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 3 | |
Dear list, it may have been discussed several times now, but the search in the archives didn't satisfy my questions. Suppose you develop a huge application which is entirely controlled through alpha numerical input files. This core application is freely available (and alternatively for sale including certain support), but -must- remain proprietary for reasons not to be explained here. For some reason it is nice to have a gui for this application. The gui should only contain some pre- and postprocessor and some control stuff, i.e. start/stop/pause buttons, log message vierwer, text editor and some visualization of 3d data. Is it somehow possible to create legal mechanism for splitting the core and the gui, such that a minimum number of licenses must be paid for? We have something in mind like: (a) Buy one Qt license for the developer who creates the Qt related code. All other developers responsible for code portions not being based on Qt can continue their work without changes. The problem: We still don't know yet if the number of Qt developers will change in the future or if the repsonsible maintainer will change. (b) We split the application: BAsed on one commercial Qt license a plugin interface is created in the core application. Then, a Qt plugin will be created using GPLed Qt (thus, the plugin will be GPL, too). The plugin just communicates through the plugin-classes with the proprietary core. The OSS community will be happy since we provide a GPLed GUI plugin. (c) We split the application into two independent processes. The interprocess communication is done with dbus. The gui is GPLed, the core is proprietary. The problems we see are: The interface is even more difficult to develop and we can not estimate the performance in case we have to transmit plenty 3d object data for visualization. My questions are: o Are the three options legal? o Which one is the best? o Are there alternatives? Thanks Sebastian W -- [ signature omitted ]
Hi,
Disclaimer: TGIANAL (thanks god I am not a lawyer).
On Fri, January 19, 2007 16:12, Sebastian Wolff wrote:
> Suppose you develop a huge application which is entirely controlled
> through
> alpha numerical input files. This core application is freely available
> (and
> alternatively for sale including certain support), but -must- remain
> proprietary for reasons not to be explained here.
>
> For some reason it is nice to have a gui for this application. The gui
> should
> only contain some pre- and postprocessor and some control stuff, i.e.
> start/stop/pause buttons, log message vierwer, text editor and some
> visualization of 3d data.
>
> Is it somehow possible to create legal mechanism for splitting the core
> and
> the gui, such that a minimum number of licenses must be paid for?
Make it different programs.
> We have something in mind like:
>
> (a) Buy one Qt license for the developer who creates the Qt related code.
> All
> other developers responsible for code portions not being based on Qt can
> continue their work without changes. The problem: We still don't know yet
> if
> the number of Qt developers will change in the future or if the
> repsonsible
> maintainer will change.
Ask Trolltech sales whether they allow this under their commercial license
(I doubt it). It is not possible with the GPL version.
> (b) We split the application: BAsed on one commercial Qt license a plugin
> interface is created in the core application. Then, a Qt plugin will be
> created using GPLed Qt (thus, the plugin will be GPL, too). The plugin
> just
> communicates through the plugin-classes with the proprietary core. The OSS
> community will be happy since we provide a GPLed GUI plugin.
Not possible under GPL: as soon as it is linked together into one process
everything has to be GPL-compatible (there are only exceptions for system
libraries, like libc).
And no, the OSS community is not happy if it is cheated upon.
> (c) We split the application into two independent processes. The
> interprocess
> communication is done with dbus. The gui is GPLed, the core is
> proprietary.
> The problems we see are: The interface is even more difficult to develop
> and
> we can not estimate the performance in case we have to transmit plenty 3d
> object data for visualization.
If you document the Interface, so that (in theory) somebody else could use
it to display different (or similiar) data using it, then this should be
legal.
(d) Purchase enough Qt licenses from Trolltech and stay completely
proprietary. Talk to Trolltech to determine how many licenses you need.
Don't worry, they are really nice and don't bite.
(e) Use a different GUI lib, whose license allows linking to proprietary
code.
Konrad
--
[ signature omitted ]
>Not possible under GPL: as soon as it is linked together into one process > everything has to be GPL-compatible (there are only exceptions for system > libraries, like libc). Is this really true? I mean, there are for example KDE style plug-ins under GPL out there and any (eg. proprietary) Qt app may use them without being asked if it is GPL compatible or not. Moreover, I have seen that static plug-ins are possible as well - may someone declare such plugins to be 'linked' as well? I could even turn the whole thing around: I make the main executable GPL representing the GUI. This one will have a plugin interface which directs to my core library which is proprietary. I really don't see the point. An proprietary software supporting Qt plugins will have this problem - they will never know if the used plugin will be GPL or not... Zitat von Konrad Rosenbaum <konrad@xxxxxxxxx>: > Hi, > > Disclaimer: TGIANAL (thanks god I am not a lawyer). > > On Fri, January 19, 2007 16:12, Sebastian Wolff wrote: > > Suppose you develop a huge application which is entirely controlled > > through > > alpha numerical input files. This core application is freely available > > (and > > alternatively for sale including certain support), but -must- remain > > proprietary for reasons not to be explained here. > > > > For some reason it is nice to have a gui for this application. The gui > > should > > only contain some pre- and postprocessor and some control stuff, i.e. > > start/stop/pause buttons, log message vierwer, text editor and some > > visualization of 3d data. > > > > Is it somehow possible to create legal mechanism for splitting the core > > and > > the gui, such that a minimum number of licenses must be paid for? > > Make it different programs. > > > We have something in mind like: > > > > (a) Buy one Qt license for the developer who creates the Qt related code. > > All > > other developers responsible for code portions not being based on Qt can > > continue their work without changes. The problem: We still don't know yet > > if > > the number of Qt developers will change in the future or if the > > repsonsible > > maintainer will change. > > Ask Trolltech sales whether they allow this under their commercial license > (I doubt it). It is not possible with the GPL version. > > > (b) We split the application: BAsed on one commercial Qt license a plugin > > interface is created in the core application. Then, a Qt plugin will be > > created using GPLed Qt (thus, the plugin will be GPL, too). The plugin > > just > > communicates through the plugin-classes with the proprietary core. The OSS > > community will be happy since we provide a GPLed GUI plugin. > > Not possible under GPL: as soon as it is linked together into one process > everything has to be GPL-compatible (there are only exceptions for system > libraries, like libc). > > And no, the OSS community is not happy if it is cheated upon. > > > (c) We split the application into two independent processes. The > > interprocess > > communication is done with dbus. The gui is GPLed, the core is > > proprietary. > > The problems we see are: The interface is even more difficult to develop > > and > > we can not estimate the performance in case we have to transmit plenty 3d > > object data for visualization. > > If you document the Interface, so that (in theory) somebody else could use > it to display different (or similiar) data using it, then this should be > legal. > > (d) Purchase enough Qt licenses from Trolltech and stay completely > proprietary. Talk to Trolltech to determine how many licenses you need. > Don't worry, they are really nice and don't bite. > > (e) Use a different GUI lib, whose license allows linking to proprietary > code. > > > > Konrad > > -- > 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/ > -- [ signature omitted ]
...still IANAL...
On Fri, January 19, 2007 17:10, Sebastian Wolff wrote:
>>Not possible under GPL: as soon as it is linked together into one process
>> everything has to be GPL-compatible (there are only exceptions for
>> system
>> libraries, like libc).
>
> Is this really true?
AFAIK, yes. I believe that's in the FAQ for the GPL on the FSFs website.
> I mean, there are for example KDE style plug-ins
> under
> GPL out there and any (eg. proprietary) Qt app may use them without being
> asked if it is GPL compatible or not.
"may" as in "the code does not prevent it" or as in "the author allows
it"? If the former: you don't need to enforce a license in code in order
for it to be legally binding. If the latter: than this code is covered
under a modified GPL. If in doubt: ask the author.
BTW: most linkable KDE code is licensed under LGPL or MIT license (both
allow linking to proprietary code). There are a some pieces of KDE code
that are indirectly called through the libs which run in different
processes (eg. some Browser-Plugins in Konqueror) - those don't need to be
LGPL.
> Moreover, I have seen that static
> plug-ins are possible as well - may someone declare such plugins to
> be 'linked' as well?
What are static plugins?
I don't think we are talking about the same thing when we say "linking":
it means that executable code resides in the same logical memory (the
memory of the same process) and (indirectly) interacts. That's what you do
if you use libraries or plugins in your process - it does not matter
whether it is statically linked (at compile time) or dynamically (at
runtime). If the code executes in the same process, it is linked by
definition (regardless of whether it is called directly or not). However,
it does not mean to communicate between different processes. If different
code executes in different processes then it is not linked. That easy.
Example from the Unix command line:
Commandline: echo hallo | grep ha
Both echo and grep use the ANSI-C library "libc".
-> echo is linked to the libc
-> grep is linked to the libc
-> echo and grep communicate (via the pipe)
-> but they do not execute in the same process, hence echo and grep are
not linked
> I could even turn the whole thing around:
> I make the main executable GPL representing the GUI. This one will have a
> plugin interface which directs to my core library which is proprietary. I
> really don't see the point. An proprietary software supporting Qt plugins
> will
> have this problem - they will never know if the used plugin will be GPL or
> not...
Ok, GPL basics for a second: GPL is a distribution license. It is enforced
on distribution time. Not on development time and not on usage time.
If you distribute proprietary app X with proprietary plugin Y that is
totally ok and not covered by the GPL. I now develop a GPL plugin Z, that
interfaces with X:
*If I develop Z, so it ONLY runs with X - it is I who violates the GPL (at
least if I use other GPL sources that are not from me, like Qt), you are
not affected.
*If I really intended Z to run with a GPL-compatible application and it
just happens to run with X as well, there is no problem, as long as none
of us bundles X and Z in distribution. The users are free to run Z with
the free application or with X.
If you develop a proprietary plugin P and I develop a GPLed application A,
the situation looks very similiar:
*If P is designed to ONLY run with A, then you violate the GPL.
*If P is designed to run with something else (legally!) and you allow your
users to run it with whatever they chose then they are free to run it in
A, if the interface matches. Neither of us (nor anybody else) must bundle
P and A however.
(This is eg. the case with plugins developed for a proprietary browser if
they are run in a GPL browser.)
This is all pretty heady stuff which confuses even lawyers. For your own
sake you should make a clean decision and EITHER develop completely free
software OR completely proprietary software. In regards to Qt: either run
with the GPL version and free up your "core" under a GPL-compatible
license (eg. GPL itself, LGPL, or MIT) or buy enough commercial
licenses(*).
(*)Important hint: the Qt commercial license does not allow to
commercialize code that was developed with Qt/GPL, so you better buy those
licenses before you start using Qt.
Konrad
--
[ signature omitted ]
"Sebastian Wolff" <sebastian.wolff@xxxxxxxxxxxxxxxxxxxx> wrote in message news:1169223058.45b0ed925e365@xxxxxxxxxxxxxxxxxxxxxxxx > >Not possible under GPL: as soon as it is linked together into one > >process >> everything has to be GPL-compatible (there are only exceptions for >> system >> libraries, like libc). > > Is this really true? I mean, there are for example KDE style plug-ins > under > GPL out there and any (eg. proprietary) Qt app may use them without > being > asked if it is GPL compatible or not. The user running a non-GPL Qt application in an environment that makes the Qt library used load GPL'ed KDE plugins is not distributing anything. As long as you don't distribute anything the GPL does not care. You plan to distribute GPL'ed stuff, and therefore you must follow the rules. > Moreover, I have seen that static > plug-ins are possible as well - may someone declare such plugins to > be 'linked' as well? That the term "plugin" is used is entirely irrelevant for the GPL. Static linking definitely triggers the GPL, as does most likely build-time linking against a shared library. > I could even turn the whole thing around: > I make the main executable GPL representing the GUI. This one will have > a > plugin interface which directs to my core library which is proprietary. > I > really don't see the point. An proprietary software supporting Qt > plugins will > have this problem - they will never know if the used plugin will be GPL > or > not... See above. You plan to create a GPL'ed piece of software that makes no sense without the proprietary counter-part; or, the other way around, you try to create propietary software that makes use of GPL'ed software. This is - at least as I understand it - exactly what the GPL tries to prevent, so your idea is - unless you follow Konrad's advise regarding option b) - against the spirit of the GPL, if not against the letter. Volker > Zitat von Konrad Rosenbaum <konrad@xxxxxxxxx>: > >> Hi, >> >> Disclaimer: TGIANAL (thanks god I am not a lawyer). >> >> On Fri, January 19, 2007 16:12, Sebastian Wolff wrote: >> > Suppose you develop a huge application which is entirely controlled >> > through >> > alpha numerical input files. This core application is freely >> > available >> > (and >> > alternatively for sale including certain support), but -must- remain >> > proprietary for reasons not to be explained here. >> > >> > For some reason it is nice to have a gui for this application. The >> > gui >> > should >> > only contain some pre- and postprocessor and some control stuff, i.e. >> > start/stop/pause buttons, log message vierwer, text editor and some >> > visualization of 3d data. >> > >> > Is it somehow possible to create legal mechanism for splitting the >> > core >> > and >> > the gui, such that a minimum number of licenses must be paid for? >> >> Make it different programs. >> >> > We have something in mind like: >> > >> > (a) Buy one Qt license for the developer who creates the Qt related >> > code. >> > All >> > other developers responsible for code portions not being based on Qt >> > can >> > continue their work without changes. The problem: We still don't know >> > yet >> > if >> > the number of Qt developers will change in the future or if the >> > repsonsible >> > maintainer will change. >> >> Ask Trolltech sales whether they allow this under their commercial >> license >> (I doubt it). It is not possible with the GPL version. >> >> > (b) We split the application: BAsed on one commercial Qt license a >> > plugin >> > interface is created in the core application. Then, a Qt plugin will >> > be >> > created using GPLed Qt (thus, the plugin will be GPL, too). The >> > plugin >> > just >> > communicates through the plugin-classes with the proprietary core. >> > The OSS >> > community will be happy since we provide a GPLed GUI plugin. >> >> Not possible under GPL: as soon as it is linked together into one >> process >> everything has to be GPL-compatible (there are only exceptions for >> system >> libraries, like libc). >> >> And no, the OSS community is not happy if it is cheated upon. >> >> > (c) We split the application into two independent processes. The >> > interprocess >> > communication is done with dbus. The gui is GPLed, the core is >> > proprietary. >> > The problems we see are: The interface is even more difficult to >> > develop >> > and >> > we can not estimate the performance in case we have to transmit >> > plenty 3d >> > object data for visualization. >> >> If you document the Interface, so that (in theory) somebody else could >> use >> it to display different (or similiar) data using it, then this should >> be >> legal. >> >> (d) Purchase enough Qt licenses from Trolltech and stay completely >> proprietary. Talk to Trolltech to determine how many licenses you need. >> Don't worry, they are really nice and don't bite. >> >> (e) Use a different GUI lib, whose license allows linking to >> proprietary >> code. >> >> >> >> Konrad >> >> -- >> 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/ >> > > -- > 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/ -- [ signature omitted ]
If the core is written without QT, and is a stand alone shared library or exec then that development team does NOT require a QT license. If the GUI, is QT based, then it becomes a stand alone situation, and you must provide licenses according to the QPL. Ie, if you go the commercial route, you should have 1 license per developer, if that number is not constant, you might have to pay extra for the temp workers.. I would not recommend using the open source route for this. While it may be legal, it sounds like your putting out a closed source app. And you may want to make the guy closed source in the future. Scott > -----Original Message----- > From: Sebastian Wolff [mailto:sebastian.wolff@xxxxxxxxxxxxxxxxxxxx] > Sent: Friday, January 19, 2007 7:12 AM > To: qt-interest@xxxxxxxxxxxxx > Subject: Software with GPLed Qt and proprietary core? > > Dear list, > > it may have been discussed several times now, but the search in the > archives > didn't satisfy my questions. > > Suppose you develop a huge application which is entirely controlled > through > alpha numerical input files. This core application is freely available > (and > alternatively for sale including certain support), but -must- remain > proprietary for reasons not to be explained here. > > For some reason it is nice to have a gui for this application. The gui > should > only contain some pre- and postprocessor and some control stuff, i.e. > start/stop/pause buttons, log message vierwer, text editor and some > visualization of 3d data. > > Is it somehow possible to create legal mechanism for splitting the core > and > the gui, such that a minimum number of licenses must be paid for? > > We have something in mind like: > > (a) Buy one Qt license for the developer who creates the Qt related code. > All > other developers responsible for code portions not being based on Qt can > continue their work without changes. The problem: We still don't know yet > if > the number of Qt developers will change in the future or if the > repsonsible > maintainer will change. > > (b) We split the application: BAsed on one commercial Qt license a plugin > interface is created in the core application. Then, a Qt plugin will be > created using GPLed Qt (thus, the plugin will be GPL, too). The plugin > just > communicates through the plugin-classes with the proprietary core. The OSS > community will be happy since we provide a GPLed GUI plugin. > > (c) We split the application into two independent processes. The > interprocess > communication is done with dbus. The gui is GPLed, the core is > proprietary. > The problems we see are: The interface is even more difficult to develop > and > we can not estimate the performance in case we have to transmit plenty 3d > object data for visualization. > > > > My questions are: > o Are the three options legal? > o Which one is the best? > o Are there alternatives? > > Thanks > Sebastian W > > -- > 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/ -- [ signature omitted ]
> Suppose you develop a huge application which is entirely controlled > through > alpha numerical input files. This core application is freely available > (and > alternatively for sale including certain support), but -must- remain > proprietary for reasons not to be explained here. > > For some reason it is nice to have a gui for this application. The gui > should > only contain some pre- and postprocessor and some control stuff, i.e. > start/stop/pause buttons, log message vierwer, text editor and some > visualization of 3d data. > > Is it somehow possible to create legal mechanism for splitting the core > and > the gui, such that a minimum number of licenses must be paid for? > > We have something in mind like: > > (a) Buy one Qt license for the developer who creates the Qt related > code. All > other developers responsible for code portions not being based on Qt can > continue their work without changes. The problem: We still don't know > yet if > the number of Qt developers will change in the future or if the > repsonsible > maintainer will change. This is not a problem. You can purchase additional Qt licenses as you go along, and you can reassign the Qt licenses to different developers twice a year (talk to sales@xxxxxxxxxxxxx for more information). > (b) We split the application: BAsed on one commercial Qt license a > plugin > interface is created in the core application. Then, a Qt plugin will be > created using GPLed Qt (thus, the plugin will be GPL, too). The plugin > just > communicates through the plugin-classes with the proprietary core. The > OSS > community will be happy since we provide a GPLed GUI plugin. If this would violate the GPL or not is something that you should check with the FSF. Explicit linking (i.e. "plugin") vs linking at runtime is one of the rather fuzzy elements of the GPL. In general however the simple rule is: if you don't know if you violate the GPL with a certain setup, then you most certainly are not qualified to accept the license terms of the GPL, and should therefore keep your hands off the Open Source version of Qt. Fair enough, the GPL is not exactly straight forward, but by introducing the GPL into a complex piece of software that is not 100% GPL you are just creating a liability - as soon as a court rules that whatever you are doing is a violation of the GPL and forces you to open your complete source code you are in trouble. USD 3000 to avoid a risk that might cost you your business is probably a good investment. > (c) We split the application into two independent processes. The > interprocess > communication is done with dbus. The gui is GPLed, the core is > proprietary. > The problems we see are: The interface is even more difficult to develop > and > we can not estimate the performance in case we have to transmit plenty > 3d > object data for visualization. Technically this is a rather suboptimal solution, but as long as it is possible for others to replace your core application with their own solution this should be ok. Again, the FSF is the authority as far as interpreting the GPL is concerned. > My questions are: > o Are the three options legal? > o Which one is the best? > o Are there alternatives? a) is the obvious, safest, most flexible choice and actually rather popular choice. And I do not say that only because I work for Trolltech :) Volker -- [ signature omitted ]
Volker Hilsheimer wrote: >> Suppose you develop a huge application which is entirely controlled >> through >> alpha numerical input files. This core application is freely available >> (and >> alternatively for sale including certain support), but -must- remain >> proprietary for reasons not to be explained here. >> >> For some reason it is nice to have a gui for this application. The gui >> should >> only contain some pre- and postprocessor and some control stuff, i.e. >> start/stop/pause buttons, log message vierwer, text editor and some >> visualization of 3d data. >> >> Is it somehow possible to create legal mechanism for splitting the core >> and >> the gui, such that a minimum number of licenses must be paid for? >> >> We have something in mind like: >> >> (a) Buy one Qt license for the developer who creates the Qt related >> code. All >> other developers responsible for code portions not being based on Qt can >> continue their work without changes. The problem: We still don't know >> yet if >> the number of Qt developers will change in the future or if the >> repsonsible >> maintainer will change. >> > > > This is not a problem. You can purchase additional Qt licenses as you go > along, and you can reassign the Qt licenses to different developers twice > a year (talk to sales@xxxxxxxxxxxxx for more information). > > ~$3000 is about 2 weeks of an engineers time. So if it would take you an extra couple of weeks of time implementing this feature without Qt Commercial... is it really worth the GPL hoop jumping? Also, if you are a small company you can buy your initial licenses for ~50% off. So Qt becomes that much better a deal at ~$1500. http://www.trolltech.com/products/qt/licenses/licensing/smallbusiness/?searchterm=Small%20business --Justin
begin:vcard
begin:vcard fn:Justin Noel n:Noel;Justin org:ICS;Engineering adr:;;54B Middlesex Trpk;Bedford;MA;01730;USA email;internet:justin@xxxxxxx title:Sr. Consulting Engineer / Certified Qt Instructor tel;work:(617) 621-0060 url:http://www.ics.com version:2.1 end:vcard
Zitat von Justin Noel <justin@xxxxxxx>: > ~$3000 is about 2 weeks of an engineers time. So if it would take you an > extra couple of weeks of time implementing this feature without Qt > Commercial... is it really worth the GPL hoop jumping? > > Also, if you are a small company you can buy your initial licenses for > ~50% off. So Qt becomes that much better a deal at ~$1500. > http://www.trolltech.com/products/qt/licenses/licensing/smallbusiness/?searchterm=Small%20business > > --Justin > > I do know these calculations. But: There are non-commercial organisations involved not being able to employ developers. Therefore, different solutions must be found. The company which is involved is willing to buy licenses for their own engineers, but not the universities and independent phd scholars being involved. Therefore we are looking for a solution satisfying everybody... The company wants to develop a gui based on the application core. The others want to add features to the gui which are not relevant for the company and which may be distributed under any open source license. But: We want the core (at least the modifications the company made to it) being proprietary and we want to maintain only ONE gui. Currently we consider a commercial Qt gui for the company and a wxWidgets/Gtk solution for the other teams. But then we need to split the code base which is not intended. Any suggestions for this case? -- [ signature omitted ]
Sebastian Wolff schrieb: > Zitat von Justin Noel <justin@xxxxxxx>: >> ~$3000 is about 2 weeks of an engineers time. So if it would take you an >> ... > I do know these calculations. But: There are non-commercial organisations > involved not being able to employ developers. Therefore, different solutions > must be found. The company which is involved is willing to buy licenses for > their own engineers, but not the universities and independent phd scholars > ... > Currently we consider a commercial Qt gui for the company and a wxWidgets/Gtk > solution for the other teams. But then we need to split the code base which is > not intended. > > Any suggestions for this case? Just as to throw in another term: there is (or used to be?) another Qt license, the "University license": cheaper than the commercial license, but I think it let's you do pretty much the same thing as with the commercial license (but don't take my word for it!). But how they are compatible to each other (if the "university license" still exists at all) I don't know - again ask the sales people at Trolltech ;) Cheers, Oliver -- [ signature omitted ]
On Fri, Jan 19, 2007 at 06:11:28PM +0100, Sebastian Wolff wrote: > Zitat von Justin Noel <justin@xxxxxxx>: > > The company wants to develop a gui based on the application core. > The others want to add features to the gui which are not relevant for the > company and which may be distributed under any open source license. But: We > want the core (at least the modifications the company made to it) being > proprietary and we want to maintain only ONE gui. > > Currently we consider a commercial Qt gui for the company and a wxWidgets/Gtk > solution for the other teams. But then we need to split the code base which is > not intended. > > Any suggestions for this case? This is probably a wild suggestion, but why not separate the app and gui into a server/client model and glue them together using http/x(ht)ml (i.e. a protocol and format) via some ipc (i.e. socket or pipe)? This effectively turns everyone's browser into a gui and you can add (scriptable) features without recompiling the app. Further, interested parties can develop their own clients (QT, wxWidgets, Gtk, etc.) from the protocol and format specification rather than the gory details inside the app. Finally, the app can identify the client (or features) and adjust itself accordingly. For example, a QT client can do its own pre/post processing and editing, but the app will need to serve a browser the appropriate pages. This means the company can keep its app proprietary, maintain its own gui, and allow others to develop and license their own without infringement. I know QT can talk http and parse xml into a DOM and assume wxWidget and Gtk have somthing similar, so it's a question of getting the app to speak http/x(ht)ml. Perhaps the easiest is a commercial QT license and use the http/xml classes on the app side. I assume this rangement will allow gui developers to use whatever license they prefer. The 3D rendering can be done in a client side plugin as a mime type and licensed under LGPL, or similar, so it should work with both proprietary and non-proprietary clients. The key questions are how cleanly the protocol and format can be added to the app and what latency they introduce. -- [ signature omitted ]
Hi, > (a) Buy one Qt license for the developer who creates the Qt related code. All > other developers responsible for code portions not being based on Qt can > continue their work without changes. The problem: We still don't know yet if > the number of Qt developers will change in the future or if the repsonsible > maintainer will change. Don't take my word for it (this is not an official Trolltech statement) but yes, I seem to recall that as a rule of thumb, only developers who include Qt headers and use Qt classes and functions need a license. Those who do not include Qt headers and do not use Qt classes and functions need not pay a license. If the maintainer changes, the license can be transferred to the new maintainer, but obviously not too often. If the number of programmers including Qt headers and using Qt classes and functions increases, you do need to buy additional licenses. You should ask the Trolltech sales team for a confirmation of the above. -- [ signature omitted ]
On Fri, 19 Jan 2007 18:11:28 +0100, Sebastian Wolff <sebastian.wolff@xxxxxxxxxxxxxxxxxxxx> wrote : > Zitat von Justin Noel <justin@xxxxxxx>: > > ~$3000 is about 2 weeks of an engineers time. So if it would take you an > > extra couple of weeks of time implementing this feature without Qt > > Commercial... is it really worth the GPL hoop jumping? > > > > Also, if you are a small company you can buy your initial licenses for > > ~50% off. So Qt becomes that much better a deal at ~$1500. > > > http://www.trolltech.com/products/qt/licenses/licensing/smallbusiness/?searchterm=Small%20business > > > > --Justin > > > > > > I do know these calculations. But: There are non-commercial organisations > involved not being able to employ developers. Therefore, different solutions > must be found. The company which is involved is willing to buy licenses for > their own engineers, but not the universities and independent phd scholars > being involved. Therefore we are looking for a solution satisfying > everybody... > > The company wants to develop a gui based on the application core. > The others want to add features to the gui which are not relevant for the > company and which may be distributed under any open source license. But: We > want the core (at least the modifications the company made to it) being > proprietary and we want to maintain only ONE gui. > > Currently we consider a commercial Qt gui for the company and a wxWidgets/Gtk > solution for the other teams. But then we need to split the code base which is > not intended. > > Any suggestions for this case? > There is absolutely no reason why you can't do this. The company needs to have commercial Qt licenses for developing the proprietary GUI. If the GUI application provides an "open" plug-in interface, then the people at the university are free to develop and distribute open source plug-ins using Qt for the closed source app. -- [ signature omitted ]
On Friday 19 January 2007 23:08, Michael Rice wrote: > There is absolutely no reason why you can't do this. The company needs to > have commercial Qt licenses for developing the proprietary GUI. If the > GUI application provides an "open" plug-in interface, then the people at > the university are free to develop and distribute open source plug-ins > using Qt for the closed source app. Please define '"open" plugin-interface'. The way you describe it here it sounds like a very serious violation of the GPL. Konrad
Attachment:
Attachment:
pgpuLf0JFSBO2.pgp
Attachment:
Attachment:
pgphvB6MBDUhk.pgp
Description: PGP signature
Message 15 in thread
...still IANAL
On Saturday 20 January 2007 18:56, Michael Rice wrote:
> As I understand the GPL: open source software developers are free to
> use whatever libraries they have a license for - open or closed
> source. The fact that a particular chunk of open source software can
> only be used with a closed source application is irrelevant.
That is wrong: you are only free to use proprietary "system" libraries. That
are those which are included in the original package of your operating
system and which you need to run ANY program on that system. Additional
libraries do not count.
Konrad
Description: PGP signature