MongoDB Now Released Under the Server Side Public License – MongoDB(mongodb.com)
mongodb.com
MongoDB Now Released Under the Server Side Public License – MongoDB
https://www.mongodb.com/blog/post/mongodb-now-released-under-the-server-side-public-license
11 comments
If anyone senses echoes to the recent Redis license related news, consider that only applied to specific plugins/extensions to Redis (whose core remains BSD), whereas this relicensing applies to all forthcoming versions of MongoDB's core open source/community variant.
If this really gets OSI approved then OSI will practically redefine what OSS is. I doubt that anything that has limits in its usage and not just redistribution rules of modifications will have any chance to get OSI approved.
EDIT: here I better explained my POV -> https://twitter.com/antirez/status/1052201491325284352
EDIT: here I better explained my POV -> https://twitter.com/antirez/status/1052201491325284352
From the OSI FAQ:
https://opensource.org/faq#restrict
-----
Can I restrict how people use an Open Source licensed program?
It is strange to me that Mongo would even couch such a change in its "open source-ness" when the FAQ from OSI specifically calls out what they have done as something that should _not_ be done.
https://opensource.org/faq#restrict
-----
Can I restrict how people use an Open Source licensed program?
No. The freedom to use the program for any purpose is
part of the Open Source Definition. Open source licenses
do not discriminate against fields of endeavor. It is strange to me that Mongo would even couch such a change in its "open source-ness" when the FAQ from OSI specifically calls out what they have done as something that should _not_ be done.
Disclosure: I work for MongoDB.
I suspect some people are responding to what they've heard, so I just want to post section 13 of the SSPL here for everyone's convenience. This section is the only part of the SSPL that isn't exactly the GPL:
> 13. Offering the Program as a Service.
> If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Software or modified version.
> “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.
Regardless of how you feel about the purpose of the SSPL, it absolutely does not apply any restrictions to using the licensed software. What it does is codify the responsibilities of someone who runs the software as a service.
I suspect some people are responding to what they've heard, so I just want to post section 13 of the SSPL here for everyone's convenience. This section is the only part of the SSPL that isn't exactly the GPL:
> 13. Offering the Program as a Service.
> If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Software or modified version.
> “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.
Regardless of how you feel about the purpose of the SSPL, it absolutely does not apply any restrictions to using the licensed software. What it does is codify the responsibilities of someone who runs the software as a service.
Let's assume I'm running a commercially-available web application. I'm not reselling mongo as a service, but I'm using mongo in my stack. My web application arguably "... primarily derives from the value of the Program ..." because it is really just a mongoose crud layer on top of your mongo that serves up a dating service for ferrets or whatever. My dating site derives a lot of value from the mongo data layer.
I understand and empathize with the problems of creating and monetizing OSS in a SaaS world, but ultimately, I'm not confident one can write a license that focus-targets SaaS vendors without potentially exposing just plain mongo users to the same litigation.
I mean, the intent here is to make the mongo company more profitable, right? Like: we want to get our cut from SaaS vendors who are selling mongo. So when that dries up, who is to say you won't go after self-hosters as well? This whole thing is super-scary to small shops who don't want to find themselves on the hook for a commercial hosting license.
It just doesn't feel like open source anymore.
I understand and empathize with the problems of creating and monetizing OSS in a SaaS world, but ultimately, I'm not confident one can write a license that focus-targets SaaS vendors without potentially exposing just plain mongo users to the same litigation.
I mean, the intent here is to make the mongo company more profitable, right? Like: we want to get our cut from SaaS vendors who are selling mongo. So when that dries up, who is to say you won't go after self-hosters as well? This whole thing is super-scary to small shops who don't want to find themselves on the hook for a commercial hosting license.
It just doesn't feel like open source anymore.
You're not offering MongoDB as a service though. I think that part is pretty explicit.
> It just doesn't feel like open source anymore.
I guess it depends on what generation you come from. The GPL was far more popular when I was coming up where as today the Apache License seems to be more popular. They have very different philosophies. I for one see no issue with companies that have invested a lot of money into OSS protect themselves from mega corporations which contribute nothing to the project and simply exploit it. This is more dangerous as the project we all take for granted could then dry up and then we're left with a mega corporation cloud provider offering that isn't interested in improving the software I use.
> It just doesn't feel like open source anymore.
I guess it depends on what generation you come from. The GPL was far more popular when I was coming up where as today the Apache License seems to be more popular. They have very different philosophies. I for one see no issue with companies that have invested a lot of money into OSS protect themselves from mega corporations which contribute nothing to the project and simply exploit it. This is more dangerous as the project we all take for granted could then dry up and then we're left with a mega corporation cloud provider offering that isn't interested in improving the software I use.
> You're not offering MongoDB as a service though. I think that part is pretty explicit.
I agree that I feel like I'm not offering it as a service, but according to your quote, "Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version"
And that does not actually map on to how I would define "offering the program as a service". I think with that definition it would not be difficult to argue that my ferrets using a webapp are "third parties interacting with a modified version of the program remotely through a computer network", because that is in fact what they are doing.
The fact that this might seem like a ridiculous twisting of the intent of "offering as a service" is somewhat immaterial. I'm old enough to have lived through the SCO trial. Companies and their lawyers, when the company is in need of ready cash, will do a lot of shaking of the couch cushions for loose change, and that includes changing how they interpret previously-acceptable behavior with their software.
Even if one argued that my ferret dating site was offering "value which primarily derives from the value of mongo" and failed to win that suit in the courts, I'd still have lost here - I'd still be on the hook for actually defending myself (or just give in to the hypothesized shakedown).
These are all the fears about open source that came from that first SCO trial and persisted via FUD from the 90s version of microsoft: that using open source platforms somehow opens corporations to legal liability, and it was (in part) to allay those fears that the OSI arose.
That's why I'm concerned about this development. I could be 100% overreacting here, but at the end of the day I am not convinced (with either this or the Redis module license thing) that it is possible to micro-target classical SaaS providers with a commercial-only license situation without collateral damage to self-hosters.
I agree that I feel like I'm not offering it as a service, but according to your quote, "Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version"
And that does not actually map on to how I would define "offering the program as a service". I think with that definition it would not be difficult to argue that my ferrets using a webapp are "third parties interacting with a modified version of the program remotely through a computer network", because that is in fact what they are doing.
The fact that this might seem like a ridiculous twisting of the intent of "offering as a service" is somewhat immaterial. I'm old enough to have lived through the SCO trial. Companies and their lawyers, when the company is in need of ready cash, will do a lot of shaking of the couch cushions for loose change, and that includes changing how they interpret previously-acceptable behavior with their software.
Even if one argued that my ferret dating site was offering "value which primarily derives from the value of mongo" and failed to win that suit in the courts, I'd still have lost here - I'd still be on the hook for actually defending myself (or just give in to the hypothesized shakedown).
These are all the fears about open source that came from that first SCO trial and persisted via FUD from the 90s version of microsoft: that using open source platforms somehow opens corporations to legal liability, and it was (in part) to allay those fears that the OSI arose.
That's why I'm concerned about this development. I could be 100% overreacting here, but at the end of the day I am not convinced (with either this or the Redis module license thing) that it is possible to micro-target classical SaaS providers with a commercial-only license situation without collateral damage to self-hosters.
Similarly things happened when MySQL was an independent company in need of cash. Because the license was GPL and GPL law wasn't well established yet they were able to shakedown some companies using MySQL with veiled threats of GPL violations.
MongoDB client drivers are all Apache however.
But yes, I feel you have valid reasons to be concerned.
MongoDB client drivers are all Apache however.
But yes, I feel you have valid reasons to be concerned.
To add to nemo44x's response...
> but ultimately, I'm not confident one can write a license that focus-targets SaaS vendors without potentially exposing just plain mongo users to the same litigation.
I completely understand your trepidation, but I hope I can set your mind at ease about that. From our FAQ (https://www.mongodb.com/licensing/server-side-public-license...):
> What are the implications of this new license on applications built using MongoDB and made available as a service (SaaS)?
> The copyleft condition of Section 13 of the SSPL applies only when you are offering the functionality of MongoDB, or modified versions of MongoDB, to third parties as a service. There is no copyleft condition for other SaaS applications that use MongoDB as a database.
> but ultimately, I'm not confident one can write a license that focus-targets SaaS vendors without potentially exposing just plain mongo users to the same litigation.
I completely understand your trepidation, but I hope I can set your mind at ease about that. From our FAQ (https://www.mongodb.com/licensing/server-side-public-license...):
> What are the implications of this new license on applications built using MongoDB and made available as a service (SaaS)?
> The copyleft condition of Section 13 of the SSPL applies only when you are offering the functionality of MongoDB, or modified versions of MongoDB, to third parties as a service. There is no copyleft condition for other SaaS applications that use MongoDB as a database.
I may be wrong but I believe that the redistribution clause should apply for OSS software to the software itself, and asking to open source some other stack component to use something in a given way is a very novel approach that IMHO is not going to be approved, or if it is, will be a big departure compared to what OSS is right now even in its most rigid incarnation of the AGPL.
A similar but different clause would be: if you want to use that DB then you have to open source the application using it. In this way the friction looks more obvious.
Disclosure: I'm going against my own interests saying that since would be cool for Redis Labs to queue in the same train. But I just believe it's not possible to do it in this way. Nothing against MongoDB itself.
A similar but different clause would be: if you want to use that DB then you have to open source the application using it. In this way the friction looks more obvious.
Disclosure: I'm going against my own interests saying that since would be cool for Redis Labs to queue in the same train. But I just believe it's not possible to do it in this way. Nothing against MongoDB itself.
> it absolutely does not apply any restrictions to using the licensed software. What it does is codify the responsibilities of someone who runs the software as a service.
Potato / potatoe. The imposition of that responsibility is a restriction.
Potato / potatoe. The imposition of that responsibility is a restriction.