Loading ...
Sorry, an error occurred while loading the content.

Re: [Lilax] Re: [lalugs] Microsoft lobbying against the GPL

Expand Messages
  • Martin Baehr
    ... how does the GPL prevent forking? it doesn t. greetings, martin. -- i am looking for a new job anywhere in the world, doing pike development and/or
    Message 1 of 9 , May 8, 2001
    • 0 Attachment
      On Thu, May 03, 2001 at 10:47:34AM -0700, Dan Kegel wrote:
      > Ironic that in one breath they condemn forking, and in the next
      > breath they condemn the GPL -- the very thing that helps prevent
      > forking!

      how does the GPL prevent forking?
      it doesn't.

      greetings, martin.
      --
      i am looking for a new job anywhere in the world, doing pike development
      and/or training and/or unix and roxen system administration.
      --
      pike programmer On The Verge | www.hb2.tuwien.ac.at
      Los Angeles | db.hb2.tuwien.ac.at
      unix systemadministrator iaeste.or.at iaeste.tuwien.ac.at
      www.archlab.tuwien.ac.at black.linux-m68k.org
      Martin B"ahr stuts.org bahai.at mud.at is.schon.org
      http://www.iaeste.or.at/~mbaehr/
    • Dan Kegel
      ... True, I misspoke. But read on: Anyone forks a GPL d product and distributes forked binaries must also distribute the sources for their fork under the GPL.
      Message 2 of 9 , May 8, 2001
      • 0 Attachment
        Martin Baehr wrote:
        >
        > On Thu, May 03, 2001 at 10:47:34AM -0700, Dan Kegel wrote:
        > > Ironic that in one breath they condemn forking, and in the next
        > > breath they condemn the GPL -- the very thing that helps prevent
        > > forking!
        >
        > how does the GPL prevent forking?
        > it doesn't.

        True, I misspoke. But read on:

        Anyone forks a GPL'd product and distributes forked binaries must
        also distribute the sources for their fork under the GPL.
        (That's why some BSD fans don't like the GPL, I think.)
        Are we agreed so far?

        That means that the original codeline can then incorporate
        the fork's changes, bringing the two codelines back together.
        So the GPL doesn't prevent forking, but it does allow healing
        the damage caused by forks.
        Does that sound accurate to you?

        The BSD license is great for a lot of things, but it doesn't
        have this particular feature.

        Cheers,
        Dan
      • Martin Baehr
        ... absolutely. ... correct! greetings, martin. -- i am looking for a new job anywhere in the world, doing pike development and/or training and/or unix and
        Message 3 of 9 , May 8, 2001
        • 0 Attachment
          On Tue, May 08, 2001 at 06:26:02PM -0700, Dan Kegel wrote:
          > So the GPL doesn't prevent forking, but it does allow healing
          > the damage caused by forks.
          > Does that sound accurate to you?

          absolutely.

          > The BSD license is great for a lot of things, but it doesn't
          > have this particular feature.

          correct!

          greetings, martin.
          --
          i am looking for a new job anywhere in the world, doing pike development
          and/or training and/or unix and roxen system administration.
          --
          pike programmer On The Verge | www.hb2.tuwien.ac.at
          Los Angeles | db.hb2.tuwien.ac.at
          unix systemadministrator iaeste.or.at iaeste.tuwien.ac.at
          www.archlab.tuwien.ac.at black.linux-m68k.org
          Martin B"ahr stuts.org bahai.at mud.at is.schon.org
          http://www.iaeste.or.at/~mbaehr/
        • Christopher Smith
          ... Hmm... I looked at his article, and the citing he makes about Lucid emacs (XEmacs) vs. GNU Emacs is really innaccurate. The truth (as I remember it) was
          Message 4 of 9 , May 9, 2001
          • 0 Attachment
            On Wed, May 09, 2001 at 08:21:15AM -0700, Steve M Bibayoff wrote:
            > Which all of this begs the question could anyone point to a fork in GPL
            > code that wasn't completly forked because of direction of use(Linux x86
            > vs. Linux PPC) or eventually recombined(gcc vs. egc)?
            >
            > An clearer explantion of what I am trying to ask was presented at
            > a "brown-bag presentation" at Linuxcare by Rick Moen. A recap is
            > here:http://www.linuxcare.com/viewpoints/article/11-17-99.epl
            > There is an updated version on Rick's server(linuxmafia.com), but it
            > appears to be unreachable at the current moment.

            Hmm... I looked at his article, and the citing he makes about Lucid
            emacs (XEmacs) vs. GNU Emacs is really innaccurate.

            The truth (as I remember it) was that proprietary emacs's where being
            built from public domain emacs code back before GNU emacs
            existed. Probably the most well known of these was Gosemacs (short for
            Gosling emacs --yup, written by the same guy who brought us
            Java). This pissed off a number of people, but in particular it
            provided a lot of motivation for RMS to start up the GNU project & the
            FSF.

            Part of this project created GNU emacs. GNU emacs proved to be a damn
            good version of emacs, and Lucid decided they would like to use it as
            a foundation for the Unix development tools. However, they needed some
            more features in it. At this time we were back in the era of GNU Emacs
            18, which was pretty ignorant (really completely ignorant) about
            GUI's. The FSF was already working on GNU Emacs 19, which among other
            things would be GUI-aware. Lucid actually hired a GNU developer to
            work on building GNU emacs 19. However, for a ton of reasons (both
            technical and social) that JWZ describes better than I can, Lucid
            and GNU were unable to align their goals. Rather than abandoning the
            substancial development efforts they'd already made Lucid proceeded to
            continue independantly on their efforts. Of course, GNU emacs fell
            under the GPL (and had since GNU Emacs version 1), and as such, Lucid
            had no choice but to release the source code for their "enhanced"
            version once they distributed the product. This was zero problem for
            Lucid because they had intended to do this all along, the only thing
            that changed was that their version was a fork with the FSF's own
            version.

            Eventually Lucid Emacs became XEmacs. However, it's worth emphasizing
            that Lucid/X Emacs was NEVER anything but free software, and we can
            thank the GPL for this.

            In terms of popularity, I'd say Emacs is as popular as it ever was
            (arguably not a grand achievement ;-), XEmacs and GNU Emacs enjoy a
            surprising amount of compatibility, and I wouldn't exactly say that,
            within the Emacs community, GNU Emacs has an overwhelming
            representation compared to XEmacs.

            Just wan't to clear that up. ;-)

            --Chris
          Your message has been successfully submitted and would be delivered to recipients shortly.