Red Hat and the JBoss Community recently announced that they will be releasing a single compiled binary under the EAP.Alpha terminology, rather than posting a community release on the community site and a separate EAP early release on the Red Hat site. This naming change has confused some members of the community, but rest assured the EAP.Alpha release is still under the LGPL as per previous JBoss Community releases.
The first release following this new strategy is version 6.1.0.Alpha, which can be found and downloaded from the JBoss Community website. This is causing some confusion, as the general community is asking (among other questions): What happened to, and where is, the JBoss AS 7.2.0.Final release?
The Details of the Change
On March 7th, Mark Little, senior director of engineering at Red Hat, explained that “from the point where we start to productise the community project . . . we will release all product builds that we create as a result of this process into the community.”1 The FAQ page goes on to explain that “[t]he first EAP stage Alpha is of equivalent, or better, quality to a community Final release.” After the EAP.Alpha release, there will be no other community binaries provided for that community major release, but community builds will happen, allowing contributions to be made and tracked.
Little explains the rationale for this change as a response to complaints that “the community is lagging behind the products, or that we’re not as responsive as some might want us to be because of our product focus,” and the goal to give the best possible experiences to JBoss customers and the wider community.2
EAP.Alpha is licensed under LGPL version 2.1 or later, just the same as previous community releases. Also as before, EAP releases other than Alphas, are available only with a paid production subscription or no-cost developer subscription, which restricts the use of binaries to development purposes only, not to be deployed into production environments.
Why This Is Confusing
Traditionally, EAP releases have been based on the community’s release. For example, EAP 4.x was based on JBoss Community 4.x, and EAP 5.x was based on JBoss Community 5.x. However, Red Hat decided not release an EAP version of JBoss 6.x because this was more of a transition release – preparing for JBoss AS 7. Thus, Red Hat’s EAP 6.x became based on JBoss Community 7.x. This was a point of confusion, as the numbering no longer lined up between the two versions.
Some of the confusion over this announcement may also be a result of the association of “alpha” with an initial and potentially unstable software release. But what’s in a name? All open source software is offered “as is,” with no warranties regarding fitness for a particular purpose, merchantability, and so forth. And yet many organizations, from Fortune 100 corporations to backyard start-ups, use all kinds of open source software in the production environment successfully.
As mentioned above in the case of JBoss, the alpha version is “equivalent, or better, quality” to the community version. Let’s be clear, so long as any version of JBoss (or any software), and regardless of whatever it is called, is offered under LGPL, the copyright holder cannot require you to do anything beyond what the license already says (e.g., purchase or use a particular version for a particular purpose); this is freedom 0: the freedom to run the program, for any purpose.3 Otherwise, it would not be LGPL anymore.
What About JBoss AS 7.2.0.Final?
As of this announcement, EAP 6.1.0.Alpha is the same code base as AS 7.2.0.Final, and as per the new release strategy, there will be only the one release named EAP 6.1.0.Alpha on the JBoss Community site. For all practical purposes EAP 6.1.0.Alpha is JBoss Community 7.2.0.Final. The primary differences between the two tags are in the images and text that are displayed during start up and when viewing the standard screens. Consequently, EAP 6.1.0.Alpha has more of a Red Hat look and feel, whereas the code tagged AS 7.2.0.Final still has the community look and feel that we all love.For a diff against the two tags, see http://www.jboss.org/jbossas/downloads.
As a provider of expert, SLA-backed technical support on many open source packages, among them the community version of JBoss, we at OpenLogic have already observed some general confusion about this announcement and want to clarify what this means in regards to our services.
OpenLogic will continue to support JBoss Community current major releases as well as two major releases back. We consider a community release as any that is licensed under an open source license with no additional restrictions.
OpenLogic will build a binary from the 7.2.0.Final tag and make it available to the public. Though the code base is the same as EAP 6.1.0.Alpha, this is to aid those who prefer the community look and feel and are not happy with the tag ‘alpha’ on their production systems. Remember, it is the same code base so, whether you choose to use the EAP 6.1.0.Alpha or the 7.2.0.Final, you are running the same system. We intend to continue to provide JBoss AS product builds via OLEX for any future releases, so long as the code base continues to be duel tagged. But since this seems to be in a current state of flux, we are not sure how long a duel-tagging scheme will remain in place.
As always with JBoss, anyone is also free to download from the source and build yourself. You can find OpenLogic’s build at: http://olex.openlogic.com/packages/jboss; the Official EAP.Alpha release at http://www.jboss.org/jbossas/downloads; and the source code at https://github.com/jbossas/jboss-as.
Open source software is about freedom. Shouldn’t that freedom include options when it comes to not only the software itself, but also the freedom to decide how your organization will use and support the software? A healthy and vibrant market (including a market built around services for open source software) requires choice. This is one reason that OpenLogic offers support around community versions of open source software, thus providing customers with more than one option when it comes to obtaining service-level agreement, expert-backed technical support.