0

Can I use Red Hat AMQ 7.7 in production without license or support subscription? And what's the difference between JBoss AMQ and Red Hat AMQ?

Justin Bertram
  • 29,372
  • 4
  • 21
  • 43
ImranRazaKhan
  • 1,955
  • 5
  • 33
  • 74

3 Answers3

0

All the projects which are part of Red Hat AMQ have open source licenses so there is no problem with building and using them in production. I don't believe there is anything legally stopping you from using any such version without support. Without a valid subscription you won't be able to use the specific bits distributed by Red Hat. Without support and easy access to the bits I don't really see why you would use Red Hat AMQ as those are arguably the two largest benefits. You could easily just use ActiveMQ Artemis directly instead.

At the end of the day, I am not a lawyer, and I do not represent Red Hat. I strongly recommend that you discuss the issue with Red Hat directly.

Red Hat AMQ and JBoss AMQ are the same thing. The "JBoss" branding was used prior to the most recent AMQ releases.

Justin Bertram
  • 29,372
  • 4
  • 21
  • 43
  • This answer is incorrect. The policy is similar to the RH Linux. You can get the source code and compile it by yourself but the binaries are licensed so the paid subscription is needed. – spoonboy May 10 '23 at 23:29
  • @spoonboy, are you sure about that? The license files in the Red Hat AMQ distribution make no mention of this. Can you provide any kind of citation? In any event, all the source is it GitHub and is fairly simple to build. Also, you note that "this answer is incorrect," but the answer makes several independent statements. Are all of these statements incorrect? Please clarify. Thanks! – Justin Bertram May 11 '23 at 03:01
  • I've approached the RH support with a similar question and they've referenced me to this document: https://www.redhat.com/en/files/resources/en-rhjb-subscription-guide-12149557.pdf , page4. In short, only a dev environment with a single user can be used with no subscription. – spoonboy May 15 '23 at 07:07
  • Sorry, I have to correct my previous statement a bit. Even for the DEV environment the subscription is assumed. It will just not consume the subscription cores, as far as I understand. – spoonboy May 15 '23 at 07:24
  • I've added the full answer . It is based on the response I've got from the RH. – spoonboy May 15 '23 at 09:52
  • Justin, I would correct the answer regarding the source code as well. There is no RH AMQ source code repository on the public repositories like GH. RH subscribers can download the RH source code from the RH web site. But, they have to register and accept the RH conditions. It is NOT that easy at all to build a free version of the RH AMQ product as far as I see. You can build ApacheMQ. But, as you mentioned in your other answer, there is no direct linkage between the versions. RH AMQ is "based on" rather than "equals to" a particular Apache release. – spoonboy May 17 '23 at 20:31
  • There is, in fact, a Red Hat AMQ source code repository on GitHub. See https://github.com/rh-messaging/activemq-artemis. It was the [first result](https://www.google.com/search?q=red+hat+amq+github) for me when I searched Google for "red hat amq github." Clone that, add a new `profile` in Maven's `settings.xml` pointing to https://maven.repository.redhat.com/ga/ (to get all the dependencies), and run `mvn -Prelease package -DskipTests`. In a few minutes you'll have a release in the `artemis-distribution/target` directory. Aside from the new profile this is the same process you'd use at Apache. – Justin Bertram May 17 '23 at 23:11
  • Yeah, I've actually found it as well. But it does not look like an official RH repository. The RH account on the GH is here: https://github.com/RedHatOfficial – spoonboy May 18 '23 at 10:33
  • In the rh-messaging repo there are up-to-date tags for candidate and engineering releases that correspond to actual releases from Red Hat. That combined with the fact that the build is using dependencies only available in Red Hat's Maven repo makes it look official to me. It's also worth noting that the description for the RedHatOfficial org says it's for, "...unsupported open source projects and code that have been started by Red Hat associates." ActiveMQ _wasn't_ started by Red Hat and AMQ _is_ supported so it would not seem to be the proper place for an AMQ repo. – Justin Bertram May 18 '23 at 15:24
  • It's also worth noting that the source code is also in Red Hat's public Maven repo (e.g. https://maven.repository.redhat.com/ga/org/apache/activemq/artemis-server/2.28.0.redhat-00003/artemis-server-2.28.0.redhat-00003-sources.jar). Although you'd need to invest some time to work backwards from the source jars to something you could actually build. – Justin Bertram May 18 '23 at 15:26
  • Yes, and the RH description for the maven repo states this: "Artifacts in the repository do not receive automated security patches as Maven requires that artifacts be immutable. As a result, artifacts that are missing patches for known security flaws will remain in the repository to avoid breaking builds that depend on them. ... If you deploy these artifacts into a production environment then you should check the Red Hat Customer Portal for potential security patches and apply them accordingly. For more details, see How Red Hat Ships JBoss Security Updates." – spoonboy May 18 '23 at 19:19
  • I'm not sure I see the relevance of that statement to this discussion. Can you clarify? Thanks! – Justin Bertram May 18 '23 at 19:23
  • What I'm trying to say is that is it not that easy to build the same version of RH product that would be matching the RH version in all the aspects (patches, dependencies). The only real proof would be a check sum. Have you managed to get the same check sum for the version with the approach you proposed? – spoonboy May 18 '23 at 19:25
  • The rh-messaging repo not only has tags for releases but tags for patch builds as well so you can ostensibly build any patch release you want. The dependencies are all part of the `pom.xml`. It may be that the only "real proof" that you're running _exactly_ the same version as RH is by running a checksum against the actual RH distribution, but of course you have to pay RH to access that which is what you're attempting to avoid by building it yourself. It seems like a catch-22. In any event, the source is open, it is easy to build, and there's no legal risk running it in production. – Justin Bertram May 18 '23 at 19:40
  • Ok, I think this is a good idea to try the theory about the rh repo and the check sum. – spoonboy May 18 '23 at 20:01
  • Keep in mind that the real test of whether or not they are the "same" is mainly through comparing the source code. The final assembly may be different due to small file-name differences, the version of Java used, build-time properties added to jar manifests, etc. These would be flagged by a checksum as different even though the actual source code was exactly the same. – Justin Bertram May 18 '23 at 20:24
0

If you want to use AMQ and not to pay for a subscription you can use Apache Artemis. All RH products have a free (as in beer) version, the difference is the RH support and the quality control (better in RH buildings IMHO)

Raúl López
  • 31
  • 2
0

The pretty much only scenario you may lawfully get and use the RH products on your prod environment without an active subscription is when you got the RH product via a valid subscription first. Then, once the subscription expired you can continue using the product without subscription as long as no other active RH subscriptions in your organisation (aka "all or nothing rule" Appendix 1, section 1.2 of the Red Hat Enterprise Agreement).

This case is covered in the Red Hat subscription model FAQ under "What if a subscription is not renewed?".

You can, of course, obtain and use the Apache ActiveMQ products as a free alternative with a similar functionality or assemble your own version of the software from the Apache source code which is publicly available.
However, the RH holds the rights on their product's binaries aka "bits footprints" and the subscription is needed if you want using them on a prod or non prod environment.

Now, regarding the sources from RH and the licence...
If you have a valid Red Hat (RH) support subscription, you can download the RH AMQ sources from the RH web site. It's important to note that the Apache ActiveMQ repository does not contain the exact sources used by RH to build their binaries. The RH sources come with an open source license specified, allowing distribution and other actions. However, there's a catch: if you choose to distribute these RH sources, you risk losing your subscription benefits.
That's the reason why an official public clone of the RH AMQ repository is not available. However, there are some anonymous repositories on GitHub that might have been created by individuals who have access to the RH sources through their subscription. These individuals cannot reveal their identities because doing so would lead to the termination of their RH subscription. It's important to note that relying on these anonymous repositories to build your production environment is not advisable from a security perspective.

Please note that I am not affiliated with RH in any manner, nor am I endorsing their approach of commercialising open-source products. The information I am providing is based on my understanding of the answers obtained from RH support. Additionally, it's important to acknowledge that RH policies may vary from one country to another in order to comply with local laws and regulations.

spoonboy
  • 2,570
  • 5
  • 32
  • 56
  • If you're focused solely on the "bits" of the product then I believe you're correct as those are licensed by Red Hat (I touched on this in my answer). However, you can easily get the _product_ (i.e. not the Apache project) source code off GitHub and build it yourself and use it. Again, everything is open source. Perhaps I didn't make this distinction clear enough in my answer. Is that what you object to? – Justin Bertram May 15 '23 at 14:17
  • The source code is not the "product". – spoonboy May 15 '23 at 16:33
  • At Red Hat the "product" is many things, but the source code is foundational to everything. That said, what customers really pay for are not products, per se, but rather _services_. These services include supporting the source code (e.g. fixing bugs, adding features, etc), building and packaging the source into easily deployable "bits," runtime and development support with tiered SLAs, consulting, etc. If someone only wants to run AMQ in production without any of those other services they can do so by grabbing the source code and building it themselves. It is all open after all. – Justin Bertram May 15 '23 at 17:20
  • Nope, this is not how RH sees it. The subscription is "non just a support contract". The RH product is "not the source code". The question was specifically about the RH product. So, you probably should be be using the RH definitions of the "product" and "subscription" when answering it. – spoonboy May 15 '23 at 17:39
  • I'm not quite sure I understand. I never said (or meant to imply) that a subscription was "just a support contract" or that the "product" was only "the source code." My points were simply, (1) the "product" is much more than the "bits," and (2) you can grab the AMQ source code, build it, and run it in production with no legal risk. The terms "product" and "subscription" are used in many different ways in many different contexts. I think these semantics, while related, are essentially beside the point. – Justin Bertram May 15 '23 at 17:54
  • I think I agree with both of your statements and I've mentioned the same points in my answer. But they are quite different from your original answer which is not just incorrect but could be dangerously misleading as the only issue with running the RH AMQ on the prod it mention is a "trouble finding the bits". Assuming you got the RH binaries somehow. Can you lawfully run them on the prod with no RH subscription? Absolutely not, the RH product subscription is needed. This is what I'm trying to clarify in my answer. But it probably would be even better if you correct your one. – spoonboy May 15 '23 at 18:08
  • I updated my answer to hopefully clarify. That said, anybody who's basing legal/contract decisions on Stack Overflow answers is clearly not doing their due diligence. :) – Justin Bertram May 15 '23 at 18:27
  • Thanks. I think I will keep my answer as well as it is more focusing on the binaries of the RH products. I think both sides the Apache and RH are not doing enough to clearly state all the aspects of relations between their products. Apache is describing RH AMQ as "a supported distribution of Apache ActiveMQ", which is not quite how RH defines their product. There is no one to one match between the Apache and RH releases. Some differences are quite significant. Like RH drops support of OpenWire in their next release of AMQ while Apache seems to intend to continue it in Artemis. – spoonboy May 15 '23 at 18:51
  • From what I can tell, calling Red Hat's AMQ "a supported distribution of Apache ActiveMQ" seems pretty accurate. It is, in fact, a distribution of ActiveMQ, although it is not _Apache's_ distribution. It is based on a specific Apache release, modified within the constraints of the license, and then supported with specific caveats. This kind of management of technical debt is pretty common among commercial support options for open source projects. – Justin Bertram May 15 '23 at 19:49
  • Now, compare it with the RH description of the relation: " Red Hat® AMQ—based on open source communities like Apache ActiveMQ and Apache Kafka". – spoonboy May 15 '23 at 20:06
  • "AMQ" looks to be a suite of components rather than just one thing. I committed a small clarification to the ActiveMQ website. – Justin Bertram May 16 '23 at 14:11