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

On Sun, 27 Nov 2005 19:14:43 +0100, Stephan Hermann wrote:
> Ok, thinking about that, the e.g. Mozilla devs are providing you with a 
> complete different binary then the original Mozilla? 

Well yes. This already happens - you can't patch Firefox and still call it
Firefox. Their trademark policy doesn't allow that.

> Wow...I need at least for the supported environment one commercial compiler 
> tool chain from MS.

I think you're being distracted by the specifics of the Mozilla project
here. I don't really care what their standard compiler is on Windows. I
don't have any objection to the idea that free software should be
buildable, of course it should be, but nobody ever implied it wouldn't be.

It was suggested that Wine may be shipping pre-compiled executables in
future: in fact we already do this in a way, as Wine will try and download
the Mozilla ActiveX installer the first time it's needed, so it makes no
difference whether it's included in the package or not. Including it
would be convenient for the user because it means they won't be disturbed
by a download popping up at some point (and a few programs don't expect
loading a widget to trigger downloads), but the bits on the hard disk are
the same at the end. So it makes no sense for you to say "we will not
include this" because the source code will already fetch it if it's
missing.

> The second view is the distributor and packagers view. The packager has to 
> provide support for his package, even when upstream doesn't exist anymore, 

That's not true. This whole idea of packagers being separate from
"upstream" is bogus - people who are interested in using and developing
the software can support it regardless of what platform or distribution
they use, by working together. There's no requirement that lone
individuals from Foobar Linux be able to do anything. And I still haven't
seen a definition of "support". What does this mean? Fix bugs? Answer tech
support queries? Add new features? Why does a packager "have" to do this,
instead of the community of interested and qualified users?

> Well, then you should change your license and/or kick the users to use
> something else then the supported distribution package manager.

Actually for a long time the stock answer to Wine tech support queries is
"did you try building from source yourself", and I'd say this clears up
about 50% of problems. Usually because the distro has provided wrong
packages, or out of date packages, or both. So in a way we already do the
latter.

> That's why the packager is responsible for the software he packages. If
> upstream would tell bugreporters to ask their distributors first, you
> wouldn't have any problems. 

Your solution to "packagers introduce bugs" is "bugs should be
reported to the packager first"? What a strange idea - why not just
eliminate this middle layer entirely and have packaging be an upstream
community effort like documentation or artwork. This way we don't have to
deal with people who think it's funny to compile out logging code, or wrap
programs in strange scripts that break upgrades, or who "fix" non-existent
security holes.

> Everyone is happy and it works. 

Sorry. My actual experience of being a real world upstream developer in
several different projects is that everybody is not happy and the system
does not work. 

More, for programs like Wine that are completely standalone I do
not see what value this system of packagers provides. It only adds work,
and thanks to things like freedesktop.org standards the software can be
installed from source in the exactly the same way everywhere and it works
just as well (or better).

-mike