Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Open Source

Elasticsearch Will Be Open Source Again as CTO Declares Changed Landscape (devclass.com) 38

Elastic, creator of popular search engine Elasticsearch and visualization tool Kibana, plans to introduce the AGPL open-source license alongside its existing licenses. The move comes three years after Elastic ditched the Apache 2.0 license, sparking controversy in the tech community.

Founder Shay Banon says the change aims to clarify Elastic's market position following AWS's creation of OpenSearch, a fork of Elasticsearch. Despite initial friction, Banon claims Elastic's relationship with AWS has improved, citing growth in Elastic Cloud revenue and customer base.
This discussion has been archived. No new comments can be posted.

Elasticsearch Will Be Open Source Again as CTO Declares Changed Landscape

Comments Filter:
  • by dgatwood ( 11270 ) on Tuesday September 03, 2024 @12:38AM (#64757896) Homepage Journal

    Affero GPL is an abomination that violates the basic tenets of Open Source by imposing additional restrictions on your freedom to modify the source. Dumping the Apache license and replacing it with a non-permissive license is a huge slap in the face to pretty much everyone. There's almost not even a reason to bother open sourcing something like this under an Affero license, because the odds of being able to use it without needing to make site-specific changes (which you won't really want to share with the world) are, frankly, not that good.

    When Elastic removed the Apache license, Amazon forked the last Apache-licensed version and began maintaining it as OpenSearch. Over time, they have started releasing functionality for free that Elastic charges for. OpenSearch is behind feature-wise in some ways, but ahead of the free ElasticSearch experience in other ways. Releasing ElasticSearch under a non-permissive license basically seems intended to lock in users, forcing them to pay Elastic money for those features (e.g. authentication system integration), and seems pretty transparently anti-user from my perspective.

    The best thing folks can do is to support OpenSearch development and roll their eyes at this half-hearted attempt at salvaging Elastic's reputation in the Open Source community. Anything short of restoring a permissive license is a copout.

    • by rta ( 559125 ) on Tuesday September 03, 2024 @01:17AM (#64757936)

      Yeah, it's a total ploy on Elastic's part. AGPL is poison for any commercial use. (not always in theory, but in practice.. no thanks; unless somehow OpenSearch stops existing and even then we'll find alternatives)

      Also, they already burned the bridge. They deserve to be shunned for their rug pull.
      I have no interest in helping them get rich on stolen work of contributors.

    • Amazon forked Elastic search before they switched licenses. They weren't giving their source changes back to the community. Don't let that stop your rant, though.
      • by rta ( 559125 ) on Tuesday September 03, 2024 @10:47AM (#64758946)

        The beef was that Amazon was making lots of money by offering a hosted service, and thus eating Elastic's lunch; not about contributing back.

        If you read up on it it's that Elastic didn't want to accept Amazon's changes because they added "enterprise" security features that Elastic reserved for their closed/paid Enterprise versions.

      • Both Elasticsearch and Amazon's Opensearch are some of the biggest pieces of shit I've ever had to troubleshoot or administer. I don't care what licenses they used, they are both such horrible pieces of dogshit I'd suggest that anyone in the market for one or the other switch to literally anything else. Solr and Meilisearch are some good alternatives. If you still want to use Elasticsearch, stab yourself in the face with an icepick a few times. That will give you an understanding of what you're about to fac
        • As a former mainframe person, I likely have to object. At least on traditional mainframes you get a message with a searchable message identifier. That message covers users, administrators and others. You might also get a return and reason code if it aborts abnormally.

          They try to help the user. I suggest finding a better error comparison.

          • I worked for IBM for 10 years. I'm not some newbie who's never seen a mainframe, but you are still probably right, because there isn't much worse than ElasticSearch except maybe ElasticSearch in a fucking Docker container.

            I just resented the hell out of the fact that z/OS and the hardware consoles would spit reason codes rather than actual errors. "Enlightened" people at IBM gently explained that this was because they could translate all the errors into different languages and they didn't have room in the
    • by AvitarX ( 172628 )

      Would you elaborate on which freedom it violates and why the OSI is wrong for approving it?

      • by dgatwood ( 11270 )

        Would you elaborate on which freedom it violates and why the OSI is wrong for approving it?

        By redefining "distribution" in a nonsensical way, such that any real-world use of the software constitutes distribution, the AGPL effectively excludes the right to make changes so that the software suits your needs unless you are willing to make your source code changes public.

        This effectively violates the OSI definition of open source, because it grants you *either* the right to create derived works (#3) *or* the right to use it in a SaaS setting (#6), but not both at the same time, because making your mo

        • by AvitarX ( 172628 )

          What's to stop me from using a webapp under agpl internally without sharing changes?

          The user of the software is the one that gets the freedoms, in a SaaS situation it could be argued the end user is the one using the software as a service (there's valid arguments that that is not the end user also, in which case use the GPL2 or Apache license depending on your preference).

          But if you accept the premise using SaaS is using software I would think you'd approve of the AGPL.

    • Exactly. No one at MAANG will ever touch radioactive AGPL (or, worse, BUSL licenses), which effectively footguns a project. FOSS means freedom to do with code what you want. GPL 3.0 is even not really FOSS because it creates horrible limitations. The techbros and impressionable Gen Z'ers on HN think AGPL or BUSL are "great".
    • by Anonymous Coward

      No True Scotsman.

      You do not get to define what qualifies as open source. The term existed before the group tried to take ownership of the term and enforce their definition as the "right" ones.

    • My heart bleeds for all those poor corporations who want to take free software, modify it to their purposes, give nothing back to the world, and are prevented by AGPL from doing so. Tragic, really.
  • GPL vs BSD (Score:3, Insightful)

    by phantomfive ( 622387 ) on Tuesday September 03, 2024 @12:49AM (#64757906) Journal
    The advantage of GPL over BSD is that it allows you to charge for commercial uses, while still keeping it free for anyone who supports open source. If you want to dual license in that way, GPL is better. Of course, BSD is more free.
    • by dgatwood ( 11270 )
      For a piece of software that has basically no possibility of non-commercial use, that doesn’t sound like an advantage in any meaningful sense of the word.
      • Open source is always better.
        • by dgatwood ( 11270 )

          Open source is always better.

          Just to be clear, the problem is that they're licensing it under AGPL, not GPL.

          As licenses go, GPL v2 is mostly pretty benign when used for end-user software, and is only annoying when somebody licenses a library under that license instead of under LGPL, because GPL limits the ability to link against it.

          GPL v3 is orders of magnitude more annoying, because the "TiVoization" bits effectively prevent porting the software to iOS or Android unless they make an explicit exception, and the patent licensing rules

          • Ok you're a moron. For some reason you believe that the iOS terms and conditions prevent the distribution of GPL3 software. And then for some reason you claim that's a problem with the GPL, when Apple is the one who specifically excluded it. The GPL 3 is written in a way that specifically allows compatibility with the Apache license. It is better than GPL 2. The only reason it can't go in the kernel is because Linus specifically excludes it. That is an issue with Linus, not with the GPL.
            • by dgatwood ( 11270 )

              Ok you're a moron. For some reason you believe that the iOS terms and conditions prevent the distribution of GPL3 software.

              RMS says so as well. And IIRC, Apple flat out rejects any app submissions that are covered under GPL v3, precisely because they think so, too.

              And then for some reason you claim that's a problem with the GPL, when Apple is the one who specifically excluded it.

              No, GPL v3 explicitly forbids distribution in a manner that the user cannot modify it. Apple's code signing makes the license fundamentally incompatible. And although I disagree with some aspects of Apple's code signing, even I agree that it does serve a legitimate purpose, and I struggle to imagine any functioning code signing system that could not at least arguab

              • No, GPL v3 explicitly forbids distribution in a manner that the user cannot modify it. Apple's code signing makes the license fundamentally incompatible.

                That is a problem with Apple. They want to own a device that you bought.

                I struggle to imagine any functioning code signing system that could not at least arguably run afoul of the restrictions in GPL v3

                All you have to do is allow people to run the code to run on devices they bought. That's it.

  • Aaand... toooo late. (Score:5, Interesting)

    by Qbertino ( 265505 ) <moiraNO@SPAMmodparlor.com> on Tuesday September 03, 2024 @12:59AM (#64757914)

    1.) Build awesome software.
    2.) Make it FOSS
    3.) Watch it become an instant hit
    4.) Reconsider, get greedy, close the source again
    5.) Watch instant Fork appear two hours later
    6.) Watch Fork become the new standard within weeks
    7.) Reopen your software
    8.) Hear everyone say: "What, that project still exists?"

    Happens every time. The Mambo/Joomla incident was my personal favorite.

    • by echo123 ( 1266692 ) on Tuesday September 03, 2024 @03:31AM (#64758086)

      The open-source Drupal community seem to have confirmed your point. Prior to the licensing fiasco and subsequent ElasticSearch fork, the Elasticsearch Connector [drupal.org] Drupal module was the way to interface ElasticSearch with Drupal's rich Search API*.

      The Elasticsearch Connector code hasn't been actively maintained much since then while the Search API OpenSearch [drupal.org] seems to be a fork that is in fact actively maintained.

      * SOLR is far, far more popular for the purpose of Drupal Search with about 55k sites currently [drupal.org]

    • Mambo was an open source Content Management System (CMS, remember those?)

      The whole situation can be summarized as:

      Miro started Mambo. He did the original work, he got the ball rolling and so he believed that he was entitled to be in charge.

      Some of the Mambo community developers did a lot of work on Mambo and, Mambo wouldn't have existed without them. While they didn't start it, they saw their contributions are paramount and they thought they were entitled to be in charge. Miro said, F you it's mine.

    • OpenOffice sends condolences to ElasticSearch
      • OpenOffice sends condolences to ElasticSearch

        Ah, yes. Open-office having been developed at SUN and acquired by the cancer of ORACLE [wikipedia.org].

        Praise be the open-source LibreOffice fork that's part of standard Ubuntu and a lot of other open-source distributions as well.

  • When will they take it closed again?

    Who would use AGPL in a commercial product and who wouldn't use OpenSearch in a non-commercial product?

    Why build your business on sand instead of rock?

    • There's no problem using A GPL in a commercial product, as long as you aren't modifying the source and keeping those modifications secret. Stop your FUD.
      • by dnaumov ( 453672 )

        There's no problem using A GPL in a commercial product, as long as you aren't modifying the source and keeping those modifications secret. Stop your FUD.

        It actually goes much farther then that - you are entirely free to use GPL in a commercial product, change the source AND keep those modifications secret AS LONG as you do not redistribute your binaries to anyone. If and only if you redistribute your binaries, do you also have to provide the source and any changes to it.

        • by dnaumov ( 453672 )

          NVM, I misread the above, what I wrote applies to "GPL", but I am not at all certain about AGPL.

          • AGPL specifically poisons any product that is or uses AGPL libraries even as a SaaS.
            • by njvack ( 646524 )

              This point seems ambiguous to me. I'm not sure if this is a "if you modify an AGPL product, you must share the source to the product, even if you are only using it as part of a service" or if it's "If you use an AGPL product as part of a service, you must provide the source to the AGPL product as well as your service."

              Regardless, it's pretty much a moot point. OpenSearch exists, is wire-compatible with ElasticSearch, and has a thriving developer community and an unambiguous, well-tested license. I struggle

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (10) Sorry, but that's too useful.

Working...