Elastic's AGPL announcement starts with the artifact
Elastic's 2024 AGPL announcement concerned eligible source code. Check the version, file headers and distribution before changing a procurement decision.
By 
Paul. Software business
An open-source announcement becomes useful to a business when it can be connected to the software that business will actually receive. Elastic's August 2024 AGPL announcement added a meaningful source-code option. It did not establish that every Elasticsearch download, feature or historical version acquired the same licence.
The right procurement response is to identify the artifact, its version and its applicable terms before changing an approval. This November 2026 retrospective examines that boundary. It offers no blanket assurance about a particular company's deployment or obligations.
Announcement and implementation are different evidence
In the announcement dated 29 August 2024, Shay Banon said Elastic would add AGPL alongside ELv2 and SSPL in the coming weeks. The future tense matters. A team reading that announcement during the historical week had evidence of an intended additional option, rather than proof that every available release already contained it.
Versioned source files provide a more precise comparison. The Elasticsearch v8.15.0 root licence describes a default dual choice of SSPL and Elastic License 2.0, subject to applicable headers. The v8.16.0 root licence instead describes a default triple choice including GNU Affero General Public License v3.0 only. It also retains other licensing categories and says solely ELv2 code is found in the x-pack folder.
That comparison establishes the difference between those tagged source trees. It does not identify the first implementing commit or make every file in v8.16.0 AGPL-eligible. The root text explicitly directs readers to applicable headers. Treating a folder name or the repository's headline licence as a substitute for those headers loses the qualification that makes the evidence accurate.
The packaged product needs its own answer
Elastic's licensing FAQ, retrieved in November 2026, distinguishes the additional source-code option from default distributions under Elastic License 2.0. The page also retains forward-looking wording about the change taking place before 8.16 became generally available. It is mutable explanatory context, so the tagged files above carry the narrower version comparison.
A business downloading a default distribution should therefore examine that distribution's own terms. It should not mark the download AGPL merely because some source can be obtained under AGPL. Conversely, a team considering a build from eligible source must establish which code and dependencies enter that build. A repository and a distributed package are different artifacts even when they share a product name.
This distinction has a concrete consequence for outsourced work. A proposal that simply lists “Elasticsearch, open source” leaves the deliverable unclear. The customer cannot tell whether it will receive a supplier-managed service, a default packaged installation or a separately built artifact. Those arrangements can imply different responsibilities for operating, updating and reviewing the software.
Write the decision around the intended use
Consider a proposed customer-search project. The business wants staff to search order records and customers to find products. The procurement record should identify the chosen software version, its source or download location and any separately licensed features the design requires. It should also say who operates it and who receives software or network access.
That is an illustrative project, not an AL+ client or an eligibility finding. Its purpose is to expose missing information. If the supplier cannot identify the artifact, a general statement about open source cannot repair the gap. Ask for the exact package and relevant licence material before accepting contractual promises built on it.
Preserve the reviewed material alongside the decision. A link to a current FAQ can explain the supplier's position, but it may change before a future maintenance discussion. A versioned licence file, package notices and the agreed deployment description make later review more concrete. None alone establishes that all conditions have been met.
Keep technical and legal questions connected without pretending they are identical. Engineers can identify components, versions and changes. The person assessing obligations needs the intended use and delivery arrangement too. A legal answer based on a different artifact can be as unhelpful as a technical answer based on a different version.
An additional option can still matter
This degree of qualification can understate the announcement. That objection deserves weight. Adding an established open-source licence can materially change which organizations can consider eligible code. A company whose policy rejected the earlier options might gain a route worth investigating. That is a real reason to revisit an earlier decision.
The qualification makes that opportunity actionable. Reopen the decision for the source and version that now offer the option, then examine whether the intended build and use fit it. Do not infer that AGPL is obligation-free, that every connected application must be published or that every service can be offered without further review. Those universal conclusions do not follow from the cited version files.
For a company already using the default distribution under reviewed terms, the source option may require no immediate operational change. A licensing headline alone is insufficient reason to rebuild a stable search system. The benefit might be a future procurement option rather than a migration to perform this week.
Leave the next maintainer an identifiable choice
A useful handover contains the actual choice, not a slogan about the vendor. Record what will be installed, what source revision matters, which terms were reviewed and what changes would require another assessment. If a later feature introduces different code or a different distribution, reopen that part of the decision.
When commissioning custom software, include that artifact record in the proposal and handover. Elastic's announcement was worth attention because it created an additional choice. The business can benefit from that choice only after locating it in the software it intends to build, receive or operate.