MongoDB found that objectionable, and changed the license such that Amazon would either have to pay, or stop using it.
Amazon stopped using it, and started using its own in-house implementation instead (presumably because it was cheaper to develop it than to pay MongoDB).
So, MongoDB got exactly what they asked for. It's just that, when they forced Amazon to make a choice, they didn't expect one of the options they gave them to be viable. They were wrong.
I don't see how Amazon is in the wrong here. They are no longer using MongoDB for free, as the authors demanded. They did not reuse any code. They are not advertising their replacement as MongoDB, either.
Is it because of API compatibility? But the notion that one cannot reimplement a public API for the sake of compatibility is in and of itself extremely hostile to the F/OSS ecosystem, given how many products in it are reimplementations of proprietary APIs.
> They are not advertising their replacement as MongoDB, either.
I don't really agree there. The service is called documentDB and this is how they describe it [1]:
> Amazon DocumentDB (with MongoDB compatibility)
> Fast, scalable, highly available MongoDB-compatible database
And the first 2 sentences:
> Amazon DocumentDB (with MongoDB compatibility) is a fast, scalable, highly available, and fully managed document database service that supports MongoDB workloads.
> Customers use MongoDB as a document database to store, retrieve ...
You have to read all of that pretty carefully to understand that it's NOT MongoDB (a term they mention 5 times in the first 4 sentences). And if you read it carefully it seems to say it's compatible with MongoDB, whereas the Techcrunch article states it's only compatible with the MongoDB API from 2 years ago.
Yeah, this is pretty clear. I do assume it will act the same as MongoDB 3.6, since that's what they claim, but it's extremely clear it's _not_ MongoDB.
I think the plainest and most obvious reading is that this is not MongoDB but that the migration from MongoDB over to this not-MongoDB would be easy because of the compatibility with MongoDB.
Agreed. Like how Digital Ocean lists their storage as S3-compatible. Amazon's on the other end of it there, Amazon's product's APIs have been copied and a competitor uses Amazon's product name in the competitor's marketing.
Digital Ocean is not advertising that they're AWS S3, just that they're S3 compatible. Like a processor that's x86 compatible, even though it's not actually an Intel 386, 486, etc. Like when computers used to advertise they were IBM compatible even though they're not an IBM PC. Like when store brands of toothpaste say "comparable to Colgate FreshWhite" but they're obviously not Colgate. Like when a startup calls themselves "Uber for horse rental" even though they're obviously not Uber.
Any company bets on Amazon not being able to rewrite their software loses the bet. They even have their own CPUs because one of the CPU vendors failed to meet with their demands.
We launched A1 instances with our Arm-Based AWS Graviton Processors to increase the selection of technology for our customers. It has nothing to do with demands of vendors, and everything to do with increasing choice, providing access to extensive technology ecosystems like those Arm has been building with their partners, and lowering costs.
Do you have a citation for that? AGPL is usually not considered business friendly or a corporate "allowed by default" license, even for internal use.
Contrary to the headline and articles inference I havent seen any indication that MongoDB source or IP is or was actually being used. As you note this all comes down to API compatibility and tangled notions of "proprietary" slash copyright.
For some reason I had the mistaken belief that Amazon was offering a curated MongoDB-in-the-cloud service on their platform in the past - before the DocumentDB announcement and API compat. I think this was confusion with Redis.
But then there's even less reason to attack Amazon.
> Is it because of API compatibility? But the notion that one cannot reimplement a public API for the sake of compatibility is in and of itself extremely hostile to the F/OSS ecosystem, given how many products in it are reimplementations of proprietary APIs.
Completely agree with your conclusion, but is this not exactly what happened in Oracle v. Google?
Unless I missed something in the appeals, the result of Oracle v Google was that APIs are copyrightable, but that an implementation of that API for compatibility purposes is fair use.
So Oracle "owns" the Java API, but Google was allowed to clone that API to make Dvalik work with Java source code.
The same should be true of MongoDB's API. MongoDB Inc owns the copyright, but if someone wants to make a compatible API, they should be covered under fair use.
> Unless I missed something in the appeals, the result of Oracle v Google was that APIs are copyrightable, but that an implementation of that API for compatibility purposes is fair use.
The result (so far) of Oracle v. Google is that Googler use was not fair use as a matter of law; that, however, was the result of an interlocutory appeal to the CAFC, and we still have further action at the district court for a judgement, and probably at least one more appeal up the chain, potentially the whole way to the Supreme Court, before we know the final outcome.
An AWS team member mentioned to me on Twitter that the DocumentDB project at Amazon began more than two years ago. Mongo may or may not have known about it directly, but even if they didn’t, they had to expect it.
The difference between AGPLv3 and the new SSPL applies to all work Mongo releasaes going forward. As intended, that difference will make it difficult for AWS to maintain compatibility, which the article points out is limited from the get-go.
If they had released this a year or two ago we would have used it. We use Mongo... barely (as in the volume of data barely registers). That's a great example of something better off being handed to a hosting company.
Self hosting MongoDB has always been a pain if you only have a small amount of data in it. The scaling goes one host, master/slave (which existed, though people would argue with you that it didn't), to 7+ separate hosts if you're going to build it properly (2x mongoose with DNS across them, 3x config cluster, 3x data cluster).
That's a hell of a jump for someone only using Mongo incidentally. You can cheat and combine multiple pieces of the cluster on single hosts but if that fails you can then get into weird multi-component failure issues.
It might not have been cheaper to make their own version than to pay MongoDB, but it might still have been worth it to Amazon in that case for a variety of reasons.
My guess on these reasons is that Amazon wanted to integrate MongoDB with their own proprietary algorithms, storage, infrastructure, and/or other solutions they already created. In my experience, databases (even with different structures) use a lot of similar components like transactions, caching, I/O pages, concurrency etcetera. If they rewrite the whole project, they could potentially use many parts that they already used in different projects.
> Amazon stopped using it, and started using its own in-house implementation instead (presumably because it was cheaper to develop it than to pay MongoDB).
I suspect the drive for DocumentDB was more because customers were asking them for it
"So, MongoDB got exactly what they asked for. It's just that, when they forced Amazon to make a choice, they didn't expect one of the options they gave them to be viable. They were wrong."
You're just talking narrowly about Amazon in this comment. What you said makes more sense if you broaden it to commercial users. They might have known FAANG companies, esp Amazon, would just ditch their software if they switched licenses. They might be targeting the companies that can't or won't build a MongoDB knockoff. The companies that will actually pay for their product. That's a huge market.
The product that Mongo offers is not the DB itself, though, but support and cloud hosting (Atlas). In practice, most people really only care about the latter. Now that Amazon is offering a competing service that is compatible, cheaper, and (if we believe their claims) better, the question for those commercial users is whether they'll pay Mongo, or pay Amazon. How do you think that's going to work out?
Depends on how Mongo is run. People going for low-cost, big-company longevity, or ecosystem tie-ins will go for Amazon. People avoiding big companies' complex offerings or bullshit might prefer Mongo. Note the existence of Amazon, Google, and DO havent eliminated the hosting market: more stuff available at lower costs than ever. Mongo might similarily have a shot it they differentiate themselves positively from Amazon.
Yeah, I don't understand it either. There is a company which puts 300 M$ effort into developing something and then another company is using the first company's brand recognition to get a competitive edge while offering zero added value (And no, hosting mongodb in AWS not a new thing, only uninformed people would assume so. When I look around I find services like Scalegrid or MDB Atlas itself which is exactly the thing that AWS is claiming to justify their decision). So yeah, you are right, I can't see how could that be wrong either.
This is literally the future open source promised and people wanted: the freedom for a business to be flexible in regards to technology and not get tied into unpleasant vendor contracts and demands.
There's no point in, or place for, spirit of the system vs letter of the system discussions or calls to morality. Mongo does not deserve to survive / exist if it can't make it's offering better than a competitors.
Would Mongo even exist as a company if it had launched as a contract only vendor? Pretty much not... so it can't demand to play both sides.
> This is literally the future open source promised and people wanted: the freedom for a business to be flexible in regards to technology and not get tied into unpleasant vendor contracts and demands.
Oh the irony. Open source is just a development model, while Free Software, if anything, it meant to provide freedom to all users, not just business.
Reinforcing the public cloud oligopoly only reduces such freedom.
So now it's based on the caveat that only small business and solo devs should benefit from the good parts of open source and anyone with sufficient scale should have to pay because Foss based startups deserve to exist regardless of their business quality and that business of certain arbitrary scale should then apply morality to their involvement with Foss.
Well, write the licenses and let's see what traction they get. I'll wager that they will be shot down by pretty much everyone
I think I almost completely disagree with you. The product of MongoDB itself offered less than zero added value when it first launched through a lack of data integrity. The $300MM put into it was put into marketing. Mongo tried to squeeze Amazon and users, which is actually great. They are trying to walk the walk now, and what they're going to realize is that they can't. Amazon will out-execute them and hopefully put DocumentDB on stronger foundations than MongoDB's original creators ever could.
Judging on your other comments, it doesn't look like you're familiar with MongoDB's historical shoddiness. I don't agree with you on practice in this case or any case. If MongoDB's company can't out-execute, then they should have never made their product open source to begin with (and in that case it probably would never have gotten as popular as it did). That's the bargain you have to make to try and monetize open source software -- you don't just get a business for free.
But beyond that, I don't agree with you on principle in this case, because I have nothing but disdain and scorn for MongoDB. Both MySQL and Postgres have fine support for unstructured data now, and provide the entire relational toolchest as well. That's not even getting into other multi-paradigm databases like CockroachDB or ArangoDB. I struggle to think of a use case that it is more appropriate for than another option; and indeed, every time I have had to deal with it in production, I have never thought that it was anything but a poor decision.
> because I have nothing but disdain and scorn for MongoDB
That’s bit harsh. MongoDB has its uses. Denormalized data struture make it very easy to scale for example. Being able to use JS everywhere is nice too.
Morally it might be questionable, if it puts MongoDB out of business and reinforces the AWS "monopoly".
However, MongoDB selected a free and open source license. This was always in the cards. They went with AGPL to keep the source maximally open for end users, but that never protected their revenue stream. (Some JS SDK companies used it for that purpose, where it makes some sene, but a DB is very different.)
But if they had started with something proprietary uptake would have been very likely much less. And people would have continued to use mysql or Cassandra if they really needed something "webscale".
It's not OSI because it places even more restrictions on usage than AGPL did, but this is very much matter of context and interpretation. If GNU would have created it it would have been welcomed by GNU-ers a lot better.
I sort of agree with their sentiment, but of course they are late to the have-cake-will-have-it-and-eaten-it-too party, as now AWS was able to fork the last AGPL-ed version and be done with it.
I doubt AWS wants Mongo out of business or else who do they have to migrate into and all they will have left is yet another NoSQL now only used in AWS.
I think AWS already identified a lot of "DB tech locked" Mongo users who wanted AWS stamped mongo, or at least they now can undercut/compete-with Atlas.
Even if MongoDB goes out of business, or becomes less popular AWS benefits as they can keep selling to these "legacy" customers their super-stable AWSgoDB, and said customers will just eat it all up without thinking.
It certainly reads similar to the Aurora PostgreSQL technical specs, but I suspect they just have a generic Aurora layer, used by MySQL and PG both which can be used by a document database.
>However, developers are technically savvy enough to distinguish between the real thing and a poor imitation. MongoDB will continue to outperform any impersonations in the market
This feels like a MongoDB sponsored post. How badly would you have to fuck up to be considered a poor imitation of MongoDB?
In any case I don't see how having their own hosted version of MongoDB is a middle finger to open source, but Aurora SQL/PostgresQL isn't. Is Cockroach a middle finger Postgres? I don't consider this any more a middle finger than the SSPL.
> In any case I don't see how having their own hosted version of MongoDB is a middle finger to open source
Especially when MongoDB is itself no-longer open source.
In fact, AWS is providing a service compatible with MongoDB 3.6, which is open source. In a way, AWS "forked" MongoDB 3.6 after the creator of MongoDB made the software proprietary. Isn't that what Open Source is supposed to provide?
I left AWS after six years of working there wholly because of their restrictive policies about developing software in your spare time -- especially if you were thinking about working on a game.
I recognize this article is about a product offering of AWS, and not their internal policies towards contributing to open source, but the two are linked in my mind and I'm not all surprised to see a headline like this.
I just now started reading Merritt's Adventure in Prolog (1990), and the very beginning seems somehow relevant to this thread:
"I was working for an aerospace company in the early 1970s when someone got a copy of the original Adventure game and installed it on our mainframe computer. For the next month my lunch hours, evenings and weekends, as well as normal work hours, were consumed with fighting the fierce green dragon and escaping from the twisty little passages. Finally, with a few hints about the plover's egg and dynamite, I had proudly earned all the points in the game.
My elation turned to terror as I realized it was time for my performance review. My boss was a stern man, more comfortable with machines than people. He opened up a large computer printout containing a log of hours each
programmer spent on the mainframe computer. He said he noticed that recently I had been working evenings and weekends and that he admired that type of dedication in his employees. He gave me the maximum raise and told me to keep
up the good work."
I "accidentally" worked at amazon for a few weeks when a company I had just joined was acquired by them.
I knew it was time to start looking when I was informed that I had to get prior permission to do ANY open source contributions even on my own hardware on my own time. That's just not feasible logistically and above and beyond the general "don't write open source that competes with us or on our our time/hardware without permission" rule most reasonable companies have.
Problem is, you could potentially encroach on a big company's interests without knowing so, i.e. they're working in [insert space] in secret, or create an ethical issue for the company. Truth is, excepting maybe Netflix, the rest of FAANG requires you to get approvals.
That is entirely possible, but not at all a problem. If something is being done in secret, so that the employee doesn't know that the other division is working on it, then there are no trade secrets that would be divulged by working on something similar.
That companies require you to get approval to work on something on your own time is fundamentally absurd. If I were a carpenter, I would not need permission to make a table. If I wrote ads, I would not need permission to write a book. That we think it reasonable for open source contributions to require company approval show that there is a severe overstepping of bounds on the part of the company.
People outside a company will not believe that employees of the company keep secrets from each other, at least when it suits them to believe otherwise.
So like it or not, if it looks like there're a conflict of interest (even if there isn't), people will blame it on the company.
So I don't really think it's so bad that they want to know what you're working on, provided that approval is usually granted.
Asking for approval, even if that approval is typically granted, still implies that they have the authority to refuse permission. The farthest that the employer's moral authority extends is to ask politely to be informed. Not to require to be informed, and certainly not to require approval.
May be the permission should be flipped - the company has to ask the employee for approval to stop the opensource project.
It would work by having the employee list their projects, and the company will, when they find a conflict or some shared interest, ask for the employee to volunteer to stop their project. The employee can refuse, but typically won't.
> You're only required to get pre-approval in case of conflicts of interest.
Given the extremely diverse set of things that Microsoft works on, much of which is likely done without you being disclosed on it, how can you be sure that your project is not a conflict of interest?
Conflict of interest = something you are directly involved with at work, or potentially worked on for the company previously. For example, if you're on the SQL Server team then contributing to SQLLite would reasonably be considered a conflict of interest, but contributions to the Linux kernel wouldn't be.
This. I have it in my contracts or a rider if they don't like amending the contract itself. I write code, when I stop working for you for the day I still write code. Yes it's lucky that I can get paid to do the main thing I enjoy, but you aren't paying me for the stuff I do off the clock. I will let you know about any major pieces of software I write (not like twenty line Python scripts for managing my music) and if you detect a conflict that's the moment to object, if you do then I'll work on something else, otherwise I own it outright and that's fair.
Good employers don't want to abuse you, and in turn don't want to get abused, drawing a line is something they can understand and their lawyers can get their heads around. "This is mine, this is yours".
Right, but once the devs release something valuable into the wild, well, the cat is out of the bag. The implications can be seriously damaging to the company. It can be as severe as invalidating patents or infinging patents belonging to other companies. Can be evenvia a dependency. I can’t believe devs make those decisions without any supervision.
However, if that is the case, I’d love to know how so one can implement similar processes internally!
Every company that is based on california, or that employs you in california, is better.
No matter what the non-compete says, if you're in CA, you can use your own hardware and non-work time to develop anything that doesn't directly compete with your employer/dayjob and doesn't use trade secrets/IP from the company.
Amazon though is mostly based in Washington, where no such law exists, so sweeping non-competes are legal.
The above is the reason that there is a difference between various FAANG companies. Even if the company policy requires you to get approval, if it really isn't a work-related piece of code, you can simply tell them to pound sand and CA will have your back.
This is misleading. While non-competes are enforceable in Washington, employers can not force employees to sign away the rights to inventions produced on their own time without employer resources.
> No matter what the non-compete says, if you're in CA, you can use your own hardware and non-work time to develop anything that doesn't directly compete with your employer/dayjob and doesn't use trade secrets/IP from the company.
What if you work for a company that happens to have a stake in basically every field of technology?
This is one of two reasons why I work for a small company, and also why I left another small company when it was acquired by a large company -- CA 2870 only offers meaningful protection when your employer
isn't active in the relevant field of endeavor.
I don't want to compete with my employer, I just want to write some sound software on my own time and to maintain my ability to contribute in open source administration. It offends me that the state of the industry is such that I'm expected to sign away my soul on taking any software development job.
(The other main reason I won't work for a big is that I don't want to work 40 hours each week but the bigs won't budge on that.)
It may be reasonable for them to do this, but it may also be reasonable for individuals to decide the practice is not worth enduring for them to work at such a place.
VMware requires approvals even for own-time projects. They don't put up artificial barriers in my experience; there's a very simple process for declaring outside projects and approval is quick as long as it's not viewed as competitive. I thought their approach seemed reasonable for a big company with a large IP portfolio.
It was not always this way--VMware has become much more open source friendly over the last few years.
Not even open source - most googlers I know will not code anything even volunteer community projects outside of work because if they were involved google would claim it was theirs.
>Truth is, excepting maybe Netflix, the rest of FAANG requires you to get approvals.
Is this really true? In my company (not FAANG, but a big one), you need approval only if what you do in your spare time has overlap with the work you are doing in your job. What the rest of the company is doing is immaterial.
It's a big company, and I don't know how long ago your experience is or what your position was.
My experience, in my part of the company, in 2019, is that stuff I do outside "work" is my own business. I contribute to open source projects all over the place.
As long as I actually do my day job during the daytime, woe betide anyone (other than my wife and family) who tells me what I should be doing with my non-work hours, on unrelated software projects.
They even let me release my skunkworks Pidgin Linux client for Chime under LGPL (although I did have to ask permission for that one as I did a bunch of it during the day).
In fact even for work hours when I'm working on Linux, we've made progress. Once upon a time you had to file a ticket to legal for every patch series that was submitted upstream.
Now we have a policy (again, in our part of the company) that your internal code review submission must have a comment on the upstream status of your patch — is it already upstream, is it going upstream, and if not, WHY NOT?
And all you need in the way of permission to do so is to get the nod from myself or a number of other people right there in that code review.
Is it perfect?
No.
Do we still have to catch up and make it as easy for other projects (like Xen, in my day-to-day work) as it is for Linux?
Yes.
Is it a massive improvement on what it was like before?
Hell yes.
I've worked at Amazon since 2007 and I can confirm it has gotten a lot better over that time, especially more recently.
I have, in the deep deep past, experienced serious strife with the older policies, and obviously nothing is perfect, but it's gotten to the point where I don't really think about the policy.
Not just that, when I was there (2013-2014), you couldn’t even post a line of code on Stack Overflow or participate in any MOOC with coding assignments without prior approval. (The security folks couldn’t do any CTFs either.) I doubt any of their competitors have such extreme policies (except maybe Apple, who knows).
Apple allows for participating in CTFs, at least under the usual "in your own time, using your own hardware, representing yourself and not the company".
> I knew it was time to start looking when I was informed that I had to get prior permission to do ANY open source contributions even on my own hardware on my own time.
This attitude seems kinda common, unfortunately. The critical issue is probably what the boundaries for 'work for hire' are. CA law [1] offers protections. Spolsky [2] offers detailed real-world context.
It might not be enforceable but it would take a very brave or wealthy individual to choose to do something that might make Amazon decide to sick their lawyers on you.
Months in court to prove innocence is still a heavy cost to pay.
Not that I agree with Amazon's policy for no open source contributions, but imagine that an employee decides to spend the 6-8hrs out of the remaining 24hrs meant for sleep on something other than sleep, what do you think will happen? That employee's productivity during those critical 8hrs of the day that is being paid for by the employer would drop like a rock, because whether we like it or not, we need time to recharge our batteries.
That's... wow. Are you saying that the employers could (or even should) demand that employees do nothing else during their free time except rest, so that they are well rested for their on-the-clock time? No late night TV for you, no early morning pool swimming session, and don't even think about taking up that physically demanding hobby, because we need you 100% focused on the job!
- 8hrs for work;
- 8hrs for leisure (daily commute, family time, hobbies etc);
- 8hrs for sleep.
Once you take out work time & leisure time all you have left is sleep time. Sleep is unique because it is an exclusive human activity — it can’t be combined with other activities.
If someone decides to misallocate rest time, then s/he will become sleep deprived leading to low productivity. This is true regardless of whether you perform physically demanding work like farming or sit all day at a desk doing knowledge work.
A self-inflicted impairment like this is no different from abusing hard drugs or consuming too much alcohol (on or off the clock), but it is vastly different from low productivity resulting from falling ill, which is beyond any employee’s control.
Whether you like it or not, paid employment demands a certain monopoly of your time. The only way to opt out is to work for yourself.
In my view, contribution to open source falls under hobbies, so the time comes from the leisure time.
I agree that if someone takes that from sleep time instead, they're harming themselves, but this still is nothing the employer should (be allowed to) care about.
If the employee underperforms at work, the employee gets a warning, and it is up to the employee to review his or her time management, being a responsible adult that they are.
I think what the post above yours is trying to say is that the company I work for has no say what I do with my 8 hours of sleep time. If I want to only sleep for 4 hours but I come to work and get my job done, who cares? It is my time anyway and they aren't paying me to sleep so why should they have a say? If my work is suffering, sure, they have a right to fire me but if I get my work done in the 8 hours, they have no say over the other 16.
If someone is badly underperforming, then they can fire them. It's simply ridiculous for a company to own a second of your time outside work hours, excepting things like people on call, of course, but I count that under work hours.
Typically that sort of thing can't just be informed to you. There needs to be an agreement made, ie you get paid for the new circumstances. A former employer realized that continued employment doesn't count. Even in an at will state, both parties need to get something out of the change.
that kind of restriction is generally not enforceable in states like california unless you explicitly get some kind of consideration (e.g., compensation) for it.
since it’s above and beyond customary work duties, you’d expect extra compensation of some kind to have you refrain from projects unrelated to the job. there are some exceptions of course. security-related government workers could be subject to extra restrictions without extra compensation, for example.
If the approvals issue in all cases where the project clearly is unrelated to the employer's business, then what's the problem? To some degree review of external work is just the sort of thing a corporate legal department is going to push for, and it's not exactly unreasonable provided that approvals issue except where there is clearly a conflict.
I agree with you -- if there's a process and it's easy enough to get an approval, I (personally) have no problems.
However, Amazon's game development policy lays out 10ish different requirements you must meet, including not working with others outside of your org, must give up ownership of IP at Amazon's request, must use Amazon services or provide feedback why you couldn't. There's no process by which any of those items can be waived.
This basically means you can't do game jams with friends unless they work in your org. And if your game jam is successful, you run the risk of Amazon just taking ownership.
The problem is that you need permission. Whether the approval is usually given is irrelevant, what matters is whether they have the option to refuse.
Think about it like this: What would be the problem with the employment contract saying that salary can be decided by the company at will if they usually paid a certain acceptable sum every month?
I tried to distinguish "shall issue" from "may issue". A "you must let us know [so we can possibly refuse]" policy and a "you must ask permission [that will issue if there is no conflict]" policy are indistinguishable. A "you must ask permission and we reserve the right to say no no matter what" policy is terrible, and I'd not work under such a policy.
But the point is that it's not a question of probabilities, but of whether they are contractually obligated to issue approval unless specific conditions are met, so an implicit "[that will issue if there is no conflict]" is not acceptable IMO. There have to be specific rules for when they may refuse approval, so you can ask an independent judge to make a decision if you think the employer is partial in its decision.
Always judge a company by how they treat their lowest employees. And since people at Amazon having difficulties trying to find time to take a piss, it doesn't really qualify as an employer for me personally.
I like their services in AWS-land and they have really good solutions. They probably treat their developers better as long as they can be exploited. But if there is another service with comparable features, I generally don't have to think very long.
I worked there too in 2015. The culture is toxic. The most surprising thing was the way all the AWS services are built with a grab bag of different teams with entirely different languages, copying CSS and code all over the place. There were no real standards. I still like AWS but knowing how bad the sausage is made makes me cringe a bit...
How you treat employees isn't the same thing as salaries.
There are environments where people earning $20,000 are still treated with respect and there are environments where people earning $200,000 are treated badly.
Every job I've had, people have been polite and friendly to me. No bullying or harassment or anything like that.
But the low-paid jobs would carefully police our working hours and sick leave, while taking a toll on our bodies and demanding measurable daily performance. Whereas the highly-paid jobs would trust me to work my contract hours, take my word if I said I was sick, didn't expect me to lift anything heavier than a laptop, and barely audited how hard I was working at all.
If you think it's prima facie disrespectful to require a doctor's note for sick leave, my poorly paid jobs have been less respectful than my highly paid jobs.
I'm sure that you can argue oh, those people are actually working for a contractor, but let's agree for a moment that this is purely a matter of paperwork, those are Oracle cleaners, that guy is on the door of Oracle's HQ building.
Yeah, it's really weird. Amazon has other IP-producing divisions, and even though Amazon Studios is very powerful, there's nothing preventing people from making their own video content. I wonder if it's just down to whoever leads that game studio pushing for such a rule.
Have you got a source on that? Not questioning that it does sound like an EU thing, but it could come in handy at my current company if there's legislation on that and I can't seem to find any.
It is different country by country. In some countries if it wasn't done on a company equipment regarding your assignments the company cannot do anything about it and they cannot limit you to work on opensource/unpaid projects.
I worked for Amazon in the EU, and the rule was certainly in force. Whether or not it could be enforced is a different question, but none of us wanted to go up against Amazon's lawyers!
Amazon EU companies tend to follow blindly what is coming from the HQ. I personally experienced this. After warned the management about getting the ministry of employment involved they immediately backed down and let us implement something according to the EU law. It is the matter of knowing your position and the law.
I work at AWS. I have also been working on a game in my spare time. I don't know when you left but there are currently zero issues in these two things co-existing. Pretty standard requirements to make sure there's a clear separation of responsibilities and that you're not working on the game when you're meant to be at work, etc.
Every company has the same attitude in my experience, this ins't unique to Amazon.
edit: For those down voting instead of just disagreeing provide a company and their policy. All the companies I've worked at have been the same as Amazon more or less and all my friends have similar employment clauses.
Amazon reserved the right to take ownership of my project and all related IP at any time (including after leaving the company.) I was also forbidden from working with anyone outside of my org on the projects.
There were no exceptions allowed.
It was considerably more restrictive than any company I've worked at elsewhere.
I disagree. My research suggested that Amazon's policies about open source and game development were stricter. (For example, I must be willing to disclose any sales data to Amazon. I must use Amazon products when possible. I must make my project available on the Amazon store if possible.) Most companies also have a process to keep copyright if you need/want to.
Yes, most companies have approval processes. They might even be onerous approvals processes. Amazon expressly forbid me from participating in game jams with people who were not in my org.
>I disagree. My research suggested that Amazon's policies about open source and game development were stricter.
Worked at microsoft for 2 years, there are the same policies. It was not contractual though. It's just that there were notes broadcasted saying that whenever you discussed with third parties, you should use microsoft tools if possible.
Want to meet someone? Send a Bing Maps link, not Google Maps.
Want to share a research? Send a Bing Link, not a Google search. etc.
As for the confidentiality clauses, I work in finance, and the rules on IP and personal projects are the same as what you describe.
Microsoft have been very helpful to OpenStreetMap. Since 2010 they allow the OSM community to trace from the Bing aerial imagery to add things to OSM. Roads, buildings, everything you can see with the aerial imagery. It's fantastically useful. OpenStreetMap database would be a fraction of the size if it wasn't for Microsoft granting us this. As of July 2018, they allow us to use Streetside imagery too. (Alas you can't use the actual maps, just the aerial/satelite imagery)
The last 4 places I've been, three encouraged us to participate in FOSS. Only one was neutral, but disallowed paid side gigs (open source was ok). It's anecdata, but totally opposite of your experience.
Yeah. Amazon loses a small but significant number of potential hires when they learn about the open source clause - often very good people, too. When I left they were actively working on trying to find a solution, as it had been a thorn in the side for years.
California law expressly prohibits this exact policy. If you want to be able to work on open source (that is unrelated to your job, on your own equipment) on your own time, move to Silicon Valley.
Even Amazon employees in CA should be exempt from this policy.
...As long as what you work on does not overlap with anything your employer does.
...which is a big problem if you work at Amazon or Google. (Can you think of a single software project that will not intersect any Google project? Are you sure?)
I don't think that offers nearly the sort ironclad protection the GP is suggesting. The broad exemptions are part of the reason AoI agreements are universal in SV.
I refuse any contract where my employer claims ownership of code I wrote in my own time on my own machine that has nothing to do with the work I do for the company. Very few contracts have contained such a clause, and I believe at least one removed such a clause when I requested it.
These days I'm self-employed and renting myself out to large companies, and this has never been an issue. They only care about the work I do for them, not about what I do in private.
Most big tech companies that I'm familiar with allow you to program on your free time, as long as you give them a heads up and it doesn't conflict with the company's products. E.g. working on a video game or contributing to open source.
Please name one, they all have the same non-compete language in their job offers and they are at-will positions. It may be allowed by your manager but company policy isn't such.
Other companies have exemption policies, or mechanisms to get approvals. Amazon does not. Your choices were work privately on your own project or leave (or risk being fired for violating the policy.)
Amazon was more aggressive (in my opinion) and much stricter than any other company I've ever worked at.
Edit: I researched a lot of the other tech companies. Here's Google's documentation, for example, which outlines an exception process: https://opensource.google.com/docs/iarc/
Hopefully a more recent Googler will answer you. In 2013 they were granted often, so long as they didn't compete with a Google product. I had to close my photo sharing site off to new users when I started at Google.
From the movie "Revolution OS" [1], Richard Stallman explaining Copyleft:
"If we put the software in the public domain, somebody else would be able to make a little bit of changes and turn that into a proprietary software package, which means that
the users would be running our software, but they wouldn't have freedom to cooperate and share."
"And what we do is, we say, this software is copyrighted and we, the authors give you permission to redistribute copies, we give you permission to change, we give you permission to add to it. But when you redistribute it, it has to be under these terms, no more and no less. So that whoever gets it from you also gets the freedom to cooperate with other people, if he wants to. And then, in this way everywhere the software goes, the freedom goes, too. And it becomes an inalienable right to cooperate with other people and form a community."
Bruce Perens, on the choice of the GPL for Debian:
"Uh, it's one of the few software licenses that was written from the standpoint of the community rather than from the standpoint of um, protecting a company or um, as is the case with MIT and BSD license, performing the goals of a government grant program. Uh, and the GPL is really unique in that. It's not just a license. It's a whole philosophy that, I think, motivated the open source definition."
MongoDB tried to protect its company's profits, and as a result, Amazon [and its users] now have a proprietary product rather than an open source one. Could have gotten free fixes from the biggest lab in the world, but instead they're getting jack squat. And since Amazon's product is proprietary, now users and the community have less freedom.
Linus is asked at the end if he's bothered that he's not cashing out on billions of dollars of use, and he basically doesn't care. He just wanted people to work on the software. If Linux had the same licensing scheme, it may have remained a hobby operating system.
> Could have gotten free fixes from the biggest lab in the world
Wasn't this one of the main points of contention, though, in addition to not purchasing a commerical license? Amazon not upstreaming (m)any of the fixes?
I don't know, it's certainly possible. But at least there was the opportunity, as they have upstreamed fixes for other projects. And it's not like keeping the fixes private was hurting anyone (unless they're security fixes; I think modern licenses should require all security bugs at least be reported, in the absence of changesets)
10 million is nothing in the scope of the "billions of dollars of use" GP mentioned and is almost a rounding error compared to how much business depends on Linux these days.
WTF with this title. We all agree API shouldn't be licenseable, but now we expect companies to feel like they shouldn't use API for free because without licensing the source code "it looks bad"?
What does this even have to do with Open Source? MongoDB isn't Open Source; not any more. Their new Server Side Public License is not an OSI-approved Open Source license, and the intent of the license change goes directly against the 6th criteria of the Open Source Definition ("No Discrimination Against Fields of Endeavor").
I keep seeing this sentence (or variations thereof) on every thread about this topic.
It sounds weird to me that people think a foundation created by Perens and Raymond (et al.), the people who defined Open Source, and wrote the Open Source Definition is not the defining authority on what open source is.
I think the idea there is that one body shouldn't have a proprietary lock on what counts as Open Source and what doesn't. OSI/OSD as the loudest voices of what is OSS, is helpful, but they shouldn't be the only voices.
(As much as I get annoyed by things claiming to be open source, that really aren't proper open source, I have to accept that this is a movement brought about by a rag-tag bunch of hackers who don't much care for single entities telling them what to do, so they should also be measured by that)
It was a movement brought by an organized group of professionals who thought that the viral nature of the GPL kept business from taking advantage of the new commons. They created an organization to monitor use of the new term "Open Source," which would be a superset of the GPL, without the onerous-to-business requirement of sharing your changes.
> “However, developers are technically savvy enough to distinguish between the real thing and a poor imitation. MongoDB will continue to outperform any impersonations in the market.”
That's a bold statement to make against AWS services.
It's new enough to be a second tier AWS service (they tend to have odd performance issues or less than ideal pricing models). My understanding is that they also block off portions of the management API that you'd typically use to maintain your own cluster and that they've had some reliability problems.
A lot of people are focusing on the bitchiness, but to me this is actually interesting from the perspective of (F)OSS evolution.
This scenario is one of the many where (F)OSS explicitly protects downstream users: company reduces availability, user forks. It just so happens that the traditional players (the small, indie user va the big, bad corp) are actually mirrored (big, bad user vs small, indie corp). This has been the ugly reality of OSS for more than a decade now, and there seems to be no way to align the interests of “big users” more closely with upstream. Before the switch last year, MongoDB already used the most “aggressively collectivist” license available, and still it didn’t protect them from rich freeloaders.
This is also the other side of the coin in the Google vs Oracle debate about apis and copyright.
Because they have money and don't use it to support the community. Nobody is saying it explicitly, but of course we want small indie people to be able to use stuff for free while rich corporations foot the bill. But it's hard to codify that in a way that doesn't explicitly so, and it's hard to enforce a rule where something is free only if you're small or poor, but it costs money if you're big and rich. And to see the largest corporation in the world use Open Source stuff for free without sharing anything back to the community, well, that doesn't sit right with a lot of people.
It's not at all hard to have a license where something is free for noncommercial or limited commercial usage, and premium otherwise. This is an extremely typical model for many products today whose licenses you could use as inspiration. See for instance things like Microsoft's Visual Studio. And the nice thing is that contract law is really quite powerful and very much on your side when it comes to enforcement. You don't need Microsoft's legal department to enforce your rights.
In my opinion I feel like the real issue is that many in the open source community want to have their cake and eat it to. They want to put ideas out there ostensibly for free and be part of the social communal movement, but when those ideas are actually used to generate value - they want to see the checks roll in. That's just not how it works. Look at products that are funded by donations. There are some exceptions, but the general rule is that they end up grossly underfunded and have to be more and more aggressive with requests for donations just to stay afloat. If people want payment, then demand payment. If you want to give away something for free, don't ever expect to get paid for it.
It's not unreasonable to wish for a middle ground where small actors don't have to pay and big actors do.
> a license where something is free for noncommercial or limited commercial usage, and premium otherwise.
That's basically what Mongo have switched to. Unfortunately, this broke other bits of community, because playing with licenses is actually not that easy.
My point is that, maybe, we need a new license that can reflect the changed times. GPL 3 wanted to be that license, but it doesn't look like it succeeded. The new licenses attempted piecemeal by this or that company (like Mongo) will always fail to cut it, because the are typically not written by people with significant experience and knowledge in this particular field (license-writing).
Maybe it's time for interested companies and expert stakeholders (FSF etc) to come together and try to agree on something that could move us all forward.
Just to be clear, the FSF does not agree with your distinction. The FSF only endorses free software, which means free for all users, commercial or noncommercial ( https://www.gnu.org/philosophy/categories.en.html ):
>Proprietary software is another name for nonfree software. In the past we subdivided nonfree software into “semifree software”, which could be modified and redistributed noncommercially, and “proprietary software”, which could not be. But we have dropped that distinction and now use “proprietary software” as synonymous with nonfree software.
>The Free Software Foundation follows the rule that we cannot install any proprietary program on our computers except temporarily for the specific purpose of writing a free replacement for that very program. Aside from that, we feel there is no possible excuse for installing a proprietary program.
The FSF doesn't have a monopoly on the sentiment of open-source communities. Their principles were developed in a very different scenario, which is the point of my comment.
> Maybe it's time for interested companies and expert stakeholders (FSF etc)
That the FSF likely would have no interest in participating in such an activity since it would betray their core principles (regardless of whether you or i feel that this principle is sound)
> Maybe it's time for interested companies and expert stakeholders (FSF etc) to come together and try to agree on something that could move us all forward.
Expecting the FSF and RMS in particular to negotiate away the core freedoms (just so that businesses can make profits, no less!) strikes me as the height of futility.
You forgot "and don't use it to support the community". It's not compensation, it's help for the community that made the profit possible, so that it can grow further.
There is the law, and there is the spirit of the law. When the law fails to produce the outcomes it was designed for, there is a problem.
Exactly. Things would look a lot different if Amazon was an active contributor of improvements to MongoDB. Plenty of companies are actively involved in the open source projects they use. It often makes a lot of business sense too: it helps the project develop in the direction they need, and by sharing their changes in that direction, they ensure that there's a community that supports the features they need, and from which they can hire experienced developers if they need to.
It makes a lot of sense, especially for smaller companies. But Amazon in this case doesn't use MongoDB for something they need, they just want to make it available to their customers. They have no opinion on what their customers need from MongoDB, so they're happy to just tag along for free.
Freeloader on open source software is someone who runs profit by selling it to a major market without contributing back to the project.
Why? Because the freeloader increases the demand side for the software (more users translate to more feature requests, more bug reports), without increasing the supply side (resources for people who work it).
This puts pressure onto the project that is hard to sustain in the long term and MongoDB took a step to fight it.
It is different in this day and age, though, with respect to the time when the FOSS philosophy was born.
The difference is that now a lot of software is run as a service, which wasn't the case back than.
So, imagine MongoDB was used some 20 years ago (and it was GPL, as AGPL wouldn't make as much sense back then). A big company comes along, makes some modifications to the base product and tries to sell it. Guess what? They have to give the source code (including their additions) to whoever buys their version (including, potentially, Mongo inc.) so they would still be on a somewhat level playing field.
Enter software as a service. Since the GPL says nothing about software served via network, MongoDB goes under AGPL, which has provisions for this scenario. Amazon is not selling software copies, they're selling a service (hosting, integration, etc). So, even if they make additions to the source code and give them back upstream, they're on a completely different level from the small player (Mongo inc. or whoever else) and, since they're not differentiating on the code alone, win in the long run.
This all to say, it's not the promise/premise of FOSS that is flawed, it's just that the playing field changed.
mongodb announced the Server Side Public License change less than 12 weeks ago. When you account for end of year and holidays, building a new product line and rolling it out in such a short period of time seems unlikely. I would guess this has been in the works for a while (although admittedly I could be overestimating engineering effort and underestimating amazon engineering talent).
MongoDB could have been having conversations with Amazon prior, trying to negotiate a licensing agreement. These negotiations take a lot of time at corporations, I could easily see someone saying "hey, MongoDB's starting to squeeze us, let's get some people working on Plan B before they cut us off".
Reverse engineering the MongoDB API, getting it to work on Aurora storage engine, verifying existing CLI/drivers work and having it all scaleable and supportable.
At least a few months work there. Even for Amazon.
Difficult to know for sure, but it's probable that MongoDB made Amazon aware that they would introduce such a licensing change, in a bid to put pressure on AWS and get them to contract with MongoDB.
You're absolutely right. AWS is not known to move that fast (though they are known to move faster if they think the competition is outpacing them).
This undoubtedly had been in the works as Aurora for MongoDB.
The timing is suspect, sure. But one look at Aurora for MySQL and Aurora for PostgreSQL will tell you that AWS would've gotten around to it regardless of licensing.
I was told on Twitter that the DocumentDB project is over two years old at Amazon. Mongo 3.6, the version whose API they claim to clone, came out about 15 months ago.
"When the terms you offer are accepted, hold to them. Else no one will trust you."
For someone to release a major software package under an open source license with particular terms, and then to get angry when other people enjoy that software under the terms that YOU specified, is just nonsense. You aren't happy with the way things played out, because you didn't really understand the types of activities that were possible or maybe just didn't think about it.
Look, it's their software and they can re-license it as they see fit. But to vilify AWS for using their open source software legitimately under the terms they licensed it under is offensive. That is giving the middle finger to open source.
How exactly the author of this article can write something that finds fault in the company using software legitimately under an open source license, and not with the company who is re-licensing their software to a non-OSI license? Who is truly giving the middle finger to open source?
The most important issue to me is that Amazon benefits from open source not only without supporting it, but by threatening it. While we can argue whether it is MongoDb or not and other issues, it is clear that Amazon benefits. Otherwise why not simply invent their own API? They have the benefit of a well thought out system, of a large pool of people who know and can use MongoDB. Can they afford to support MongoDB? If not perhaps they should just 'fess up.
The open source system is great. Many individuals create the content and share it. There has been a great tolerance for companies like Amazon that exploit - not use but exploit - this community. While I don't have enough experience to know if MongoDB's response was a good one, I do think it is time for the community at large to begin a continuing discussion of what to do when large companies like Amazon are bad citizens.
Open source thrives on being ... well open, and it is important to retain that openness within the community.
Bezos gives everyone the middle finger. Doesn't matter if you're part of the massive open source stack they profit from or one of their workers unfairly paid trying to meet unfair workload demands or one of the 100s of countries, states and cities they relentlessly conspire to steal taxes from.
What's really funny about their not-mongodb as a service is they will inevitably roll over any piece of software third parties host on AWS too if they think it makes enough money. Your SaaS is just another project for some team waiting on their next. They have already done that for 10,000s of physical products on Amazon.com that were sold by third party vendors who became redundant via Amazon releasing similar products under their own brands.
>is they will inevitably roll over any piece of software
Can you please clarify? I'm researching AWS and am interested in the historical practices of the company, but I'm not sure what "roll over" means in the context you used it.
I mean they will inevitably go through the websites people are hosting on AWS looking for profitable software to copy, because that's what Amazon has always done to people making money on Amazon.
This is a funny joke, but a really dumb thing to say seriously. It all depends on your use case and knowing the tool. Mongo is far and away the best choice of DB for an internal app I’ve been building, but managing it is a pain and I’ve been unhappy about the direction the company has been headed. So I’m thrilled that AWS is going to take the burden away from me entirely with this new service, which I would have happily paid MongoDB for instead on the same usage-rated terms. Oh well.
The fact that some are okay with and would use an unreliable tool is not inconsistent with the fact that it is documented that the tool is unreliable. Popularity among users has little to do with the tool being reliable, and this particular one is already popular for being unreliable.
What you are saying doesn't really make any sense.
A systemically unreliable database would never be popular as its not a piece of your architecture that you can tolerate having constant outages with. And there is no evidence of MongoDB being systemically unreliable.
> A systemically unreliable database would never be popular
1. Correctness and popularity are different
2. Not everyone looks for correctness, even when looking for a database. See: MySQL.
> as its not a piece of your architecture that you can tolerate having constant outages with
Reliability and correctness are not binary scales of 'works' vs. 'does not work'. Again, see MySQL.
> there is no evidence of MongoDB being systemically unreliable
There is plenty of evidence of MongoDB losing writes because of its (honestly) stupid design: writing to memory maps instead of files, never fsyncing, sharding and distributing without confirming disk flush.
---
MySQL: For a long time, one needed to be aware of certain caveats and corners and limitations of MySQL or be surprised with data inconsistency and loss. That is not to say that MySQL could not be operated reliably; it could, just that the barrier was higher than it appeared.
From truncating data (with a warning) to not accepting and silently (i.e., without warnings) ignoring CHECK constraints, I've had clients who lost business data and realized it only too late to go back to the original data source.
I used to think MySQL was an bad database due to its concessions of correctness and poor documentation, until MongoDB came along with their lofty marketing and high-and-mighty "Nobody needs SQL anymore, we are Web-scale" blare-horn and failed to deliver on even keeping the data it claimed to have saved.
A reckless enough design (e.g., returning success when a request is merely buffered at the client) can lose writes without telling you that it lost writes, which won't affect its popularity among users who don't audit for that.
This is a fair question, I would advise not listening to anybody who says they have a "one size solution" for all data.
For searchable structured data, I'd probably go with elasticsearch. It scales very well and you can turn off indexing and use it as a document store.
I am a huge fan of postgresql and the more I use it the more awesome I find it, so I'd probably use postgresql's JSONB column type for unstructured data if that's a requirement. You can pair it with citus and make it scale quite well.
For pure document storing there's RethinkDB which performs well and does not lose your data as MongoDB does.
> "To be fair, AWS has become more active in open source lately"
What are they referring to?
From my perspective, Amazon rarely open sources their work. It's one of the reasons I would never want to work at Amazon. It's very clear they have no love for technology outside of making a business out of it.
More like Mongo gave AWS the finger, then AWS said fine and started using Postgres. Now Mongo is upset that they have an inferior product that is losing market share because they killed of their potentially laregest cloud deployment.
The headline is as misleading and wrong as it could be.
AWS is not giving open source the middle finger. It is giving the middle finger to a project that was once open source and has decided to be no longer open source.
We are in the middle of a transformation and its clear open source will have to change. There is little stopping cloud providers and other well funded parties monetizing your projects leaving little room for you to.
Because they don't have to focus on development they can divert their resources to marketing, adding the syrup on top to 'ease use' and ride the hype wave while the original developers are dismissed as 'technical' folks who do not understand marketing when the fact is they do not have time left over from development, or the resources.
It's perfectly legitimate to expect to sustain yourself while building open source products and projects. Unfortunately we are flooded with one sided superficial perspectives and short term narratives that look at open source projects as if its a crime to expect to make some money while not even examining slightly the parasitic models of cloud providers and others who in effect hijack open source projects with marketing.
The end game is few can compete with the resources, reach and engineering of behemoths like AWS, Azure, GCP and others. And at the customer end the cloud is unavoidable and thus will only see increased adoption. This is not only going to affect open source but dismantle entire groups of software and hardware ecosystems.
The only way forward seems open source projects that leverage these cloud platforms to provide some additional functionality, but these projects will be intimately tied to these platforms and not 'open' as we understand the term.
> It's perfectly legitimate to expect to sustain yourself while building open source products and projects.
I’m not convinced that should be the case. Any business endeavor carries risk, whether its basis is open source software, closed-source software, or any other product type, and one shouldn’t have an expectation of any level of success.
There are fortunately many success stories relating to open source software, so from my perspective it’s unclear that anything needs to change.
> However, developers are technically savvy enough to distinguish between the real thing and a poor imitation. MongoDB will continue to outperform any impersonations in the market.
snerk Well, if it doesn't lose your data or have broken replication protocols for years, then it'd be a poor imitation, so I'll give the CEO that one.
They changed the licensing basically forcing Amazon to pay or stop using Mongo or build something else. But at an AWS level that's a lot of money apparently, so they stopped using it.
Flamebait. Replace “open source” with “MongoDB” (the company, not the code) then the title makes much more sense, and the article is kind of a nothingburger.
A major part of the success of open source has been the fact that companies have the option to fork/tweak/sell the code. MongoDB has benefited from this as much as anyone. They gained the adoption levels they have now by advertising these exact benefits. Only later did they decide you need a commercial license to provide it as a service. How many companies would have thought twice about using MongoDB had they thought they would eventually have to pay for it and/or couldn't monetize it themselves?
You don't need a commercial license to provide SSPL code itself as a hosted service if you release the service-rigging code you use to do so.
As for the most typical use case, web apps, see their FAQ:
> The copyleft condition of Section 13 of the SSPL applies only when you are offering the functionality of MongoDB, or modified versions of MongoDB, to third parties as a service. There is no copyleft condition for other SaaS applications that use MongoDB as a database.
Compare their prior, public clarification on the scope of AGPLv3:
> Note however that it is NOT required that applications using mongo be published. The copyleft applies only to the mongod and mongos database programs. This is why Mongo DB drivers are all licensed under an Apache license. You application, even though it talks to the database, is a separate program and “work”.
Much as Kernel developers published a statement clarifying and limiting the sweep of GPLv2 copyleft, Mongo published a statement clarifying and limiting the sweep of AGPLv3 copyleft.
I've heard from a former Mongo employee that Mongo wrote several letters to users and vendors, assuring them that AGPLv3 didn't require release of their app code.
Is there a license category that says something like: "Anyone can use our tech to build stuff with for free however you may not re-sell our tech wrapped in maintenance or hosting services"?
If you're a small open source company with a services business model, how do you stop someone like AWS forking your code, making a few changes they don't share with you and basically becoming the de-facto supplier of maintenance and services for your tech?
> Is there a license category that says something like: "Anyone can use our tech to build stuff with for free however you may not re-sell our tech wrapped in maintenance or hosting services"?
Yes, there is. It's what MongoDB did. It's not Open Source.
> If you're a small open source company with a services business model, how do you stop someone like AWS forking your code, making a few changes they don't share with you and basically becoming the de-facto supplier of maintenance and services for your tech?
You have a business model that does not work. You've been lying to your investors claiming that you have one. That's exactly the MongoDB story.
That’s incorrect. MongoDB’s Server Side Public License differs from Commons Clause and some of the “community” licenses from other database companies we’ve seen. The latter prohibit hosting programs as a service for others. SSPL explicitly permits that, but triggers copyleft, so the service rigging code must be released under the same terms.
It's not just Open Source who will get nasty signs from amazon. They already have too much power for one company and the more power they'll have the less they have to abide by rules normal companies/humans have to abide by.
Yeah, overall this seems like a bad move by Amazon on multiple fronts. The name of the new service is DocumentDB, which by itself is a name they have recycled from competitors...
MongoDB has a terrible reputation when it comes to scalability and support. If you search you can find a bunch of horror stories.
I don't have any angle to condemn or support this move, but it definitely seems like a response to what AWS customers and the market were asking for: "Give us a managed MongoDB or MongoDB-like service that doesn't suck"
I find a bunch of horror stories about DynamoDB and PostgreSQL too. Your point is? How is that even related to the fact that AWS is basically piggybacking on MongoDB-s R&D effort and brand recognition?
Also it's clear that you have zero knowledge about Mongodb hosted services. Because otherwise you would know that very good supported hosted services exist which are 100% compatible with AWS (beside MDB Atlas).
You found it disgusting that a software vendor decided to implement features in order to match competitors in the space? That's... how product development works.
MongoDB found that objectionable, and changed the license such that Amazon would either have to pay, or stop using it.
Amazon stopped using it, and started using its own in-house implementation instead (presumably because it was cheaper to develop it than to pay MongoDB).
So, MongoDB got exactly what they asked for. It's just that, when they forced Amazon to make a choice, they didn't expect one of the options they gave them to be viable. They were wrong.
I don't see how Amazon is in the wrong here. They are no longer using MongoDB for free, as the authors demanded. They did not reuse any code. They are not advertising their replacement as MongoDB, either.
Is it because of API compatibility? But the notion that one cannot reimplement a public API for the sake of compatibility is in and of itself extremely hostile to the F/OSS ecosystem, given how many products in it are reimplementations of proprietary APIs.