Hacker News Reader

Comment by arpinum | Hacker News Reader

"protection against public cloud providers offering open source products as a service without contributing back".

I have no issue with whatever license they choose, but let's be honest, its not about contributing back to these projects, its inserting a poison pill clause that they know cloud providers can't meet.

Specifically, by contributing back they mean, per the license: "If you make the functionality of the Program or a modified version available to third parties as a service, you must make the *Service Source Code* available via network download to everyone at no charge, under the terms of this License."

View on HN

Elasticsearch couldn't exist without the open source Lucene project which is at its core.

Lucene is licensed under the permissive Apache license which is why Elastic is able to release proprietary paid modules that link with it.

Now they are closing the same holes that they themselves used to create their product. Contributing back is definitely the last thing on their minds.

Elastic contributes massively to Lucene, so this is a false dichotomy

Thanks for pointing this out.

Red Hat (my employer currently) is typically in the same boat here and it drives me crazy how people don't think about that before criticizing.

People love to say, "Red Hat couldn't exist without <project>" which is true, but what they don't realize is that a ton (sometimes all) of the development of that upstream project is done by Red Hat employees. Without that a lot of projects may not even exist.

There are no doubt "open source" companies that take more than they give, but it's a little more nuanced and complicated than people make it out to be.

Would Elastic be in a position to "close source" / "re-license" their code if Lucene itself wasn't permissively licensed? Your argument's putting the cart before the horse.

No, offering your code under Apache/MIT is a bell you can't unring. You can stop offering future changes under the license, but everything up to the point where you change the license is available forever.

And guess what, when a corporation uses Elasticsearch in a serious way they will inevitably end up contributing back. It's actually easier to just get a change merged upstream rather than to manage a whole fork, unless the upstream is really hard to get patches merged with.

The whole narrative of "company X is offering Elasticsearch as a service and not contributing back!" is ridiculous. First of all, the whole point of free software is that somebody somewhere is going to be making money with that software, and that's okay, regardless of contribution. Second of all, in practice companies like Elastic will always exaggerate the extent to which corporations aren't "contributing back".

What they really mean is Amazon isn't contributing financially to Elastic Co. That's what they're pissed about, and that's why they clearly wish they were actually in the business of proprietary software (which they now are)

> It's actually easier to just get a change merged upstream rather than to manage a whole fork, unless the upstream is really hard to get patches merged with.

The thing is "really hard to get patches merged" is a fuzzy barrier. There are many, many example of what most would consider reasonably maintainers where companies just don't contribute back. Even in breach of GPL.

>First of all, the whole point of free software is that somebody somewhere is going to be making money with that software, and that's okay, regardless of contribution.

No, the point of free software is that users of the software have the freedom to use the software, redistribute the software, modify the software, and redistribute modified versions of the software. Someone making money using those abilities is incidental to the actual goal.

I agree but you're really splitting hairs at this point, aren't you?

When then is SSPL still enforced on those who contribute to Elasticsearch?

What do you expect them to do though? If they want to be viable as a business they need to place some restrictions so they can have a monopoly on some aspect in order to derive profit.

If they're not viable as a business, they die and nobody benefits from that.

It's this kind of all or nothing criticism that has made me rethink open source. I'm releasing a product this year, and it's going to start under a proprietary license. Because it seems you're damned if you do and damned if you don't. At least commercial closed source products don't attract this kind of criticism.

Agreed, if their hosted cloud services and premium features aren't viable as a business, and they don't have any intention to develop this software without a profit, then they shouldn't have positioned themselves as a free-and-open-source product in the first place.

You can run the SSPL'd code, you can view the SSPL code, if you change the SSPL code then contribute back if you distribute your changes. If you run a service providing the SSPL code, contribute the management layer back as well.

It gets more code into the open, where's the disconnect?

I am not concerned with the code of other users' management layers. I am concerned with being able to use the code of this product in the way I want to use it. Copyleft is not important to me, I see permissive licensing as being a bigger priority for freedom.

> they don't have any intention to develop this software without a profit, then they shouldn't have positioned themselves as a free-and-open-source product in the first place.

If something satisfies the four freedoms [0], it is free software.

[0] https://www.gnu.org/philosophy/free-sw.html.en

How does SSPL satisfy GNU's "freedom 0", to run the program for any purpose?

In the same way the AGPL satisfies it, you can run it for any purpose if you provide the source code to users.

Well, the linked page indicated that copyleft is something that applies only to distribution and not use, but I guess the AGPL shows that that's not true.

Nonetheless I don't agree with the GNU's claim that copyleft doesn't reduce freedoms. Of course a permissive license provides more freedoms: it's right there in the name

But this issue isn't really about permissive vs copyleft licensing anyway: Had Apache used a copyleft license with Lucene, Elasticsearch would have never existed.

But Amazon is hardly offering Lucene as a SaaS offering, don't they?

If they did, should that mean Elasticsearch can't?

I don't see the point there.

Lucene is a library, you can hardly offer it as SaaS. It's gluework.

On the other hand, Elastic is much more enduser software, which is much more routinely abused for SaaS hosting by larger corporations.

I expect Elastic to not pretend they are doing this in the spirit of getting contributions back. Just say that this is in the interests of their business model.

It's a vocal minority that slings the hate. There are tons of people that appreciate open source with exceptions to prevent managed offerings by cloud providers as long as self-hosting to support your own stuff is allowed (including ability to customize/extend/patch).

I for one will (with a few exceptions) only pay for a product that is open source (at least enough so that I can self-host for my own product if I want should things change). Vendor lock-in is a serious problem and concern for many, and open source is how you address that concern. The best example is GitLab, which gets a ton of money from me that would otherwise go to GitHub (which I like better) if GH were open source.

By going proprietary you avoid the vocal minority on the internet, but you also (silently) shrink your potential customer pool. Especially with the AWS/Parler stuff, there are even more people that want the option to self-host in case they get de-platformed if the Overton Window continues to shift.

May I ask what your product is? Just curious :-)

> It's a vocal minority that slings the hate.

That's usually the case.

> at least enough so that I can self-host for my own product ... Vendor lock-in is a serious problem

I'm leery of vendor lock-in myself. Self-hosted will be the only way to run my product in the beginning, and the cloud service will follow when it's popular enough to make sense.

> May I ask what your product is? Just curious :-)

I haven't published the website yet (it will be at https://flowstate.dev), but it's a framework/runtime for building backend APIs using SQL and JavaScript. It lets you run SQL queries from the browser, among other things. Which sounds crazy, but it actually works well. Once I have a hosted cloud service it becomes a backend-as-a-service platform kind of like Parse or Firebase.

I'm not against open-sourcing it down the road, but it can't be an OSI license, and I'll wait until it's big enough that I'm less worried about competitors just lifting my source code. I know copyright laws protect against that, but that only matters if you have the resources to litigate.

I do want my users to be able to dig into the source if the documentation is lacking, and also to patch/modify it if they need to - so I need some kind of source-visible license down the road. I think I would also add a clause that if the company goes under or gets acquired and shutdown then all source code gets published under the Apache 2 license.

This "We need it for survival" is bullshit. With Elastic being public company you can see their revenue growing 60% last year.... with Apache 2.0 license. It is not the case what we've been loosing revenue for years due to AWS competition and this is the last action of the last resort. This is simply about speeding up the growth at expense of your users which is of course sugarcoated as "it is good for you"

> speeding up the growth at expense of your users

Rather at the "expense" of Amazon AWS

I wish comms were more honest about this, they'd earn more trust than just telling the community SSPL is now an OSS license despite what OSI has shot back about it, and that this is some type of necessary evil.

contributing back can mean monetarily. i’m sure elastic would be willing to sell a commercial license to a cloud provider if the deal makes sense.

They already do. https://www.elastic.co/about/press/elastic-partners-with-ali...

Thats fine, but then don't title the blog post "Doubling down on open", make it "Creating a more profitable business model".

Those aren’t necessarily contradictory titles. Large OSS projects require funding, or they run a serious risk of stagnation. If there are massively profitable corporations using OSS and contributing nothing back, or even actively competing with the project, then a more profitable business model may be the best thing an OSS project can do to ensure its longevity.

Reply on news.ycombinator.com