Wine BSD Fork 'Rewind' Emerges

Moridineas writes: "Since the wine project decided to change from an X11 style license to an LGPL license, a BSD fork has emerged, called Rewind (for 'Re-engineering Windows,' or something like 'Rewind to the old Windows days' in the words of Ove Kaaven) and currently hosted at http://rewind.sourceforge.net (but looking for a new home). The announcement of the fork and some additional information was posted to the wine-license mailing list [winehq.com]. At least one company [transgaming.com] has already stated that they will not be able to work with the LPGL wine (citing among other things, possible DMCA violations) and will be actively helping Rewind (with cash and code it seems)."

Comments

I find this cool!

[mirabilos]

If this is going to be a more qualitative version
of Win32 I find this really cool.
Ok, Microsoft will be able to integrate parts
of Rewind into Windows, but, hey, BSD spirit is
not "Let's make free software better!" but more
like "Let's make _all_ software better!"
Probably even some folks at Microsoft will be able
to contribute to Rewind - hey am I dreaming?
Anyways, let's see which one will be better than
the other one, which evolves to the more accepted.

If only the Rewind developers would care about it
running on OpenBSD... the last Wine that did is
from 1999, because it is said to require new
binutils (which OpenBSD doesn't have on i386
because it uses a.out-bsd format and not ELF)
and kernel threads.

Re:I find this cool!

[tps12]

which OpenBSD doesn't have on i386 because it uses a.out-bsd format and not ELF

Is that true?

Re:I find this cool!

[mirabilos]

Yes, it is true at the moment, but more and more
architectures are switching to ELF/OLF, and i386
will be amongst them until 3.3, but probably even
3.2 - as Art has received the gcc/binutils config
he had requested, he will probably do it soon.
You can look for ELF on http://marc.theaimsgroup.com/
on the OpenBSD mailing lists (I think it was on
misc@).

Re:I find this cool!

[tps12]

That really surprises me. Doesn't the use of .so dynamic libraries depend on ELF? I thought that was why Linux, NetBSD, FreeBSD, etc. switched in the first place. Or does OpenBSD use some kind of improved a.out on steroids?

Also, how come OpenBSD has way better "album covers" than any other OS? No offense to Linus Torvalds, but the penguin is pretty dumb. Worse even than the BSD "daemon", and definitely no match for that puffer fish or whatever. Also, the name "Tux" is dumb...it is not clever to point out that penguins look like they are wearing tuxedoes. It would be much better if the mascot were a guy in a tux whose name was "Penguin". Haha. Also, is "Tux" supposed to rhyme with "Linux"? That means it's either pronounced "Tix" or "Toox", both of which sound stupid and make no sense.

Re:I find this cool!

[Guy Harris]

Doesn't the use of .so dynamic libraries depend on ELF?

No. The first UNIX to use that particular flavor of dynamic libraries was SunOS 4.0, which used a.out. (NOTE: I said "that particular flavor of dynamic libraries", not "dynamic libraries".)

The BSDs that had dynamic libraries originally used a.out as well; one could think of the a.out that SunOS 4.x and the BSDs used as an "improved a.out on steroids".

The System V Release 4 shared library mechanism was derived from the SunOS 4.x one; some of the things put into ELF (which was the executable image/shareable image/object file/core dump format devised by AT&T for System V Release 4) were done to better support that shared library mechanism. The free UNIXes that use ELF use reimplementations of the SVR4 shared library mechanism.

Systems using the Linux 1.x kernel didn't use a SunOS 4.x-style shared library mechanism, although it might have been possible to implement it if the 1.x kernel supported calls to memory-map files; perhaps 1.x lacked those calls.

Re:I find this cool!

[mirabilos]

Actually, the special a.out flavour used by OpenBSD
for everything (on i386 et al.) is called NETBSD_NATIVE.
You can also find a lot more hints at the NASM
(Netwide ASseMbler) page at http://nasm.2y.net
The format is called aoutb (in contrast to aout)
and fairly modern, there is (in the nasmdoc) a
tutorial how to write shared libraries, which also
explains the few (user-visible) differences like
the traditional underscore.
By the way, if ELF hadn't been underscore-less,
we would have gas with .intel_syntax not needing
those cruelful % signs before the registers.
That sucks (which does GNU, anyway, but with GNU
it is like with democracy: choose the smaller bad).

Re:I find this cool!

[mirabilos]

OpenBSD is a.out-bsd, on i386.
With regards to the other arches, I do not operate
them so I don't know it without having to look.

But the source is free, try it yourself:

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/ar ch /

Wine will still be number 1

[Eivind]

This project will always lag behind the Wine-LGPL tree.

The reason is simple. Anyone can take code under the X11-license and relicense it under the LGPL, while it is not allowed to distribute code under the LGPL under a X11-license.

The practical upshot of this is that any improvements to the Rewind tree can be instantly copied into the Wine-LGPL tree, while any new functionality or bugfixes in Wine-LGPL has to be clea-room re-implemented to go into the Rewind-tree (unless the contributor licenses his contribution under X11-license like some contributors have said they will.)

Re:Wine will still be number 1

[tps12]

Well, the nature of the fork is that after a short while the two code bases will probably differ by enough that patches to one will not be immediately relevent to the other. By the same token, the developers of the two projects will probably become fairly disjoint. It'll be interesting to see where they both end up going. If Rewind is going to be the path of choice for commercial interests, then we will probably see more of Wine's top goals (running Office and the more popular games) being accomplished in Rewind. Then Wine will likely develop a new focus (Wine CE? Or tighter integration into Gnome? Lots of ways to go...). It'll be fun to see what slashdot story is posted about these project a year from now. (Even more fun than seeing what slashdot story is posted about them next Wednesday.)

Re:Wine will still be number 1

[rubinson]

It'll be fun to see what slashdot story is posted about these project a year from now. (Even more fun than seeing what slashdot story is posted about them next Wednesday.)

Given Slashdot's track record, it'll probably be the exact same story!

This is the wrong approach

[Ogerman]

At least one company [transgaming.com] has already stated that they will not be able to work with the LPGL wine (citing among other things, possible DMCA violations) and will be actively helping Rewind (with cash and code it seems)

First of all, the DMCA is an unconstitutional law and it needs to be fought tooth and nail until it is defeated. Transgaming should not be required to implement copy controls for their emulator to be both useful and legal.

Second, this is more about Transgaming's business model than anything else. It's incompatible with LGPL because they require the ability to sell "value-added" proprietary versions of Wine. Since they don't own Wine, they are unable to dual-license it--such as making the old free and the new proprietary. Now, if we can trust them to release improvements back to the BSD codebase, this is fine. I, for one, would be more inclined to support them if they stuck with LGPL and just let subscribers control by vote the direction of development (ie. which games to support). Here's another idea: Proprietary game developers themselves! If game companies could pay Transgaming to support their latest and greatest games in Linux, don't you think their sales would rise? It would be sort of like Loki, except ensuring emulator support would be alot easier than porting. Then game companies could put stickers on their games that say "Works with Linux via Wine!" Or they could even include a Wine install kit (unsupported of course).

Transgaming

[ulmanms]

From their page:

The LGPL would dictate that we publicly release the source code to our copy-protection support - an action which would violate the tenets of the US Digital Millennium Copyright Act (DMCA)

Now, I've never used their software, but wouldn't the breaking of the copy protection be the part that the DMCA would have a problem with, not the publishing of how to do so? ElcomSoft wasn't publishing how to crack ebooks, but that didn't help Dmitry.
I'm sure Transgaming knows more about why they can't use the LGPL than I do, but this part seems inconsistent to me.

DMCA

[rodentia]

I believe the issue is that TransGaming's copy-protection support, which is a major feature incenting game shops to work with them, could be construed at law to constitute a circumvention technique against the game's copy-protection. Remember that the DMCA is concerned about sustaining copy-protection, not interdicting code. It remains technically illegal for one to explain how deCSS works, let alone write code to do it.

Re:Can someone explain to me...

[spongman]

no, that doesn't make sense, but that's not what the article says. read it again.

No thats not it

[HanzoSan]

Transgaming doesnt sell software, you subscribe to a service which funds development of the software.

The software is free, however they CANT release the binary version of wine because it uses securerom and other licensed code.

They cant release the 3d game code because not enough users subscribed to pay for it.

Nothing is being sold, you subscribe to pay for the development of the code when transgaming can pay for that development the code is released to you

Re:Translation of their "PRESS RELEASE"

[HanzoSan]

Transgaming needs to make money, why dont you subcribe and help them RELEASE their code if you want it so bad.

Wrong

[HanzoSan]

Transgaming will take Rewind, and add their own code to it then just release a binary.

Transgaming will only release to Rewind when they get enough subscribers to pay for the release of code

You see, the Rewind tree is NOT GPL which means it will always have corperate support

DCMA is US only you know

[horza]

Why not just host the software in Europe (and have it's theoretical 'base' there)? We are unencumbered by oppressive regimes such as the USA. Remember PGP and other encryption packages, where you could download secure versions from Europe but could only obtain crippled versions from the USA? This was used as evidence that the law was driving hi-tech business overseas and the US law was changed. Perhaps you could achieve the same with the DCMA?

Phillip.