Licensing and technical issues with a Wine package that includes the Mozilla ActiveX Control
Greetings, As part of my work to create the ultimate works-out-of-the-box Wine package, I've begun to ponder the idea of including the Mozilla ActiveX control inside the Wine package. Currently, to install applications that use Internet Explorer internally, such as Steam, the user has to download the Mozilla ActiveX control as a tar file and then manually register the DLL to get Wine to use it (see the Howto in the AppDB entry here: http://appdb.winehq.org/appview.php?versionId=1554 ) Modifying Wine to recognize when the Mozilla ActiveX Control is installed without having to register it manually should be easy enough, however distributing it with the Wine package or as a separate side package presents an unusual licensing issue. Now, the Mozilla ActiveX control is freely licensed, and we can redistribute it however we please. Unfortunately, to make it work in Wine we also need to use the dlls for the Microsoft Foundation Classes that it's written in such as msvcp70.dll, as Wine does not currently implement those. These files have an unusual license. Someone who owns the compiler (such as MSVC 7) is allowed to distribute them, however redistribution further from there isn't necessarily allowed, as the person receiving the file doesn't have a license to redistribute like the EULA for the compiler grants. This doesn't seem to prevent us from giving out the package with the DLL included, however users wouldn't be able to redistribute it. This sounds much like the way the situation is with the NVidia drivers. Would building the package be the right way to go here, with the ultimate destination being the restricted copyright repository in Ubuntu? Or is there something I'm overlooking here (perhaps reading the license wrong)? Thanks, Scott Ritchie
Hi Scott, On Sat, 2005-11-19 at 22:01 -0800, Scott Ritchie wrote:
Greetings,
As part of my work to create the ultimate works-out-of-the-box Wine package, I've begun to ponder the idea of including the Mozilla ActiveX control inside the Wine package. Currently, to install applications that use Internet Explorer internally, such as Steam, the user has to download the Mozilla ActiveX control as a tar file and then manually register the DLL to get Wine to use it (see the Howto in the AppDB entry here: http://appdb.winehq.org/appview.php?versionId=1554 )
When I read the Howto (http://www.linux-gamers.net/modules/wfsection/article.php?articleid=17) there is one section about "If you don't want to install the MozActiveX Control". In this section of the Howto the author wrote, that you don't need the mfc dll when you installed the actviveX control of Mozilla. Thinking about security risks to have activeX applets anyways, and thinking about the possibilty if there is a Wine installation with enabled ActiveX out of the box (which I, as a normal user wouldn't want), I'm not quite sure, if we should ever ship this with a winepackage.
Modifying Wine to recognize when the Mozilla ActiveX Control is installed without having to register it manually should be easy enough, however distributing it with the Wine package or as a separate side package presents an unusual licensing issue.
Now, the Mozilla ActiveX control is freely licensed, and we can redistribute it however we please. Unfortunately, to make it work in Wine we also need to use the dlls for the Microsoft Foundation Classes that it's written in such as msvcp70.dll, as Wine does not currently implement those.
As I understand the Howto, Steam somehow needs this mfc dll, but doens't ship it. That can mean, that the Steam developer don't have the rights to distribute it, which sounds a bit strange to me. If they don't deliver a vital dll for their software, they have a problem, which we or better you should not solve, with shipping any propietary software in the wine app. I think wine has to be an running environment for MS Windows applications, yes, but installing windows software should be in the responsibily of the user who is using Wine.
These files have an unusual license. Someone who owns the compiler (such as MSVC 7) is allowed to distribute them, however redistribution further from there isn't necessarily allowed, as the person receiving the file doesn't have a license to redistribute like the EULA for the compiler grants. This doesn't seem to prevent us from giving out the package with the DLL included, however users wouldn't be able to redistribute it.
This is a no go. I don't think we're allowed to ship it in any way, because (ok, I don't really know the correct distribution license, but MS is in any form very restrictive) we don't comply to their rules. MFC dll stuff is user orientated and should not be shipped by default.
This sounds much like the way the situation is with the NVidia drivers. Would building the package be the right way to go here, with the ultimate destination being the restricted copyright repository in Ubuntu? Or is there something I'm overlooking here (perhaps reading the license wrong)?
Well, it sounds more like the distribution license of Sun Java. ,-) Honestly, I don't like the idea to distribute userland windows applications or libraries in our packages. If wine upstream will include them, I, as one of the universe maintainer, would remove them from the upstream source package. Actually I'm quite frightend that someone will develop a new spyware tool, which runs only on wine environments and using unseen buffer overflows to inject malicious code or starts linux binaries, which are installed during the installtion of those tools. And the easiest way to do it, is to activate activeX by default. That's all IMHO, and I would like to hear James (elmo) and/or Martin (pitti) about their concerns regarding security and licensing issues. Regards, \sh
On Sun, 2005-11-20 at 12:55 +0100, Stephan Hermann wrote:
Hi Scott,
On Sat, 2005-11-19 at 22:01 -0800, Scott Ritchie wrote:
Greetings,
As part of my work to create the ultimate works-out-of-the-box Wine package, I've begun to ponder the idea of including the Mozilla ActiveX control inside the Wine package. Currently, to install applications that use Internet Explorer internally, such as Steam, the user has to download the Mozilla ActiveX control as a tar file and then manually register the DLL to get Wine to use it (see the Howto in the AppDB entry here: http://appdb.winehq.org/appview.php?versionId=1554 )
When I read the Howto (http://www.linux-gamers.net/modules/wfsection/article.php?articleid=17) there is one section about "If you don't want to install the MozActiveX Control". In this section of the Howto the author wrote, that you don't need the mfc dll when you installed the actviveX control of Mozilla.
That section of the howto requires finding a native shdocvw.dll and native shlwapi.dll - ie, not built in to Wine. Implicitly, this means Internet Explorer is installed.
Thinking about security risks to have activeX applets anyways, and thinking about the possibilty if there is a Wine installation with enabled ActiveX out of the box (which I, as a normal user wouldn't want), I'm not quite sure, if we should ever ship this with a winepackage.
The risk is to Wine and Wine alone, especially if Wine only has read access outside of it's own .wine directory. Also, due to the copyright issue this would most likely be a separate package for the user to install such as wine-activex, since it needs to be in a separate repository.
Modifying Wine to recognize when the Mozilla ActiveX Control is installed without having to register it manually should be easy enough, however distributing it with the Wine package or as a separate side package presents an unusual licensing issue.
Now, the Mozilla ActiveX control is freely licensed, and we can redistribute it however we please. Unfortunately, to make it work in Wine we also need to use the dlls for the Microsoft Foundation Classes that it's written in such as msvcp70.dll, as Wine does not currently implement those.
As I understand the Howto, Steam somehow needs this mfc dll, but doens't ship it. That can mean, that the Steam developer don't have the rights to distribute it, which sounds a bit strange to me. If they don't deliver a vital dll for their software, they have a problem, which we or better you should not solve, with shipping any propietary software in the wine app.
Steam doesn't ship that DLL since it assumes people have Internet Explorer installed. If you install IE with Wine, you don't need the Mozilla ActiveX control (and you can instead use native shdocvw and shlwapi).
I think wine has to be an running environment for MS Windows applications, yes, but installing windows software should be in the responsibily of the user who is using Wine.
Requiring the user to configure it with Winetools is always an option. Currently, when Wine discovers an app like Steam that needs ActiveX, it prompts the user if he would like to download it. However, this doesn't work. If that were working automagically (with the download location being one who has distribution rights), perhaps this whole issue would go away.
These files have an unusual license. Someone who owns the compiler (such as MSVC 7) is allowed to distribute them, however redistribution further from there isn't necessarily allowed, as the person receiving the file doesn't have a license to redistribute like the EULA for the compiler grants. This doesn't seem to prevent us from giving out the package with the DLL included, however users wouldn't be able to redistribute it.
This is a no go. I don't think we're allowed to ship it in any way, because (ok, I don't really know the correct distribution license, but MS is in any form very restrictive) we don't comply to their rules.
Don't be so certain just because it's Microsoft. We already ship the msttcorefonts package, for instance.
MFC dll stuff is user orientated and should not be shipped by default.
This sounds much like the way the situation is with the NVidia drivers. Would building the package be the right way to go here, with the ultimate destination being the restricted copyright repository in Ubuntu? Or is there something I'm overlooking here (perhaps reading the license wrong)?
Well, it sounds more like the distribution license of Sun Java. ,-)
Honestly, I don't like the idea to distribute userland windows applications or libraries in our packages. If wine upstream will include them, I, as one of the universe maintainer, would remove them from the upstream source package.
Actually I'm quite frightend that someone will develop a new spyware tool, which runs only on wine environments and using unseen buffer overflows to inject malicious code or starts linux binaries, which are installed during the installtion of those tools. And the easiest way to do it, is to activate activeX by default.
Touche.
That's all IMHO, and I would like to hear James (elmo) and/or Martin (pitti) about their concerns regarding security and licensing issues.
Regards,
\sh
Thanks, Scott Ritchie
Le dimanche 20 novembre 2005 à 12:04 -0800, Scott Ritchie a écrit : [...]
Requiring the user to configure it with Winetools is always an option. Currently, when Wine discovers an app like Steam that needs ActiveX, it prompts the user if he would like to download it. However, this doesn't work. If that were working automagically (with the download location being one who has distribution rights), perhaps this whole issue would go away.
Maybe we could make Wine download this file from several locations that have a right to redistribute it (Does someone at WineHQ or Codeweavers has a MSVC licence ?)... We could use the same script I did for the Mozilla ActiveX Control ? Thanks. Jonathan
On Sun, 2005-11-20 at 21:19 +0100, Jonathan Ernst wrote:
Le dimanche 20 novembre 2005 à 12:04 -0800, Scott Ritchie a écrit : [...]
Requiring the user to configure it with Winetools is always an option. Currently, when Wine discovers an app like Steam that needs ActiveX, it prompts the user if he would like to download it. However, this doesn't work. If that were working automagically (with the download location being one who has distribution rights), perhaps this whole issue would go away.
Maybe we could make Wine download this file from several locations that have a right to redistribute it (Does someone at WineHQ or Codeweavers has a MSVC licence ?)... We could use the same script I did for the Mozilla ActiveX Control ?
I wonder if it's possible to have the people at mozilla.org host it? Perhaps we can get someone there interested in Wine. Thanks, Scott Ritchie
Le dim 20/11/2005 à 15:19, Jonathan Ernst a écrit :
Le dimanche 20 novembre 2005 à 12:04 -0800, Scott Ritchie a écrit : [...]
Requiring the user to configure it with Winetools is always an option. Currently, when Wine discovers an app like Steam that needs ActiveX, it prompts the user if he would like to download it. However, this doesn't work. If that were working automagically (with the download location being one who has distribution rights), perhaps this whole issue would go away.
Maybe we could make Wine download this file from several locations that have a right to redistribute it (Does someone at WineHQ or Codeweavers has a MSVC licence ?)... We could use the same script I did for the Mozilla ActiveX Control ?
? We already provide a link to download the Mozilla ActiveX control (which already _contains_ msvcp60.dll, see below) on winehq. The problem is that it'd like to load that file (or msvcp70.dll, but it's basically the same thing) before it's available. Try this (which work without downloading anything else than the control from the web): Make a symlink from your fake "c:\windows\system32" named msvcp70.dll pointing to "c:\Program Files\Mozilla ActiveX Control v1.7.12\msvcp60.dll". Then download/install the Mozilla ActiveX control. It'll register itself correctly. You can then remove the symlink, it looks like it works after. I thought about patching the RH binaries to do just that (when we download the file), but it'd need users to keep the default location, and would be a bit fragile. Also, about including the control in binary packages, even without any license worries, it'd still increase the size of your binary packages by almost 5MB, which is close to a 40% increase in total package size. For that reason, I don't think it's a good idea to include it. Now, fixing it so it installs correctly out-of-the-box, that's something to pursue. Vincent
Hi Scott, Scott Ritchie wrote:
Now, the Mozilla ActiveX control is freely licensed, and we can redistribute it however we please. Unfortunately, to make it work in Wine we also need to use the dlls for the Microsoft Foundation Classes that it's written in such as msvcp70.dll, as Wine does not currently implement those.
Probably the best solution is to patch Mozilla AvctiveX Control to not use msvcp70.dll. It shouldn't be too hard. A further plan is to not use Mozilla ActiveX Control, what means implementing shdocvw.dll on top on MSHTML that currently uses raw Gecko. Jacek
On Sat, Nov 19, 2005 at 10:01:08PM -0800, Scott Ritchie wrote:
This sounds much like the way the situation is with the NVidia drivers. Would building the package be the right way to go here, with the ultimate destination being the restricted copyright repository in Ubuntu? Or is there something I'm overlooking here (perhaps reading the license wrong)?
Er. The NVIDIA drivers have no source code and you cannot modify them (as with the ATI drivers), but you are given explicit permission to freely redistribute them. Restrictions on redistribution are far more problematic than that.
participants (6)
-
Daniel Stone -
Jacek Caban -
Jonathan Ernst -
Scott Ritchie -
Stephan Hermann -
Vincent Béron