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

On 11/29/05, Mike Hearn <mike at plan99.net> wrote:
> > Do the Scott's packages inflict these kind of problems?
> No, thank goodness! The Debian ones do. The Gentoo ebuilds have in the
> past. As well as many other less popular ones I forget.

That's one reason why we decided to ship breezy with packages based on
Scotts work.

> My solution would just be for Scotts package to include the Moz
> AX control and keep it in an upstream repository, like the
> wine.sourceforge.net one, where he has control of it and can include what
> he wants. That way I think everybody is satisfied?

I think a better solution would be if the wine package would not
include the Moz AX control. That way, we could have Scotts package in
our universe repository. However, to enable users to use applications
with that Moz AX control, I'd suggest to put it in a different
package, which depends on wine and handles the registration into wine.
If that package was freely redistributable, we could include it in our
'multiverse' repository. Please correct me if I make wrong assumptions
here.

I see 3 possible approaches to the problem. The first one would be a
package like the msttcorefonts package: On installing the package asks
the user for the location of the files needed (with a reasonable
default downloading url), and then installs the required files at the
right place and registers it with wine. We could include such an
installer package in ubuntu without much legal concerns, I think.

The 2nd approach would be to create a package including that Moz AX
control, but not including it into ubuntu. The user who want run
software which needs that control would be required to download the
.deb from the wine website. We do this approach with the packages
'w32codecs' and 'libdvdcss'.

The 3rd approach would be to ship a shellscript in the wine package,
which does the downloading an registering of the Moz AX control or a
package including this control. Please have a look at the file
/usr/share/doc/libdvdread3/examples/install-css.sh, which follows this
approach.

Both approaches are a bit ugly, but work around the problem that we
cannot ship unredistributable software. If wine would include
unredistributable parts in their source package, we would have to cut
them out, as we already do with quite some packages. That's the point
Stephan raised in this way to heated discussion. Please let's work
together so that we don't need to do that.

--
regards,
    Reinhard