Slashdot Mirror


Jive Software To Open Source Its Jabber Server

fernique writes "Jive Software, a leading provider of knowledge-based support software, announced today that it will license its Jive Messenger application under the GPL Open Source license. Jive Messenger, based on the open IETF standard XMPP protocol, is a Java-based server for comprehensive group chat and instant messaging (IM)."

15 comments

  1. Not a standard ... yet by dago · · Score: 3, Informative

    Btw, XMPP isn't a standard yet, just a draft and soon to be published RFC.

    --
    #include "coucou.h"
    1. Re:Not a standard ... yet by fernique · · Score: 2, Informative

      Yeah, its work is still in progress. And in addition to XMPP proto there are JEPS (Jabber Enhancement Proposals), which update more frequently than core.

      --
      igor
  2. Componentisation and GPL by tod_miller · · Score: 3, Interesting

    If I write an application that, for instance, sends faxes. You could use a closed source driver for this, or you could use a GPL'd driver for this.

    Right? Now, if I wrote a game, that wanted to use this GPL jive, what level of abstraction would allow me to use this (ditribute is as a 'suggested' compatible chat server) wihtou GPL'ing my own code?

    This is more of a query that has laid dormant in my mind, now I see this (and that open source voice recognition) and I think more abou tit. Not that I do not want to relewase the source of my own app - just wondering.

    I will look at this. (Jive software I heard about them in a negative context a while back, or was that Jive forums? blast)

    --
    #hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
    1. Re:Componentisation and GPL by Anonymous Coward · · Score: 1, Informative

      It's cool as long as you're not linking with GPL'ed code. (You can generally link with LGPL'd libs if you don't modify them).

    2. Re:Componentisation and GPL by fuzzbrain · · Score: 2, Informative

      My understanding is that if you were to write an external component that communicated with the server over tcp/ip then it doesn't matter what license that component uses, even if the server itself is gpl. But if you want to write a module that integrates with the server internally then you do need to worry about licenses...

      Jive software are the same people who put out the smack xmpp java library which is imho very well written, so I suspect that the server is also quite good.

      It's good to have another opensource jabber server as I think jabberd2 has been a bit of a disappointment. I doubt it will be as good as ejabberd though.

    3. Re:Componentisation and GPL by tod_miller · · Score: 1

      in Java terms. If I don't import, but I use some kind of classloader lookup (based on user pref) and cast it to an interface (sorry to be so blunt!) so I talk to this 'mystery' GPL / nonGPL library, can I jsut let loose my code, heck, and even send a copy of the GPL stuff (redist allowed!) as a suggested thungamyjib(TM), which works with it (since I knew it would)

      Of course, problem here is, you would need to modify the GPL code to work with you interface, which is fine, because you will send your version back, and if you distribute it, you will send you code changes, and with that seperate project,keep to the GPL.

      Any opposition to this? Am I wrong? Seems like a simple 'get around'.

      --
      #hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
    4. Re:Componentisation and GPL by theCoder · · Score: 1

      Keeping in mind that IANAL, I think you are wrong. This isn't very "legal speak", but the general idea is that if you "need" a GPL'd library in order to build your app, then your app is a derivative work, and must also be licensed under the GPL (if you give it to anyone). In C/C++, "need" means you're including the header files and linking with the library. In Java, I guess "need" would mean the library's .jar or .class files must be present for the compiler to get method signatures.

      Your idea of a buffer library isn't going to work because the GPL is viral (I'm not saying that's good or bad, just that it is). Because your buffer library needs the GPL library, it becomes GPL'd itself. Since your app links with it, it would be GPL as well. At least I think that's how it works. What I'm not entirely sure about is the idea that you could relicense your buffer library to yourself under a license that doesn't require your app be GPL'd. I don't know if that would be technically violating the terms of the GPL, but it would be violating the spirit of the terms.

      The authors of a GPL'd library made a choice to restrict their library to only other GPL applications. Other library others choose less restrictive licenses like the LGPL. It may be unfortunate you can't use a GPL library in your non-GPL app, but you do have to respect the author's choices (and the authors have to accept that their library might not gain as wide acceptance because of their library). The only way to "get around" the GPL would be to contact the authors and see if they would license the application (possibly for a fee) under terms you could accept.

      --
      "Save the whales, feed the hungry, free the mallocs" -- author unknown
    5. Re:Componentisation and GPL by tod_miller · · Score: 1

      I am aware of LGPL - of course.

      What I am suggesting is:

      Nice Library, GPL

      Modify library, keep it GPL, but implement your interface...

      aah, I see, the interface becomes GPL... UNLESS the interface is:

      Interface (non GPL)
      |
      |
      GPL Library--- via interface ---- Your non GPL library

      THis would mean that realistically and technically, you could ENABLE GPL'd software, like drivers, to work with your proprietary code.

      The 'Interface' (which needs to be the same class loaded object for it to be the same interface) ... *thinks* Of course, the interface is in package abc, GPL'd XYZ uses ABC, and you use ABC.

      Now the problem would be: a GPL'd program might not be allowed to contain one interface class that comes from a non-GPL'd package, but as you said, you could relicense it to yourself.

      The reasons for this are twofold:

      If you wanted to interoperate some software that was GPL/LGPL in the same way ('drivers'), as a benefit to OSS, or slightly malisciously, and use a GPL speech recognition software in commercial software, using a standard.

      Of course, you could easily write a network layer that abstrasts it all through XML, and GPL that, and then just support anything that uses that network layer, even you proprietary software.

      So that is completely legit. [I think GPL means you can distro your modifications is the source is available, and of course, you have no objects releasing simple XML hooks that you want to use on the GPL'd library.

      You crush the software back into just data. You use it in a black box. anything could be in there.

      Is this against the spirit of GPL?

      --
      #hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
    6. Re:Componentisation and GPL by mikefe · · Score: 1

      Yeah, I think abou' tit too.

      But what does that have to do with the -- Ohh!

      --
      There: Something at a specific location.
      Their: Owned by someone.
      Please make sure your english compiles.
  3. Hmmm, ejabberd you say.... by VasiliTerkin · · Score: 2, Interesting
    One thing that stops me from immediately jumping onto Jive jabber server is the seemingly absent internalisation support.

    I glanced at ejabberd recently and was initially spooked by the choice of the language - Erlang. Thought it was some obscure toaster programming language. Turns out its from Erricsson, opensourced, and designed for fault tolerance and things like routers and servers.

    Can someone point to a good review of the most common, free Jabber servers? (Possibly for Windows: Jabberd 1.4.x; Erlang; some Java ones, now including the Jive)

    The Jabber.org's server features page is a good start, but says nothing of reliability and general feel.

    1. Re:Hmmm, ejabberd you say.... by j3110 · · Score: 1

      If it's part of the XMPP spec to do internationalization, then it may not...

      On the other hand, if XMPP relies on XML encodings, I'm sure it will. Java natively supports unicode as it's default character encoding. All the XML parsers support UTF-8 as well.

      --
      Karma Clown
  4. Wasn't Jive Forums once GPL based? by EnronHaliburton2004 · · Score: 1

    If I remember right, Jive Forums used to be an GPL'd open source project? This was in the Jive 1.x or 2.x days. Then the company forked the code, and the next branch was not GPL anymore ...

    This was somewhere between 1999 and 2002, anyone remember this? I was last looking at Jive about 8 months ago, but now I can't find the history any more ....

    1. Re:Wasn't Jive Forums once GPL based? by General_Corto · · Score: 1

      Yes - one of my former co-workers is on the staff of Jive Software as a result of the additions he made to the forums. I added a couple of pieces of functionality too. Version 1 was Apache licensed I believe.

    2. Re:Wasn't Jive Forums once GPL based? by Anonymous Coward · · Score: 0

      Yes upto 1.2.4 (IIRC) it was open above 2.x it became commercial.

  5. Submitter forgot to add.... by sproketboy · · Score: 1

    ... and since it's Java, it performs almost as fast as C and C++!
    :)