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
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
Would be interesting as it would ease adoption into Apache project and would qualify directly for corporate entities which have a restricted set of preferred licenses.
ReplyDeleteI am trying to port the latest 3.4.0.Alpha1 version of JGroups to Android...but its deep integration with JMX is very annoying to me to disable since JMX is not available under Android (an attempt to make sure Jgroups codebase can support Android and be merged back to master git without side effects).
ReplyDeleteBesides that, why are the Byteman script files not referred correctly: "conf/scripts/.." instead of "scripts/..."? Thanks for the latest correction to the Maven pom file; I've managed to run Maven under Eclipse Juno IDE, though some plugins have no version id.
I am trying to port the latest 3.4.0.Alpha1 version of JGroups to Android...but its deep integration with JMX is very annoying to me to disable since JMX is not available under Android (an attempt to make sure Jgroups codebase can support Android and be merged back to master git without side effects).
ReplyDeleteBesides that, why are the Byteman script files not referred correctly: "conf/scripts/.." instead of "scripts/..."? Thanks for the latest correction to the Maven pom file; I've managed to run Maven under Eclipse Juno IDE, though some plugins have no version id.
The integration with JMX is not really deep; we use annotations @ManagedAttribute and @ManagedOperation to expose attributes and methods via JMX. You could probably simply replace classes ResourceDMBean and JmxConfigurator in org.jgroups.jmx with Mock classes to get rid of JMX support. Or even better, make it configurable, then this change could go back into the main code base...
ReplyDeleteRe the Byteman scripts: I set the classpath to be ./conf, so ./scipts is sifficient, when executing BM tests. Can't you simply remove the tests directory ?
Thanks Belas...
ReplyDeleteHow portable will it be to be mergeable to the main codebase when we have static Java import package references not supported by Android?
For example, in org.jgroups.util.Util.java, I have to disable all Java import packages of java.lang.management.*, javax.management.* just to disable (comment out) dumpThreads(), _printThreads(), getMBeanServer() and registerChannel().
If I don't remove/disable (comment out) them, they will trigger errors in an Android build.
Besides that, I could not find a way to exclude tests/junit-functional/org/jgroups/tests/JmxTest.java from build-helper-maven-plugin's 'add-test-source' execution goal which needs the source tests/junit-functional.
Any ideas?
Thanks for your idea.
ReplyDeleteNow, how to make a cross-platfrom version of JGroups so that it can be merged into the main codebase when we have some Java import package references not supported by Android and removing those tests directory that may be needed to test a JGroup build?
For example, in org.jgroups.util.Util.java, I have to disable all Java import packages of java.lang.management.*, javax.management.* just to disable (comment out) dumpThreads(), _printThreads(), getMBeanServer() and registerChannel().
If I don't remove/disable (comment out) them, they will trigger errors in an Android build.
Besides that, with Maven, I could not find a way to exclude tests/junit-functional/org/jgroups/tests/JmxTest.java from build-helper-maven-plugin's 'add-test-source' execution goal which needs the source tests/junit-functional. The best way is to reorganize the tests directory so that JmxTest.java can be excluded from a test.
Any ideas?
Yes, you probably have to modify Util, should be pretty simple though... unless you want to automate this.
ReplyDeleteRe JmxTest: I don't use the maven build, so I don't know