Elasticsearch is na drie jaar weer opensource beschikbaar onder AGPL-licentie

Elastic heeft Elasticsearch weer opensource beschikbaar gesteld onder de oude AGPL-licentie. De problemen die de bedrijven eerder hadden met AWS, zijn inmiddels in zoverre opgelost dat het weer mogelijk is de oude licentie te gebruiken in plaats van de gesloten.

Elastic schrijft in een blogpost dat het Elasticsearch weer 'opensource kan noemen'. Het bedrijf heeft de gebruikerslicentie van de zoekengine veranderd in een GNU Affero General Public-licentie, of AGPL. Die is specifiek bedoeld voor software die over andere netwerken loopt, waarmee het bijvoorbeeld makkelijk wordt software-as-a-servicepakketten aan te bieden waarin Elasticsearch is geïntegreerd. Elasticsearch zegt dat die licentie 'werkelijk opensource is' en dat die licentie veel gebruikt wordt, onder andere in MongoDB en Grafana.

Elastic veranderde in 2021 het licentietype voor Elasticsearch en voor zijn eigen Kibana-software. Die waren altijd beschikbaar onder de Apache License Version 2.0, maar Elastic wijzigde dat in twee eigen licentietypes: Elastic License 2.0 en Server Side Public License, ook wel ELv2 en SSPL genoemd. Daarmee was de software een stuk minder bruikbaar, omdat ontwikkelaars beperkt werden in hoe ze de software mochten gebruiken.

Amazon maakte daarop een opensourcefork van zowel Elasticsearch als Kibana. OpenSearch en OpenSearch Dashboards waren nagenoeg dezelfde softwarepakketten, maar in tegenstelling tot Elastics software was dat wel nog onder de ALv2-licentie beschikbaar.

AGPL wordt 'in de komende weken' een derde licentietype voor Elasticsearch, naast ELv2 en SSPL. Die blijven beide ook nog bestaan voor de software. Elastic zegt dat het in de afgelopen jaren veel problemen had met Amazon en specifiek AWS, waar Elasticsearch veel gebruikt wordt. Het bedrijf zegt dat het er al rekening mee had gehouden dat Elasticsearch zou worden geforkt, maar dat inmiddels de relatie met AWS dermate is verbeterd dat het bedrijf weer een nieuwe opensourcelicentie durft toe te voegen aan het product.

Update: in het artikel stond per ongeluk dat de zoekengine veel werd gebruikt in MongoDB en Grafana, maar dat moest het licentietype zijn.

Reacties (29)

[v42.net]

Elastic is de maker van Elasticsearch. Volgens Elastic misbruikte Amazon hun open licentie door een product aan te bieden dat concureerde met Elastic's eigen betaalde dienst (die onder andere ook op AWS beschikbaar is). Om te voorkomen dat dat vaker zou gaan gebeuren hebben ze toen de licentie aangepast. Ik heb geen ervaring met OpenSearch, maar gezien de goede support van Elastic voel ik niet de behoefte om Opensearch te gaan gebruiken. Ik ben ooit begonnen met Elasticsearch 2.0 en zowel hun product (self-hosted) als hun dienst (Elastic Cloud) bevallen nog steeds heel goed. Maar dat is natuurlijk heel persoonlijk, ik kan niet voor iemand anders spreken. Als Opensearch je goed bevalt, zie ik geen reden om over te stappen.

Nog een kleine opmerking bij het artikel: Ontwikkelaars werden niet beperkt, alleen de manier waarop je het resulterende product vervolgens als dienst mocht aanbieden werd beperkt.

[Reactie gewijzigd door v42.net op 30 augustus 2024 14:15]

[Rob Coops]

Jaren met Elastic gewerkt en na de licentie switch gezien het product that het bedrijf waar ik voor werkte (alle klanten hadden een Elastic installatie) overgestapt naar OpenSearch. Geheel pijnloos en 100% compatible alleen geen licentie gerommel met Elastic voor de honderden Elastic installaties die wij hadden draaien op dat moment.

De support van Elastic in ieder geval op Elastic cloud was redelijk alleen hadden ze wat moeite met grotere omgevingen met +100TB aan data.

Ik moet zeggen dat ook zonder support Elastic/OpenSearch goed werken en ik tot nog toe in middels drie jaar later niet een keer een probleem heb gezien waar support voor nodig was om het op te lossen. Nogmaals dat is honderden Elastic installaties gedurende zo'n 2.5 jaar in middels (je kunt niet van de een op de andere dag overstappen zeker niet met zo veel installaties)
Maar ik begrijp heel erg goed dat veel grote bedrijven simpel weg niet zonder vendor support willen moeten leven voor het geval dat... en ik denk dat men daarom dat ze heus wel weer wat klanten terug zullen winnen maar ik denk ook dat flink wat van hun klanten liever niet weer overstappen omdat je nooit weet waneer ze weer van licentie veranderen en de laatste verandering heeft voor aardig wat werk en dus kosten gezorgd bij veel grote bedrijven die op z'n minst moeten onderzoeken of ze dankzij de nieuwe licentie niet in de problemen zouden kunnen komen. En dat zal er denk ik ook voor zorgen dat veel van deze klanten liever even zullen wachten voor ze weer in zee gaan met Elastic.

[edwinjm]

maar gezien de kwaliteit van Elastic's support voel ik niet de behoefte om

Algemene tip: zeg gelijk "goede support" of "slechte support", dan hoeft de lezer niet eerst een logicadiagram in zijn hoofd te bouwen om te bepalen wat je bedoelt 😉

[_eXistenZ_]

Mooi maar nu is iedereen toch gewoon over op Opensearch? Waarom zou je nog terug willen, wetende dat Elastic random hun licentie verandert wanneer ze er in in hebben?

[Freeaqingme]

Dat niet alleen. Dit is ook het bedrijf die toen ES nog open source was, alle security plugins uitsluitend betaald aanbood.

Daarnaast, de vorige keer dat Elastic de licentie veranderde, deden ze dat omdat ze zeiden dat Amazon profiteerde van hun product zonder terug televeren. Echter, Amazon had volop Pull Requests open staan, waar Elastic simpelweg niets mee deed.

Nou support ik Amazon niet zo snel/vaak, maar in dit geval is Amazon wel echt de betere partij van de twee.

[BugBoy]

Dus een bedrijf dat hun core-product gratis ter beschikking stelt, maar voor extensies wel geld vraagt vind je verkeerd. Maar een bedrijf dat voor alles geld vraagt vind je wel okee? Die logica snap ik niet helemaal.

AWS heeft gewoon schaamteloos ElasticSearch geforkt en daar een betaalde dienst van gemaakt. Daarmee werd het verdienmodel van Elastic behoorlijk ondermijnt. Dat Elastic maatregelen heeft genomen is jammer, maar wel begrijpelijk.

AWS staat er niet om bekend dat ze veel teruggeven aan de community. Veelal zijn de PRs bedoeld om het spul beter te laten draaien op AWS. Daarbij kost het reviewen van PRs veel werk en alle die code moet ook onderhouden worden. Ik werk zelf voor een OSS bedrijf. Veel "contributors" submitten een PR dat functionaliteit toevoegd, maar mist unit tests, integratie testen en het moet uiteindelijk ook onderhouden worden.

Ik ben wel benieuwd waar de relatie met AWS is verbeterd. Daar kan ik niet veel over vinden...

[Freeaqingme]

AWS heeft gewoon schaamteloos ElasticSearch geforkt en daar een betaalde dienst van gemaakt. Daarmee werd het verdienmodel van Elastic behoorlijk ondermijnt. Dat Elastic maatregelen heeft genomen is jammer, maar wel begrijpelijk.

Schaamteloos een open source product forken nadat het bedrijf achter dat product de licentie verandert naar iets dat niet open source is. Terwijl dat bedrijf dat het forkte (Amazon) volop had terug gecontribute aan het open source product (waar Elastic dan weer vaak niets mee deed).

AWS staat er niet om bekend dat ze veel teruggeven aan de community. Veelal zijn de PRs bedoeld om het spul beter te laten draaien op AWS. Daarbij kost het reviewen van PRs veel werk en alle die code moet ook onderhouden worden. Ik werk zelf voor een OSS bedrijf. Veel "contributors" submitten een PR dat functionaliteit toevoegd, maar mist unit tests, integratie testen en het moet uiteindelijk ook onderhouden worden.

Volgens mij was dat hier niet zo hoor. AWS contribute volop terug aan functionaliteit, niet enkel om het beter op AWS te laten draaien. Daar had Amazon een aantal full time contributors opzitten, die echt wel professioneel genoeg zijn om feedback op zo'n PR te verwerken, documentatie te schrijven en unittests te fixen.

Ik herken echt wel wat je zegt in z'n algemeenheid, maar in het geval van OpenSearch was Amazon echt niet de bad guy imho.

[_JGC_]

SSPL is gewoon een open source licentie, hij is alleen nogal extreem restrictief op wat je met de code mag doen zonder broncode van je aanpassingen of integraties te delen.

De oude licentie was de Apache 2.0 licentie, die eigenlijk heel vrij is. Mag je commercieel uitbuiten. Zolang je het eindproduct niet verkoopt maar aanbiedt als dienst hoef je de broncode niet vrij te geven.

AGPLv3 en SSPL werken dat gat weg: je mag gerust een gewijzigde ElasticSearch servcie hosten, maar van wijzigingen maak je de broncode openbaar. SSPL gaat daarin een heel stuk verder dan de AGPL.

[Freeaqingme]

Nou kunnen we helemaal gaan nitpicken, maar ik zou zeggen dat SSPL source-available is. Niet open source. Dat zegt in ieder geval het Open Source Initiative (OSI): The SSPL is Not an Open Source License

[_JGC_]

SSPL is in zoverre open dat het onbruikbaar is voor commercieel gebruik. De licentie gaat te ver in het open zijn. Waar je bij AGPL alleen aanpassingen aan Elasticsearch vrij moet geven als je het gaat hosten, moet je bij SSPL je hele project met alles eromheen vrijgeven.

Van Wikipedia:

It includes most of the text and provisions of the GNU Affero General Public License version 3 (AGPL v3),but modifies its provisions for software that is conveyed over a network—requiring that anyone who offers the functionality of SSPL-licensed software to third-parties as a service must release the entirety of their source code, including all software, APIs, and other software that would be required for a user to run an instance of the service themselves, under the SSPL. In contrast, the AGPL v3's equivalent provision covers only the licensed work itself.

[wooha]

Een behoorlijk stuk verder inderdaad. Als je het als dienst aanbiedt, dan moet je de volgende sources ter beschikking stellen onder de SSPL:

“Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.

Als je dat niet mag vanwege andere overeenkomsten/licenties, dan mag je de software helemaal niet als dienst aanbieden. Gelukkig valt het OS niet onder de Service Software.

Dit komt overigens uit de MongoDB versie. Ik weet niet of Elastic precies dezelfde licentie gebruikt.

In de discussie met OSI stelde MongoDB nog wijzigingen voor, die ik in de uiteindelijke versie niet terugzie, waarschijnlijk omdat OSI het zelfs met die wijzigingen niet ging accepteren.

• Een deel van die service software zou onder een andere OSI licentie kunnen vallen, waarbij het niet toegestaan is om de licentie aan te passen naar SSPL
• Je mag blijkbaar geen gesloten software gebruiken voor alle ondersteunende software, behalve het OS, libraries en compilers
• Ik zie niet hoe waar die Service Software "definitie" ophoudt. Valt onder "hosting software" ook KVM, VMWare, of zelfs de firmware van de routers die je gebruikt om de dienst aan te bieden?

Ik zou me er niet aan wagen om die software te hosten en ik denk dat dat ook precies de bedoeling is, maar misschien denkt een jurist daar anders over.

Edit: libraries en compilers toegevoegd als uitzondering.

[Reactie gewijzigd door wooha op 30 augustus 2024 19:24]

[kozue]

En wat is er mis met betaalde extensies op een open kernproduct? Mogen ze van jou geen geld verdienen? Genoeg bedrijven gebruiken het al gratis zonder iets terug te leveren.

[Freeaqingme]

Nee hoor. Daar is an sich niets mis mee. Maar dat je dan precies de security extensies betaald maakt is wel frapant. Daarmee is het core-product dus inherent insecure. Dat je als bedrijf dat zogenaamd goede bedoelingen heeft moedwillig een onveilig product publiceert om geld te verdienen met de beveiliging daarvan dat vind ik niet bepaald chique.

[MadEgg]

Het product is prima te gebruiken zonder security features. Het hangt heel erg van je netwerk set-up af of dat een probleem vormt of niet. Bijvoorbeeld als je de boel in Kubernetes draait met Istio proxies en RBAC zit al die security zooi alleen maar in de weg en brengt het niets extras ten opzichte van wat je al hebt.

[TechSupreme]

Er zijn nog genoeg project die ES gebruiken. Als je eenmaal een volwassen project hebt dan is het niet zo makkelijk als in je vingers knippen en we zijn om.

[MadEgg]

Opensearch ondersteunt ook nog best wat dingen niet die Elasticsearch wel doet. Dynamic templates bijvoorbeeld. En Elastic is zeker geen heilig boontje maar AWS hanteert wel een embrace extend extinguish strategy. Elastic moest iets om te voorkomen dat ze werden overlopen door deze gigant, dus helemaal kwalijk nemen kan je het ze ook niet.

AGPL lijkt me een prima licentie, zij het wat restrictiever dan de apache license. Niets mis mee, goede stap.

[t_o_c]

Omdat bedrijven zoals Amazon gratis willen meeliften op het succes van andere bedrijven.

Elastic bouwt een goed product en vervolgens forkt Amazon dat (want opensource) en bied het aan op hun eigen cloudservice voor een lagere prijs dan die elastic realistic kan aanbieden. Heeft Amazon hier zelf iets voor gedaan? Nee. Dat is het hele probleem.

Voor de rest had het veranderen van de licentie voor veruit de meeste elastic klanten geen tot weinig impact.

[phobosdeimos]

Natuurlijk niet. Vergelijk even de GitHub repo activity van opensearch met elasticsearch: de activiteit rond elasticsearch (stars, pull requests, commits, issues) is nog altijd een veelvoud van de activiteit van opensearch.

Waarom zou je de bedenkers en ontwikkelaars van elastic de rug toekeren om trouw te zweren aan een schurftige firma als Amazon?

Ik blijf lekker bij het origineel: heb een 10 node cluster draaien van ongeveer 20TB en die doet het al vele jaren vlekkeloos, upgrades gedaan van v5 tot en met v8 zonder downtime. Rock solid.

[jrswgtr]

Wij werken veel met het Hypernode platform. Bij nieuwe Hypernodes staat tegenwoordig standaard OpenSearch ingeschakeld, maar het is ook nog mogelijk om over te schakelen naar ElasticSearch 6 of 7.

Weet iemand argumenten waarom je dit wel of juist niet zou moeten doen?

[satya]

Compatibiliteit misschien, in het begin gaf opensearch niet de juiste type/versie terug waardoor de applicatie niet kon werken. Was oa bij graylog het geval.

[MadEgg]

Argument om het niet te doen: je loopt achter de feiten aan? Elasticsearch 6 is antiek en unsupported, Elasticsearch 7 is ook al flink op leeftijd en op alle fronten voorbij gestreefd door versie 8.

[4tro]

Elasticsearch 6, dit zou je niet meer moeten doen omdat ie al een tijdje EOL is

[z1rconium]

Als je met de elastic/ELK aan de slag wilt, dan kom je nog wel wat complexiteit tegen, er is een opensource project 'zincsearch' die een simpelere versie heeft gemaakt, maar die elastic compatible is qua ingestion en API, weet niet of ik dit in een productie env zou aanraden maar voor lab/thuisgebruik werkt het top. Als alternatief voor kibana+elastic heeft dezelfde developer ook 'OpenObserve' gemaakt, weet niet waar hun focus nu ligt ik vermoed de laatste.

[Reactie gewijzigd door z1rconium op 30 augustus 2024 12:42]

[MadEgg]

Zinc is een leuk initiatief maar het wordt niet echt actief ontwikkeld, en is verre van feature complete. Inderdaad leuk voor lab/thuisgebruik maar voor enterprise gebruik is dit niet echt een kandidaat op dit moment.

[pentode]

Wat jaren terug bij Ykoon BV waar Marktplaats.nl bedacht en ontwikkeld is in Leiden.
Op https://www.koopkompas.nl/contact_us.php a way back. En dat draaide op een verouderde cms OScommerce een up2date search engine geïmplementeerd.

En ik heb daar toen Sphinx Search voor gebruikt. In een CentOS omgeving.
Elastic search was java geloof ik en dat was allemaal nog al zwaar aangezet.

Eerst kon je je brood opeten eerdat je een zoekresultaat had.
Maar na implementatie van de nieuwe search engine ging dat door een miljoen records
bijna in real time ;-P Na oa. indexering.

Info Sphinx Search voor de geïnteresseerden

[Reactie gewijzigd door pentode op 30 augustus 2024 21:55]

[thegve]

https://www.marktplaats.n...ats-geschiedenis.dot.html

Marktplaats ontstond in 1999 in Emmeloord als klein initiatief om tweedehands spullen aan te bieden. In deze eerste dagen kon het vergeleken worden met een digitaal prikbord.

Marktplaats is onze (groot)-regionale trots. Niet uit Leiden..

[pentode]

Dát is NIET de hele oprichting geschiedenis ;-P lees ook m'n andere reactie.

"Op 9 mei 1999 zette Rene van Mullem voor het eerst Marktplaats online. Begin 2000 kocht kringloopketen Het Goed met Bob en Frank Crebas Marktplaats, dat in 2004 in handen kwam van het Amerikaanse eBay. Vandaag het uitgebreide relaas van vader en zoon Crebas en belangrijkste programmeur Robin Schuil en een beknopte herinnering van bedenker Rene van Mullem."

Bron: Marktplaats bestaat 15 jaar

[Reactie gewijzigd door pentode op 31 augustus 2024 23:00]

[HollowGamer]

Al heel lang geleden overgestapt op Meilisearch, en ook zijn er genoeg andere alternatieven.

Zeg niet dat ES niet uniek is, maar hetzelfde zal ook gebeuren met Redis. Die licenties zijn gewoon te verwarrend en te gevaarlijk als je een (groot) commercieel bedrijf bent.

[Reactie gewijzigd door HollowGamer op 30 augustus 2024 15:13]

[pentode]

@thegve
Marktplaats is toch echt opgericht gemaakt bedacht in de Kruisstraat 2 in Leiden. Op een klein kamertje. Heb er zelf met m'n neus bij in de buurt gezeten ;-P

Bron: oude adres

Wiki: Marktplaats

Netkwesties: Marktplaats 15 jaar

 

[Reactie gewijzigd door pentode op 31 augustus 2024 19:42]