>"... use directly to provide that service": this falls under contract law, not copyright law. Licenses fall under copyright law, not contract law. Licenses dic

>"... use directly to provide that service": this falls under contract law, not copyright law. Licenses fall under copyright law, not contract law. Licenses dictating terms beyond the scope of the copyrighted work, which is what the SSPL does, is copyright abuse and legally invalid. Copyleft licenses, including the GPL family, work strictly within copyright law; the terms they dictate apply only to the copyrighted work. Yes, derivatives of copyrighted work fall under the same copyright. No, "... use directly to provide that service" does not qualify as derivative work and thus does not fall under the copyright of the original work. I think that there's some room here. The links that you gave had two examples, the Lasercomb case and the Sandisk case. The SSPL isn't like either of those. From your first link: > For example, in Lasercomb, the license agreement required the licensee to > agree not to develop a competitive computer-aided design program for 99 > years. Lasercomb America v. Reynolds. 911 F.2d 970, 15 USPQ2d 1846 (4th > Cir. 1990). In Practice Management Information Corp. v. American Medical > Ass'n 121 F.3d 516 (9th Cir. 1997) the AMA licensed “CPT” health care > codes (in which the AMA claimed a copyright) on a condition that the > licensee not use any other such competing codes. In Assessment > Technologies v. WIREdata. 350 F.3d 640 (7th Cir. 2003), the copyright > holder tried to limit the licensee’s access to the licensee’s own data > stored using the software. This defense is almost always applied to > prevent a copyright holder from leveraging its copyright to impose > anti-competitive practices. In other words, what we're looking at here is, "Now that you have accepted our license terms, you can't build a competing software, with no out" What the SSPL says (paraphrasing) is "If you can't offer our product as SaSS on an SSPL stack, then you can't offer it (see 12. No Surrender of Others Freedom)." It doesn't say, "by using our software, you are not allowed to build a competing product." Let's look at SanDisk: >SanDisk had a patent licensing program that required any licensee to provide a grant-back license to any subsequently-developed patents in the same field of use. Two courts examined SanDisk's program under both the antitrust and patent misuse angles. In other words, SanDisk said, "if you use our license, we can use anything else in this space that you license." MongoDB is not saying, "now that you have licensed Mongo, you MUST SSPL regardless of whether you are currently using Mongo." Again, point 12 comes into play here. You are allowed to simply /not/ use Mongo. You have an out. The requirement of having a stack under SSPL or compatible license is a precondition for being allowed to provide Mongo as a service, not a limitation of what you can do after the fact. In other words, if the company sued over SSPL can't or won't release their stack, then they just can't provide Mongo as a service. That is, I think an enforceable outcome within the bounds of copyright: "if you do X, you can't use our copyrighted material." Thus I think your point of the SSPL being unenforceable is incorrect. Of course, this is interpretation, IANAL, and we won't truly know the result of this until it hits a court. >This is not how open source licenses work — open source licenses do not confer ownership of copyright by mere usage — so I don't know what your point is. You've misunderstood me. I mean that providers lose the ability to use closed source code in the providing of the service. The statement you were quoting was said with the presumption that "you" (in the general sense) were the provider of the service, who also owned the copyright to said closed source code used to provide said service, and that the thing lost was the ability to keep that software closed-source. >SSPL is not an open-source license What, because some committee says it isn't? Very well, open-source in the colloquial sense, as in "I can read the source code, modify it, and run it if I wish."