HN user

metheus

343 karma

http://bringingfire.com/what-is-bringing-fire/

Posts26
Comments70
View on HN
engineering.mongodb.com 6y ago

Getting storage engines ready for fast storage devices

metheus
2pts0
www.mongodb.com 7y ago

MongoDB and Realm make it easy to work with data, together – MongoDB

metheus
43pts18
www.darkreading.com 7y ago

Rubrik Data Leak Is Another Cloud Misconfiguration

metheus
1pts0
www.mongodb.com 7y ago

Documents Are Everywhere

metheus
18pts1
digitizingpolaris.com 7y ago

It’s alive: MongoDB’s open source SSPL license application

metheus
10pts0
writing.kemitchell.com 7y ago

/dev/lawyer How to Speak Copyleft

metheus
1pts0
engineering.mongodb.com 7y ago

Causal guarantees are anything but casual

metheus
2pts0
www.mongodb.com 7y ago

MongoDB Now Released Under the Server Side Public License – MongoDB

metheus
15pts11
engineering.mongodb.com 8y ago

Considering the Community Effects of Introducing an Official MongoDB Go Driver

metheus
2pts0
www.bleepingcomputer.com 8y ago

R6BD Goes Down After Hacker Wipes Database and Holds It for Ransom

metheus
2pts0
news.brown.edu 8y ago

Opioid makers made payments to one in 12 U.S. doctors

metheus
270pts98
money.cnn.com 9y ago

Sexual harassment in tech: Women tell their stories

metheus
2pts0
arstechnica.com 9y ago

Security guard robot ends it all by throwing itself into a watery grave

metheus
3pts0
www.vox.com 9y ago

The weird power of the placebo effect, explained – Vox

metheus
3pts0
news.ycombinator.com 9y ago

The evolution of a no-lock, no-wait write consolidation algorithm in WiredTiger

metheus
2pts0
arstechnica.com 9y ago

Clips is the Apple-made video sharing app that’s not a social media network

metheus
1pts0
arstechnica.com 9y ago

US spies still haven't told Congress the number of Americans caught in dragnet

metheus
103pts22
money.cnn.com 9y ago

An 81-year-old woman just created her own iPhone app

metheus
2pts0
www.bodylabs.com 9y ago

Mosh: Using AI to Predict 3D Human Pose and Shape from a Single Image – Body Labs

metheus
1pts0
arstechnica.com 9y ago

Divided federal appeals court rules you have the right to film the police

metheus
1pts0
engineering.mongodb.com 9y ago

MongoDB’s JavaScript Fuzzer: Harnessing the Havoc

metheus
1pts0
www.deepstuff.org 9y ago

Recording analog memories in human cells

metheus
13pts0
www.washingtonpost.com 9y ago

NPR is killing off comments. That’s great news

metheus
1pts0
engineering.mongodb.com 10y ago

Succeeding with ClangFormat, Part 1: Pitfalls and Planning

metheus
1pts0
engineering.mongodb.com 10y ago

Digging into D3 Internals to Eliminate Jank Over Large Data Sets

metheus
1pts0
engineering.mongodb.com 10y ago

Code-generating away the boilerplate in our migration back to SpiderMonkey

metheus
4pts0

Hi, I work at MongoDB, and I'm here to elaborate in answer to your comment.

I was at the presentation last Thursday, they (OnGres) have fully open sourced both their methodology and their results and had a pretty strict divide between teams designing the benchmarks and teams running the benchmarks.

MongoDB could create a Pull Request/Merge Request against that repository so we can all judge those results ourselves

The existing, unaltered content of the OnGres repo is all the testimony one needs to know that the OnGres team is incapable of or unwilling to produce a valid test of MongoDB. Open source garbage is still garbage.

I understand the allure of asking for a pull request from our testing team to demonstrate how we obtained the measurements we cited in our retort. It is tempting to see this as a case of well-intentioned scientists, doing their best, honestly asking for peer review. But that view relies on two things that we can not take for granted: 1) that the OnGres team is acting in good faith and will work to correct their errors, fairly declaring MongoDB more performant if they concur with our results; and 2) that such an open back-and-forth will be illuminating to bystanders.

1) We cannot assume that OnGres is acting in good faith when their report so clearly demonstrates that they biased the test against MongoDB. This conversation should start and end with the fact that OnGres used an experimental MongoDB driver to compare against PostgreSQL with a production driver and a dedicated connection pooler in front of it. (What kind of pull request could MongoDB submit to address the use of sysbench, which requires a Lua driver?) They are simply not credible.

2) What would a MongoDB-submitted patch prove? It would certainly print out different numbers, but that alone proves nothing. For those numbers to mean anything, you have to read and understand the code. Anyone capable of understanding why our patch is valid is equally capable of seeing the deep flaws in the code as published, no patch required.

Consider this: if a research group funded by the fossil fuel industry published a report, littered with false statements and methodological errors, claiming that climate change isn't happening, NASA and NOAA aren't obligated to issue full a correction of that report along with their response calling shenanigans.

No, we're not going to get mired in a patch war with demonstrably biased authors over a fundamentally flawed comparison methodology. We have published our own benchmarks demonstrating how to test MongoDB performance, and in a few months, one of our engineers will present her work adapting the industry-standard TPC-C at the VLDB conference.

their current response is only words and a single table showing unlikely results.

There is nothing unlikely about our obtaining speedups to queries by using indexes that OnGres ignored.

However I do think the criticism of not tuning MongoDB is valid, however their response is dishonest:

> with their own heavily tuned PostgreSQL.

This was explicitly not the case according to OnGres other than the established norms of taking 25% memory for `shared_buffers` etc. No other tuning that is normally done for big clusters was done.

I'm very comfortable using the phrase "heavily tuned" when OnGres used "established norms" for PostgreSQL and ignored the existence of those (clearly documented) norms for MongoDB, while falsely claiming in their report that MongoDB does not require tuning.

I agree, it does sound like a step in the right direction.

Here’s how I look at the issue you have with trust in companies and regulatory bodies: I cannot imagine a world (inhabited by humans) without bureaucratic inefficiency and corruption inherent to the systems that organize large societies. It's like a law of social thermodynamics. We should continually strive to fight against the chaos and bad behavior, but at some level we have to understand that as long as humans are humans, /those/ efforts (e.g. anti-corruption legislation) will be marred by bureaucracy and corruption (e.g. lobbyists influencing anti-corruption legislation), like a recursive glitch in the matrix. If you can recognize the challenges that introduces, but be at peace with it, you can stay focused on what "steps in the right direction" we can make.

I appreciate your comment about how the market works, thanks for that.

You certainly have a point about our not working with the OSI prior to issuing the SSPL. All other things being equal, we would like to have, but as a publicly traded company it's just not responsible to announce "we will be changing our license... to... something... we'll get back to you on what that'll be... sometime."

We weren't happy about it, but we're doing the best we can given the constraints. We're all grownups, and accept that one of the consequences is that some in the OSS community feel betrayed by that change, but we ask that you let our actions going forward, not the worst suspicions of those most predisposed to judge us harshly, determine what you think of our dedication to OSS and our community.

As for non-employee contributors to the MongoDB codebase (who account for about 3% of the codebase), I think we should credit them with the same adult responsibility for their actions as we hold MongoDB to. Their contributions were made in full knowledge of the attribution requirement, and we have no reason to believe -- and no evidence -- that they resent anything MongoDB as a company has done.

Dunno if this thread is too cold for you to notice my reply, but there absolutely is... MongoDB Mobile was released last year, and along with Stitch, MognoDB’s serverless application platform, you can get exactly what you want — mobile sync.

I also work for MongoDB.

I respect your opinion about whether the SSPL is free or open, but it is not one that is uniformly shared by the OSI, as evidenced by the discussion currently underway in the license-approval mailing list. Many have argued in its favor. On that basis, some of your assertions in paragraph one are subjective.

Not that there’s anything wrong with subjectivity! I think it is valid to ask the question of whether the move was motivated by greed... it’s even understandable why people would default to that conclusion. (I wish that weren’t the case, but I’m not naive.)

Since you’re asking, I will give you my answer: the SSPL was created to make it viable for open source projects that are largely or completely funded by a single entity to remain funded in an era of large cloud vendors. While it is about revenue, it is not about greed.

The proof of the pudding is in the tasting, and I won’t ask you to just buy my claim. Just keep your eyes open for a conspicuous absence of MongoDB strong-arming community MongoDB users into buying commercial licenses.

As far as including MongoDB in Debian et al, goes, we absolutely respect process and principles. We’re waiting to see what the feedback from the OSI is.

Much of what you say about the lack of clarity is fair, but we hope that those things will be resolved when the SSPL gains OSI certification. In the meanwhile, we will do our best to 1) listen closely to the specific arguments as to what is unclear, and 2) attempt to dispel what we see as misunderstandings, often prompted by what is essentially FUD.

I appreciate your suggestions on what other licensing options we have. I think you really get what we are trying to do. That strategy is exactly how MongoDB has sold its enterprise edition for years. With apologies if I'm pointing you to something you've already read, we think the current landscape of the tech industry makes that insufficient, as our CTO's announcement post goes into: https://www.mongodb.com/blog/post/mongodb-now-released-under...

Anyhow, I do want to address this:

It creates all sorts of headaches. And conveniently your company's way to solve that is a commercial license.

I think this is unfair. Everything we have said about the SSPL makes clear that it has one very exclusive set of targets in mind: large scale cloud providers with the means to strip-mine not just MongoDB, but any open source project with significant traction. And the one actual data point in this conversation supports that position: fatbird posted that they were on a sales call with MongoDB recently, specifically asked if they were affected by the license change, and were told "no". Is that a legally binding rider to the SSPL? Of course, not, but if the plan for the SSPL was to use it to wring money out of community users, wouldn't the answer have been "yes"?

If you've already read that announcement post, or if you now do, would you let me know if it makes anything clearer?

Sorry, let me clarify. It's always possible to claim anything. I meant that the claim is too weak for the SSPL to create that threat.

It's obvious that several people disagree, but within this thread, conversing about this article, we should expect a bias to see things that way. I hope you'll stay open to being convinced otherwise. The SSPL has been submitted for review to the OSI, and this issue is one of the points of discussion that we're listening very closely to.

Absolutely I understand. And you taking the time to articulate the issues is generous, and I appreciate that as well.

I make no claim that the SSPL is as easy to understand as the GPL. It's not. IMO the GPL's domain is such that it's easier for it to capture its intention succinctly. Do you link your software to this library? No? You're in the clear. You do? Then your software has to be released under the GPL.

The SSPL wants one thing: for people who make software available as a service to release their service stack under the SSPL. The problem is that defining "as a service" too narrowly makes it easy to circumvent. Imagine you used a really narrow definition, something along the lines of "running and managing an unmodified version of the software on behalf of someone.” It would be easy to add a single junk feature and get out of that obligation.

Every ambiguity you cite in the license is precisely crafted to thread that needle. Lawyers can certainly debate whether it was done so effectively, but the way I see it, we are looking at competing design goals: 1) embody the above licensing requirements, and 2) be easily comprehensible to laypeople. In a perfect world, these goals would not be in competition, but as we designed the SSPL, it was clear that they are.

The language you cite in your concern here is a good example of that:

> or offering a service that accomplishes for users the primary purpose of the Software or modified version.

Does not explicitly mention MongoDB, except by contrast implying that if we offer a service - even one not MongoDB-based - that accomplishes the primary purpose of MongoDB or a fork of it, then we're subject to the new terms.

At first glance, that last phrase "or offering a service that accomplishes for users the primary purpose of the Program or modified version" is an astounding overreach; it seemingly attempts to obligate you to release completely unrelated software under the SSPL just because it provides the licensed software's behavior. But the mere fact of a license's existence cannot obligate you to its terms; you have to use the licensed software. So it follows that the clause only affects you if your "unrelated" software is used to provide the same functionality as the licensed software that you are using in the service. I.e. you wrap the software in a clean-room implementation of a connecting driver and then build an external proxy that offers an identical API to the wrapped software but uses none of its code.

I hope that example at least makes clear that the language used in the SSPL doesn't introduce ambiguity for its own sake, or as a means to drive users to commercial licenses, it is a byproduct of the need to counter real-world means of circumventing its requirements.

> offering a service the value of which entirely or primarily derives from the value of the Program or modified version,

Explicitly calls out interacting with MongoDB. My company's website is basically a wrapper around accepting a query from a user, converting that into the appropriate NoSQL query, reformatting the result, and presenting it to the users. Since our web server is more or less an abstraction layer from the underlying database, it sounds like our whole website would be subject to the new terms.

Looking at the example of your company's website, I would say with complete certainty that it is not affected. You are not making that database's functionality available to anyone, and no matter how thin the functional layers are that you put on top of it, the value you provide doesn't derive primarily from the value the database provides.

Now, without implying that the SSPL is so perfectly crafted that it needs no refinement, I'd like to present this thought experiment:

If the area that the SSPL seeks to cover inherently means that its language has to be less straightforward, but if also it is shown to be legally sound and confined to the territory we claim it to be, then is it a worthy endeavor to pursue? If so, what constitutes "shown to be legally sound" etc.?

I think we're all on the same page about the shoddiness of being in the open source insurance business, but that is not what the SSPL is for, nor could it be used for that. We simply can't make the claim that any SaaS other than specifically MongoDB as a service derives primarily from MongoDB -- or rather, it it's possible to make the claim, but it's easier to defeat it.

No apologies required! If we see this question come up a lot we can add it to the FAQ.

MongoDB does not release the stack for Atlas, our SaaS. That's possible because we own the copyright to the source code -- we don't have to issue the software to ourselves.

The blog post we published announcing the change covers this, as well as our motivations and expectations in a lot of detail:

https://www.mongodb.com/blog/post/mongodb-now-released-under...

Disclosure: I work for MongoDB.

You're in the right ballpark, for sure, but the SSPL addresses the difference explicitly. I'll use your example of Tumblr to clarify.

Tumblr is built on some component technologies, like a database, an app framework, operating systems, backup systems, load balancing, etc. But Tumblr itself is not any of those things. Nor does it make any of its component technologies available to the public as a service. You cannot pay Tumblr to backup your servers, or to rent you VMs running an OS, or to do load balancing for your infrastructure. Even if every single one of those components were licensed under the SSPL, Tumblr would not have to release a single line of their code under the SSPL, because they provide something else -- a publishing platform.

Disclosure: I work for MongoDB.

Forcing droves of community users to buy commercial licenses is not the intention of the SSPL -- indeed, it cannot serve that function, as it does not obligate them to do anything at all unless they are making the licensed software itself available to the public as a service.

Disclosure: I work for MongoDB. If you look at these two threads you'll find my comments in them, addressing similar concerns to those raised in this one.

https://news.ycombinator.com/item?id=18229452 https://news.ycombinator.com/item?id=18229013

To reiterate those comments, the SSPL only affects people who are offering the licensed software to the public as a service. This does not include any software that uses MongoDB as a component, even if it's a commercial SaaS offering itself. The FAQ we put out here makes that clear: https://www.mongodb.com/licensing/server-side-public-license.... 99.999% of MongoDB users are not affected by this license change.

People have expressed concerns that the 1) the FAQ is not the license, and 2) the language of the license does not make the intended responsibility clear enough. But it was drafted with that intention (and reviewed by outside counsel, with an eye towards being explicit without giving bad actors loopholes to exploit). Nonetheless, addressing those concerns is extremely important to us. This exact issue is being discussed on the OSI license approval mailing list, and we are considering very seriously all of the feedback.

The article anchoring this thread contains a lengthy discussion of copyright misuse and of impracticability. Those are also the subjects of discussion on the OSI mailing list, where Heather Meeker, writing on MongoDB's behalf, refutes claims that are similar to those made in the article. In particular, the SSPL is not trying to make people release substrate infrastructure, or adjacent tooling, under the SSPL. Consider the last line of section 13: "...all such that a user could run an instance of the service using the Service Source Code you make available." This means that as long as the Service Source Code you release is enough for anyone to run the service, you've fulfilled your obligation. As an example, you would not have to somehow be able to offer CircleCI under the SSPL (an impossibility), as long as your tooling that orchestrates its use is public, because anyone can use CircleCI.

It's our hope that these discussions will lead to an accepted understanding of the actual obligations of the SSPL. The only people we want to be in any way affected by it are those who are literally offering the licensed software as a service, and we want those people to release their management stack under the SSPL. Thanks for helping us with that.

That's not correct, the license only says if you make SSPL licensed software itself available as a service, you have to release the service code under the SSPL. Using the licensed software to build anything else at all is ok to do without releasing your code.

The SSPL neatly sidesteps that workaround. It does not specify anything about the provenance of code, or the extent to which code is shared with the licensed software's code.

If you offer a service based on the licensed software, and the value of the service being publicly provided entirely or primarily derives from the licensed software, every bit of code -- the clean-room driver, the compatible interface, the admin scripts, UI for management, etc. -- used to offer that service must be made available under the SSPL.

if you take the licensed software, and link it (via rpc / network) to your other software, you must share not only any changes you've made to the licensed part, but the whole thing that uses it.

Slight modification makes this accurate to the SSPL: if you take the licensed software, and link it (via rpc / network) to your other software which you use to offer the SSPL licensed software as a service, you must share...

Another tricky question is where the border line is.

Ultimately the trigger of the SSPL is whether what you offer publicly is the SSPL-licensed software as a service. It doesn't trigger the SSPL if you make MongoDB available as a service to your application internals as long as what you're making available publicly is not "a service the value of which entirely or primarily derives from the value of the Program or modified version..."

"Software as a service" is a well understood concept, and on the strength of that understanding, the SSPL is clear. (Although as with all things there are edge cases, there aren't more edge cases with the SSPL than with other licenses.)

If your web app uses MongoDB (or any SSPL licensed software) to provide a value that is not substantially MongoDB itself, you are not making the software available as a service. If your code facilitates making MongoDB's features available to other users, you are providing MongoDB as a service and are obligated to make all that code available under the SSPL.

To add to nemo44x's response...

but ultimately, I'm not confident one can write a license that focus-targets SaaS vendors without potentially exposing just plain mongo users to the same litigation.

I completely understand your trepidation, but I hope I can set your mind at ease about that. From our FAQ (https://www.mongodb.com/licensing/server-side-public-license...):

What are the implications of this new license on applications built using MongoDB and made available as a service (SaaS)?

The copyleft condition of Section 13 of the SSPL applies only when you are offering the functionality of MongoDB, or modified versions of MongoDB, to third parties as a service. There is no copyleft condition for other SaaS applications that use MongoDB as a database.

Disclosure: I work for MongoDB.

I suspect some people are responding to what they've heard, so I just want to post section 13 of the SSPL here for everyone's convenience. This section is the only part of the SSPL that isn't exactly the GPL:

13. Offering the Program as a Service.

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. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Software or modified version.

“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.

Regardless of how you feel about the purpose of the SSPL, it absolutely does not apply any restrictions to using the licensed software. What it does is codify the responsibilities of someone who runs the software as a service.