4 ms·

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 c

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

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

fche 8y ago

> 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.