Licensing and technical issues with a Wine package that includes the Mozilla ActiveX Control

[Scott Ritchie]

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