JGroups to investigate adopting Apache License 2.0

We've started to investigate whether JGroups can change its license from LGPL 2.1 [1] to Apache License (AL) 2.0 [2]. If possible, the next JGroups release will be licensed under AL 2.0.

The reason for the switch is that AL 2.0 is more permissive than LGPL 2.1 and can be integrated with other projects / products more easily. Also, AL 2.0 is one of the most frequently used licenses in the open source world [3], and you can't go wrong with that, can you ? :-)

I've received quite a number of requests to change the license over the years, from the open source community and from companies trying to integrate JGroups into their products.

This change should increase acceptance of JGroups with other open source projects or commercial products.

So what would the impact of this change be ?

• For projects / products using a current (<= 3.3) JGroups release, nothing would change (they're still licensed under LGPL 2.1)
• For projects / products upgrading to the AL licensed release (once it's out), nothing would change; the AL 2.0 license is even more permissive

Let me repeat this, nothing would change except that LGPL skeptics should now be able to use JGroups.

Note that Infinispan is looking into making the same change, see [4] for details. As Infinispan consumes JGroups, it is important for JGroups to have the same license as Infinispan, or else integration would be a nightmare; it's hard (if not impossible) for an AL project to consume an LGPL project.

Changing the license would be done in the next JGroups release. Whether this will be 3.4 or whether a license change warrants going directly to a 4.0 is still undecided.

We're currently working with Red Hat's legal department and the community to see whether this switch is possible and what needs to be done to make it happen.

Opinions ? Questions ? Feedback ? Please post to this blog, or the JGroups mailing list.

Cheers,

[1] http://opensource.org/licenses/LGPL-2.1
[2] http://opensource.org/licenses/Apache-2.0
[3] http://osrc.blackducksoftware.com/data/licenses
[4] http://infinispan.blogspot.co.uk/2013/05/infinispan-to-adopt-apache-software.html

JGroups 3.3.0.Final released

I'm happy to announce that JGroups 3.3.0.Final was released today.

It contains quite a few optimizations and new features, the most prominent ones being:

• Message batching: messages received as bundles by the transport are passed up as batches. Compared to passing individual messages up the stack, the advantage is that we have to acquire resources (such as locks) only once per batch instead of once per message. This reduces the number of lock acquisitions and should lead to less context switching and better performance in contended scenarios.
• Asynchronous Invocation API: This allows the recipient of a message in MessageDispatcher or RpcDispatcher to make the delivering thread return immediately (making it available for other requests) and to send the response later. The advantage is that it is the application which now decides how to deliver messages (e.g. sequentially or in parallel), and not JGroups. The documentation is here: http://www.jgroups.org/manual-3.x/html/user-building-blocks.html#AsyncInvocation
• UNICAST3: this is a new reliable unicast protocol, combining the advantages of UNICAST (immediate delivery) and UNICAST3 (speed). It is the default in 3.3.
• New internal thread pool: to be used for internal JGroups messages only. This way, important internal JGroups messages are not impeded by the delivery of application messages ahead of them in delivery order. While this pool is not supposed to be used by application messages, it will help for example to decrease unneeded blocking (by credit messages getting queued up behind application messages), or reduce false suspicions (due to heartbeats getting handled too late, or even getting dropped).
• RELAY2 improvements: RELAY2 is the protocol which relays traffic between geographically separate sites. This will be the topic of my talk at Red Hat Summit in June.
• New timer implementation: a better, simpler and faster implementation; the default in 3.3.
• New message bundler: this new bundler handles sending of individual messages and message batches equally well. Default in 3.3.

A more detailed version of these release notes can be found at [1]. The documentation can be found at [2]. The JIRA is at [3].

Please post questions and feedback as usual on the mailing list.


[1] https://github.com/belaban/JGroups/blob/3.3/doc/ReleaseNotes-3.3.0.txt

[2]  http://www.jgroups.org/manual-3.x/html/index.html

[3] https://issues.jboss.org/browse/JGRP