Live data from Hacker News

AWS, MongoDB, and the Economic Realities of Open Source

stratechery.com

241–250 of 257 posts

Re: AWS, MongoDB, and the Economic Realities of Open Source

#241
post #232

Earlier quoted context omitted.

more than VMs. yes, and that's the vendor lock in part. sometimes it's okay though. but AWS monoculture is not a bright future.

All of the services with no lock in Elastic Cache - hosted Redis and Memcached Aurora - compatible with MySQL and Postgres RDS - hosted versions of Mysql, MariaDB, Sql Server, and Oracle. Redshift - yes it uses a proprietary/columnar store engine but it is compatible with Postgres. Etc. But the bigger point is that you’re always locked into your infrastructure, do you think your CTO is going to move from their millio…

AWS has quite a few other solutions that you haven't mentioned that are not so portable.

I'm not advocating simply ignoring AWS's strengths because let's say Lambda/EBS/ELB/etc. is proprietary, but this is a very real, very simple risk. As AWS can, it will raise prices.

And sure, maybe it doesn't matter because you can always just fall back to using whatever you use on simple VMs, and AWS will always have some competition in the simple VM hosting space and VM prices will therefore will be low.

However, I'm on the opinion that institutional inertia will "kick in" (to use a rather bad figure of speech for something that is about as agile as a drum of molasses) and will simply let AWS rent-seek.

Re: AWS, MongoDB, and the Economic Realities of Open Source

#242
post #241

Earlier quoted context omitted.

All of the services with no lock in Elastic Cache - hosted Redis and Memcached Aurora - compatible with MySQL and Postgres RDS - hosted versions of Mysql, MariaDB, Sql Server, and Oracle. Redshift - yes it uses a proprietary/columnar store engine but it is compatible with Postgres. Etc. But the bigger point is that you’re always locked into your infrastructure, do you think your CTO is going to move from their millio…

AWS has quite a few other solutions that you haven't mentioned that are not so portable. I'm not advocating simply ignoring AWS's strengths because let's say Lambda/EBS/ELB/etc. is proprietary, but this is a very real, very simple risk. As AWS can, it will raise prices. And sure, maybe it doesn't matter because you can always just fall back to using whatever you use on simple VMs, and AWS will always have some compet…

So you’re going to “move to the cloud” and just host a bunch of VMs.

Congratulations, you now have the worse of all worlds. You’re spending more than baremetal, you’re spending just as much on maintenance and management instead of letting someone else do the “undifferentiated heavy lifting” and your developers are moving slower than they would have if they took advantage of your cloud vendors offerings.

Win????

Re: AWS, MongoDB, and the Economic Realities of Open Source

#243
post #239

Earlier quoted context omitted.

I think it was specifically Amazon not releasing their changes. Maybe AGPL would cover them and force the release, but if Amazon stuck their heals down it would be an expensive legal fight. My guess is that it was just easier to change the licence used going forward to one that is more explicit and unambiguous about the matter. It was my understanding that AGPL was supposed to cover this specific type of use, so woul…

I'd actually be kind of surprised if Amazon did actually use it - most of the big tech companies are allergic to AGPL, and e.g. Google does not allow it to be used at all, even internally.

> I'd actually be kind of surprised if Amazon did actually use it

They did, which is how this discussion started.

Until 4.0.4 / 4.1.5 MondoDB was released under the AGPL licence. Upon those releases it switched to SSPL (which IIRC is APL plus extra "commons clauses"). Amazon have stopped using MongoDB as they do not want to (or for some reason are unable to) abide by this new license, but had previously been happy to use the code under [their interpretation of] AGPLv3.

Re: AWS, MongoDB, and the Economic Realities of Open Source

#244
post #239

Earlier quoted context omitted.

I'd actually be kind of surprised if Amazon did actually use it - most of the big tech companies are allergic to AGPL, and e.g. Google does not allow it to be used at all, even internally.

> I'd actually be kind of surprised if Amazon did actually use it They did, which is how this discussion started. Until 4.0.4 / 4.1.5 MondoDB was released under the AGPL licence. Upon those releases it switched to SSPL (which IIRC is APL plus extra "commons clauses"). Amazon have stopped using MongoDB as they do not want to (or for some reason are unable to) abide by this new license, but had previously been happy to…

I haven't seen a source clearly saying that Amazon had been using MongoDB - I thought the DocumentDB release last week was the first MongoDB product they offered?

EDIT: and searching HN comments, there's multiple people claiming AGPL is entirely banned inside Amazon too

Re: AWS, MongoDB, and the Economic Realities of Open Source

#245

Earlier quoted context omitted.

> Parity is an open source license No, it isn't: https://opensource.org/licenses/alphabetical A few issues: > 3. Contribute software you develop, deploy, monitor, or run with this software. That goes farther than the OSI, FSF, or DFSG allows, extending into software that is not in any way derived from the licensed software. It's also not obvious from the license that it allows private modifications that aren't distri…

Ok. So, you're using the technical definition of open source from that organization instead of the popular one I was using. That's fine. The goal of copyleft is supposed to get modifications shared. Parity does it better than any popular license. They all screwed up allowing people to dodge their goal. So, I'd say Parity is better at making open and free software than all of those. They need to update their requireme…

> So, you're using the technical definition of open source from that organization instead of the popular one I was using.

The OSD is the popular, widely used definition, as opposed to simply "source available". In general, I've found a roughly 100% correlation between people who try to say that "open source" should mean something other than the OSD and people who have a vested interest in pushing something that the OSD wouldn't permit.

> The goal of copyleft is supposed to get modifications shared.

Under an open source license. Otherwise it's just an incompatible proprietary ecosystem that happens to encourage sharing within its walls. That doesn't help or contribute to the open source community at all.

> They need to update their requirements to match reality

Proprietary software vendors come and go, and they often think that the requirements should change to accommodate them. The world goes on, and people whose requirements include open source licensing continue to ignore software that doesn't meet those requirements. This is not new; there has been a steady progression of custom non-open licenses that try to blur the line for just about as long as FOSS has existed. Long before there was "commons clause" and "license zero" there was Microsoft's "shared source". It failed then, and it'll fail now.

I've already seen a number of conferences this year with talks on the agenda about the problems of non-open licenses that attempt to pretend to be open, and how to work around them.

Regarding the comments you linked to, "License Zero" is even more blatantly non-open. And multiple people already provided detailed issues with those comments, to which I have little more to add.

"open source" is a bright true/false line for a reason, much like "non-toxic" or "food safe". If you want to build something proprietary, go ahead, but trying to pretend it's open is harmful FUD.

Re: AWS, MongoDB, and the Economic Realities of Open Source

#246

Earlier quoted context omitted.

Ok. So, you're using the technical definition of open source from that organization instead of the popular one I was using. That's fine. The goal of copyleft is supposed to get modifications shared. Parity does it better than any popular license. They all screwed up allowing people to dodge their goal. So, I'd say Parity is better at making open and free software than all of those. They need to update their requireme…

> So, you're using the technical definition of open source from that organization instead of the popular one I was using. The OSD is the popular, widely used definition, as opposed to simply "source available". In general, I've found a roughly 100% correlation between people who try to say that "open source" should mean something other than the OSD and people who have a vested interest in pushing something that the O…

"Under an open source license. Otherwise it's just an incompatible proprietary ecosystem that happens to encourage sharing within its walls. "

Remember I shifted to talk about Parity license which forces all modifications to be shared regardless of intent or distribution model. As in, every change is available to anyone who wants it. Whereas, your open source licenses have led to many "incompatible, proprietary ecosystems" that used their code to build such things. Parity leads to more open code than open source given it tries to allow no loopholes to build walled gardens or hide code.

""open source" is a bright true/false line for a reason, much like "non-toxic" or "food safe". If you want to build something proprietary, go ahead, but trying to pretend it's open is harmful FUD. "

It's not, though, because it's built on a legal system that isn't true or false. Quick example where we'll apply a modern strategy to older times:

1. UNIX spread everywhere. Your goal is to make a UNIX application that every gets and benefits from under open source license. You do that.

2. AT&T sues you for copyright infringement. They claim API's are copywritable. They win. Your app is now illegal and you owe money.

3. They promise to sue other people who didn't buy app-building licenses from them.

Is your open source app really meeting the goals of open source if you (a) can't legally use it, (b) can't legally share it, and (c) anyone who tries might get sued? I don't think so. Next example:

1. 3G is invented. Some company patents it. Telecoms standardize on it.

2. Your goal is to write open-source stack for cellphones. Folks want 3G. You develop and release as open source a 3G stack people start integrating.

3. You and many of them get sued in patent courts that determine you're infringing on a patent. Note that patent law says you not only can't distribute patented works: you can't even create a duplicate. You have to stop distributing it immediately, pay damages, and, if wanting use to continue, negotiate a licensing package with them with upfront, annual, and/or royalty costs.

Is your open source app meeting the goals of open source if you (a) can't legally write it, (b) can't distribute it, and (c) anyone who uses it might get sued? I don't think so.

Now a big picture example. Microsoft and Apple use BSD-licensed code to help build their proprietary platforms that rake in billions of dollars. Then spend millions of that bribing politicians to strengthen copyright and patent laws in a way that facilitates lawsuits against competitors, including OSS developers or companies. They set things up so building compatible products is either illegal or financially dangerous. They also push for the patent laws to stay allowing broad, non-really-built inventions that exist only on paper to make lawsuits numerous and easy to win. The open source code has actually facilitated a reduction in software freedom across the board by sending piles of money to evil companies opposing software freedom who actively change the law to support their goals.

So, you have lobbyists, courts, and patent law attacking software freedom. Whoever has the most money on that gets more ground over time. The good folks maximizing freedom need piles of money to fight back (see Oracle vs Google). Within this environment, you are pushing licenses that mostly send money to the folks opposing freedom while only giving a trickle to those supporting it. You're also pushing licenses that allow them to hoard software in many cases that generates this wealth. Those licenses not only don't help the goal overtime: they erode it by giving the other side power and ability to build walled gardens. Obviously, something needs to change to reduce the fortunes evil companies can build off of software to send more of that money (or at least opportunities like w/ code changes) back to the good guys.

The loophole-filled licenses that you're pushing already led to laws and court rulings that worked against freedom. Folks were warned. FSF had right idea but tried to be too soft on commercial side. Look what happened. Now, you're still acting like the licenses aren't contributing to the problem while saying your goal is more software available with source for more people with less walled gardens. Parity forces source to always be shared with no walled gardens possible. I don't see how you talk about proprietary and walled gardens in relation to Parity if it makes them impossible, but the licenses you push already led to a ton of them.

I mean, feel free to reject Parity for any flaw in it achieving its goal of opening and sharing software. Just don't make stuff up like how forcing release of source code creates walled gardenes. Maybe you were thinking about Prosper, which is proprietary with its own benefits. Since you're an OSS guy, I was highlighting Parity since it's more in line with your goals. With no loopholes benefiting companies fighting against software freedom.

Re: AWS, MongoDB, and the Economic Realities of Open Source

#247

Earlier quoted context omitted.

> So, you're using the technical definition of open source from that organization instead of the popular one I was using. The OSD is the popular, widely used definition, as opposed to simply "source available". In general, I've found a roughly 100% correlation between people who try to say that "open source" should mean something other than the OSD and people who have a vested interest in pushing something that the O…

"Under an open source license. Otherwise it's just an incompatible proprietary ecosystem that happens to encourage sharing within its walls. " Remember I shifted to talk about Parity license which forces all modifications to be shared regardless of intent or distribution model. As in, every change is available to anyone who wants it. Whereas, your open source licenses have led to many "incompatible, proprietary ecosy…

Fascinating to refer to "loophole-filled licenses", while referencing a license with no legal history of enforcement. Meanwhile, the GPL does have a long history of legal enforcement, and has successfully gotten code released on numerous occasions. What rulings are you referring to that "worked against freedom"?

Apart from that, this is nothing that hasn't been seen in every past "it's hard to make money on Open Source" argument. Meanwhile, people are busy making money on Open Source.

Please don't build random non-open licenses and call them open. If you'd like to call your license open, go get OSI to call it open.

Re: AWS, MongoDB, and the Economic Realities of Open Source

#248

Earlier quoted context omitted.

"Under an open source license. Otherwise it's just an incompatible proprietary ecosystem that happens to encourage sharing within its walls. " Remember I shifted to talk about Parity license which forces all modifications to be shared regardless of intent or distribution model. As in, every change is available to anyone who wants it. Whereas, your open source licenses have led to many "incompatible, proprietary ecosy…

Fascinating to refer to "loophole-filled licenses", while referencing a license with no legal history of enforcement. Meanwhile, the GPL does have a long history of legal enforcement, and has successfully gotten code released on numerous occasions. What rulings are you referring to that "worked against freedom"? Apart from that, this is nothing that hasn't been seen in every past "it's hard to make money on Open Sour…

"Fascinating to refer to "loophole-filled licenses", while referencing a license with no legal history of enforcement. "

They might come up with something. License Zero author has done a remarkable job of focusing on root causes and simplicity to prevent that. When he worries about commercial use, he says commercial use triggers the requirement. When he wants changes released, his license says any change has to be released. Use, changes, and combining with other works in an app are about as all-encompassing as you can get in a simple license. Whereas, Open Source and Free Source focused on linking and distribution which have plenty of complexity that corporate imaginations might work around. Which they did to tune of billions of dollars and plenty unshared improvements.

"What rulings are you referring to that "worked against freedom"?"

Oracle's API ruling, risk of patent suits, and next string of problems lobbyists and lawyers invent. Stuff would've been worse if we didn't luck out with giants IBM and Google paying for the legal battle. With [F]OSS-centered lobbying, we might have even got better laws and protections on these issues. [F]OSS sends most of the money to the opposition, though, with their main licenses and strategies.

"hasn't been seen in every past "it's hard to make money on Open Source" argument. "

I said you can loose money if they patent sue you or pull some stuff about API. These are real things in real court cases. I said it isn't really open and free to distribute if that risk exists. So, we have to mitigate it. I don't believe you when you say it's what open source discussions have always involved if my comments are the only ones I've ever seen here bringing this stuff up. Most comments about money and open-source are about making it profitable to the developers, not funding work in Congress and courts to protect our freedoms.

"If you'd like to call your license open, go get OSI to call it open."

I call mine shared source or source available per your prior advice on that. (Thanks again btw.) Prosper is shared source. Parity is free with source-sharing with maximum copyleft and some patent-suit protection. Looking at OSD, Parity appears to meet every requirement except No 9. That one specifically facilitates proprietary software and walled gardens built on top of or alongside open source code. Since Parity has copyleft for bundles, it can't be open source under that definition. Debian has that same provision, too.

It does have the four freedoms in a mandatory way that kicks in on any change, not distribution models or other guesswork. So, it's Free as in Speech Software that forces all freedoms to happen on derivatives of and bundles with the software with some patent protection. More freedom-preserving than OSI licenses in more situations. So, you're right that it shouldn't be called open source since those are less free and allow more corporate damage than Parity.

Re: AWS, MongoDB, and the Economic Realities of Open Source

#249
post #244

Earlier quoted context omitted.

> I'd actually be kind of surprised if Amazon did actually use it They did, which is how this discussion started. Until 4.0.4 / 4.1.5 MondoDB was released under the AGPL licence. Upon those releases it switched to SSPL (which IIRC is APL plus extra "commons clauses"). Amazon have stopped using MongoDB as they do not want to (or for some reason are unable to) abide by this new license, but had previously been happy to…

I haven't seen a source clearly saying that Amazon had been using MongoDB - I thought the DocumentDB release last week was the first MongoDB product they offered? EDIT: and searching HN comments, there's multiple people claiming AGPL is entirely banned inside Amazon too

In which case I don't see why this is such a big issue. Amazon couldn't use it before the change because of their licence use policy, and can't after the change either. So the change represents no change in that respect.

Implementing an interface compatible with something that you can't use for licensing reasons is no biggie. Other projects, Free/free/OS/commercial, do that sort of thing all the time.

I wonder where the problem that drove the change actually was... RH dropping it from their distro is an issue related to the licence change, but I don't get the impression that was the intended target.

I should probably find time to dig back into the details, as I feel I've missed something notable.

Re: AWS, MongoDB, and the Economic Realities of Open Source

#250
post #241

Earlier quoted context omitted.

AWS has quite a few other solutions that you haven't mentioned that are not so portable. I'm not advocating simply ignoring AWS's strengths because let's say Lambda/EBS/ELB/etc. is proprietary, but this is a very real, very simple risk. As AWS can, it will raise prices. And sure, maybe it doesn't matter because you can always just fall back to using whatever you use on simple VMs, and AWS will always have some compet…

So you’re going to “move to the cloud” and just host a bunch of VMs. Congratulations, you now have the worse of all worlds. You’re spending more than baremetal, you’re spending just as much on maintenance and management instead of letting someone else do the “undifferentiated heavy lifting” and your developers are moving slower than they would have if they took advantage of your cloud vendors offerings. Win????

You can't just "move to the cloud" by firing Ops people and giving an AWS account to your Devs.

Or, well, you can, but then don't forget to set your billing limit to infinity as well. Because AWS wants to make money.

Anyway, I'm not saying RDS/Aurora/etc. is bad, but eventually the heavy lifting will be available for anyone ( https://github.com/beekhof/rss-operator and similar projects ), and it's not like AWS likes to pay when they don't perform according to their SLA.

Post reply on HN