Wine versions + future
Martin Wilck <[email protected]>
| Newsgroups | gmane.comp.emulators.wine.license |
|---|---|
| Message-ID | <[email protected]> |
Hi all,
not having cared about the licensing issues a lot in the past,
I have read the last threads in this list with increasing concern.
What bothers me most is the perspective of different independent
wine versions emerging and the gaps between them widening.
The FAQ already lists 7 different versions, and probably there are
more to come (Lindows?).
Apart from the fact that this takes variable coding time away for
maintaining branches, merging etc., my main concern is the confusion
it causes.
IMO what users want is a single version of wine that (ideally) handles
all Windows applications. Currently a user may need to install
- crossover plugin for surfing
- crossover office for productivity
- winex for gaming
- cvs wine (rewind?) for some other applications that need the hottest
wine features.
From my experience, maintaining different versions of wine on the same
computer and associating each app with the "suitable" version is a pain in
the neck and definitely nothing we want Linux newbies or fresh
Windows-Linux converts to administer.
While for some users the decision which wine to install may be simple
according to their preferences, others may be totally confused and
stay with Windows or VMware instead. Even worse for Linux distributors:
Faced with a broad range of possible user preferences, which wine version
should they package? Or should they take on the work of installing
several versions and resolving the issues related to that?
IMO this is will be a major obstacle for the future success of wine.
As all of us, from freedom-loving spare time hacker to company owner,
are equally interested in wine's breakthrough, I think it is
absoultely crucial that the issues that have lead to the version
separation be resolved and resolved quickly. In the current situation,
that obviously requires a substantial readiness for compromise on all
parts.
I don't think that "code trades" for particular pieces of code
are the way to go - rather a general, reliable procedure for coexistence
of "free" and "commerical" wine versions must be found (e.g. an Aladdin-
style agreement where it is guaranteed that commercial additions become
part of the free tree after a certain, predefined amount of time,
and companies in turn may use the free wine's full features).
Technically we must reach a point where there is no commercial wine,
but only commercial addon modules for wine (additional or replacement
DLLs, for example) that are able to coexist with each other and enhance
the free wine's capabilities.
You may call me naive because I haven't elaborated on the license
issues that are at the core of the wine tree's branching. While
I tend to favor xGPL, I would be content with a different free software
license if it resolves this branching mess.
However reading through the last threads, I find a number of arguments
I simply can't buy, especially those about the hypothetical
future platforms wine may not be able to support if it's LGPL.
We have an enormous potential user base now, and its vast majority
wants to run standard windows apps on standard PCs running standard Linux
installations (if there is such a thing as a standard Linux installation).
Do we want these people to be turned away by the current confusion just
because we think there may be some others on future exotic platforms that
perhaps cannot use it? Why don't we just wait
if such a system ever appears, and react when that happens? If the
relationship between the free wine community and the companies involved
were good, I am very confident such an issue could be resolved.
Unfortunately this relationship seems to have become pretty tense lately,
which is bad for resolving any issues.
Just my 2 cents.
Martin
PS: I herewith state that I was expressing my personal views in this
email. These were not views of my company.
--
Martin Wilck Phone: +49 5251 8 15113
Fujitsu Siemens Computers Fax: +49 5251 8 20409
Heinz-Nixdorf-Ring 1 mailto:[email protected]
D-33106 Paderborn http://www.fujitsu-siemens.com/primergy