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