28 March 2013

JBoss community and EAP are things changing?

Before we start a caveat. We are trying to interpret this in good faith but we are not lawyers so therefore any discussion or interpretation of license agreements you should check out with your lawyers. This is not legal advice!
Recently Mark Little announced that EAP Binaries Available for All Developers which seems to announce a change in policy of JBoss community releases and access to EAP binaries.
As you know JBoss community is the open source released product that comes with no support, patches etc. and JBoss Enterprise Application Platform (EAP) is the supported Red Hat product that comes with long term support, ongoing patches and indemnity. As a JBoss partner we believe in the value of the EAP product for production environments as you need to be able to get security patches and bug fixes to your deployed JBoss servers without getting a boat load of other changes you don't want. It just makes sense given the minimal cost.

 However we also believe in a solid, production quality and viable JBoss community release which is as close to EAP as possible so that customers could put community into production and easily transition to EAP without a complete regression test of their application. Too many times we have seen customers with community in production that just can't transition to EAP rapidly due to the differences and therefore the impact on their application. Hence there has been concern in the community about the lack of a JBoss community release after 7.1.1see (https://community.jboss.org/thread/197780?start=0&tstart=0). So I believe this announcement has been made to assuage this concern.

Labelling Changes


So lets unpick the announcement. There appears to be two parts. There's Mark's Blog and a corresponding FAQ.The first part is that there will be a release in community for each branch of community that forms the basis of the EAP productionisation process. To quote Mark;

"What we are proposing to do is pretty simple: from the point where we start to productise the community project (e.g., AS7.1) we will release all product builds that we create as a result of this process into the community (e.g., EAP 6.0 Alpha 1, which is based on AS 7.1) so that all developers within our communities or with our customers can take advantage of them immediately."

However the FAQ states;

"Q. Will you also release EAP 6.1.0 CR / GA and future EAP 6.1.x point releases in the community?

A. Major (x.0) and minor (6.x) EAP releases (other than Alphas which are freely available) will be available with a paid production subscription or with a zero-dollar developer subscription. Security updates and patches are only available with a paid subscription."

Which sort of contradicts Mark's "We will release all product builds..." so my take on this is essentially that there will be future community labelled releases but they will be labelled with an EAP alpha label. After that you won't see any more releases on that branch. So essentially instead of getting a 7.1.2 label we get a EAP 6.1 alpha label, who knows if we'll get a 6.1.1 alpha, only time will tell. I suspect the alpha naming is more of a psychological "fear factor" label so that ops guys will say "You wanna deploy what! It's only alpha, no way". Only time will tell what this release strategy means as it seems pretty confused at the moment.

Developer Subscription 


The second part of the announcement is the zero cost developer subscription whereby you will get hold of the EAP binaries. However there isn't really any more information about that other than it is coming. Now as a developer you can currently get access to EAP pretty easily either via buying a JBoss Developer Studio Portfolio Edition subscription (£68 per year, per developer in the UK) which gives you access to everything, we can sell you one if you want one ;-). Or you could download an eval version of the EAP on a 30day eval. So getting hold of EAP binaries is pretty easy and low cost now. Obviously zero cost is lower than £68 per seat so there's an improvement.

But the complexity is in the unknown legal details of the new subscription. Now I am not a lawyer but my understanding of JBoss licensing is that JBoss is licensed under the LGPL and EAP is licensed under the LGPL with the addition of the JBoss EULA. The EULA grants you a perpetual LGPL but prevents redistribution of Red Hat trademarks. Therefore customers can continue to use EAP in production, after downloading an eval once their eval lapses but can not give the binaries to a third party. Again we don't recommend this as you still need ongoing patches and support, the benefits of a subscription don't disappear once you have the binaries! However once you get a paid subscription, in addition to the license agreements, you sign up to the subscription agreement and you agree to pay a subscription fee for all units of JBoss EAP in production and also agree to compliance inspections and audits.So it's an all or nothing agreement, which is fair and prevents you from supporting 1 JBoss and funneling all your support requests through the single subscription. What will be interesting is seeing if the terms of the zero dollar developer subscription include the "Reporting and Inspection" sections of the current subscription agreement. Thereby tieing up the developer in a whole bunch of other requirements over and above the basic LGPL and EULA. As if they do then organisations must monitor what their developers are signing up to in any "click-wrap" agreements.



To me the stated aim of "EAP binaries for all developers" is the right headline but the new policy is as "clear as mud" and without seeing how the new release labeling strategy pans out, after a few iterations, and what the legal terms of the new subscription agreement are; probably even more confusing than before. To me the simplest route and my preference is for RedHat just to release JBoss EAP equivalent binaries in community with no support, indemnity, security patches or bug fixes under LGPL or under the current JBoss EULA. My belief is those people who are not going to pay for a subscription probably never will no matter what labeling tweaks and legal adjustments Red Hat make and they probably don't have much money anyway. The reason to buy a subscription will still exist even with full EAP in community and the path to migrate to a subscription will then be easy.

If you enjoyed this post, why not subscribe to our feed?

Enter your email address:


  1. Steve, a minor correction for a start.

    "JBoss community is the open source released product" Huh? JBoss Community is our name for what goes on under the JBoss.org banner. I think you mean JBoss AS? Even then, it's an open source *project*, not a product.

    In terms of my blog versus the FAQ where we discuss releases, we will be putting out Alphas, Betas, CRs, nightly builds (probably) and eventually the GA. We're still working to get all of this tied into our processes, so initially it is likely we may miss one or two of these binaries. However, the aim is to make them all available.

    As to why the Alpha is called an Alpha, well it's pretty standard software development terminology and one which we have used internally for a long time. It's just that the community has not been able to see these binaries until now.

    If you want details on the $0 subscription then check out the Red Hat JBoss Fuse release we did the other week. That uses it.

    Feel free to send us details of things that you think should be clarified in the FAQ. Or even better, be a good community member and discuss them in the open forums we created at the time of the announcement.

  2. Hi Mark,

    Thanks for the clarification on the releases this is indeed great news! It also clears up the Alpha label.



  3. Finally! Can I get the JBoss EAP code, compile using maven and use it in a production environment without a subscription?

  4. Sorry JBoss dudes, but this change is lame. Outwardly, it appears nothing more than attempt to coerce users away from the community editions. I've working in organizations that were fine with open-source and community editions, but had a zero-tolerance policy for "alpha" products. While you claim it is a semantics issue, and maybe it is, I know those semantics have a large impact on how some organizations feel about the various versions. Even the current organization I'm working for, which is very open-source friendly, has expressed concerns about me moving forward using 6.1.0 Alpha, so I labeled it 7.1.2 in my demo.

  5. I agree it is a bit lame. Our view, even as a RedHat/JBoss partner, is that EAP should be easily available for download without any subscription. Then it is easy for people to buy a support subscription when they move it into production without having to do a regression test phase to move to EAP from a community release. As it stands developers use the community release then can't migrate to EAP when they go to production quickly as it involves regression testing as a minimum.

    The developer subscription is a move in that direction but seems to also include a legal sleight of hand, sidestepping the GPL and EULA, whereby the developers promises not to move into production without purchasing a subscription. Now IANAL but I am a director and I can not see how a developer has the legal right to bind a company like that. Clicking the click wrap license agreement in this case would be stepping beyond their authority.