5 ms·

The AGPL has the requirement that all "derived works" are equivalently licensed. The SSPL does the same, except it has a different definition of what a derived

The AGPL has the requirement that all "derived works" are equivalently licensed. The SSPL does the same, except it has a different definition of what a derived work is, based on a more modern understanding of how software is used and distributed mainly through cloud services. People are using semantic loopholes to sidestep their AGPL requirements (the intended requirements, even if not enforcible). Whether something is a "derived work" is not black and white, but for a court to decide. It isn't at the whim of a panel of OSI judges to decide.

jimktrains2 8y ago
The gpl is defined by the same metrics, so I don't understand what issue you take with the agpl. Moreover, "they're the same because the sspl redefined a term to mean something entirely different" is intellectually dishonest.
- sparkie 8y ago
  You're still missing my point. The AGPL closed a loophole of GPL software that people did not need to release the source code because they never actually released the software (but made it available through a server). We can agree that the AGPL is the successor in spirit of the GPL because it tries to close such loophole and make the software and derived works be required to be published under the license as the author intended. The use of cloud services to sidestep the AGPL requirements is the newest loophole to try and avoid the requirements that the software author intended. The SSPL is in that sense, the spiritual successor to the AGPL attempting to close the loophole, just as the AGPL closed the GPL loophole before it. The problem here is, that we're in unexplored territory. MongoDB is attempting something new and innovative to try and establish what the author of a piece of software expects from the users of that software. Some might argue that the purpose is to extract money, which may or may not be true, but it is beside the point. They should be able to test such licensing and have the market decide whether or not it is acceptable - whether people want stronger copyleft or whether they AGPL is the limit of copyleftness they're willing to accept. "Derived work" has no concrete definition. It is mostly a case of examining previous legal cases for comparison, and coming to a judgement which takes previous cases and the nuances of the specific situation into account. We have a legal system which handles these cases, so that specific organizations don't become the arbitrary rule makers of society. In my opinion, if you're making a user interface which merely wraps an existing database, then you're creating a derived work. The technicalities of whether or not you're "making available" the software shouldn't be the deciding factor. The AGPL, in spirit, requires that people release derived works under it, even if the precise legalese allows you to sidestep it. Work licensed under the SSPL has almost all of the same freedoms AGPL works have, unless you are a cloud provider attempting to wiggle your way around the licensing requirements for derived works, and only then the additional clause steps in. So they have every right to label it as "open source", because the source code is open, and restrictions on its use are few, or irrelevant to most users. The OSI is not the judge of whether or not they are open source. Everyone is their own judge and can call it what they want. This movement by the OSI is clearly an attempt to assert control over the term "open source," to prevent Mongo and others using it if it does not fit their definition. IMO, such efforts should be resisted because they prevent licensing innovation. The OSI would become the obstacle to trying new open licensing schemes. They are not an unbiased party like a legal court - they have a vested interest in their current licensing definition and are protectionist in not wanting competing definitions.
  - jimktrains2 8y ago
    > The use of cloud services to sidestep the AGPL requirements is the newest loophole to try and avoid the requirements that the software author intended. See, I disagree with you wholly here. Cloud-based services are literally what the AGPL was designed to "counter". Changes to the application _itself_ need to be released, but anything supporting said application is out-of-scope of the license. > "Derived work" has no concrete definition. I think the definition given by the copyright office is as close as we'll get. [2] >> A derivative work is a work based on or derived from one or more already exist-ing works. Common derivative works include translations, musical arrange-ments, motion picture versions of literary material or plays, art reproductions, abridgments, and condensations of preexisting works. Another common type of derivative work is a “new edition” of a preexisting work in which the edito-rial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work. >> To be copyrightable, a derivative work must incorporate some or all of a preexisting “work” and add new original copyrightable authorship to that work. Specifically that last sentence quoted. Management software that does not contain the original code is not a derived work. > Work licensed under the SSPL has almost all of the same freedoms AGPL works have, unless you are a cloud provider attempting to wiggle your way around the licensing requirements for derived works, and only then the additional clause steps in. I also wholly disagree with you here. SSPL violates the 4 Freedoms [1], and as such is substantially different. It's not something that you can go, "well, but I don't like that, so I'm not going to include it in my definition of equal". Freedom 0 ("The freedom to run the program as you wish, for any purpose") cannot be "qualified with "conditions", otherwise it is not a freedom. Freedom 0 is also fundamental for the other Freedoms to even be meaningful. [1] https://www.gnu.org/philosophy/free-sw.en.html https://www.gnu.org/philosophy/free-sw.en.html [2] https://www.copyright.gov/circs/circ14.pdf https://www.copyright.gov/circs/circ14.pdf
    - sparkie 8y ago
      > A derivative work is a work based on or derived from one or more already exist-ing works. A management software might be considered a derived work, depending on how coupled it is with the underlying software. There is no black and white definition. The FSF state[1] >> Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged). >> So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program. [1]:https://www.gnu.org/licenses/gpl-faq.html#MereAggregation https://www.gnu.org/licenses/gpl-faq.html#MereAggregation > Freedom 0 ("The freedom to run the program as you wish, for any purpose") How does the SSPL violate the freedom in a way that the AGPL does not? The AGPL places a condition on this freedom. The condition that if you make the work available through a public server, then you must make the source code available too. The SSPL is attempting to do the same for what it perceives as derived works (the management software, which is useless without the underlying software). It doesn't place any restriction on use, because you are still free to use it. You just have the condition that you make the code of your derived works available too, similar to the AGPL.

jimktrains2 8y ago

The gpl is defined by the same metrics, so I don't understand what issue you take with the agpl. Moreover, "they're the same because the sspl redefined a term to mean something entirely different" is intellectually dishonest.

sparkie 8y ago
You're still missing my point. The AGPL closed a loophole of GPL software that people did not need to release the source code because they never actually released the software (but made it available through a server). We can agree that the AGPL is the successor in spirit of the GPL because it tries to close such loophole and make the software and derived works be required to be published under the license as the author intended. The use of cloud services to sidestep the AGPL requirements is the newest loophole to try and avoid the requirements that the software author intended. The SSPL is in that sense, the spiritual successor to the AGPL attempting to close the loophole, just as the AGPL closed the GPL loophole before it. The problem here is, that we're in unexplored territory. MongoDB is attempting something new and innovative to try and establish what the author of a piece of software expects from the users of that software. Some might argue that the purpose is to extract money, which may or may not be true, but it is beside the point. They should be able to test such licensing and have the market decide whether or not it is acceptable - whether people want stronger copyleft or whether they AGPL is the limit of copyleftness they're willing to accept. "Derived work" has no concrete definition. It is mostly a case of examining previous legal cases for comparison, and coming to a judgement which takes previous cases and the nuances of the specific situation into account. We have a legal system which handles these cases, so that specific organizations don't become the arbitrary rule makers of society. In my opinion, if you're making a user interface which merely wraps an existing database, then you're creating a derived work. The technicalities of whether or not you're "making available" the software shouldn't be the deciding factor. The AGPL, in spirit, requires that people release derived works under it, even if the precise legalese allows you to sidestep it. Work licensed under the SSPL has almost all of the same freedoms AGPL works have, unless you are a cloud provider attempting to wiggle your way around the licensing requirements for derived works, and only then the additional clause steps in. So they have every right to label it as "open source", because the source code is open, and restrictions on its use are few, or irrelevant to most users. The OSI is not the judge of whether or not they are open source. Everyone is their own judge and can call it what they want. This movement by the OSI is clearly an attempt to assert control over the term "open source," to prevent Mongo and others using it if it does not fit their definition. IMO, such efforts should be resisted because they prevent licensing innovation. The OSI would become the obstacle to trying new open licensing schemes. They are not an unbiased party like a legal court - they have a vested interest in their current licensing definition and are protectionist in not wanting competing definitions.
- jimktrains2 8y ago
  > The use of cloud services to sidestep the AGPL requirements is the newest loophole to try and avoid the requirements that the software author intended. See, I disagree with you wholly here. Cloud-based services are literally what the AGPL was designed to "counter". Changes to the application _itself_ need to be released, but anything supporting said application is out-of-scope of the license. > "Derived work" has no concrete definition. I think the definition given by the copyright office is as close as we'll get. [2] >> A derivative work is a work based on or derived from one or more already exist-ing works. Common derivative works include translations, musical arrange-ments, motion picture versions of literary material or plays, art reproductions, abridgments, and condensations of preexisting works. Another common type of derivative work is a “new edition” of a preexisting work in which the edito-rial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work. >> To be copyrightable, a derivative work must incorporate some or all of a preexisting “work” and add new original copyrightable authorship to that work. Specifically that last sentence quoted. Management software that does not contain the original code is not a derived work. > Work licensed under the SSPL has almost all of the same freedoms AGPL works have, unless you are a cloud provider attempting to wiggle your way around the licensing requirements for derived works, and only then the additional clause steps in. I also wholly disagree with you here. SSPL violates the 4 Freedoms [1], and as such is substantially different. It's not something that you can go, "well, but I don't like that, so I'm not going to include it in my definition of equal". Freedom 0 ("The freedom to run the program as you wish, for any purpose") cannot be "qualified with "conditions", otherwise it is not a freedom. Freedom 0 is also fundamental for the other Freedoms to even be meaningful. [1] https://www.gnu.org/philosophy/free-sw.en.html https://www.gnu.org/philosophy/free-sw.en.html [2] https://www.copyright.gov/circs/circ14.pdf https://www.copyright.gov/circs/circ14.pdf
  - sparkie 8y ago
    > A derivative work is a work based on or derived from one or more already exist-ing works. A management software might be considered a derived work, depending on how coupled it is with the underlying software. There is no black and white definition. The FSF state[1] >> Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged). >> So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program. [1]:https://www.gnu.org/licenses/gpl-faq.html#MereAggregation https://www.gnu.org/licenses/gpl-faq.html#MereAggregation > Freedom 0 ("The freedom to run the program as you wish, for any purpose") How does the SSPL violate the freedom in a way that the AGPL does not? The AGPL places a condition on this freedom. The condition that if you make the work available through a public server, then you must make the source code available too. The SSPL is attempting to do the same for what it perceives as derived works (the management software, which is useless without the underlying software). It doesn't place any restriction on use, because you are still free to use it. You just have the condition that you make the code of your derived works available too, similar to the AGPL.