Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Wine Software

Wine BSD Fork 'Rewind' Emerges 55

Posted by timothy from the backwards-compatibility dept.
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)."
This discussion has been archived. No new comments can be posted.

Wine BSD Fork 'Rewind' Emerges More

Wine BSD Fork 'Rewind' Emerges

Comments Filter:

  • I find this cool! (Score:3, Informative)

    by mirabilos ( 219607 ) on Thursday April 18, 2002 @01:40PM (#3367355) Homepage
    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.
    • which OpenBSD doesn't have on i386 because it uses a.out-bsd format and not ELF

      Is that true?

      • 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@).
        • 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.

          • 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.

          • 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).
  • Why in this article are there *BSD Trolls when this article is about a fork of WINE which still uses Berkeley license instead of LGPL. WINE would in a good thing to have a BSD like license on because corporations can use it for their apps and change it according to their needs and their code and not release that info. Code which is not in GPL is still can be Free Software, http://www.gnu.org/.

  • Wine will still be number 1 (Score:3, Interesting)

    by Eivind ( 15695 ) <eivindorama@gmail.com> on Thursday April 18, 2002 @02:02PM (#3367600) Homepage
    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.)

    • 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.)
      • 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!

    • Re:Wine will still be number 1 (Score:1, Informative)

      by Anonymous Coward
      I tend to doubt that. A lot of developers are jumping ship for the free BSD-based Wine, and it has multiple companies' support behind it, which the LGPL Wine doesn't have. I don't expect them to be around much longer at all.


    • 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

  • This is the wrong approach (Score:3, Interesting)

    by Ogerman ( 136333 ) on Thursday April 18, 2002 @02:20PM (#3367748)
    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 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

  • Transgaming (Score:2, Informative)

    by ulmanms ( 106454 )

    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.

    • 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.
  • If Transgaming can't help rewind because of possible DMCA violations then why are they contributing code and cash?

    Is it just me, or does that not make sense?
  • TRANSLATION:
    They want to benefit from the work of others for free, but they don't want to share the changes they have built on top of the hard work done by the original developers. GJC

    P.S. Please don't mod me down as I am not trolling, just speaking the truth. :)
  • 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.

Slashdot Top Deals

The clash of ideas is the sound of freedom.

Close