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

On 11/28/05, Mike Hearn <mike at plan99.net> wrote:
> Incidentally, I've seen quite a few people report that the official
> mozilla.org binaries of Firefox are much faster than the Ubuntu versions.
> Maybe the reason is buried somewhere in that patch?

Please have a look at http://bugs.debian.org/mozilla-firefox and rethink.

> > Well, the download approach does not inflict redistribution problems for
> > distributors. So please keep the current solution.
>
> You're saying it's OK for a program to go automatically download something
> once it's been installed but it's not OK for that download to be included
> in the package. They seem equivalent to me, even with the VC++ runtime.

No, it may be equivalent from the upstream POV. It is definitely a
difference from the distributors POV, because this way, we are NOT
redistributing the VC++ runtime. I don't suggest that that download
should happen automatically and unasked. In my opinion, the user must
(at least should) have the possibility to choose if he wants to
download and run non free software to get additional functionality.

> > Then how about working with the packagers of the distribution in making
> > the packages better?
>
> Well, we did. [...]

So you are disappointed from the experiences you made in the past.
Well, you have to understand that we cannot speak for others. We can
only ask you to try again with us. In Ubuntu, our wine packages are
based on the work from Scott, not on the Debian ones.

> > wine is not completely standalone. If it was that easy as you try to
> > suggest, you wouldn't complain about bad packages, would you? I mean,
> > out of date packages are not the only problem you mentioned.
>
> Well, it requires tracking the dependencies of the application as they
> change from version to version, which as they're optional often doesn't
> happen. People assume that configure will bail out if a new dependency is
> added so they don't have to follow development (wrong), or that
> dependencies will never change (wrong).
>
> Beyond that it's easy. The problem is when people are tempted to "improve"
> things. For instance,  "hmm, regedit doesn't look
> very useful, I will split it up into an optional wine-utils package like a
> good packager" not realising that programs rely on it being there. So when
> a program crashes 10 frames deep on startup because it's missing a
> registry entry the installer should have created, but didn't because
> regedit was missing, you can easily spend 2-3 hours figuring out what went
> wrong. And when you find out it's not really a bug at all but an
> "improvement" - well it makes you angry. Your time was wasted by the
> system.
Do the Scott's packages inflict these kind of problems?

> Anyway. We've gone way off topic here. My original question was what's
> wrong with shipping PE EXE/DLL binaries in a Wine package, which was
> answered, and now we're on the topic of whether distributions should
> randomly change upstream decisions like what to ship. I don't see it going
> anywhere ...

To summarize the answers how I understood it (and so far nobody
objected): It should be okay to ship PE EXE/DLL in a binary package,
but not in the source package. These binaries must be created by a
free (as in speech) tool chain at build time, preferably with mingw32
because it is already in ubuntu.

Distributions should certainly NOT randomly change upstream decisions.
However it happens from time to time, that upstream makes decisions
which inflict problem on the usability of the package in a given
distribution. In that case, the package maintainer is free (and
sometimes obliged) to alter the upstream source.

This happened in fact with quite some packages that are distributing
unfree material in their upstream source. Prominent examples are
firefox, mysql (documentation is separate), mplayer (shipping a copy
of libdvdcss) and many others. Other cases include upstream releasing
only a tar.bz2 source taball (and no tar.gz). This is covered by the
Debian Developers Reference, chapter 6.7.8.2 [1].

In any case, a close and good relationship between package maintainers
and upstreams can avoid many confusion and problems.

[1] Debian Developers Reference, chapter 6.7.8.2
http://www.us.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-origtargz


--
regards,
    Reinhard