San Francisco's mayor declared state of emergency as the coronavirus spread - <AUTHOR> https://www.businessinsider.com/san-francisco-state-of-emergency-coronavirus-covid19-outbreak-2020-2?r=US&IR=T <comment><USER2> Discussed earlier...

[https://news.ycombinator.com/item?id=22419424](https://news.ycombinator.com/item?id=22419424)

</comment><comment><USER3> To put the headline in context, this is a necessary move to unlock funding for preparation and potential mitigation.

<comment><USER4> I think it's a wise move because of both outcomes:

1\. There is no pandemic - it's a valuable, real-world logistics and pain- points training exercise.

2\. There is a moderate pandemic - they had extra time and resources to prepare.

I just doubt any governmental body besides perhaps even the US military could build 8000+ of bed capacity, positive air pressure triage and care facilities in 8 days as happened in China. That was an organizational, logistics and execution achievement. Different agencies globally should be sharing information and best-practices across countries, not going all puffery nationalistic. Solidarity or divided-we-fall.

<comment><USER5> > _I think it 's a wise move because of both outcomes: 1\. There is no > pandemic ... 2\. There is a moderate pandemic_

Given the information that we currently do and don't have, there's clearly more possibilities than just those two. (I am not making any claim about how likely any particular possibility is)

</comment></comment></comment><comment><USER6> This is a preemptive declaration of emergency. As of today, there are no confirmed cases of coroavirus in SF.

<comment><USER7> At least two people infected with coronavirus were treated in SF (UCSF).

<comment><USER4> To be clear, it was a couple who were vacationing in Wuhan, picked it up there, then quarantined at their home, but both got worse and they had to be hospitalized.

[https://www.sfgate.com/bayarea/article/coronavirus-San- Franc...](https://www.sfgate.com/bayarea/article/coronavirus-San-Francisco- UCSF-UC-San-Benito-15028812.php)</comment></comment></comment>


Ask HN: Doing calisthenic or going to gym? - <AUTHOR> Goals: gains weight <comment><USER2> if you want to gain weight avoid cardio, but you need to change your diet if you want to gain weight</comment>


Why Subversion is better than Git - <AUTHOR> http://subversion.wandisco.com/component/content/article/1/40.html

<comment><USER2> He seems to be saying that svn is better than git because _some_ git users have a central repository they work against, and because they are planning on adding some features that might to some extent allow them to mimic a few things git already can do. That's just about the weakest argument for svn over git I've ever heard.

Then the went on to use the word "enterprise" about 10 times in 30 seconds. Not convincing.

<comment><USER3> The whole centralized vs distributed debate does not make much sense anyway, the choice of words is very poor. You almost always want to work on a common repository when working with other people - but the whole point of DVCS is that this common repository can be different for different usages (release vs development vs documentation vs testing ...). Something like subversion makes it very difficult to have several full fledge, synchronized repositories. Once you have a way to easily replicate live repo on the fly, you have already almost everything needed for a DVCS.

Also, something which is often overlooked: subversion was very poor even before DVCS came to light. It was only good at making sure everybody could work on the same snapshot. Branch management was inexistent not so long ago, no usable merge capabilities, awful interface to compare branches, etc... Just using git as a client to svn repository through git-svn already brings many advantages. Git-svn has saved me countless hours already compared to straight svn when working on public projects, especially for release management. svn log, blame, diff are slow to the point of being useless once you need to compare past revisions.

</comment></comment><comment><USER4> Subversion is better than Git because many people use Git in a centralized manner? Wouldn't that make Git better, since it offers more options?

</comment><comment><USER5> They've ignored Git's superior branching scheme though. Once you use Git for a while and get a hang of branches, you won't want to go back to the Subversion way of doing it.

<comment><USER6> FWIW, I'm of the school of thought that branching is bad, causes mess, and should be hard.

Having said that, branching seems pretty simple in svn if you really like having them.

<comment><USER7> The problem is that svn makes branching easy, but merging very hard. This provides an incentive to postpone merges which of course makes them even harder once the excuses run out and they have to be done. Distributed SCMs recognize that branching is necessary, but actually provide the tools to make merging easy. Once merging is easy, branching doesn't look bad any more.

<comment><USER6> It still looks bad to me. I want 1 codebase, developed linearly.

Definitely I can see the appeal of branches for software you ship, where you need to bug fix an old version and release a patched ver etc, but I can't really see the need for web based software, which I think is pretty usually developed linearly without much mess.

I much prefer doing branches in the source code (If that makes sense).

For example say you have a widget and you want to try a different strategy, create a newWidget in the source, make it so you can swap it in and out of the runtime maybe for testing. Keep developing it, until you're sure it's cool. When cool, replace widget with newWidget. If it doesn't work out, just delete it.

<comment><USER8> "I want 1 codebase, developed linearly."

Then, when you want to commit your branch, rebase the branch from your master before merging. Then, when you merge, the patches will show up all in a row at the point you commit, as if they were all done in a row. Essentially, this is exactly what happens when you are working with subversion for a couple of days and then do several commits at the end.

Except you can trivially have multiple of these things going at a time.

I'm going to ask you a question: Have you actually tried git or anything for a significant period of time, like, at least a couple weeks? (Not just "yeah, 5 minutes.") If not, I'd point out that you're speculating about how git _might_ affect workflow to people who actually _know_ how git affects workflow, since they are living it. (And if so, you're not doing a great job of showing that you tried it.)

<comment><USER6> Yes I tried it for a day (Not long I agree). It looked like a reasonably copy of svn, but it didn't offer me anything.

Let me restate: I do not like branches and use them _very_ rarely.

So, to the guy who hates branches, what does git offer me over svn (Which does all I need at the moment)?

<comment><USER9> "So, to the guy who hates branches, what does git offer me over svn (Which does all I need at the moment)?"

The ability to version control your project (even without branching you can checkin) when disconnected (from your network).

<comment><USER6> Yes, I do this with svn easily enough (Local install of svn). Simple enough...

Maybe that's a good selling point for people who aren't connected to the net much though,

<comment><USER9> "Yes, I do this with svn easily enough (Local install of svn). Simple enough..."

Yeah Right :-P Obviously I meant if you were working on a project with its repository on a remote server. Assuming you want local version control (as you seemt o do, since you are locally installing svn) you'd maintain a separate local repository, maintain the same project under both, and synch them both when you get back online?

And if you had two laptops say (apart from the remote server) , you'd maintain 3 repositories?

<comment><USER6> It's not really a use case I have. If I'm working, I have internet connectivity :/

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> Came across as excuses as why the subversion design was so inflexible and how it's going to change.

Painting a picture that distributed version control systems learnt from subversion is rubbish. These technologies were developed over the same period: bitkeeper's development started some time in 1997.

</comment><comment><USER11> Somehow I get the feeling that he's getting bored with Subversion even himself and ready to move on to Git ;-)

</comment><comment><USER12> _He also talks about the upcoming changes in Subversion, such as Working Copy Next Generation (WC-NG), which he believes will cause a number of Git users to convert back to Subversion._

If I've already left for git (or other dvcs) why would I come back just for "working copy"? I moved on from Subversion for much more than that...

</comment><comment><USER13> I always hated the way svn left its .svn cruft all over the place. Glad to see they're trying to get away from it with version 1.7 but it's the same kind of glad as seeing someone try to make an iPod killer.

</comment><comment><USER14> I'll give them this: they certainly have their work cut out for them. If they can make me want to go back to SVN, they'll have performed a miracle.

</comment><comment><USER15> "Most people were using CVS or other proprietary version control systems"?

<comment><USER16> Perhaps that should read, "Most people were using CVS or other, proprietary, version control systems"?

</comment></comment><comment><USER17> Wow, that's 4 minutes of my life I won't get back, and I'm a subversion (and git) user ;-(

</comment><comment><USER18> I literally thought this video was a joke for the first couple minutes. But then it wasn't very funny, and I realized "holy crap, this guy is serious." I don't know what else to say.

</comment><comment><USER19> Improving subversion borrowing some "distributed feature" from git&co? I'm not sure of how many would care... The thing that make svn a "toy" scm is the branching model/facilities(e.g. merge) and this is the area that seriously needs to be improved. Do you want to bring svn "to the enterprise"? Start offering what other enterprise scms offer, take clearcase for example, it has its issues but the branch/merge facilities are great.

</comment><comment><USER20> Not for nothing, but Wandisco sells $1000/seat software that makes Subversion distributed (i.e. more like Git).

I checked it out about three years ago (before Git was on my radar) when the company I worked for brought on some offshore developers, and they were on a slow and unstable internet connection.

</comment><comment><USER21> Is there a transcript of this anywhere?

</comment><comment><USER22> Haha this dude is so awesome :)

We are better cause... we are just better! Everybody knows that! And we gonna have these useless features from git soon too!

</comment><comment><USER23> This is marketing trash. Life is too short, don't watch.

</comment><comment><USER24> I don't think there is anything they can do to get me to switch back. Out of every VCS I've tried, Git seems to be the most flexible and advanced.</comment>


Jaxtr introduces JaxtrSMS to send free text messages around the world - <AUTHOR> http://truvoipbuzz.com/2011/11/jaxtrsms-send-unlimited-free-text-messages-review/

<comment><USER2> Works for me...thanks!!</comment>


MongoDB's Server Side Public License Is Likely Unenforceable - <AUTHOR> https://www.processmechanics.com/2018/10/18/the-server-side-public-license-is-flawed/ <comment><USER3> Yeah, I'm not necessarily opposed to the general spirit of what they're trying to do here, but this license just doesn't make sense in practice. Now that I've had more time to look at it, I'd really recommend that everybody stay the f%!# away from MongoDB.

This bit in particular really hits the nail on the head:

 _Let 's assume that it is ok somehow to pass forward other open source software, solving that problem. What about my continuous integration software (e.g. CircleCI), or my business backup software (e.g. Jungle Disk) or my code hosting service (e.g. Github)? There is no logical bound to this license. Taken on its face, I would theoretically be bound to release the internal source code of services from third parties that I included in or relied upon to deliver my service._

Copyleft is one thing, but this is so invasive and byzantine that it beggars belief that anybody actually thought this license made sense.

<comment><USER4> There are many arguments provided as justification for this new license - <USER2> seem specious in my opinion

1\. Big cloud vendors are making money off MongoDB's investment Completely untrue. The big three - AWS, Azure and GCP dont have a MongoDB as a service solution. The only commercial entity making any real money off MongoDB is MongoDB, Inc. AGPL has achieved its purpose here. The only big cloud vendor with a solution is Rackspace and they release their modified MongoDB code.

2\. Big cloud Vendors in China are breaking the law and they need this new license to control them If they are technically modifying the source code and not providing it back to the community then they are already breaking the law. You don't need a new license to control this problem

So what is this about? In my opinion it is an exercise in naked extortion and control

1\. Clear out any ISV Vendors/As-a-service Competitors - Any commerical entity who does anything remotely interesting with MongoDB is in big trouble. I'm talking about Monitoring, backup, performance profiling, analytics, reporting etc..anything really. MongoDB could easily bring a reasonable claim against them that the value of their service is "primarily or mostly derived from MongoDB". Also its very unclear on what needs to be open sourced to be compatible. The license seems deliberately vaguely worded so that it is as broad as possible.

2\. End users using MongoDB - While MongoDB claims this does not affect end users in any way I would be very wary of this claim. The license in authored in such a generic way that there are many possible interpretations. If MongoDB, Inc for some reason does a claim against you then your only defence is to buy a license or go into litigation. "Trust us, we will never do that" is not a good enough argument.

To summarize, be very wary of this. If you are a developer and dont think this affects you run this by your legal deparment or VC and see the alarm on their faces :)

<comment><USER5> Also, print out and have notarized a copy of their current FAQ. It's probably legally binding for promissory estoppel. If their interpretation of the license suddenly becomes much stricter, it may be handy to prove that they promised you explicitly in writing that they intended the looser meaning.

</comment></comment></comment><comment><USER6> Only a data point here -- after I read about this license change on HN, it took me about 2 hours to struggle over the issue, discuss with my team, and switch from MongoDB to PostgreSql. We are very lucky in that we were into this project for only two months, prototyping and learning the ropes with MongoDB schema. With PostgreSql now, everyone feels secure in a familiar territory. Yes, we have to make changes and its not rocket science to move over.

The issue is not about having to buy a license here. The problem is the uncertainty with a product whose license agreement is being switched over mid- stream. It makes me weary of what else might happen with their license structure further down the road.

<comment><USER7> weary (tired) -> wary (concerned)

not nit-picking, just attempting to help other readers who aren't native English speakers

<comment><USER8> For those that don't know, they are sometimes pronounced the exact same, which is why they are often mixed up (see also affect and effect). Where I'm from weary is pronounced WEER-y though.

<comment><USER9> I hear "weary" spoken so very rarely that I have no idea how it's pronounced here (Indiana). I can't even make up my mind how I pronounce it, but I'd wager it's almost, but not quite, indistinguishable from wary.

<comment><USER10> One is w-ee-ry the other w-ah-ry.

<comment><USER11> > w-ah-ry

I've always heard it pronounced way-ree.

<comment><USER12> Ware-ee?

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> Absolutely. This license change takes it completely out of the contention for anything I would have previously considered it for. Can you imagine if Nginx said you had to release any software you run behind it as FOSS?

<comment><USER13> And then what? The owner of the code is entitled to license the software as they want it [1]. If you dislike the license, then use a different program or fork the last version before the license change.

I can fully understand the frustration of pro-copyleft developers and companies that want to use copyleft for a 'share or pay model'. Cloud computing makes existing licenses toothless by moving the software from the client to the server, thereby avoiding distribution. It can be argued that such use is not in the spirit of copyleft and is effectively a loophole from the perspective of copyleft licensing.

It is not surprising that people try to make new copyleft licenses that fill that loophole. This may not be the best formulation, but it is definitely much better than the Commons Clause nonsense that was hyped a couple of weeks ago (which makes software proprietary).

[1] Whether it is enforceable is another issue.

<comment><USER5> Of course they're entitled, but I'm also entitled to say I think this move was either idiotic or malevolent.

I'm unsympathetic to the "oh no the cloud" mindset. I've worked at companies that have made on-premise patches to FOSS since the 90s. Can you imagine if Linux required you to make the source available of all software you ran on it? Or MySQL? Or Perl/PHP? I can vaguely see the point of the AGPL for things like web front end stuff where there's a blurry line between you visitor merely visiting your site and you distributing the software to them. But that's just madness for infrastructure code.

And I'll bet that the MongoDB team has used lots of FOSS that they didn't financially support, so I see it as whining when they complain about others doing the same.

<comment><USER14> You use their code for free and call them "idiotic or malevolent" when they make it harder for you to use their code for free. I can completely understand the frustration of their users if this move makes their life harder but it's still pretty entitled of you to insult them because they changed the license to something you don't like.

It's perfectly understandable if you decide not to use their software because you find their license unacceptable but don't insult them for doing what they want with their own project. If a sizeable enough number of contributors are unhappy with the move they're still free to fork and continue the previous version of Mongo DB with the old license.

<comment><USER5> There is a decent chance that they're using code I've written, and I haven't seen a penny from them. Have you? Has anyone?

I think it's either:

\- Idiotic, because they meant well but managed to shoot themselves in the foot by making their software unviable, or

\- Malevolent, because they're using this as a wedge to either force you into a pay-or-lose-it situation, while still trying to paint themselves as FOSS.

<comment><USER15> Because you don't feel others are freeloading on you does not mean software consumers aren't freeloading.

You're free to change your licenses (or not), just as other projects are (but should).

It's time the free ride and expectations of charity by for-profit users ends.

<comment><USER5> What _is_ freeloading? MongoDB is building a project off the works of others and selling it. So am I. If you're employed, so are you. And in return, hopefully we all contribute back to that ecosystem so that the next person can build off our new work.

You say "freeloading". I say "participating in a rich culture of shared work". Maybe I don't contribute all my local work to Emacs upstream, but I push out a lot of Python stuff. Maybe you don't bother sharing all the Python tweaks you've made, but you're an active Vim contributor. Perhaps there's someone else that's a Vim "freeloader" but who cranks out a lot of kernel code that you and I both benefit from. I think that's a healthy, mutually-beneficial arrangement.

<comment><USER15> Try paying your rent and grocery bill with "participating in a rich culture of shared work". It's just as much of a joke as "pay you? It'll give you exposure!" frequently expressed to creatives.

It's clearly not mutually beneficial when one side is reaping outsized rewards (and not at all ashamed about it), and your example of small contributions to vim and python is disingenuous; we're talking about entire software packages used without compensation by businesses (Redis, Elastic, Mongo to name a few).

<comment><USER5> Did Redis, Elastic, Mongo et al pay for Linux development, or glibc, or their text editors, or compilers, or ...? Why should they get the financial benefit from building on top of others' donated work - and claim to be an equal participant in the FOSS ecosystem - and then be peeved with others expect the same in return?

If Mongo were a closed, proprietary product who wanted to be paid, sure. I happily pay for Apple stuff, for instance. But saying "hey, come use our FOSS project!" and then pivoting to "...as long as you pay up!" is extremely disingenuous.

<comment><USER15> Situations change. What you get for free today, you are not guaranteed to get for free tomorrow, nor should you feel entitled to continue using a tool previously provided for free.

This is absolutely no different than commercial vendors who change pricing or licensing terms year to year (ie "we no longer offer an on prem version; SaaS only now; last year you paid $100k, this year our price is $200k"). You've just been anchored to an unusually low price previously.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> Remind me of that one time when they went berserk on every tooling vendor using the name « Mongo » in their product name :

RoboMongo,MongoGUI etc... they all received a legal notice to remove the name mongo from their product.

This was probably one of the most evil thing have seen in the open source industry .

Most of those vendors were open source with paid premium features or donation.

After receiving their legal notice most of those vendors deprecated or sold their project to a company feeling betrayed by Mongo.

As a result Mongo Compass became the de facto GUI for MongoDB and is advertise as sold with MongoDB Enterprise.

<comment><USER17> I have absolutely no problem with trademarks as long as they're used as consumer protection.

For example, there's the whole uBlock vs uBlock Origin thing, where uBlock Origin is the good one run by the original maintainer, and uBlock is run by people who had nothing to do with the original project.

[https://en.wikipedia.org/wiki/UBlock_Origin](https://en.wikipedia.org/wiki/UBlock_Origin)

Trademarks can be used offensively, and few cases were more offensive than the Linux trademark dispute back in the 1990s, when William R. Della Croce, Jr., someone with nothing to do with the Linux kernel or anything else of value, acquired the trademark to "Linux" in September 1995 and began to demand royalties from the people who did _useful_ things with their time. It took a court case to dislodge him.

[https://en.wikipedia.org/wiki/Linux_Mark_Institute](https://en.wikipedia.org/wiki/Linux_Mark_Institute)

[https://www.linuxjournal.com/article/2559](https://www.linuxjournal.com/article/2559)

What Mongo did was meaningfully better than what Della Croce did, and closer to the spirit of "prevent people from confusing products and thinking stuff is from the original development team when it isn't", but I can see how it would be an unpleasant shock in the Open Source world which, sadly, usually doesn't know or do a damned thing about trademarks until some asshole forces the issue.

<comment><USER18> It often seems like trademark lawyers must be fairly dim, as a lot of things confuse them that don't confuse anybody else.

<comment><USER19> That's a rather unnecessary ad hominem.

What you should consider in your rage against trademarks is that they protect something _far weaker_ than copyrights and patents. Trademarks are fundamentally exchangeable identifiers. They do not hold any value beyond what they are infused with due to their attachment to some company (person/organisation/...). Unlike patents, which cordon off the part of scientific reality from most, or copyright, which fundamentally relies on deadweight losses to make its mechanism work, trademarks are almost exclusively positive: there is nothing you gain from calling your product "Mongo-X" apart from the meaning the term carries based on the company creating the product.

(This slightly glosses over some practicalities, such as some terms having meaning before being adopted as a trademark, or the possible depletion of combinations of letters that can be pronounced. But those are just superficial practicalities, and they are acknowledged in various limits to trademarks).

</comment></comment></comment></comment><comment><USER20> For people defending this, you're being naive. It's way too easy to argue that the value of any app resides mostly in the data it collects. That data is stored in MongoDB, therefore the value of the app "primarily derives from the Program."

Of course their sales people are saying "No. We won't use it that way." Sales people gonna sell.

I'm sure the people currently running MongoDB would not do that. What happens when they get acquired by, say, Oracle? Or some other company that absolutely would do that?

The bottom line that you have to assume from a legal point of view is that any part of an agreement that can be abused, will be abused. This not only can be and will be, but it will be really easy.

If they are doing this to prevent people from competing with their own service --which they absolutely are--then they need to rewrite it and make that explicit. This is way too squishy for anyone with an ounce of brains to use in a commercial product.

</comment><comment><USER21> MongoDB of course has right to change their license to anything they want. One day they might decide to go proprietary with no notice too...

According to our poll many users will seek alternatives for MongoDB because of the license change

[https://www.percona.com/blog/2018/10/24/poll-mongodb- license...](https://www.percona.com/blog/2018/10/24/poll-mongodb-license- change/)

MongoDB probably feels they have reached critical mass so it does not matter any more...

<comment><USER16> >MongoDB probably feels they have reached critical mass so it does not matter any more...

They have become a new standard and they are aware of it.

Just look at any bootcamps for devs this days , it's basically always JS + MongoDB. Not Postgres or MySQL , Mongo.

Mongo has become the new MySQL for a lot of devs these days.

It's often the only DBMS they know...

These move is somewhat coherent with what others are doing in the industry ( Redis Enterprise Modules new licence , Docker preventing download without creating an account etc...)

Open Source is now Venture Backed , as a result it needs to make profit.

<comment><USER22> > Just look at any bootcamps for devs this days , it's basically always JS + > MongoDB. Not Postgres or MySQL , Mongo.

The online classes love Firebase. :-D

But yeah, I had to explain to a bootcamp dev a few weeks ago what Postgres was. I felt rather sad.

<comment><USER23> I am a bootcamp dev (still in it) and I can confirm that its all node + mongo. I know what postgres is but obviously dont know anything about it technically. I am struggling to understand what this license change means for someone like myself who is building a web app with mongo...

<comment> village-idiot Postgres is orders of magnitude safer, sometimes a bit slower, but requires a bit more forethought when it comes to planning a schema to match your models. You typically appreciate this more in maintenance and later development more than you appreciate it up front.

The general risk with any for profit open source company is either them pulling all the good features into the paid version, or suddenly changing your license so that closed source projects have to either stay on the old versions or pay for a commercial license.

</comment></comment></comment></comment></comment><comment><USER24> Okay so after reading the article, and thinking about this for a while, I get the following out of this debacle:

The issue here is that SaaS providers are building tools on top of MongoDB that effectively add functionality, instead of modifying MongoDB (which would force them to share those changes publicly).

This is a valid concern and I understand the motivation behind the license change. However, how is this different from any other FOSS?

Just as a random example, think of a proprietary blog/site provider like Tumblr and Weebly. They are effectively a SaaS provider that introduces tools on top of open-source web servers (like nginx or apache) to make hosting a website much easier. Instead of building the entire model/code of your website, you simply add customizations using a frontend.

Maybe the comparison is not ideal, but my understanding is that all FOSS suffers from this concern, and the industry seems to be doing well enough.

<comment><USER25> 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.

<comment><USER26> Technically, Tumblr provides persistence for ramblings and pictures and makes them available to the public. Tumblr is a brand wrapped around a database.

I could do the same thing with a worse UI by hosting MongoDB on an open port.

<comment><USER27> And taps are just zero-length swipes!

</comment></comment></comment></comment><comment><USER28> I can understand the sentiment and realize the need to monetize, it's hard when others take your code and make more money out of it then you (which I am assuming is the case).

But even if they are right, this doesn't seem smart, it feels like a knee jerk reaction. I imagine that they hope that by doing this they'll cause people who are using mongo on other providers to move to mongolabs, since there is 0 chance of these providers open sourcing their infra.

But that's not whats going to happen, either cloud providers will remain with old versions and people will gradually move to different dbs or they'll just fork it, they certainly have the manpower for it, this will give them incentive.

Frankly though I think this is well within the agpl, cloud providers aren't modifying the code they are building things around it.

<comment><USER29> > it's hard when others take your code and make more money out of it then you

Just my opinion, of course, but I think this is only true for sales and management types who are profit driven. For engineers and artists, it's not really an issue. We want to see our best work appreciated, primarily.

<comment><USER15> > For engineers and artists, it's not really an issue. We want to see our best > work appreciated, primarily.

I want to be paid first. Everything else comes second. That doesn't not make me an engineer. It makes me a wise engineer. Money buys options and freedom. Prestige and other abstract concepts are used to steal your time and value.

<comment><USER29> Right, but you aren't going to raise hell if someone makes more money on your work than you did. That's not the attitude of a craftsman, but business folks think in terms of lost potential revenue and junk like that and thus are not above such things.

<comment><USER30> It's okay if they make 'more' money, but whenever an entity makes giant piles of money I wish there was a small mandatory royalty to the original creators.

</comment></comment></comment></comment></comment><comment><USER31> As a non-lawyer who's tried to understand copyright law, this analysis confuses me; my understanding was that in the realm of source code "by default" you only have rights to use that source code through a license or contract, so it seems odd that any restriction on the terms would be misuse or detrimental to competition, when the option always exists to not use MongoDB.

This isn't me trying to argue against the article; I'm trying to understand the law as it applies to my profession.

<comment><USER32> This uncertainty and confusion is by design and the whole point of this license. It's designed to make people who are not lawyers consider getting a commercial license just to avoid the potential for legal headaches that may or not materialize.

I doubt it will work since many people will indeed not want to deal with companies that are dangling legal threats over their own users like this. IMHO there's no other way to interpret this than as exactly that: a user hostile move. Whether this thing is enforceable or not is beside the point.

<comment><USER25> 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.

<comment><USER32> The problem with that statement is that it is your company's lawyers interpretation of what it is all intended to mean. Yet, it's not certified by the OSS foundation and there are now loads of articles trying to interpret what it all means, which suggests to me that this is not a clear cut case of this being all that clear at all. Either way, your company is trying to actively restrict how the software is used even further than the AGPL already did.

I'd recommend sticking with well understood OSS licenses. There are plenty of those. This one is neither OSS (until the OSS foundation says otherwise) nor well understood. Both are problems. Especially when mixing with GPLed code. It creates all sorts of headaches. And conveniently your company's way to solve that is a commercial license. I'd still argue that that was the main point. I'd suggest celebrating any successful use of your software instead of trying to constrain it.

My suggestion would be to use Apache 2.0 and try to get companies to take a commercial license based on the merit of added value in terms of support, extra goodies, etc. This seems to work well for others in the industry (e.g. Elastic that recently IPOd); it's well understood; explicitly compatible with GPL; and has none of the disadvantage of rolling your own license.

<comment><USER25> 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...](https://www.mongodb.com/blog/post/mongodb-now-released-under-the- server-side-public-license)

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?

<comment><USER32> > I think this is unfair

I'm just parroting the sentiments here. This is how this move is perceived.

I think your CTO is wrong on this. This situation is not something that is going to improve with more blog posts, explations, or proclamations from your c level executives.

So, a wise move would be to roll this back ASAP and withdraw the SSPL.

This license is no a solution to Mongo's revenue problems and may actually make things worse. It sure doesn't solve any problems your users are having so whatever this is, it is not in their interest.

</comment></comment></comment></comment></comment></comment><comment><USER33> Huh. So, the rush to release and announce the license before OSI vetted it, was in fact VERY VERY intentional. Not some poorly planned "rush the news out" mismanagement.

And the recent stink on HN where OSI claimed MongoDB was not Open Source because the license had not yet been reviewed, with many claiming (correctly) that OSI is not the determiner of what is open source, appears to have been out of order.

I think there was a base assumption that the license would in fact be fine, and OSI claiming it wasn't because they hadn't stamped it ... yet ... was overreaching.

Anyway my understanding is that the single largest user (and commercial licensee) of MongoDB hates it and can't wait to get away from it. With that in mind, this licensing nonsense smells like a desperate grab. Maybe it's time to short $MDB?

<comment><USER34> Who's their single largest user?

</comment></comment><comment><USER35> I honestly don't see how this can pass OSI or DFSG approval. It's a blatant violation of rule 9, which prohibits restrictions on distribution of other software.

<comment><USER25> There is no restriction, only the requirement that the systems that make your service run be made available under the SSPL.

<comment><USER35> If your license places _any_ requirements on software that is not a derivative work of software you own the copyright to, the license is nonfree by the standards of the OFSI and the DFSG and probably others.

</comment></comment></comment><comment><USER36> Isn't it just so that the Mongo's SSPL is a natural extension of AGPL, modified to make it cover things that wouldn't otherwise be considered a derived work (which is exactly what FSFs interpretation of GPL does for more typical, 'single-host' situations), and inheriting the AGPL's problems?

<comment><USER37> I'm not sure what the question is, but the AGPL is very carefully drafted to avoid the problems Van is talking about.

<comment><USER36> Well, according to the article the second problem is directly inherited from AGPL.

<comment><USER38> Not quite. There are administrative problems with the AGPL, which are inherited here. But it is the scope of this license that pulls in these new defenses.

<comment><USER39> I'm sure they will address your concerns in SSPL v2. But make no mistake, you can't win here.

<comment><USER40> I will then create _Anticensor 's_ Public License, stating everything interacting with said work must be licensed under the same license.

</comment></comment></comment></comment></comment></comment><comment><USER41> Why does the article think MongoDB is located in the jurisdiction of the 9th Circuit? I mean sure they operate nationally in some senses, but their HQ is in NYC (2nd Circuit). And if they're incorporated in Delaware as most funded tech startups are, that isn't 9th Circuit either.

Am I missing something or is the author? Also, what stance has the 2nd Circuit taken on copyright misuse, if any?

</comment><comment><USER42> I'd be interested in seeing a license that better accomplishes the goals cited as motivation for moving to this license, that would hopefully also avoid the flaws mentioned in this article and throughout the comments.

Is there an example of such a license?

Could this type of license even be created in an enforceable way?

</comment><comment><USER43> MongoDB doesn't deserve all the credit (or blame) for what they've created. The client libraries are true open source projects, and a lot of the good parts of the design have probably come from them. I think they've also accepted a lot of contributions to mongod without compensation, and had the copyright assigned to them. Having the copyright assigned to them is reasonable, but it facilitates them closing an open source project that's received many community contributions, which is unethical IMHO.

<comment><USER44> They use plenty of other open source components as well. As I pointed out in other parts of the discussion they use PostGres beneath the scenarios for their reporting solution and charge customers for it. What do they contribute back to the PostGres community?

</comment></comment><comment><USER45> Just thinking. Can you make a fork of MongoDb before license change and keep merging upstream changes under former license? Not asking because I want to hurt Mongo, just curious.

<comment><USER46> Yes, you can fork, but no, you can't merge new changes, those come with a different license (except maybe for third-party contributions, you could ask them to double license them under the old one too).

</comment></comment><comment><USER47> Why isn't a straightforward solution to the "impracticability" problem just a "to the extent possible" or "authorized"-type predicate?

<comment><USER38> This would significantly ameliorate the problem.

<comment><USER47> So then, really, a big part of the critique here is that the SSPL is simply not written very well?

<comment><USER37> i mean to be fair that's the big problem with most licenses as "not written very well" covers almost all problems with contracts :)

Like the LGPL is confusing because it is not written well in some sense. But that goes to "confusing" instead of "unenforceable".

But yes, better written the problem with this license would just be "They are _trying_ to claim things they know they can't claim" instead of "they are _actually_ claiming things they know they can't claim".

The next question that would pop into my head would then be "At what point does attempting to claim rights to things you know you can't, as a way of scaring people into paying you, cross into unfair and deceptive trade practices"

<comment><USER47> Sorry, I just meant: "a more conscientious lawyer could have straightforwardly drafted that contract to avoid some of its major problems". Like, the subtext of the question is, if I was MongoDB, and stipulating that I didn't create unreasonable work conditions like "get it done in a day", should I be pissed at my lawyer?

Additional question: if you can fix that problem with the contract with a "to the extent possible" predicate, is that really not the default? Like, if a clause can be interpreted as requiring the impossible, even if a straightforward alternate interpretation doesn't, that clause is broken?

<comment><USER37> Yes, they could have. So yes, you should be pissed at your lawyer if they didn't warn you.

In my experience, the lawyers mostly warned the clients and the clients did it anyway.

Part of being a lawyer is simultaneously taking the blame for stuff like that while having done very careful diligence so that your malpractice insurance rates don't go up from clients successfully suing you :)

</comment></comment></comment></comment></comment></comment><comment><USER48> Sincere question: who is actually using MongoDB these days?

<comment><USER49> At GitLab we still use it for Gitter. It wasn't a priority to convert it to PostgreSQL. After the WiredTiger updates I think Mongo got a lot more reliable. But I would start any new project with PostgreSQL.

</comment></comment><comment><USER50> Interesting that none of the clouds even offer hosted mongodb in the first place, and from everything I know there were 0 plans for any of them to start. They all have their own proprietary databases to promote instead. Meanwhile MongoDB Atlas seems to be doing well so the entire impetus for this license change seems rather unwarranted.

</comment><comment><USER19> I think both this discussion, as well as last year's Facebook/React Patent License brouwhaha (and Redis, more recently) would all be far better if people assumed good faith, and tried to actually get at the core of the problem.

It's clear that there's a gap in existing licences that some regard as unfair. It also seems plausible that many projects could have dramatically better resources if the companies they are attached to could find a way to capture a fraction of their product's worth to their largest users. Just offering service with their competitive advantage being only the result of name recognition seems to work only for a very select group of huge projects. And even there, the likes of Canonical or SUSE show how hard it is.

Yet it is obviously challenging to write a license that adequately captures these facts. I think everyone would have something to gain from finding a way to make these situations work.

A required part of that solution may be for the community to interpret licenses not with the current they-are-trying-to-screw-us mindset but with, say, the "reasonable person" standard often used by the courts in contract/license disputes.

That's not going to be easy, considering "expect the worst and don't risk anything" always looks like sound advice, given that you will never know what you missed on the path not taken.

But the GPL's success should be inspiring here: it was initially met with scepticism, especially among corporate lawyers. Their essential pessimism never changed (it's how they became corporate lawyers in the firs place). But as it happened, it was enough for just few to take the risk, and subsequently creating precedents in court affirming the GPL, that made the concept cross the chasm to being palatable even to initial sceptics. Once courts fill in the questions of interpretation currently clouding these (necessarily somewhat abstract) licence, some doubts may dissipate.

</comment><comment><USER51> Startup idea: A MongoDB as a Service company with the entire hosting/management platform written from scratch in Befunge or Brainfuck...

(VCs please form an orderly queue. Priority given to investors willing to pay in Bitcoin or Monero. Contact deets in profile...)

</comment><comment><USER52> Use Postgres, problem solved.

<comment><USER53> While I like relational data and I _love_ Postgres specifically, there are some tasks and contexts for which non-relational stores are better suited.

<comment><USER54> I'm sure that there are tasks for which non-relational stores might be better suited, but pretty much anything MongoDB does, Postgres does it better and in a more performant way (esp after the optimizations to the JSONB data type in the last few major releases).

<comment><USER55> This is a very bold comment, explain how you scale write, do HA in pg?

<comment><USER54> Postgres HA: [https://www.postgresql.org/docs/9.5/static/high- availability...](https://www.postgresql.org/docs/9.5/static/high- availability.html)

<comment><USER55> This is not what I called HA or horizontal scaling. Have a look at what MongoDB or Cassandra do.

<comment><USER52> Unless you're operating at Google/FB/Twitter/etc scale, this is not a problem most of us face IRL. We need to stop pretending we have these problems at 99% of the places we work at. Most of us don't. We don't need 1,000 microservices, Kubernetes, Docker, and a terribly unreliable NoSQL database like MongoDb (there are better, more optimal solutions for those companies than MongoDb (Cassandra being one of them.))

<comment><USER55> The fact that someone has to manually promote a slave as master is a big operational cost. The people that actually use PG at scale have to write a lot of tools / plumbing to overcome those issues, the same "issues" that were solved by most NoSQL solution, horizontal scaling, HA, shards re-balancing ect ...

<comment><USER11> > The fact that someone has to manually promote a slave as master is a big > operational cost.

It doesn't need to be _manual_ , only in a layer above/outside PostgreSQL. There are solutions that automate leader elections for any secondary- promotable-to-primary system (not just PostgreSQL), just not built into PostgreSQL.

We looked for about two years, on and off, to setup smoother, less-manual HA for our PostgreSQL setup. We ended up writing some, as you say, "tools / plumbing to overcome those issues". By far, though, the most time we spent on it was been spent in reading, testing, and getting to understand how things work.

After everything, unfortunately, no other system fit our requirements. Many came close in their marketing copy, but on closer look, every system had caveats. Ultimately, PostgreSQL is the only system I could still trust to do the right thing. In fact, the solid foundation that Postgres provides is why I can trust third-party layers (similar to Stolon and Patron) to focus on the job of switchover correctly without losing or otherwise messing with my data. In fact, I can even switch which tool I use, without it affecting my data.

The little plumbing we've written over Pg's built-in replication allows us to horizontally scale using logical replication and assuredly have HA using physical replication. At the end of the day, any shop that does anything important with data at scale needs to know how their data is actually being treated, irrespective of what the marketing promises. Hell, even when the data-store does not blatantly lie to you about keeping your data safe or uncorrupted, you can lose data due to bad use of tooling or explicitly-set unsafe configuration. "I'll just use this; it'll solve all my problems!" is rarely a thing to blindly believe when dealing with important data.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER56> Cloud computing is becoming the dominant model, and the current combination of OSS licenses and public cloud players/incentives make it nearly impossible for OSS companies to monetize in the cloud. While there are no perfect answers, we either need to come up with new licenses (difficult) or pursue a new approach to cloud (decentralization) that supports OSS monetization.

<comment><USER57> The umbrella issue is monetization of software. Perhaps the philosophy of OSS as a monetization strategy is fatally flawed for certain types of software. I love OSS and it is very useful, but in the world we see that some things are better suited for selling online (not usually pet food), etc. Perhaps it is simply an issue of a particular problem that cannot be well solved by OSS. If that is the case, then perhaps we fall back to the idea of "software monetization" and go proprietary for certain things which work best that way, while pushing OSS for things where it works very well.

</comment></comment><comment><USER58> So has there been a startup yet that forked mongodb's pre-license change form? Get cracking, VC folks.

<comment><USER59> A viable VC-backed startup business model for a GPLv3 or AGPL MongoDB isn't necessarily possible.

</comment></comment><comment><USER20> It's hilarious to me that out of all the problems _with the way MongoDB works_ it's the license, of all things, that gets a strong reaction from the HN crowd that says, "I'm never using that!"

<comment><USER60> MongoDB's technical problems are so well known that it's boring to bring them up again.

<comment><USER61> Mongodb is like Marmite, half tbe world loves it, half hates it, go figure.

</comment></comment></comment><comment><USER62> Apple's SDK has an EULA that says it cannot be deployed on a server and made available as a service. Why can't mongo just create a license that says such a deployment requires a commercial license from them?

</comment><comment><USER63> Arguing that the license is invalid as a defense in court seems to be a risky legal strategy.

'Your honour, my argument is that I was copying this copyrighted software, for profit, without any legal license to do so. Oh wait...'

</comment><comment><USER25> 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=18229452) [https://news.ycombinator.com/item?id=18229013](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...](https://www.mongodb.com/licensing/server-side-public-license/faq). 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.

<comment><USER64> Does MongoDB also release their stack or are they exempt from the disclosure requirement?

Apologies if this has been asked a million times -- didn't see it in a skim of your linked discussions nor the FAQ.

<comment><USER25> 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...](https://www.mongodb.com/blog/post/mongodb-now-released-under-the- server-side-public-license)

<comment><USER65> That takes some level of hypocrisy - you are not making your Atlas as opensource, but you require others to do so. This clearly indicates that you are using an opensource license as an extortion schema against competitors.

<comment><USER66> It absolutely does not make them hypocritical. They own the copyright and can do as they choose. They simply don't want other companies getting rich on their back by simply offering a MongoDB SaaS. Why is it OK for AWS to just take a project and start making millions off of it while the people who invested in the project get nothing? AWS and similar cloud companies are simply trying to strip mine all the value from some popular open source projects and contribute nothing back. Most of these cloud companies show zero interest in partnering with the copyright owners so now we're seeing copyright owners take a stand against this exploitation.

There's a big difference between a piece of free software being vital to your codebase and you simply selling that free software as-a-service.

</comment></comment></comment></comment></comment><comment><USER67> Intellectual "property" is cancerous repression. It's time for copyright to die.

</comment><comment><USER68> I don't understand the line of reasoning. Can anyone give me a lay explanation?

My understanding of the license change is basically "if you use MongoDB to support any site, all software higher in the stack needs to be released as well".

Is that accurate?

If so, why can't an author make this part of the license?

<comment> nevi-me No. If you take MongoDB and offer it as SaaS, the additional software that's part of your offering, such as monitoring, backup solutions, etc, have to be open-sourced, or you have to make their code available (since the chair of OSI defines what's open source).

<comment><USER69> I just had a call with MongoDB sales yesterday, and specifically asked if the licence changes impacts us, where we use Mongo as a datastore for our application, but we're not offering Mongo itself as a service. They were very quick and clear to say that the change is about those providers offering Mongo itself as a service. Using mongo in your stack to provide your service is not implicated at all.

The only grey area I see is if you offered some sort of database-as-a-service backed by Mongo but not explicitly sold as Mongo-as-a-service.

<comment><USER70> This makes sense, and I believe you, but lawyers being lawyers, I don't think any corporate legal team is going to even bother with trying. Easier to say "no".

Source: 1 data point; the company I work for's legal team just said "no".

<comment><USER69> Same fight here, but we're digging in our heels and bothering to convince the internal lawyer that it's not a problem. We'll win, but it takes time we'd rather not have to spend.

<comment><USER37> What mongo says on a sales call is not going to be found usable in court.

<comment><USER69> The odds of anyone here ending up in court over licence terms for using Mongo as part of their backend, are so vanishingly small that to actually decide against Mongo on the basis of that chance amounts to professional malpractice.

</comment></comment></comment></comment></comment></comment></comment><comment><USER71> Doesn't Unifi use this?

<comment><USER72> not as a service, but yes as a backend

</comment></comment><comment><USER73> Is this similar to the GPL3 in intent to force website backends to become open source?

<comment><USER74> How does the GPL3 have that intent? AGPL does, but GPL?

<comment><USER75> My understanding is that AGPL does only for that piece of software, not all layers above it?

</comment></comment></comment><comment><USER76> > accused infringer would then, quite rightly, plead impracticability

I'm not a lawyer, but I wouldn't expect that to be a valid defense. If you can't comply, don't use it.

<comment><USER77> I wish the article had taken this question more seriously. Impracticability _is_ a defense under contract, but a fundamental requirement in the US test is:

> _" an occurrence of a condition, the nonoccurrence of which was a basic > assumption of the contract"_

Impracticability is not a defense against signing stupid or damaging contracts; it specifically releases a party when circumstances _change_ such that a contract is no longer reasonable. Standard examples are things like the outbreak of war or a supply chain collapse, which don't render a contract literally impossible to fulfill but do place fulfillment outside the domain of any reasonable effort.

Defending against conditions which were already in place when a contract was signed is far harder, and even _impossibility_ is not necessarily a defense if the impossibility is obvious at the time of signing. The only common defense I know of against conditions present at the time of signing is illegality, which of course comes up quite often with things like noncompete clauses.

The misuse complaint at least looks plausible, but I'm pretty baffled by the appeal to impracticability.

<comment><USER38> Here is the analysis: Let's think about the context where this would come up: A party ("Service") takes the SSPL'd MongoDB and implements a service. Service releases some code based on a good faith interpretation of the scope of the release necessary. There is a dispute between MongoDB and Service as to the scope of the necessary code release.

In the ensuing lawsuit, Service raises misuse and argues that the scope is ambiguous. Leaving aside the misuse argument, a court could either a) find for Service, thus restricting the scope of the code to be delivered, or b) find for MongoDB, thus giving rise to an immediate defense of frustration/impracticability, which would undo the contract.

<comment><USER77> Interesting, thanks very much. I hadn't realized that a new court interpretation of a contract could form the unforeseen circumstance for a defense.

</comment></comment></comment></comment><comment><USER78> I never understood all the hate mongo gets. Like any tool, if people simply took the time to understand it and use it correctly, maybe they wouldn't run into issues.

<comment><USER9> MongoDB made some _very_ sketchy, undocumented (or poorly documented) technical decisions in its early years that placed data at great risk.

It's better now, but very few things worry technical people more than a database that loses data. It's hard to get past that early impression.

<comment><USER79> Then again, so did MySQL. Do you remember the MySQL 3.x "MyISAM" days? No transactions, automatic truncation and type conversions, etc...

<comment><USER80> ...and a significant portion of IT people still distrust MySQL.

<comment><USER81> ... or they love it, like uber</comment></comment></comment></comment></comment>


Ask HN: Internet Wargame – How would it go down? - <AUTHOR> Imagine a major conflict between the US and China or Russia escalates.
Would the net would be one of the first and major attack vectors? I think it might be.
But it's all a bit ephemeral to me. How would it go down? How would the countries attack and defend themselves?
Some ideas:
-) Disable / overload / damage / infiltrate infrastructure (power plants, hospitals, military installations, communication networks, ..) either via compromised nodes, backdoors or DOS
-) Defend by cutting off most international networking, except for some routes between military bases, etc.
-) Circumvent defenses by activating attack botnets inside target country(ies) before cutoff, or control them via agents and satellite connections
Or would the attacks be more subtle, mostly trying to gain intelligence via compromised communication networks?
Do you think the big players all have access to large, international botnets, or can quickly and automatically create botnets with tooling for known hacks / zero days?
Do they have suites of tooling for compromising and attacking infrastrucutre?
Do they have installations and established protocols at ISPs and major routing infrastructure (transatlantic cables, etc) to either close them of or use them for flooding target networks? And do so quickly?
Also, we hear hacking accusations against Russia and China regularly, but never against the US. I think they probably hack just about everyone and have  compromised many foreign networks, but no one dares speak out about that publicly. Do you disagree?
So many questions...
I'd love to hear some opinions! <comment><USER2> > _Also, we hear hacking accusations against Russia and China regularly, but > never against the US._

Does the NSA spying on Germany not count? What about STUXNET?</comment>


New Youtube Layout - <AUTHOR> http://mashable.com/2011/11/21/enable-new-youtube-design/#354673-Add-Channels-to-Your-Homepage
I'm pretty excited that Youtube has decided to update (and no, this is not another April Fools prank ;).  I haven't fully decided how I personally feel about it (the filters do seem more personalized), but it most definitely has a Google+ flavor to it--which again, may or may not be a good thing.

What do "you" think? <comment><AUTHOR> I'm pretty excited that Youtube has decided to update (and no, this is not another April Fools prank ;). I haven't fully decided how I personally feel about it (the filters do seem more personalized), but it most definitely has a Google+ flavor to it--which again, may or may not be a good thing.

What do "you" think?</comment>


Lockitron To Be Powered By Electric Imp - <AUTHOR> http://techcrunch.com/2013/03/21/lockitron-wifi-electric-imp/ <comment><USER2> I love the idea of flashing the wifi details onto the device and skipping WPS. Someone did a similar thing for a project at the launch festival hackathon a couple weeks ago. Looks like the video is down, but the demo page is still up with viewable source. No app to show it working though: <http://theboxforgotten.com/bridge/>

A question re the imp - why would they decide to use an SD card format?

<comment><USER3> Hi, Electric Imp co-founder here. We made the card format first to facilitate folks who wanted to make products that could optionally use an imp, as well as those who wanted one permanently installed.

We're currently developing a solder-down module, but some vendors still find the card more attractive because the slots are very easy to integrate on a board.

<comment><USER2> Interesting. What happens when you plug a regular SD card into a imp slot? And what happens when you plug an imp into a standard SD slot?

<comment><USER3> Nothing. The pins were allocated such that plugging an imp into an SD-card slot won't hurt it or the device, and putting an SD card into an imp slot won't hurt either the card or the device.</comment></comment></comment></comment>


Google Earth Pro Coming to Linux - <AUTHOR> https://productforums.google.com/forum/#!topic/maps/tCkY0Fd5_uI <comment><USER2> Joke is on you, Google. I only use the command line.</comment>


Introducing The New IFTTT - <AUTHOR> http://blog.ifttt.com/post/25506427600/thenewifttt <comment><USER2> Note to hardware hackers: IFTTT almost certainly started with some musings about "wouldn't it be cool if I could make my household X trigger web API Y" and for many entrepreneurs would have led to a startup about smart gadgets. There have been many over the years.

The very clever thing about IFTTT is they sat and cheaply began the process of building the web layer.

I like it!

WeMo is likely the first of many many gadgets and interfaces where they can accept links.

Now they wait and see how quickly the China Ecosystem and the gadget makers like Belkin deliver lots of nice cheap easy trigger devices.

BugLabs...Nest...Dropcam...LG Smart Refrigerators...Toyota Prius...

<comment><USER3> It would be more exciting if they had an API.

I don't see any way to add channels - either a hardware one or a software one. You could use RSS but that is it. And I don't see any way to add an action. They could very easily add a "web hook" URL for a custom action.

I get really annoyed when I see sites like this that anoint winners. They already have an API to work with outside sites but they just don't publish it

<comment><AUTHOR> I started last week to work on the API. Stay tuned.

<comment><USER4> Exciting stuff! That seems like an interesting way to bring back in the hardware possibilities from the comment above - using an ifttt API in tandem with smart devices could eliminate a ton of work in developing automation.

Also, what's ifttt like to work for so far?

<comment><AUTHOR> Very fun and small team of 8 with great vision. Starting the week before this redesign was a little hectic, but it was worth the effort. Only big things to come :)

</comment></comment></comment></comment></comment><comment><USER5> People who know seem excited about this, so I spent two minutes following links. I still have no idea what ifttt is.

This would help:

\- Change the tagline from "Put the Internet to work for you" to something more descriptive.

\- Have a prominent "About" link on the blog. Write an About page, or better put some content on your home page.

<comment><AUTHOR> I'll work on getting better info on the blog. In the mean time, here's our about page <http://ifttt.com/wtf>

<comment><USER6> Even that needs a lot of work.

Okay, so I can create "connections" on an "if this then that" basis. I need more examples of the sorts of thises and thats that I can use as input and output, though. Like, apparently I can control my home appliances? And... what else?

<comment><USER7> Really? The second heading on the page clearly gives five examples with an obvious link to 46 more.

<comment><USER8> Why do I need another website to do Twitter, Facebook, Evernote, Email, or Weather? I already have apps that do whatever it is those things are.

No, the page in question does have 1 really good example, the if Instagram then Dropbox example. I think the homepage of IFTT would benefit from a nice animation where the "this" and "then" options cycle through various options. It would show how any tigger can be combined with any action and highlight a few of the good use cases.

</comment></comment></comment></comment></comment><comment><USER9> This is a little off-topic but I would still like someone from ifttt to answer in more detail the method that they use to store passwords for 3rd party sites.

I think this is an important detail for an app like ifttt as they necessarily have to store the actual passwords in a form that they can reverse encryption (for websites that do not support something like OAuth) for in order to submit on the user's behalf. So it's important to get some transparency on the mechanism by which ifttt does this.

I also posed the question here a while ago: [http://www.quora.com/How-does- ifttt-securely-store-passwords...](http://www.quora.com/How-does-ifttt- securely-store-passwords-for-sites-that-do-not-use-OAuth-or-similar-methods)

<comment><USER10> > I also posed the question here a while ago: [http://www.quora.com/How-does- > ifttt-securely-store-passwords...](http://www.quora.com/How-does-ifttt- > securely-store-passwords-for-sites-that-do-not-use-OAuth-or-similar-methods)

And you appear to have received an answer there, as well. Anything using OAuth doesn't need to store passwords, and for anything else ifttt stores the password in an encrypted (but obviously retrievable) form. I don't see how they could do otherwise; at most, they could refuse to interoperate with any sites not supporting OAuth, and I don't see the benefit to that.

<comment><USER9> To be clear, I was looking for more detail around _how_ they were doing the reversible encryption.

</comment></comment></comment><comment><USER11> It is a bummer that the Belkin WeMo's are going to be so expensive.

<http://www.belkin.com/wemo/> ($50 switch, $100 for switch + motion sensor)

<http://ifttt.com/wemo_switch>

If I was looking to dip my toe into some home automation toys, I would rather pick up a Nest($250) and one of the iOS/Android powered home locks (~$300) than the equivalent # of WeMos(at $50/per)... but that's just me. To get real value out of a WeMo system, I figure you need at least 10 spread around your house.

If the WeMo's were $20-25/ apiece and they had a wall switch version, I think Belkin & IFTTT would be a game changer in the home automation space.

<comment><USER12> >one of the iOS/Android powered home locks (~$300)

Check out Lockitron! (<https://lockitron.com>) - we come with an API, no monthly fee, and a variety of locks that will work on most doors or apartment buzzer systems.

<comment><USER13> What's the solution when your phone is stolen/offline/out of order?

<comment><USER14> Lockitron also offers locks with a keypad, and every lock comes with a Bluetooth keyfob for emergencies like this. <3 lockitron.

<comment><USER15> I don't see any keypads on the site. Is this true?

A keypad backup is a very desirable feature to me. Possibly to lots of others too, I would think.

<comment><USER12> Ah, yes, a bit of a secret those. We're currently doing field tests with our keypad locks.

</comment></comment></comment></comment></comment></comment><comment><USER16> Hell yeah for marketing this is cool:

IF retweeted

Then Turn Strobe Light On

Then Wait 5 seconds

Then Turn Strobe Light Off

<comment><USER17> Sounds like it could give you a seizure if your tweet went viral.

<comment><USER16> Ha! It could be a lot of fun to think of potential dashboard (1 for each sale/sign-up seems like a good metric for some startups) related hardware/software interfaces.

</comment></comment></comment><comment><USER18> I've skimmed the first two screen-heights of that page, and I still have no idea what it actually is or does. Maybe link to an explanation somewhere?

<comment><AUTHOR> <http://ifttt.com/wtf>

Edit: Sorry for the trouble. We're working getting a link to our About page from the blog. If you hit the home page, the giant 'Learn more' link has been really successful at getting people there.

</comment></comment><comment><USER19> Wow, how have I not heard of WeMo before? Though Belkin is typically a little overpriced, I think they've opened the door for other companies (Phillips, maybe?) to offer their own version. I'm definitely looking forward to automating my dorm next year.

<comment><USER20> I wondered the same thing as I've been researching controllable power sockets for a while (although more looking at digital IO/USB control).

I only discovered WeMo today via a comment on Twitter. Though they were announced back in January as available in "US summer" it seems they've been pretty much under the radar since then until now.

</comment></comment><comment><USER21> My first thought on seeing the name was that it had something to do with Fourier transforms.

</comment><comment><USER22> I would use IFTT if I could pay them money.

I am wary of building on top of any third party web service, but I free services like this I may play with but never depend on for personal or business use.

<comment><USER23> I've upvoted you, but I really want to second this verbally too. I don't see any adverts on IFTTT (and even if they were: once setup, I wouldn't be visiting the site often and seeing them), and don't understand how they're monetising. This is a service I'd really like to use, but I don't want to come to depend upon it, then find it folding (either due to monetary problems, or acquired by a third party and being shut down).

Some information on how they intend to stay alive would be fantastic.

<comment><USER24> I wondered about that too, and one thing that occurred to me was that if they get popular, they've got access to combine data about their users across all the source and sink services the users use. That is, they can get all my readily available Facebook data (friends, likes, etc.), my Twitter feed and follower/followee/favorites lists, etc.

I doubt IFTTT is doing such data fusion today (their userbase is probably too small to make it worthwhile), but I wonder if that's the eventual plan. To advertisers, that sort of data could be immensely valuable for ad targetting.

</comment></comment></comment><comment><USER25> I very much like it, two comments:

There doesn't seem to be any interface for adding multiple channels of the same type. My use case: a personal gmail account and a google apps email account. In general, it would be good to be able to add multiples of any channel, eg

\- multiple time channels for different time zones

\- multiple twitter accounts

\- multiple sms accounts

The ability to share recipes is great, however it is too hard to browse them. Of the ~35000 shared recipes I suspect many are variations on a theme, and whilst the ability to filter by channel and the ranking by popularity are useful much more could be done. In particular,

\- being able to choose existing tags when creating new recipes

\- being able to browse existing tags

\- suggesting recipes that are similar to the one I am adding, or even creating!

Love to see how this progresses, especially as the API opens up.

</comment><comment><USER26> I am happy about their foray into the physical world but there is a much more critical feature still missing in my opinion: the possibility to check for a desired trigger (e.g. stocks) at a specific time/date or, in general, the possibility to combine multiple triggers at once

</comment><comment><USER27> I'm not clear on the difference between a trigger and a quick trigger. Is it just that regular triggers are run in batch jobs, and quick triggers are processed individually?

<comment><USER28> Most of the triggers on IFTTT require polling to receive updates. We poll the sources roughly every 15 minutes.

Quick triggers, on the other hand, are event-driven.

So, for instance, if you had a task that was "IF I send IFTTT a Google Chat THEN post to Twitter" we'll now post your tweet within a couple of seconds (vs. before it would have been within 15 minutes)

</comment></comment><comment><USER29> If you are looking for 'microcontrollers <-> webservices with full restful api' then Cosm looks pretty good. Arduino, Nanode, mbed, devices running OpenWRT...

They just changed names from Pachube.

<https://cosm.com/>

</comment><comment><USER30> This is the first time I hear about IFTTT. I like it very much. The name is terrible though. The other similar startup on HN, Zapier, has a much better, easier to remember name. I'd go as far as to suggest to change the name. Here's one: apibit.com is still available.

<comment><USER31> "If this then that" is a terrible and hard to remember name?

IFTTT is just the acronym.

</comment></comment><comment><USER32> The Belkin WeMo looks useful, but looking over its site quickly, it doesn't appear to be programmable through an API.

Does anyone know of a similar product which can be programmed through an API?

<comment><USER33> it sounds like IFTTT is its API.

</comment></comment><comment><USER34> Not really excited. There are not many new channels, and those are mainly for some additional devices. Some may find them useful though.

<comment><AUTHOR> The key thing for the new channels is that it's the first expansion outside the screen and into the physical world. A lot more to come in that area, stay tuned.

<comment><USER35> like the pebble yea?

<comment><AUTHOR> Yep!

</comment></comment></comment></comment><comment><USER36> If its an introduction, how can I read the entire post without knowing what the hell it is?

</comment><comment><USER37> Is there any updates on the ifttt api? When is the ETA?</comment>


The secret in my blood - <AUTHOR> https://www.bbc.co.uk/news/resources/idt-sh/the_secret_in_my_blood <comment><USER2> … and no scientists tried to find out why he is seemingly resistant to the virus?? That is the _real_ secret in his blood.

<comment><USER3> I'm not sure he necessarily is resistant to the virus. It has a long and variable incubation period, and he may have been lucky enough that this incubation period reached the point at which HAART treatment was widely available.

<comment><USER4> In the article it says:

"Matt looks at where he is today with amazement. His hepatitis C has gone and his viral loads of HIV are still undetectable – he's never had to take anti- retrovirals. Of about 1,250 haemophiliacs infected with both hepatitis C and HIV due to the scandal, according to the campaign group Tainted Blood, fewer than 250 are still alive. "It really is, in terms of health outcomes, like winning the lottery," he says."

<comment><USER3> Ah thanks, missed that. Makes you wonder whether the Hep C treatment (probably with interferon) helped to keep the HIV under control too.

</comment></comment></comment></comment><comment><USER3> This is a lovely story, and I enjoyed reading it.

I'm not sure the infection of haemophiliacs from blood products should be compared to Grenfell. Unlike aluminium cladding on a skyscraper, patients took factor concentrate on specific medical advice to treat bleeds that would otherwise not have stopped.

These factor concentrates required hundreds of blood transfusions to make just a small amount (they were also highly expensive, and still are today, shots can easily cost several thousands of pounds each), and they were given to treat bleeds, which were life-threatening or limb-threatening. In younger children and severe haemophiliacs they had to be given factor regularly to prevent bleeds.

The enquiry will need to look at how the pharmaceutical/product companies and health organisations dealt with incoming information, and whether they had a viable alternative at the time. There is suggestion that the UK producer of factor concentrate (BPL) was highly underfunded at the time, and unable to produce the required amount of factor concentrate to supply the country.

There is a UK public enquiry ongoing to assess whether someone or some organisation should hold responsibility for it - and I agree it is overdue.

<comment><USER5> It is not about quantity, it is about process. If they had not mingled the blood of thousands of individuals the damage would have been far, far less.

Of course more - smaller - batches would have been more costly.

<comment><USER3> It's a chemical fractionation process [1] on thousands of litres of blood plasma, and that's how it is still done today for those products which aren't produced by recombinant DNA. But these days there are repeated health screens and viral testing on both the donors and batches, as well as solvent- treating/ultra-filtering the products.

Maybe it is possible to process in smaller batches, but I suspect that is down the the facility producing it, and the issue was the that UK weren't able to increase their in-house production at the time.

[1] [http://www.penroseinquiry.org.uk/finalreport/text/354876_cha...](http://www.penroseinquiry.org.uk/finalreport/text/354876_chapter_19.html)

</comment></comment></comment><comment><USER6> > Despite a supporting letter from Matt's HIV consultant pointing out that he > had contracted HIV and hepatitis C through contaminated blood products > supplied by the NHS, they were told these were not "exceptional > circumstances".

No matter how much I see, hear or read about government bureaucracies treating people badly because doing otherwise would risk having to own up to their mistakes it still doesn't disgust me any less. It's one thing for a corporation (which is supposed to be profit driven) to treat people badly and refuse to acknowledge it or compensate those who were harmed. It's inexcusable for a government entity (which is supposed to be serving the people in some manner) to behave that way.

<comment><USER7> Can you not sue the government in the UK? I am struggling to understand why this was not a massive class action lawsuit. They severely impacted these people's lives and deserve compensation.

<comment><USER8> [https://www.theguardian.com/society/2017/sep/26/contaminated...](https://www.theguardian.com/society/2017/sep/26/contaminated- blood-scandal-victims-win-ruling-to-launch-high-court-action)

</comment></comment></comment><comment><USER9> Always insightful to enter the minds of people who are told they're "meant to die". The mental fortitude of this man is amazing.

Great short read - would love any recommendations of other short stories about similar situations.

<comment><AUTHOR> Here's the journalist's twitter account. [https://twitter.com/mrjonkelly](https://twitter.com/mrjonkelly)

Here's another article he wrote: [https://www.bbc.co.uk/news/resources/idt- sh/tainted_love](https://www.bbc.co.uk/news/resources/idt-sh/tainted_love)

IRIN News may have similar items. Here's one about refugees which is close. [http://www.irinnews.org/special- report/2018/07/19/destinatio...](http://www.irinnews.org/special- report/2018/07/19/destination-europe-misery-and-misunderstandings-part-1)

</comment></comment><comment><USER5> > In the media, the disease was largely associated with groups such as drug > users and gay men, who were routinely stigmatised at the time.

This is still very much the case today, depending on where you live it might even be worse today than it was in the 80s.

<comment><USER10> But that "stigma" is not inaccurate is it? Most of the people _in the US_ with AIDS are gay men and drug users. Sure other people get AIDS, but the rate is much lower.

Edit: clarified I was talking about US cases

<comment><USER5> > Most of the people with AIDS are gay men and drug users.

Did you just step out of a time machine or something?

The vast majority of AIDS victims in the world are not gay and never used drugs.

Have some stats:

[https://www.avert.org/global-hiv-and-aids- statistics](https://www.avert.org/global-hiv-and-aids-statistics)

<comment><USER11> If you randomly select an HIV positive person from a Western country and know no other facts about them, it is correct to update your belief towards thinking they are either homosexual or a user of IV drugs. If their gender is revealed male this is especially true.

Obviously you cannot update this strongly if you are selecting from the global population but you would still update in that direction. Making these priors explicit is extremely taboo.

<comment><USER5> You are dangerously wrong. No, it is not true that > 50% of the HIV positive people in Western countries are either gay or use drugs intravenously.

It is that sort of stupid thinking that contributes to HIV spreading the way it does, after all: you are not a drug user and you are not gay, and neither is your partner, so what could possibly happen.

<comment><USER12> [https://www.cdc.gov/hiv/statistics/overview/ataglance.html](https://www.cdc.gov/hiv/statistics/overview/ataglance.html)

[https://www.cdc.gov/hiv/group/msm/index.html](https://www.cdc.gov/hiv/group/msm/index.html)

Canada -> 53% of new HIV infections are MSM [http://www.catie.ca/en/fact- sheets/epidemiology/epidemiology...](http://www.catie.ca/en/fact- sheets/epidemiology/epidemiology-hiv-canada)

Australia - > 68% of new HIV infections are MSM [http://www.hivmediaguide.org.au/hiv-in-australia/hiv- statist...](http://www.hivmediaguide.org.au/hiv-in-australia/hiv-statistics- australia/)

UK -> 54% of new HIV infections are MSM [http://www.catie.ca/en/fact- sheets/epidemiology/epidemiology...](http://www.catie.ca/en/fact- sheets/epidemiology/epidemiology-hiv-canada)

<comment><USER5> It appears my facts on gay HIV are off but on drug users they are on (for the west).

Globally the situation is _much_ different and about the same number of men as women have HIV and drugs do not appear to be a big factor in to the equation.

It is interesting how the data has changed over the years, for a long time gay men were not the largest group but maybe with the increased effectiveness of anti-virals combined with decreased mortality the balance has shifted substantially once again.

In the beginning of the AIDS epidemic it was basically a disease afflicting predominantly gay people and only rarely heterosexuals. The two groups being somewhat socially isolated was an important factor in this. Then the balance shifted as more and more heterosexual people got infected and was made worse by people thinking that HIV would pass them by because they were not gay.

So now we have come full circle.

Still, 32% (at best) are pretty lousy odds so better be very careful.

<comment><USER10> _Still, 32% (at best) are pretty lousy odds so better be very careful._

That's not how statistics work.

MSM and IV drug users are a small percent of the overall population. If you looked at the rate of HIV cases and divided by the respective population, you'd see that MSM and IV drug users are at a far greater risk of contracting HIV than heterosexuals (by magnitudes of order).

However, that certainly doesn't infer that heterosexual can't get AIDS and that they shouldn't seek to avoid it through appropriate measures.

<comment><USER5> Well yes, obviously gay people and drug users are not the bulk of the population so that 32% indicates 32% of all of those that end up HIV positive.

For the mainstream population that is a _much_ lower risk than for a smaller group that has a roughly equal incidence in absolute numbers.

But that risk is still substantial, and you do not want to end up as an entry in the tally of that 32%, which is a substantial number of individuals, if approximately 4% is LGBT then maybe 50% of those (so 2% of the population) takes 68% of the cases, leaving 98% to divide the remaining 32%.

There are many lotteries with far fewer winners.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> Who on earth made the decision to pay prisoners for blood and not test it? I realise it was the early days of HIV, but enough was understood at the time to make that one of the most evil things I've ever heard.

<comment><USER14> This occurred before HIV was isolated and identified as the cause of AIDS. There was concern earlier on that there seemed to be a correlation between the platelets products and AIDS cases but they had very little data.

<comment><USER15> HIV wasn't the only known blood-borne pathogen, though, so I'm not going to let "the authorities" off the hook.

Edit: To be clear, I know you're not making excuses for them either.

<comment><USER14> Obviously, I don't know the details of 1970s/1980s plasma products, but I think it's probably fair to assume that they were screening for pathogens they knew about at the time. I think in retrospect it's easy to say that they should have taken the factors off the market sooner, but at the time it was probably a very difficult situation. Hemophilia is an incredibly dangerous condition without treatment and there was a reasonable expectation that people would die without access to clotting factors.</comment></comment></comment></comment>