Unfortunately the DXP source code is currently avail to paid subscribers only. The release you mentioned in the github repo (2026.q1.0) is not for DXP, but was a CE release (i believe it was CE 7.4.3.148 or something, when I tried to built it).
Source code scanning should be done for your custom module deployments (if have any) and probably do a VAPT.
Hey @arun - actually, there is only one repo - GitHub - liferay/liferay-portal Ā· GitHub. Previously this was used to build both CE and DXP, but now, as you know, instead of building Liferay Portal Community Edition we make Liferay DXP available to everyone via the Free Tier.
Internally we still have an Update number (the 148) you mentioned above. We build a new one of these as needed, and then every 3 months one of these becomes the basis of the next Quarterly Release.
Liferay DXP 2026.Q1 equates to U147, while Liferay DXP 2026.Q2 will most likely map to U149.
Weāre pretty open about this - in each Quarterly Release webinar we share the development milestone that forms that basis of a release, and the release strategy.
Yes, I understand that there will be a CE mapping like U147/148 for every DXP release which can be found using Commit search results Ā· GitHub
But are you sure its the same code base as DXP, as I found some codes missing (com.liferay.portal.ee.license) from GitHub - liferay/liferay-portal Ā· GitHub ? So if i needed to make some changes in portal-impl.jar, can I compile the so called mapped version (U147) and deploy to the DXP free tier?
From past experiences, we seen the end userās reluctance to upgrade to the latest version (there are still some people using Liferay 6.1 CE ), where they want to patch something, they would be able to do so as the source code was available.
So, you ask a question which raises a really important point - if youāre using the Free Tier (or indeed using Liferay DXP in any way) you are not allowed to extend by modifying the source code. This is governed by the EULA. So, the example you provided is not something you are allowed to do if using the Free Tier. You can extend Liferay DXP (using Client Extensions, OSGi Modules etc.) but you canāt modify it.
The alternative to the Free Tier is to compile from the source, in which case you are no longer using Liferay DXP but you are building (sort of) Liferay CE yourself. At that point you would be using the LGPL license, which allows you to modify the source - and of course because itās governed by the LGPL you are required to make your modifications available to anyone as well.
This is kind of the point - if anyone is using Liferay for mission-critical production purposes where access to fixes to issues, security fixes, etc. is important (which, by definition it should be for production use-cases) then our recommendation is to become a Subscriber. But, there are other models available for situations where subscribing maybe isnāt possible.
In terms of upgrades, we know itās hard (certainly if youāre still on 6.1!) but something that (in my opinion at least) is something that anyone using Software needs to build into their standard operating procedures. While no-one is advocating upgrading every 3 months (although some of our Customers do) the upside of having upgrades as part of your Business as Usual activities is that the more frequently you upgrade, the less effort it takes. Similarly, the more you extend using loosely couple approaches like Client Extensions (instead of OSGi modules) the easier your upgrades becomeā¦
Anyway, this may not be the answer you were hoping for - just trying to be as open as we can be!
Hi. If we have many instances of Liferay (distincts deployments), all on the same domain but with subdomains (portal1.mydomain.org``, ``portal2.mydomain.org, etc ā¦), do we need separates activation keys ? one for each ?.
Same ask for multiple instances dedicated for DEV, QA end PROD (dev-portal1.mydomain.ord, test-portal1.mydomain.org, ā¦).
Iām afraid that we have to manage many activation keys, despite we are a single company.
), where they want to patch something, they would be able to do so as the source code was available.