JBossDeveloper

Justin Bertram wrote:

 

To my knowledge, all JBoss source code is licensed under an open source license and is not relicensed for enterprise products.

 

True, they cannot do that, as they do not own all rights to all source.

Justin Bertram wrote:

 

  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.

The only problem (and this is different than RHEL/CentOS) is that the term "JBoss" is a trademark as well and it is sprinkled all over the source and ABI. You simply cant remove it.

Aliaksei Lahachou wrote:

 

Sure, we can download EAP 6 for evaluation, but we cannot install it on production servers. We are thinking to buy EAP, but only for customers, who are willing to pay more, others get AS as usually. Now we have a problem, because EAP has no corresponding AS version. 7.1.3.Final we also be EAP only, and we will probably have to switch to AS 7.2.x version of AS. This makes quite some trouble, because we have to support different versions of servers.

BTW: last time we had a discussion with RH this was specifically not possible. If you sign the EAP contract you cannot deliver Community licenses. I dont know if this has changed, it would be very good as we would look for the same model. We have been even trying to by consulting/developer hours to fix some specific community bugs and they refused (however this was back in the 3.x times).

henk de boer wrote:

 

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?

Yes, different. There are at least timestamps (jar dir metadata, comments in pom.properties and others) and hostnames or os version in the binaries. However instead of comparing a single checksum it might be able to drill down on jar entry level and have only a few environmental specific differences.

Albert, I work for Red Hat and we have a team that works with people shipping/ selling products that include JBoss.   I'm seeing a lot of confusion between Community vs Enterprise.  Start with this link for ISVs and then call Red Hat https://www.redhat.com/resourcelibrary/catalogs/jboss-isv-program-guide

Jason, first of all thank you for your very thorough and honest reply. It was a while back already, but I hadn't thanked you for it yet, so there it is

I absolutely understand your point of view. As I think I mentioned before, nobody can live from nothing. There has to be some amount of income from something.

Personally I think that just offering support on a specific version of JBoss AS, without making that specific version difficult to obtain and/or not legal to actually use without a contract, would work as well. Obviously you (Red Hat) have put a lot of thought in all of this, so who am I to know better, but I do have a few decades of industry experience (yeah, getting old), and I've personally never seen any company I've worked for get a support contract only because binary bits were otherwise difficult to obtain.

So, IMHO, there are already the companies who need a support contract anyway. The free availability of the bits is irrelevant to them.

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.

That sounds reasonable indeed, but in the thread https://community.jboss.org/message/763773 I read that this is seemingly not possible. Rich Sharples says:

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)

If necessary artifacts and tools required for the build are not made available, then how is anyone supposed to build EAP really?

Jason Greene schrieb:

 

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

 

 

Jason, thanks for your insightful answer. However, I am still wondering where these restrictions to the use of the Red Hat trademarks are stated in the Community Edition. JBoss AS 5 had the EULA which included the trademark restrictions. The EULA were removed for JBoss AS 6 (https://issues.jboss.org/browse/JBAS-8862?focusedCommentId=12581776&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12581776), so where can the restrictions be found now?

jpobos wrote:

 

Jason, thanks for your insightful answer. However, I am still wondering where these restrictions to the use of the Red Hat trademarks are stated in the Community Edition. JBoss AS 5 had the EULA which included the trademark restrictions. The EULA were removed for JBoss AS 6 (https://issues.jboss.org/browse/JBAS-8862?focusedCommentId=12581776&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12581776), so where can the restrictions be found now?

As jpobos asked, I would like to know this as well. Has anyone found these restrictions yet?

henk de boer wrote:

 

jpobos wrote:

 

Jason, thanks for your insightful answer. However, I am still wondering where these restrictions to the use of the Red Hat trademarks are stated in the Community Edition. JBoss AS 5 had the EULA which included the trademark restrictions. The EULA were removed for JBoss AS 6 (https://issues.jboss.org/browse/JBAS-8862?focusedCommentId=12581776&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12581776), so where can the restrictions be found now?

 

As jpobos asked, I would like to know this as well. Has anyone found these restrictions yet?

I was originally referring to the EAP EULA which is here:

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

Community guidelines are available here:

https://community.jboss.org/wiki/TrademarkGuidelines

This is an interesting dicussion. There seems to be a lot of comparison between this and the RHEL/Fedora model. However IMHO the principle may be the same but the practice is wildly different. Fedora has regular 6 monthly releases and regularly pushes out bug fixes and security patches through system updates. JBoss community nowadays seems to freeze at a buggy old release for a very long time with no published release cycle. Developers can't get at the latest and greatest stuff in community without building it themselves unlike Fedora.To quote from the Fedora Release Lifecycle document;

"Fedora is focused on free and open source software innovations and moves quickly. If you want a distribution that moves slower but has a longer lifecycle, Red Hat Enterprise Linux, which is derivative of Fedora or free rebuilds of that such as CentOS might be more suitable for you. Refer to the RHEL page for more details.

This is NOT true of community JBoss AS 7, it appears to move slower than EAP. Not sure what happened to the open source philosophy of "Release Early, Release Often".

As a RH partner I understand the value of subscriptions and the need to make money but my view is that customers who are going to buy subscriptions will buy a subscription irrespective of what is going on in community, for all the reasons we sell them on. They want somebody to call. They want down-ported fixes. They want patches and bug fixes without getting new features at the same time. All things they can't get from Community even if it moved fast. I don't think trying to move people to EAP on the argument that it is a better quality product than a dodgy 9 month old community with many known bugs is a compelling argument. In fact not keeping community up to scratch in quality will put potential customers off when they try it and it is buggy and old without any obvious activity. When they compare with other open-source app servers out there whereby both Tomcat and GlassFish push regular updates to open source and then you can buy commercial support of these point releases.

Remember JBoss EAP's competition is not limited to Community conversions. If they never use community they are unlikely to migrate to EAP. In my view as a RH partner it is essential for the success of EAP that community is released early and often with new features as well as bug fixes and security updates.

I'd also like to still be able to build EAP from source, like the old EAP 5 branches in the SVN repo. To be honest all these years no-one has bothered to release a Cent-AS, so it's a pretty low risk. As why bother, life's too short, just buy EAP. If somebody is so against buying a subscription that they'd support and build an EAP from source for production then they are never gonna buy one. However for supporting paying EAP customers it is invaluable to be able to build from source.

Just my 2 cent's worth

Steve Millidge wrote:

 

In fact not keeping community up to scratch in quality will put potential customers off when they try it and it is buggy and old without any obvious activity.

I've seen this happening a lot in practice. People trying out the community release, then being shocked because of the many bugs in it, and thinking that exactly THAT is what they are getting with EAP, but just with a subscription/support attached.

Maybe it would be more clear if 7.1.2 and 7.1.3 were mentioned on the community download page along with their (EAP) release dates, but then with a link to the evaluation version and a clear mention that it's a 'commercial only' release.

By doing that it would be more clear that 7.1.1 is a dodgy old release, and that there are newer/better versions available for paying customers.

I would have to agree. Although it's probably an exception, we will most probably see the situation that 7.1.1 is over a year old when 7.2.0 is relased and in the meanwhile 7.1.2, 7.1.3 and 7.1.4 will have been EAP-released.

What amount of work is involved with a community release? Would it be impossible to have a policy that would say "When an EAP release is 4 months old, if there has been no community release in 6 months, it will be community released as-is"?

Should I interpret the silence as "nah"? Somebody more inclined towards conspiracies might think that the longer release times between community releases is a way to make EAP more attractive

Making the EAP more attractive is IMHO just one aspect of their strategy. Besides this they also know that 7.1.1 is still far more stable than GlassFish (believe me, once you go some further than the tutorials it's shit all over the place), so they have nothing to fear in this area.

They also want to avoid the birth of some CentAS, as they had bad experience with the CentOS phenomenon. Hence the difficulties when trying to build EAP yourself.

I'm betting that even 7.2 will never see the light...

JBoss/RedHat is a company and their obligation is to maximize the profit of the shareholders. But shareholder value for a company as RedHat comes also from keeping the community happy so I'm still confident that 7.2 will see the light of day (with a hopefully shorter release cycle for forthcoming community releases)

Nicklas Karlsson wrote:

 

JBoss/RedHat is a company and their obligation is to maximize the profit of the shareholders. But shareholder value for a company as RedHat comes also from keeping the community happy

Indeed, otherwise they almost might as well go fully closed source and only sell binaries with a support contract. I think that detailed bug reports and community provided patches are part of what makes Jboss AS as good as it is.