4 ms·

From the OSI FAQ: https://opensource.org/faq#restrict https://opensource.org/faq#restrict ----- Can I restrict how people use an Open Source licensed program

From the OSI FAQ: https://opensource.org/faq#restrict 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.

metheus 8y ago
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.
- antirez 8y ago
  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.
- pfooti 8y ago
  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.
  - nemo44x 8y ago
    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.

metheus 8y ago

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.

antirez 8y ago
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.
pfooti 8y ago
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.
- nemo44x 8y ago
  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.