I have a question regarding the use of portions of Wine in a commercial application. Sorry if this is not the right place to post but I am not sure who I can directly address this to. The application my employer develops is a financial application designed to work on Win 2K and Win XP, but we have a need for a Win32 function that is only supported in XP (TzSpecificLocalTimeToSystemTime). We could write an implementation of this function ourselves for Win 2K but I have noticed that there is a full implementation in Wine. Is it permissible to use the source for this function in our application? If so, what provisions do we need to make with regard to recognition of Wine and supply of source code to our customers ? I am currently trying to demonstrate the benefits of Open Source technology to my employer (I have already replaced one proprietary third-party component in our application with a better Open Source implementation) and this could really help to move this process along. Longer-term, I want to try and get the application running on Wine, but that's another story. Regards, Dominic
Hi, On Wed, Jan 04, 2006 at 03:29:22PM +0000, Dominic Wise wrote:
I have a question regarding the use of portions of Wine in a commercial application. Sorry if this is not the right place to post but I am not sure who I can directly address this to. np (I don't think wine-users would be an appropriate place for such a specific question)
The application my employer develops is a financial application designed to work on Win 2K and Win XP, but we have a need for a Win32 function that is only supported in XP (TzSpecificLocalTimeToSystemTime). We could write an implementation of this function ourselves for Win 2K but I have noticed that there is a full implementation in Wine. Are you sure this is the only Win32 API with this exact functionality? There might be a good reason why it's been introduced at such a late date as XP+ only...
cd wine; find . -name "*.spec"|xargs grep -i time.*time
Is it permissible to use the source for this function in our application? If so, what provisions do we need to make with regard to recognition of Wine and supply of source code to our customers ? Err... no. (at least not directly)
While Wine's license (LGPL) allows linking to Wine components, it still carries the same restrictions as the GPL license when it comes to directly integrating such code in closed-source programs. However I think(!) that it's legally valid to gather some "inspirations" from such code if absolutely needed and then write your own implementation of this function, much preferrably by first looking at the code and then, completely isolated, writing your own quite different code. (anybody please correct me NOW if this is fatally incorrect!) But I'm afraid the best way to avoid license violations is to code this function without looking at the (L)GPL'd implementation of this algorithm, if possible. Another way *might* be to ask the original author of this function (see CVS logs) whether he permits you to use his *original*, *unpatched* version of this function. BTW, if you absolutely want to directly use Wine-related code in a commercial (or, to be exact: proprietary) application, then may I direct you to http://de.wikipedia.org/wiki/ReWind ? This is a source tree mostly consisting of the old Wine codebase before the MIT -> LGPL license change. Problem is that rewind is too old to already contain an implementation of TzSpecificLocalTimeToSystemTime().
I am currently trying to demonstrate the benefits of Open Source technology to my employer (I have already replaced one proprietary third-party component in our application with a better Open Source implementation) and this could really help to move this process along. Nice! (hopefully code that uses a license that's compatible with proprietary applications, though)
Longer-term, I want to try and get the application running on Wine, but that's another story. ...preferrably by fixing Wine bugs if there are any, instead of adding Wine workarounds to the application. :)
Andreas Mohr -- GNU/Linux. It's not the software that's free, it's you.
On Wed, 2006-01-04 at 17:00 +0100, Andreas Mohr wrote:
Hi,
On Wed, Jan 04, 2006 at 03:29:22PM +0000, Dominic Wise wrote:
I have a question regarding the use of portions of Wine in a commercial application. Sorry if this is not the right place to post but I am not sure who I can directly address this to. np (I don't think wine-users would be an appropriate place for such a specific question)
The application my employer develops is a financial application designed to work on Win 2K and Win XP, but we have a need for a Win32 function that is only supported in XP (TzSpecificLocalTimeToSystemTime). We could write an implementation of this function ourselves for Win 2K but I have noticed that there is a full implementation in Wine. Are you sure this is the only Win32 API with this exact functionality? There might be a good reason why it's been introduced at such a late date as XP+ only...
cd wine; find . -name "*.spec"|xargs grep -i time.*time
Pretty sure it's the only one. Not sure why it was added later. Maybe there wasn't demand for it until XP came about.
Is it permissible to use the source for this function in our application? If so, what provisions do we need to make with regard to recognition of Wine and supply of source code to our customers ? Err... no. (at least not directly)
While Wine's license (LGPL) allows linking to Wine components, it still carries the same restrictions as the GPL license when it comes to directly integrating such code in closed-source programs.
However I think(!) that it's legally valid to gather some "inspirations" from such code if absolutely needed and then write your own implementation of this function, much preferrably by first looking at the code and then, completely isolated, writing your own quite different code. (anybody please correct me NOW if this is fatally incorrect!) But I'm afraid the best way to avoid license violations is to code this function without looking at the (L)GPL'd implementation of this algorithm, if possible.
Another way *might* be to ask the original author of this function (see CVS logs) whether he permits you to use his *original*, *unpatched* version of this function.
BTW, if you absolutely want to directly use Wine-related code in a commercial (or, to be exact: proprietary) application, then may I direct you to http://de.wikipedia.org/wiki/ReWind ? This is a source tree mostly consisting of the old Wine codebase before the MIT -> LGPL license change. Problem is that rewind is too old to already contain an implementation of TzSpecificLocalTimeToSystemTime().
Hmmm... I thought from Dan Kegel's earlier response that it would be OK to put the function into a separate library (DLL) and release this library under a separate license to the rest of the application. It's a pity if this is not permissible. Anyone else have any thoughts on this? The 'inspiration' route seems like cheating to me. I would much rather simply use the Wine code in a way that is compatible with the LGPL, if this is possible. If not, I probably just won't tell the developer working on this where to find the Wine code.
I am currently trying to demonstrate the benefits of Open Source technology to my employer (I have already replaced one proprietary third-party component in our application with a better Open Source implementation) and this could really help to move this process along. Nice! (hopefully code that uses a license that's compatible with proprietary applications, though)
They are a bit wary at the moment but the more benefits they see the easier it will become. Hope I'm OK on this one :- The program I am using (Open Object Rexx) is licensed under the CPL. The FAQ for the CPL suggests to me that it's OK to modify it and incorporate it into a proprietary application. In any case, its actually under beta testing in a development version of our application so it's not a disaster if licensing issues prevent it from making it into the a general release.
Longer-term, I want to try and get the application running on Wine, but that's another story. ...preferrably by fixing Wine bugs if there are any, instead of adding Wine workarounds to the application. :)
Of course!
Andreas Mohr
Dominic Thanks, Dominic
Dan Kegel is correct. You can create a DLL containing LGPL code and load it from a proprietary application, as long as the source to the DLL is distributed.
From the LGPL Preamble:
"This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. "When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library." --Daniel Remenak On 1/4/06, Dominic Wise <dominic.wise(a)ukonline.co.uk> wrote:
Hmmm... I thought from Dan Kegel's earlier response that it would be OK to put the function into a separate library (DLL) and release this library under a separate license to the rest of the application. It's a pity if this is not permissible.
Anyone else have any thoughts on this? The 'inspiration' route seems like cheating to me. I would much rather simply use the Wine code in a way that is compatible with the LGPL, if this is possible. If not, I probably just won't tell the developer working on this where to find the Wine code.
Thanks for identifying the relevant part of the license, and for clarifying the situation wrt separate DLLs. Very helpful. I'll give the rest of the license a good read for future reference. Dominic On Wed, 2006-01-04 at 09:53 -0800, Daniel Remenak wrote:
Dan Kegel is correct. You can create a DLL containing LGPL code and load it from a proprietary application, as long as the source to the DLL is distributed.
From the LGPL Preamble:
"This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs.
"When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library."
--Daniel Remenak
On 1/4/06, Dominic Wise <dominic.wise(a)ukonline.co.uk> wrote:
Hmmm... I thought from Dan Kegel's earlier response that it would be OK to put the function into a separate library (DLL) and release this library under a separate license to the rest of the application. It's a pity if this is not permissible.
Anyone else have any thoughts on this? The 'inspiration' route seems like cheating to me. I would much rather simply use the Wine code in a way that is compatible with the LGPL, if this is possible. If not, I probably just won't tell the developer working on this where to find the Wine code.
On Thu, 5 Jan 2006 04:28, Dominic Wise wrote:
Hmmm... I thought from Dan Kegel's earlier response that it would be OK to put the function into a separate library (DLL) and release this library under a separate license to the rest of the application.
That is correct, as long as you provide source for the DLL.
Anyone else have any thoughts on this? The 'inspiration' route seems like cheating to me.
It is a difficult area and best avoided unless you happen to be a lawyer and know exactly how far you can go. You would have to reduce the information in the original function to something that contained none of the original copyrightable expression and then reimplement from that. The problem is by the time you have done that you may as well be implementing from the original documentation (modulo anything that the implementation reveals about deficiencies in the documentation). -- Troy Rollo - wine(a)troy.rollo.name
Dominic Wise wrote:
On Wed, 2006-01-04 at 17:00 +0100, Andreas Mohr wrote:
Hi,
On Wed, Jan 04, 2006 at 03:29:22PM +0000, Dominic Wise wrote:
I have a question regarding the use of portions of Wine in a commercial application. Sorry if this is not the right place to post but I am not sure who I can directly address this to.
np (I don't think wine-users would be an appropriate place for such a specific question)
The application my employer develops is a financial application designed to work on Win 2K and Win XP, but we have a need for a Win32 function that is only supported in XP (TzSpecificLocalTimeToSystemTime). We could write an implementation of this function ourselves for Win 2K but I have noticed that there is a full implementation in Wine.
Are you sure this is the only Win32 API with this exact functionality? There might be a good reason why it's been introduced at such a late date as XP+ only...
cd wine; find . -name "*.spec"|xargs grep -i time.*time
Pretty sure it's the only one. Not sure why it was added later. Maybe there wasn't demand for it until XP came about.
Is it permissible to use the source for this function in our application? If so, what provisions do we need to make with regard to recognition of Wine and supply of source code to our customers ?
Err... no. (at least not directly)
While Wine's license (LGPL) allows linking to Wine components, it still carries the same restrictions as the GPL license when it comes to directly integrating such code in closed-source programs.
However I think(!) that it's legally valid to gather some "inspirations" from such code if absolutely needed and then write your own implementation of this function, much preferrably by first looking at the code and then, completely isolated, writing your own quite different code. (anybody please correct me NOW if this is fatally incorrect!) But I'm afraid the best way to avoid license violations is to code this function without looking at the (L)GPL'd implementation of this algorithm, if possible.
Another way *might* be to ask the original author of this function (see CVS logs) whether he permits you to use his *original*, *unpatched* version of this function.
BTW, if you absolutely want to directly use Wine-related code in a commercial (or, to be exact: proprietary) application, then may I direct you to http://de.wikipedia.org/wiki/ReWind ? This is a source tree mostly consisting of the old Wine codebase before the MIT -> LGPL license change. Problem is that rewind is too old to already contain an implementation of TzSpecificLocalTimeToSystemTime().
Hmmm... I thought from Dan Kegel's earlier response that it would be OK to put the function into a separate library (DLL) and release this library under a separate license to the rest of the application. It's a pity if this is not permissible.
AFAIK, that is correct. You can license individual files within any application however you want, and as long as the DLL containing the aforementioned function is licensed under LGPL (which it would be, since the license would be inherited from wine), and you can release the entire source of that DLL, then I see no problem with it. SO.. the question is, will that DLL contain _only_ that function, or will it contain others that need to be linked to as well, and if the 2nd applies, can the rest of the functions within that DLL be open source, LGPL'ed? Tom
participants (5)
-
Andreas Mohr -
Daniel Remenak -
Dominic Wise -
Tom Spear (aka Dustin Navea) -
Troy Rollo