by willlll on 10/25/18, 2:24 PM with 239 comments
by mindcrime on 10/25/18, 3:42 PM
This bit in particular really hits the nail on the head:
Let's assume that it is ok somehow to pass forward other open source software, solving that problem. What about my continuous integration software (e.g. CircleCI), or my business backup software (e.g. Jungle Disk) or my code hosting service (e.g. Github)? There is no logical bound to this license. Taken on its face, I would theoretically be bound to release the internal source code of services from third parties that I included in or relied upon to deliver my service.
Copyleft is one thing, but this is so invasive and byzantine that it beggars belief that anybody actually thought this license made sense.
by gtycomb on 10/25/18, 4:18 PM
The issue is not about having to buy a license here. The problem is the uncertainty with a product whose license agreement is being switched over mid-stream. It makes me weary of what else might happen with their license structure further down the road.
by kstrauser on 10/25/18, 3:21 PM
by asien on 10/25/18, 4:40 PM
RoboMongo,MongoGUI etc... they all received a legal notice to remove the name mongo from their product.
This was probably one of the most evil thing have seen in the open source industry .
Most of those vendors were open source with paid premium features or donation.
After receiving their legal notice most of those vendors deprecated or sold their project to a company feeling betrayed by Mongo.
As a result Mongo Compass became the de facto GUI for MongoDB and is advertise as sold with MongoDB Enterprise.
by ianamartin on 10/25/18, 4:43 PM
Of course their sales people are saying "No. We won't use it that way." Sales people gonna sell.
I'm sure the people currently running MongoDB would not do that. What happens when they get acquired by, say, Oracle? Or some other company that absolutely would do that?
The bottom line that you have to assume from a legal point of view is that any part of an agreement that can be abused, will be abused. This not only can be and will be, but it will be really easy.
If they are doing this to prevent people from competing with their own service--which they absolutely are--then they need to rewrite it and make that explicit. This is way too squishy for anyone with an ounce of brains to use in a commercial product.
by PeterZaitsev on 10/25/18, 4:09 PM
According to our poll many users will seek alternatives for MongoDB because of the license change
https://www.percona.com/blog/2018/10/24/poll-mongodb-license...
MongoDB probably feels they have reached critical mass so it does not matter any more...
by princekolt on 10/25/18, 4:27 PM
The issue here is that SaaS providers are building tools on top of MongoDB that effectively add functionality, instead of modifying MongoDB (which would force them to share those changes publicly).
This is a valid concern and I understand the motivation behind the license change. However, how is this different from any other FOSS?
Just as a random example, think of a proprietary blog/site provider like Tumblr and Weebly. They are effectively a SaaS provider that introduces tools on top of open-source web servers (like nginx or apache) to make hosting a website much easier. Instead of building the entire model/code of your website, you simply add customizations using a frontend.
Maybe the comparison is not ideal, but my understanding is that all FOSS suffers from this concern, and the industry seems to be doing well enough.
by Illniyar on 10/25/18, 4:57 PM
But even if they are right, this doesn't seem smart, it feels like a knee jerk reaction. I imagine that they hope that by doing this they'll cause people who are using mongo on other providers to move to mongolabs, since there is 0 chance of these providers open sourcing their infra.
But that's not whats going to happen, either cloud providers will remain with old versions and people will gradually move to different dbs or they'll just fork it, they certainly have the manpower for it, this will give them incentive.
Frankly though I think this is well within the agpl, cloud providers aren't modifying the code they are building things around it.
by nicole_express on 10/25/18, 3:56 PM
This isn't me trying to argue against the article; I'm trying to understand the law as it applies to my profession.
by jiveturkey on 10/25/18, 9:01 PM
And the recent stink on HN where OSI claimed MongoDB was not Open Source because the license had not yet been reviewed, with many claiming (correctly) that OSI is not the determiner of what is open source, appears to have been out of order.
I think there was a base assumption that the license would in fact be fine, and OSI claiming it wasn't because they hadn't stamped it ... yet ... was overreaching.
Anyway my understanding is that the single largest user (and commercial licensee) of MongoDB hates it and can't wait to get away from it. With that in mind, this licensing nonsense smells like a desperate grab. Maybe it's time to short $MDB?
by amyjess on 10/25/18, 4:00 PM
by trasz on 10/25/18, 3:37 PM
by jkaplowitz on 10/25/18, 9:29 PM
Am I missing something or is the author? Also, what stance has the 2nd Circuit taken on copyright misuse, if any?
by vitalus on 10/25/18, 3:56 PM
Is there an example of such a license?
Could this type of license even be created in an enforceable way?
by benatkin on 10/25/18, 6:11 PM
by finchisko on 10/25/18, 4:29 PM
by tptacek on 10/25/18, 4:13 PM
by polynomial on 10/25/18, 4:57 PM
by manigandham on 10/25/18, 10:00 PM
by matt4077 on 10/26/18, 2:06 AM
It's clear that there's a gap in existing licences that some regard as unfair. It also seems plausible that many projects could have dramatically better resources if the companies they are attached to could find a way to capture a fraction of their product's worth to their largest users. Just offering service with their competitive advantage being only the result of name recognition seems to work only for a very select group of huge projects. And even there, the likes of Canonical or SUSE show how hard it is.
Yet it is obviously challenging to write a license that adequately captures these facts. I think everyone would have something to gain from finding a way to make these situations work.
A required part of that solution may be for the community to interpret licenses not with the current they-are-trying-to-screw-us mindset but with, say, the "reasonable person" standard often used by the courts in contract/license disputes.
That's not going to be easy, considering "expect the worst and don't risk anything" always looks like sound advice, given that you will never know what you missed on the path not taken.
But the GPL's success should be inspiring here: it was initially met with scepticism, especially among corporate lawyers. Their essential pessimism never changed (it's how they became corporate lawyers in the firs place). But as it happened, it was enough for just few to take the risk, and subsequently creating precedents in court affirming the GPL, that made the concept cross the chasm to being palatable even to initial sceptics. Once courts fill in the questions of interpretation currently clouding these (necessarily somewhat abstract) licence, some doubts may dissipate.
by bigiain on 10/25/18, 11:14 PM
(VCs please form an orderly queue. Priority given to investors willing to pay in Bitcoin or Monero. Contact deets in profile...)
by GiorgioG on 10/25/18, 3:22 PM
by golubbe on 10/25/18, 9:15 PM
by Latteland on 10/25/18, 3:57 PM
by ianamartin on 10/25/18, 4:16 PM
by luddy on 10/26/18, 8:04 PM
by mr_toad on 10/25/18, 10:24 PM
‘Your honour, my argument is that I was copying this copyrighted software, for profit, without any legal license to do so. Oh wait...’
by metheus on 10/25/18, 5:38 PM
https://news.ycombinator.com/item?id=18229452 https://news.ycombinator.com/item?id=18229013
To reiterate those comments, the SSPL only affects people who are offering the licensed software to the public as a service. This does not include any software that uses MongoDB as a component, even if it's a commercial SaaS offering itself. The FAQ we put out here makes that clear: https://www.mongodb.com/licensing/server-side-public-license.... 99.999% of MongoDB users are not affected by this license change.
People have expressed concerns that the 1) the FAQ is not the license, and 2) the language of the license does not make the intended responsibility clear enough. But it was drafted with that intention (and reviewed by outside counsel, with an eye towards being explicit without giving bad actors loopholes to exploit). Nonetheless, addressing those concerns is extremely important to us. This exact issue is being discussed on the OSI license approval mailing list, and we are considering very seriously all of the feedback.
The article anchoring this thread contains a lengthy discussion of copyright misuse and of impracticability. Those are also the subjects of discussion on the OSI mailing list, where Heather Meeker, writing on MongoDB's behalf, refutes claims that are similar to those made in the article. In particular, the SSPL is not trying to make people release substrate infrastructure, or adjacent tooling, under the SSPL. Consider the last line of section 13: "...all such that a user could run an instance of the service using the Service Source Code you make available." This means that as long as the Service Source Code you release is enough for anyone to run the service, you've fulfilled your obligation. As an example, you would not have to somehow be able to offer CircleCI under the SSPL (an impossibility), as long as your tooling that orchestrates its use is public, because anyone can use CircleCI.
It's our hope that these discussions will lead to an accepted understanding of the actual obligations of the SSPL. The only people we want to be in any way affected by it are those who are literally offering the licensed software as a service, and we want those people to release their management stack under the SSPL. Thanks for helping us with that.
by pitaj on 10/25/18, 5:49 PM
by appleflaxen on 10/25/18, 3:24 PM
My understanding of the license change is basically "if you use MongoDB to support any site, all software higher in the stack needs to be released as well".
Is that accurate?
If so, why can't an author make this part of the license?
by jason46 on 10/25/18, 3:47 PM
by akvadrako on 10/25/18, 3:41 PM
by tlrobinson on 10/25/18, 3:42 PM
I’m not a lawyer, but I wouldn’t expect that to be a valid defense. If you can’t comply, don’t use it.
by ilikechairs on 10/25/18, 3:36 PM