Hi,

you ware presented with Terms & conditions page and "i agree" button first time you tried to download non-alpha version of EAP 6.1, I would say you probably did that when you ware downloading beta version some time back.

That agreement is valid for a year (if i recall corectly) and you are not presented with it every single time you try to download EAP, but terms still apply.

--

tomaz

Tomaz,

I must believe you since I really don't recall. However, I don't recall having downloaded the beta version before, in fact I don't recall having downloaded EAP at all before, but maybe I simply fogot.

Sorry to be such a stickler about this, but I now must ask you: can you (RedHat / JBoss) legally proof to me that I have really agreed to the terms and conditions?

If not, I believe I am legally off the hook (not that I really would take advantage of that) since I can claim that I have never agreed to any terms and conditions and you guys can't proof me wrong.

I will do some test and provide more feedback as a follow-up soon.

UPDATE: I did a simple test by registering again with a different user name and must admit that I got presented with a page that required me to agree to the terms and conditions of the developer program before I downloaded EAP. So, I must have downloaded some EAP version before and simply forgot about it.

ulrichromahn wrote:

 

Sorry to be such a stickler about this, but I now must ask you: can you (RedHat / JBoss) legally proof to me that I have really agreed to the terms and conditions?

I belive so, but that is not my point of experise, I will ask guys that deal with that.

--

tomaz

As Tomaz says, you are asked to sign the T&C once a year, and are asked when you go do the download. We will be adding a note to the download page to refresh you of the T&C (I don't know what form this will take visually/design wise here atm).

I will work with the team to add the T&C and info on when you signed the T&C last to your jboss.org profile. In the meantime, please email help@jboss.org including your jboss.org username and the team will be able to give you this info. Make sure you send from the email address you registered with, so they can validate your identity.

HTH

Hi,

My understanding reading the FAQ's (http://www.jboss.org/jbossas/faq) is that you can use EAP 6.1.0.Alpha in production since it's the same as community 7.2.0.Final, but it's not recommended to that kind of environment. Any other EAP version you need the subscription. Can anyone confirm this?

For what I understand, ALL the community versions of JBoss AS (aka WildFly), are just a test bed for the EAP version, a Final community version is just an Alpha (sometimes pre-Alpha) version of the EAP, from that point of view even a Final version of WildFly is NOT recommended for production use, we well never see a 7.2.1 version of JBoss AS with all the fixes of EAP 6.1 Final, that is not good or healty for all the community users... it feels that the community version is unpolished and full of bugs...

Is sad that Red Hat takes this actitude, the message they send is pay me or you won't get all the bugfixes, one could think that JBoss EAP is just a support subscription, but is not the case... that is the reason about the change of name to WildFly, to make it clear that the community version is just something different to EAP, it's even a double work since JBoss developers have to track bugs from WildFly that could affect or not the EAP version, and they have to merge what is done from WildFly back to JBoss EAP.

Having a single line of code base could be more efficient in the development of the Application Server/Platform that trying to force users to pay a subscription... I know that money is a big factor, but I truly believe that companies that require a support subscription will pay for a subscription, even if they can use a EAP version for free identical to the supported one, companies demands that someone could respond in case of problems so they will pay for support.

Red Hat is an open source company, and in open source one of the most important things is the community, but Red Hat seems to treat the community as secondary citizens :-(

Jorge,

I kind of agree with your opinion, but...

JBoss is part of RedHat which is a publicly traded company. It's primary goal, after serving its customers, is to increase value for its shareholders which means that the organization has to be profitable. In order to be profitable, one has to make money. I suspect I did not tell much of a secret here...

So, I completely understand JBoss's motivation for this move.

However, I don't understand why JBoss doesn't publish a free "community edition" of EAP with which people and organizations should be able to do whatever they like, including running in production. This has been demonstrated by other open source companies that operate successfully in this model. That would mean that RedHat/JBoss could release a version of EAP free to the public similar to what they do today, except that there would be no restrictions on it. If people now decide to use that version, they can, except that they won't be able to request support nor receive bug fixes and patches. RedHat may also decide not to publicly release point released, e.g. 6.1.1 to the public, which would be perfectly fine. That would eliminate the need to maintain two separate code streams plus it would make it less confusing for the community.

As I mentioned in a previous post on this topic, most companies that decide to use JBoss/EAP as a standard JEE application server in a mission critical production environment is well advised to purchase a subscription from JBoss.

By the way, if the community, and that's us, is not happy with the way JBoss handles this, we are free to create our own "upstream" open source project similar to CentOS based on RHEL. All we have to do is create a fork of WildFly and then production-harden it ourselves, including getting those bug fixes applied to the HEAD of Wildfly back into that fork.

One last note, EAP is released under the LGPL and JBoss is a good open source citzen and released the sources together with EAP 6.1.0.GA. But, since the source is LGPL, you are free to take the EAP sources create a diff between it and the JBoss 7.2.0.Final source and merge the differences back to JBoss 7.2.0.Final. Now you just have created a JBoss AS 7.2.1.Final which is code-identical to EAP 6.1.0.GA.

Hi Ulrich

I TOTALLY agree with your point regarding:
<SNIP>
However, I don't understand why JBoss doesn't publish a free "community edition" of EAP with which people and organizations should be able to do whatever they like, including running in production. This has been demonstrated by other open source companies that operate successfully in this model. That would mean that RedHat/JBoss could release a version of EAP free to the public similar to what they do today, except that there would be no restrictions on it. If people now decide to use that version, they can, except that they won't be able to request support nor receive bug fixes and patches. RedHat may also decide not to publicly release point released, e.g. 6.1.1 to the public, which would be perfectly fine. That would eliminate the need to maintain two separate code streams plus it would make it less confusing for the community.
<SNIP>

Could NOT had said it better myself!

Regards
Per

Fabrizio Benedetti wrote:

 

If I understand correctly, the free "community edition" of EAP is JBoss AS 7, or Wildfly.

EAP differences are:

• needs subscription for production
• you receives bugs/security patches
• you can receive technical support

But the base code is community edition.

 

If the differences stop there, I'm fine.

 

Overall, that's accurate.

Fabrizio Benedetti wrote:

 

But if the truth is that community edition is REALLY not ready for production,

That's not correct. Final versions of WildFly (previously known as JBoss AS) have always been used in production and will continue to be used. We encourage people to use them. The only caveat is, if you run into issues or have questions (just like you would with any other software), you will have to rely on the volunteers in the community to help you or you have to deal with such issues yourself.

Jorge Solorzano wrote:

 

 

Is sad that Red Hat takes this actitude, the message they send is pay me or you won't get all the bugfixes, one could think that JBoss EAP is just a support subscription, but is not the case... that is the reason about the change of name to WildFly, to make it clear that the community version is just something different to EAP, it's even a double work since JBoss developers have to track bugs from WildFly that could affect or not the EAP version, and they have to merge what is done from WildFly back to JBoss EAP.

 

Jorge, my rest of the reply to this post isn't really directed to you. It's meant to clear the confusion and some incorrect statements about WildFly and the community as a whole.

I've already replied numerous times in various posts/threads that  WildFly (previously known as JBoss AS) is like always, a open and free to use community project. In fact, I even blogged about why we changed the name of the project to WildFly and presented some history behind that rename http://jaitechwriteups.blogspot.in/2013/06/wildfly-release-and-history-behind-the-release.html.

But let me just repeat and try to summarize what the recent development means to WildFly and JBoss EAP.

How did the (previously named) JBoss Application Server releases work?

JBoss Application Server (which is now known as WildFly) was (and still is) a community effort. The JBoss AS/WildFly community consists of volunteers who contribute in various ways. Some of these volunteers just happen to work for Red Hat.

JBoss AS/WildFly binaries are released to the general public, just like any other open source project. Just like any other project, JBoss AS/WildFly too go through a series of (typically) Alpha, Beta, CR and ultimately Final versions for each version of the project. Community members are encouraged to use each/any of these versions in their applications and help us improve the project.

Other than Final versions of the project, the other versions aren't recommended to be used in production for obvious reasons. Of course, that doesn't mean you can't use them in production. Final versions of the project which have gone through internal testing and testing by the community members are encouraged to be used in production. And yes, no one is expected to pay for these community binaries even if you use them in production. So they are really free to use.

Where does JBoss EAP come into picture?

JBoss Enterprise Application Platform is not a new thing. JBoss EAP has been around for a while now. Starting JBoss AS 4.2.x version of the community edition, Red Hat started productizing the community versions to release enterprise versions for paid subscriptions. Unlike, the community version on which this productized version was based and unlike other versions of the community project, the paid subscription JBoss EAP entitles the customers to ask questions, raise issues, raise feature requests and expect them to be answered by a dedicated team of support personnel in a timely fashion. This makes it ideal for enterprises out there to use these paid subscriptions since in a typical business model you want immediate and dedicated team to look into issues instead of having to rely on community volunteers to help you with answers.

That's not just all, as paid subscribers the customers are entitled to request for certain features in the application server. Of course, community members of the community edition too are entitled to request for features but remember that on the community side it's all volunteers who do the work (it doesn't matter that some of these volunteers work for Red Hat, they are still volunteers).

The other added advantage of JBoss EAP is that extra care is taken to ensure that changes made in bug fix releases or minor releases don't break or introduce major changes or impact existing applications. This is commonly referred to as JBoss EAP is much more "stable". This does not mean that the community JBoss AS/WildFly version is buggy but instead the "stability" refers to the amount of changes that get introduced in newer minor versions of EAP. For example, a subsequent community version release might include numerous important bug fixes and at the same time include a major new technology integration or experimental techonolgies. The EAP releases on the other hand try to introduce such changes in a more controlled way. In other words, the EAP version waits for these changes to "settle down" in the community before letting those changes in.

How do bug fixes and feature requests make it into the community versions and the EAP versions

Bug fixes (or feature implementations) that are raised against the community version get included in the next version of the community edition of JBoss AS/WildFly. Issues that are raised by customers of the paid subscription JBoss EAP too get tracked (some in JIRA and some in the support portal). Such bugs in most cases are applicable to the community version too. So whatever bug fixes are made against the EAP version are also applied to the community version code (yes we do that).

An important thing to remember at this point is, EAP customers are entitled (if feasible) to have such fixes made available to them as one-off patches or in a subsequent bug fix release of EAP. Community users too get those bug fixes in the next community release of JBoss AS/WildFly but like previously explained, the next community release can also bring in certain other major changes to other parts of the application server.

Now a similar process exists the other way around i.e. if a bug is found in the community and that bug is affecting an EAP customer, then that bug fix is also applied to the EAP version and made available to the customer. Again, this bug fix might be delivered in an one-off patch immediately or in the next bug fix release of EAP unlike the community edition which will include the bug fix but might also have other major changes.

So what's changed recently which has caused all this confusion?

For one, we have changed the name of the community project from JBoss AS to WildFly. I and others have explained in various different places, why we changed the name. If you still haven't read about it, then please do read this blog http://jaitechwriteups.blogspot.in/2013/06/wildfly-release-and-history-behind-the-release.html or other material that's already available.

So that's one part of the change. i.e. we renamed the community project. That shouldn't really be a confusing thing.

The other part of the change is on the JBoss EAP side. As much as we love WildFly (previously known as JBoss AS), we love JBoss EAP equally and we (as Red Hat employees) are proud of it. The fact that JBoss EAP is a paid subscription is no shame and we want more and more people using it. So we decided to make certain versions (leading to Final version) of EAP be available to the general community for them to use. This included the EAP 6.1.0.Alpha1 and other such binaries. Certain versions of these binaries  required the users to agree to terms and conditions about its usage.

Most of the confusion in the community, surrounds this decision. Some feel that the community edition (i.e. WildFly) has now become restrictive. That's completely missing the point although I am not blaming the community for it. The fact that JBoss EAP which was previously available as paid subscriptions is now made available for downloads on jboss.org and made available for the general community does not mean that WildFly (the community edition) has become more restrictive. In fact, WildFly doesn't really come into the picture here. On the contrary, the availability of JBoss EAP binaries has now been made more relaxed and more widely accessible. Of course, some of the versions of EAP require you to agree to the terms and conditions of usage but it's still a step forward from JBoss EAP point of view. Like you might see now, the availability of JBoss EAP to a wider audience does not  mean that you cannot use WildFly or that WildFly has suddenly become restrictive.

So what does this mean to WildFly and its usage?

From a WildFly community point of view, nothing really has changed except the name. The project is as active as always. There already have been 2 releases within a couple of months http://wildfly.org/download/. Jason Greene (the project lead) has already outlined the goals and schedule of the 8.0 series of WildFly (here http://lists.jboss.org/pipermail/jboss-as7-dev/2013-March/007884.html and here http://lists.jboss.org/pipermail/wildfly-dev/2013-May/000062.html) and just like always we are busy with fixing bugs, adding features and sometimes introducing major changes in the community edition.

As for the usage of WildFly binaries, you are free to use them even in production just like you always did with the community edition.

This section regarding EAP above does not mention any restrictions regarding using EAP in production without a subscription.  It does mention that you are not entitled to support or enhancement requests.  Does it explicitly state anywhere that production use of eap requires a subscription?  I cant see plenty of references to "not recommended" but nothing about violating any agreement.

If someone is comfortable with deploying eap to prod without a subscription (for whatever reason). Why wouldnt they be able to do this under LGPL

http://www.redhat.com/licenses/jboss_eula.html