[jbertram]

What I was referring to is the concept that JBoss AS is fully opensource, yet the JBoss AS that's part of JBoss EAP seems to have a field of use restriction. Why bother with this?

IANAL, but I believe the "field of use restriction" (as you call it) applies to Red Hat trademarks and is part of the contract that EAP customers (willingly) sign as part of their subscription.  As to why this is bothered with, I can't answer that question since IANA(RH)L.

Why not put the bits on the community download page, clearly state that it's completely unsupported (the current download page already does that), and let the community do with it as they please?

I feel like we've covered this ground already, but I'll try to explain it again in a different way.  As I understand it, enterprise and community are like the circles in this venn diagram.  The red area in the middle which they share is essentially source code and some developers.  However, each circle is a distinct ecosystem with its own release cycle, feed-back mechanism(s), priorities, points of distribution, etc.  A release from one ecosystem isn't distributed from the other.

Isn't that the spirit of true opensource?

I'm not sure how "the spirit of true opensource" is is defined.  It seems rather vague. 

In any case, I personally believe that Red Hat is a rather unique model of open source consistency which has a wide range of thriving communities and commercially successful products.

If I build from the exact same tag, make no modifications whatsoever and use the exact same tools in the exact same version Red Hat used, would the hash really be any different?

I'm not sure.  Try it and see.

[henk53]

Justin Bertram wrote:

What I was referring to is the concept that JBoss AS is fully opensource, yet the JBoss AS that's part of JBoss EAP seems to have a field of use restriction. Why bother with this?

IANAL, but I believe the "field of use restriction" (as you call it) applies to Red Hat trademarks and is part of the contract that EAP customers (willingly) sign as part of their subscription.  As to why this is bothered with, I can't answer that question since IANA(RH)L.

Lawyers and developers don't always mix well I guess

IANALE, but from my limited understanding I could guess that the AS 7.1.2.Final.redhat-1 build (e.g. the bits in JBoss EAP 6.0.0) has the term "Red Hat" sprinkled throughout it, and that it's this very term that prevents the binary being distributed and being put up on the community download page (kinda like Debian removed the term "Firefox" and its icon from the Firefox Debian package).

I'm not sure how "the spirit of true opensource" is is defined.  It seems rather vague.

It is, although we have the concept of so-called OSI approved licenses. Again, IANALE, but I strongly believe that something that has a field of use restriction can not* be called open source. Ergo, if Red Hat is the original owner of all copyrights regarding the JBoss AS source (and/or have found agreement with all contributors) they can dual license the code and/or binary builds, but IMHO they can't* call the result open source.

The problem is here that the JBoss AS bits in EAP seemingly can be used for development and evaluation purposes, but are not allowed to be used in production.

I might be mistaken, but in open source you should not tell your users where they can and can't use the code for. So saying the code is not allowed to be used on mobiles, or on computers from brand X, or in the automotive industry, or by people who believe in Y, etc etc would all not be "in the spirit of open source". So if EAP is fully open source, and I would be so crazy to put it in "production" without any support contract, then this would have to be my choice and of course also my full responsibility.

*)

There is ofcourse a difference between a legal "can't" and a more ethical oriented "shouldn't"

In this context, the following entries from the Apache Open Letter to Sun regarding Harmony might be interesting:

Q : What is a "field of use" restriction?
A : A "field of use" restriction is a restriction that limits how
    a user can use a given piece of software, either directly or
    indirectly.  To give a concrete example from the Sun / Apache
    dispute, if Apache accepted Sun's terms, then users of a
    standard, tested build of Apache Harmony for Linux on a
    standard general purpose x86-based computer (for example, a
    Dell desktop) would be prevented from freely using that
    software and that hardware in any application where the
    computer was placed in an enclosed cabinet, like an
    information kiosk at a shopping mall, or an X-ray machine at
    an airport.

Q : Is a "field of use" restriction incompatible with both open
    source and free software principles?
A : Yes, both.  See the Open Source Initiative's open source
    definition (http://www.opensource.org/docs/osd), most notably
    section 6 and 10 and the Free Software Foundation's free
    software definition
    (http://www.gnu.org/philosophy/free-sw.html) most notably
    freedom #0.

See http://apache.org/jcp/sunopenletterfaq.html

[fcorneli]

henk de boer wrote:

Justin Bertram wrote:

What I was referring to is the concept that JBoss AS is fully opensource, yet the JBoss AS that's part of JBoss EAP seems to have a field of use restriction. Why bother with this?

IANAL, but I believe the "field of use restriction" (as you call it) applies to Red Hat trademarks and is part of the contract that EAP customers (willingly) sign as part of their subscription.  As to why this is bothered with, I can't answer that question since IANA(RH)L.

Lawyers and developers don't always mix well I guess

IANALE, but from my limited understanding I could guess that the AS 7.1.2.Final.redhat-1 build (e.g. the bits in JBoss EAP 6.0.0) has the term "Red Hat" sprinkled throughout it, and that it's this very term that prevents the binary being distributed and being put up on the community download page (kinda like Debian removed the term "Firefox" and its icon from the Firefox Debian package).

What we need is a CentAS, no?

[henk53]

Frank Cornelis wrote:

henk de boer wrote:

Justin Bertram wrote:

What I was referring to is the concept that JBoss AS is fully opensource, yet the JBoss AS that's part of JBoss EAP seems to have a field of use restriction. Why bother with this?

IANAL, but I believe the "field of use restriction" (as you call it) applies to Red Hat trademarks and is part of the contract that EAP customers (willingly) sign as part of their subscription.  As to why this is bothered with, I can't answer that question since IANA(RH)L.

Lawyers and developers don't always mix well I guess

IANALE, but from my limited understanding I could guess that the AS 7.1.2.Final.redhat-1 build (e.g. the bits in JBoss EAP 6.0.0) has the term "Red Hat" sprinkled throughout it, and that it's this very term that prevents the binary being distributed and being put up on the community download page (kinda like Debian removed the term "Firefox" and its icon from the Firefox Debian package).

What we need is a CentAS, no?

Right!

[jbertram]

I think you're barking up the wrong tree here, Henk.  Red Hat has been using this same basic model for the last ten years, at first for RHEL/Fedora and now for EAP/AS.  I'm not aware of any legitimate legal challenges which have been brought against it.

To my knowledge, all JBoss source code is licensed under an open source license and is not relicensed for enterprise products.  Any restriction on EAP is based on the Red Hat trademarks and the contract which customers sign when they acquire a subscription.  It isn't related to the source, per se.

Eight or so year ago, at my previous employer, we used JBoss AS for a number of different projects.  We had a support contract with JBoss (they hadn't been acquired by Red Hat yet).  If I recall correctly, they supported basically any version you could download, and there was no enterprise/community split.  However, JBoss was a relatively small company at the time and support was somewhat spotty because there were so many different combinations of projects which you could toss together into the server and still be supported.  I think they were doing they best they could with the model they had, but JBoss grew in popularity rather quickly (to their credit) and I don't think the resources could scale sufficiently to keep pace.  Enter Red Hat.

I remember when Red Hat acquired JBoss and introduced the EAP/AS split.  At first I was convinced that it must violate some part of the open souce license.  My colleagues and I were admittedly upset about it. 

Not long after that I attended the "JBoss World" conference with one of my colleagues.  One evening at a catered receptions in the conference center we cornered the director of product line management at JBoss (a division of Red Hat).  We grilled him about our grievances and the open source violations we perceived in their model.  He rather patiently walked us through how the model works and how it doesn't violate any open source licenses, etc.  I went back to my hotel room that night a bit more humble, and (reluctantly) impressed with the answers I received.

Red Hat has done their homework on this model which isn't surprising since a fair part of their business model is based directly upon it.

If you really have deep concerns about the legality or even the "spirit" of Red Hat's model then I recommend you get in touch with Red Hat directly rather than banter with us here on the community forum.

As far as "CentAS" goes, I believe that's perfectly allowable under the open source license just as with RHEL.

[jason.greene]

It is, although we have the concept of so-called OSI approved licenses. Again, IANALE, but I strongly believe that something that has a field of use restriction can not* be called open source. Ergo, if Red Hat is the original owner of all copyrights regarding the JBoss AS source (and/or have found agreement with all contributors) they can dual license the code and/or binary builds, but IMHO they can't* call the result open source.

The problem is here that the JBoss AS bits in EAP seemingly can be used for development and evaluation purposes, but are not allowed to be used in production.

IANAL but I can tell you that's not accurate.

The source for all redhat products is available on ftp.redhat.com, you can get the complete source for EAP6 right here:

ftp://ftp.redhat.com/redhat/jbeap/6.0.0/en/source/

That is by definition open source. Further it meets all the terms required by the LGPL.

The terms of using EAP and RHEL are spelled out in the respective EULAs here (note section 1):

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

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

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

If however you purchase a subscription, there are terms for the subscription (your access to the bits). If you violate those terms, you risk losing your subscription (which includes subsequent updates, patches, the legal assurance program, support etc), but the EULA, the LGPL and trademark law still govern the terms on the bits you have. You can read our generic subsription terms here:

http://www.redhat.com/licenses

Allow me to take a step back though and explain that this is just Red Hat's business model. We sell subscriptions, not standalone support contracts.

Subscriptions include:

• Access to our certified enterprise bits (all releases, security patches, hot fixes, updates etc)
  • Delivery of updates for up to 7 years since the major version release
  • Compatibilty gaurantees
  • Certification with other products including certain security compliance certifications
    • Includes some heavy internal QA with these combinations
  • RHN
• Access to the assurance program
• Exceptional support

Red Hat (and JBoss) previously had a model that just sold support contracts on community versions. That model was just not as viable as the one we have today, since at least then not everyone saw the value in "just support" (not to mention the desire of customers for very long running patch streams, which require signifcant funding on our part). The subscription is a lot more of a tangible thing (decesion makers just get it), and it has immediate benefits the day you purchase it.

Believe me I would love to give you guys *everything* for free, but without funding from a successful business JBoss AS/EAP (and it's various components) would lose the many full time developers behind it, and Java EE would lose the many Red Hat contributions (which in the past gave us CDI, BV, annotated EJB, JPA, etc). So we have to have some kind of right balance.

Essentially we give you three choices:

1. Stick with community - You get always get the latest and greatest cutting edge stuff (including experimental features), but you have to get support from the community and update more frequently since the community really only focuses on the latest major + minor version.

2. Buy an EAP subscription - You get all of the features above, which lead to minimizing the amount of work you need to spend on app server maintenance and support.

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.

This to me is a pretty good deal, and well beyond what you get from proprietary vendors, or a slower moving community-only project.

I can fully understand being cautious about this model, but it might be helpful to look at Fedora/RHEL, which is what we have been following and has done for years.

Anyway thanks for being frank about this. Your feedback doesn't go unnoticed.

[borisha]

I agree 100% with Hank, and most probably a lot of JBoss users do. It is very confusing how you manage whole EAP thing.

Having all binaries available in chronological order (clearly without any support and not even being called EAP, just 7.1.2, 7.1.3) would definitely make things more transparent and easier.

This 'secretly tagging' approach only confuses everyone and give good execuses to competitors.

[jason.greene]

Borisa Zivkovic wrote:

I agree 100% with Hank, and most probably a lot of JBoss users do. It is very confusing how you manage whole EAP thing.

Having all binaries available in chronological order (clearly without any support and not even being called EAP, just 7.1.2, 7.1.3) would definitely make things more transparent and easier.

This 'secretly tagging' approach only confuses everyone and give good execuses to competitors.

If it was "secret" then the tag would not be in our public git repo. It would be in a private, or "secret" repo.

As mentioned previously the clear internal version ordering between EAP and AS is to help those that use both. You can easily tell how a feature or fix on one relates to the other. The simple fact of the matter is that 7.1.2 was not (and never intended to be) a full official community release. It's simply a placeholder. The next comunity release stream is 7.2.x

[aldab]

Ok, but to clarify. It is still ok to build by myself the 7.1.2 version without paying for subscription and use it in production, right?

Also, I couldn't find that, what if we sell more products with jboss AS 7. Anyway we provide support (patches), customer does not care about it. Do we need then pay for each customer a subscription fee? Or is it enough that company will pay one subcription and build it's own product based on jboss?

[saltnlight5]

Wow, so much talks go into just a little tag appear on the git repo.

But for the interest of the public community, wouldn't a tag such as "7.1.2.EAP.Final" appear on public git repo be much more clean and less arguable?

I understand things are open and public by JBoss developers, and you guys are great at what you do. You guys provided an awsome product as open source, and you also provided a customer worry free version (EAP). No argument there. However, using the same tag format for EAP and the community version is confusing. As a user looking at https://github.com/jbossas/jboss-as/tags, I would expect "7.1.2.Final" to apear on community download page as well.

[ybxiang.china]

Ｉ read all of your comments.

I think JBoss's strategy is correct. If it gives everyting(including the EAP) to us, then it will die like SUN. Then all of us will lose everything.

• If our boss is stingy, then we use JBoss AS Community version, but the boss must hire more developers. It is good to us.
• If our boss is generous, then we use JBoss EAP, but the boss must fire more developers. It is NOT so good to us.

Right?

[jbertram]

I don't think either of your bullet points are necessarily true.  There are strategic reasons to use either community or EAP (or both).  It certainly isn't as simple as being stingy or generous.

Furthermore, I don't understand why developers would get fired if their company used EAP.  Any development time or effort saved using EAP would enable developers to focus on issues more directly related to their business rather than on the application server itself or do something else productive. 

[sfcoy]

I don't think it has much to do with bosses at all. It has more to do with what our (as in yours and my) customers want, and typically that is a fully supported application server.

If your customer does not think they need this you should be wary of taking on this support load yourself. I'd rather spend my time doing product development.

[wdfink]

As  Justin Bertram and Stephen Coy said there are many different reasons, from my own experiance and discussions with different other developers and managers

I'll add the following (most) important reasons:

• ensure a 24/7 availibiliy of support in critical situations.
• save a lot of time if it is possible to ask the support for  finding solutions or best practice
• access to the Knowledgebase
• planning security with longer support for releases regarding features and patches
• legal security

And this will still not all

[b.eckenfels]

It's worth noting that the EAP download from the Red Hat Customer Portal is reserved for Red Hat customers who either have an active subscription or wish to evaluate EAP with an eye to eventually purchasing a subscription.

And they need to agree to the EULA (how binding or not binding that is). On the other hand, RH is bound by the LGPL and has to provide all source and tools to build the EAP Distribution (to customers).

Bernd