JBossDeveloper

jaikiran pai schrieb:

 

From a WildFly community point of view, nothing really has changed except the name. The project is as active as always.

I don't agree concerning this point. In my opinion the release frequency of final community version binaries suffered from the decision to release EAP 6.1.0 Alpha instead of a JBoss AS 7.2.0.Final version. While these are almost the same and production usage of the EAP 6.1.0 Alpha would be allowed i'm sure the adoption isn't the same as it would be with a 7.2.0 Final binary due to the FUD the EAP 6.1.0 Alpha suffix created.

So currently the latest final community binary is 7.1.1.Final which was released more than a year ago (2012-03-09) and WildFly 8.0.0.Final is scheduled for 2013-11-13. This seems to be a fairly long release cycle - maybe too long for a healthy opensource project.

Chris,

the EULA does not have any of those statements, that is correct. However, the specific verbage is in the JBoss Developer Program agreement to be found here: http://www.jboss.org/developer-program/termsandconditions

and we all have to agree to this when we download EAP the first time (although we won't get reminded of that on subsequent downloads which is confusing and JBoss promised a fix for that).

The important paragraph is towards the top and starts with a "WARNING". This is the section that pertains to EAP (after aplha).

Thanks for the reponse ulrichromahn.  Makes sense. 

These seem almost like separate (maybe contradictory but certainly confusing agreements).  What happens in a scenario where developer (a) develops an application under the developer program and sells application to customer (b) (not bundling eap).

Does customer (b) require a support agreement to then use EAP, or would they be ok to use their own acquired EAP with application (a) under the EULA agreement?

r.reimann wrote:

 

I don't agree concerning this point. In my opinion the release frequency of final community version binaries suffered from the decision to release EAP 6.1.0 Alpha instead of a JBoss AS 7.2.0.Final version. While these are almost the same and production usage of the EAP 6.1.0 Alpha would be allowed i'm sure the adoption isn't the same as it would be with a 7.2.0 Final binary due to the FUD the EAP 6.1.0 Alpha suffix created.

 

So currently the latest final community binary is 7.1.1.Final which was released more than a year ago (2012-03-09) and WildFly 8.0.0.Final is scheduled for 2013-11-13. This seems to be a fairly long release cycle - maybe too long for a healthy opensource project.

r.reimann has a valid point here: if JBoss is so confident that the community edition, aka WildFly, is production-quality code and there is very little difference between itself and EAP (except for some very specific patches that may or may not make it back to community some time later), why doesn't it then publish binaries on the jboss.org site or somewhere else? This does not necessarily boost the community's confidence in the JBoss/WildFly project.

Having said that, creating one's own binary is actually pretty easy. In order to do that, one just has to know enough about git and how to create a branch based on a label and how to setup maven. I have a running build here that does this on a daily basis and once I find a new tag, will create a branch off it and then create a binary build (through the pom.xml located in the dist folder) and publish it into my own local Nexus. So, I have always the latest and greatest binaries available in my Nexus, including all the daily snapshots - very convenience at times when testing some new features.

One last question that may come up: why would I create new branches off of git labels? The answer is quite simple: there are certain bug fixes coming after a label that I may want to cherry-pick and merge back into my binary release. So, I am essentially creating my own point releases. Without a branch, I would not be able to do that, at least not easily.

r.reimann escribió:

 

jaikiran pai schrieb:

 

From a WildFly community point of view, nothing really has changed except the name. The project is as active as always.

I don't agree concerning this point. In my opinion the release frequency of final community version binaries suffered from the decision to release EAP 6.1.0 Alpha instead of a JBoss AS 7.2.0.Final version. While these are almost the same and production usage of the EAP 6.1.0 Alpha would be allowed i'm sure the adoption isn't the same as it would be with a 7.2.0 Final binary due to the FUD the EAP 6.1.0 Alpha suffix created.

 

So currently the latest final community binary is 7.1.1.Final which was released more than a year ago (2012-03-09) and WildFly 8.0.0.Final is scheduled for 2013-11-13. This seems to be a fairly long release cycle - maybe too long for a healthy opensource project.

Yes, that's my point, the latest final community binary is 7.1.1, in github there is a 7.1.2 tag (which correspond to 6.0 Final EAP) and a 7.1.3 tag (which correspond to 6.0.1 Final EAP), at least the tags exists and is fairly easy to build it, but why they are not promoted and published in the download pages as binaries? It seems that hide the versions to promote the use of EAP.

Q. Are there any restrictions on how I can use EAP 6.1.0 Alpha?

A. No – it has the same license and terms as AS releases however as it's an Alpha release we don't recommend using it in production.

Yes, JBoss AS (aka WildFly) get promoted as Final versions but those Final versions are the base for an EAP Alpha, even if the 7.2.0 binary gets promoted and that RedHat/JBoss recommend the use of Final community release in produccion, you don't recommend the use of an EAP Alpha in producction wich is supposed to be better in quality terms than a Final community release; that's really makes my head spin. Again is that is a subtle promotion to EAP.

Don't get me wrong, it's ok that you promote the EAP version, it's perfectly understandable, I know that WildFly developers are volunteers but I'm pretty sure that most volunteers are Red Hat employees, and that model of development is just awkward, a release and forget model seems bad for any project, so if there are patches applied in EAP why is so dificult to backport to some new release like 7.1.4 (or 7.2.1).

Jorge Solorzano wrote:

 

Yes, JBoss AS (aka WildFly) get promoted as Final versions but those Final versions are the base for an EAP Alpha, even if the 7.2.0 binary gets promoted and that RedHat/JBoss recommend the use of Final community release in produccion, you don't recommend the use of an EAP Alpha in producction wich is supposed to be better in quality terms than a Final community release; that's really makes my head spin.

I agree with you Jorge. This is very confusing. For the latest versions if EAP 6.1 Alpha is the same to JBoss AS 7.2.0 Final, then the EAP 6.1 Alpha should be production ready and the binaries to use until WildFly 8.0.0 Final, right?

ulrichromahn wrote:

 

My lengthy post below is not intended to encourage people to use EAP 6.1 in production without a support agreement. I personally believe in the value of this support and would everybody encourage to buy one.

Personally I'd like to underscore this point as well. That said...

 

As per this site, EAP 6.1.0 Final clearly has been made available under the LGPL. In order to download the zip and sources, one just has to login with one's JBoss Community userid and password, but at no point in time was I asked to acknowledge or agree to any other legal terms.

Under the LGPL you are free to make the source available to others without any restrictins and without any usage restrictions. Whether you have or haven't agreed to anything, whether when downloading or at some point in the past, may not be relevant when you gave the source to your friends. They never excepted anything and the GPL does not allow it that they have to accept anything.

It's a little strange that you have to accept the same "do not use in production" terms when downloading the source from the general JBoss download page. The same source is also available from Red Hat's FTP site, and then you don't have to accept any such agreements.

I'm still not 100% sure what the exact legal basis is for the "do not use in production" terms on a LGPL licensed work, but it looks like it's the word "Red Hat" that supposedly appears at various places in the downloaded binary. This word is a trademark, so you are not allowed to use it without a license. Incidentally, this is a bit similar to how Nintendo protected its hardware from unlicensed software:

"The game would only start if the word was correctly in place in the ROM. If anyone wanted to produce a game without Nintendo's permission, they would be claiming to use the word 'Nintendo' without a licensed trademark, and therefore Nintendo would be in a position to sue them for trademark infringement."

See: http://eurogamer.net/articles/2013-07-04-born-slippy-the-making-of-star-fox

So if you ship JBoss EAP to customers, you're exposing them to the word "Red Hat", which you are not allowed to do. But... if you run JBoss EAP on your own server and remove the root.war, you're to the best of my knowledge not exposing your users at any time to the word "Red Hat". I wonder if there is a legal ground to forbid this kind of usage.

See this thread as well: https://community.jboss.org/message/761728

Jason Greene wrote:

"3. Self build and support  EAP - You get some of the benefits of the enterprise releases (e.g. patches to older major versions and so on), but you have to invest time and energy to build and maintain/verify your app server distribution bits."

and

"In other words everything (bits and code) except for the trademarks is distributable. We offer open source (which pertains to copyright), but not open trademark, which is an entirely different set of laws (variations in every country). You'll also notice there is no "field of use restriction" in the EULA"

So earlier Jason Greene seemed to say that if you build JBoss EAP yourself from the source, you can do with the result whatever you want. There is however the catch that the standard build script references (open source) tools in specific versions that have not been made publicly available. Rich Charples remarked:

"Right now we do not have a way of making EAP easily buildable for the general public (nor does the L-GPL or GPL require us to)"

But as it appeared there's nothing really special about the build, as Alexis Hassler proved: https://github.com/hasalex/eap-build

I do wonder why after a self-build it's supposedly okay to use, as the trademarks may still be in there. I also wonder what the exact definition of "production usage" is. The above refers to distributing JBoss EAP, which is distinctively different from using JBoss EAP.

On a separate but related note: it was my impression that until recently EAP was not actually "licensed" but people would get access to it under a support subscription contract. [...]

If JBoss/RedHat really wanted to restrict the usage of EAP the way you indicated above, they either have to go back to the old model and resctrict access to people with subscriptions only

I don't think this is correct. You could previously freely download JBoss EAP for evaluation just as well. The big difference was that it was "hidden" on some Red Hat portal site, where you had to create a free but enterprisey Red Hat account, and then you had to wade through various lists and make many clicks just to get to the product. As a result MANY people I spoke to where utterly unaware of that JBoss EAP was actually different software. They thought JBoss EAP was just the name of the support contract and that the (at times) bug ridden JBoss AS version on the main download page was where they would get a support contract for.

People would thus evaluate JBoss AS, came to the conclusion it was not of sufficiently high quality, and therefor didn't opt for a support contract. This was a shame, since had they evaluated the much better JBoss EAP builds in which many bugs are fixed, I guess they would have opted for that support contract.

So what Red Hat/JBoss did now is simply making the JBoss EAP builds as visible as can be by putting them directly on the main download page and making it very clear that the EAP build is the supported product instead of the more buggy AS builds.

 

[...] or better be served in changing the license of EAP to a more restrictive proprietary license that legally enables them to do that.

You can't have your cake and eat it. JBoss is an open source product and this gives them the benifit that people choose them on the basis of them being open source (for various reasons, political and technically, such as being able to debug with source attached, auditing the source, creating your own patches if needed, etc etc), and them getting potentially razor sharp bug reports (pointing out the exact line and conditions under which an error occurs) and them getting patches.

If they would like to use a restrictive proprietary license instead, maybe even becoming closed source (like WebSphere and WebLogic) then all these benifits go away as well. If I'm not mistaken Red Hat/JBoss doesn't even have the full copyright to all the source code to make such a full license change. Besides that, Red Hat/Jboss is a company that strongly believes in open source and has open source at the heart of their operations. It would be extremely out of character for them to make JBoss EAP suddenly closed source and/or under a restrictive license, and I don't think anyone at Red Hat/JBoss wants to make such a move.

So where do we stand:

1. JBoss EAP remains open source; LGPL
2. This thread more or less suggests the restriction on production is based on accepting terms when downloading
3. LGPL source code is free to distribute (by definition of the LGPL). Others can build the same binaries without ever accepting any restrictive Red Hat terms
4. LGPL source code is available from the main download page but only after having accepted terms
5. Exact same LGPL source is also available from Red Hat FTP site without any login or terms to be accepted (ftp://ftp.redhat.com/redhat/jbeap)
6. Other threads suggest or claim the restriction on production is based on the Red Hat trademark (https://community.jboss.org/thread/197780?start=75&tstart=0)
7. Trademark as far as I know comes into effect when distributing a product, but for running in production one does not necessarily have to distribute (can run on your own servers)
8. Self-build from the above mentioned LGPL source allegedly allows you to use the result in whatever way you see fit
9. Self-build is not directly possible; the pom among others references dependencies that have not been published (e.g. Ant 1.8.3-redhat-1 instead of just 1.8.3).
10. The unpublished "hidden" dependencies either seem to have no change in them at all (just a repackaging?) or very little changes. They can be trivially changed into corresponding dependencies that have been published. See https://github.com/hasalex/eap-build
11. A direct self-build probably still has the trademarked term "Red Hat" (or variants) in to it. Yet, in threads about self-build it's (as far as I've seen) not mentioned that this should be removed.
12. If self-build still has the trademarks, but is okay to use in any way fit, is the legal base for the production restrictions accepting the terms and not the trademarks?
13. What is the exact definition of production usage anyway?

Jorge Solorzano wrote:

Yes, that's my point, the latest final community binary is 7.1.1, in github there is a 7.1.2 tag (which correspond to 6.0 Final EAP) and a 7.1.3 tag (which correspond to 6.0.1 Final EAP)

This is not correct.

The 7.1.2 tag has been the BASE from which 6.0 Final EAP was eventually produced. There are quite a lot of changes between those releases. Same goes for the 7.1.3 tag and 6.0.1 Final EAP. See this for some more details: http://henk53.wordpress.com/2013/01/09/the-curious-case-of-jboss-as-7-1-2-and-7-1-3

In short the issue is that the development of EAP is not done on public Github anymore. So there's a tag, say 7.1.2, and I guess there's a private branch made of that (maybe this branch is on Github as well, but just not visible). Then development likely continues in this private branch and at some time this branch is tagged (7.1.2.Final-redhat-1 in this case). From this private branch a product is compiled, and a source snapshot is created, which are both made available.

I wonder though why Red Hat/JBoss does this private branch thing. The end result in source is made available anyway, we just don't see the intermediate steps. Why keep those secret in an open source project?

Over here Mark Little said:

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.

But if Red Hat or JBoss doesn't really respond (anymore) to that discussion here, then what's the entire point of that statement?

I've put great effort in writing the post above and created a list with many points, but there has been no reaction from Red Hat / JBoss yet. Granted it's only been two days, but the last messages from others before that haven't gotten a reply either and they are quite a bit older.

I hope we can get this discussion going. JBoss makes great software (the best I think), and it would be absolutely awesome if some of the muddy details could be cleared up a little.

henk de boer wrote:

 

Over here Mark Little said:

 

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.

 

But if Red Hat or JBoss doesn't really respond (anymore) to that discussion here, then what's the entire point of that statement?

 

Henk, you do see that this is a 3 page discussion and there are many similar discussions like this one where Red Hat employees have responded and continue to respond to questions, don't you? Please be patient.

jaikiran pai wrote:

 

Henk, you do see that this is a 3 page discussion and there are many similar discussions like this one where Red Hat employees have responded and continue to respond to questions, don't you? Please be patient.

I believe that part of the reason that there are so many similar discussions is that some questions are just not really answered.

Some of the items on my list where already asked in the long JBoss 7.1.2 discussion I participated in many months ago. I've scanned those other discussions and the same questions come up multiple times, but they are never really answered. So people open up a new topic, maybe just to "try again". There even was a mockery of this process by someone on a reddit discussion some time back and many commenters agreed with it. Just saying...

That said I understand that Red Hat on the one hand wants JBoss EAP to be almost closed source like so there's no way around getting a subscription, and on the other hand it wants to be open source for all the benifits that brings. Jason Greene already explained so much that this is an at times difficult balancing act, and I can surely understand that.

Anyway, I'll be a little more patient then and check back in a few weeks orso to see if anything has been answered. Thanks for your time!

ulrichromahn wrote:

 

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, thanks to the jboss.org team, each individual's profile now has a couple of fields which provide a link to the terms and conditions that the user agreed to and the date on which he/she agreed. You can take a look at your (own) profile page to find that data.

jaikiran pai wrote:

 

ulrichromahn, thanks to the jboss.org team, each individual's profile now has a couple of fields which provide a link to the terms and conditions that the user agreed to and the date on which he/she agreed. You can take a look at your (own) profile page to find that data.

Jaikirian, do you know why there is a loggin and terms and conditions for downloading the source archive at jboss.org/jbossas/downloads?

henk de boer wrote:

 

 

Jaikirian, do you know why there is a loggin and terms and conditions for downloading the source archive at jboss.org/jbossas/downloads?

I hadn't noticed that, but I think it's just an oversight. I'll check with those who might know more.

jaikiran pai wrote:

 

I hadn't noticed that, but I think it's just an oversight. I'll check with those who might know more.

Great, thanks a lot in advance!