5 ms·

The definition is not well-accepted. For example, why does the AGPL get a free pass but the SSPL does not? When it comes down to it, there are just a bunch of

The definition is not well-accepted. For example, why does the AGPL get a free pass but the SSPL does not? When it comes down to it, there are just a bunch of people who make arbitrary decisions about what is to be included. But what they include should not matter to you. You should not be making your decision to use software based on whether or not the OSI approved it - unless you don't have the means or expertise to decipher the specific requirements of a language and are more than happy to take the word of this organization for it. Ultimately, the OSI is a protectionist organization which is attempting to prevent a competing organization from using the term "open source" because they don't quite agree on some subtle details that an innovative licensor has chosen to attempt to gain approval of. Whether they gain approval is for the market to decide - not the OSI.

jimktrains2 8y ago
In what way does the agpl even compare to the sspl? The agpl doesn't extend itself to any other software you're running.
- sparkie 8y ago
  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.
geofft 8y ago
The definition is well-accepted; the interpretation of the definition in difficult (and perhaps intentionally-difficult) cases is not. That seems perfectly reasonable and pretty common. The existence of cyan doesn't mean the definition of blue isn't well-accepted. And in any case, I'm not making my decision based on the OSI approving it. I'm making my decision based on my personal consideration that the DFSG expresses principles that are important to me, and the OSD is basically the same thing. (The DFSG, however, does clarify that certain licenses are "a compromise," which seems to have been dropped in the OSD, and I think it's perfectly valid for a definition to have this level of nuance.) I'm making my decision based on my personal belief that "innovating" on these principles isn't great, and the market is the exact opposite of the entity I want deciding on how free/open source software works. For the record, I do actually see the AGPL as "innovating" against the spirit of the DFSG/OSI, although I don't think there's a strong argument that they're non-compliant with the letter of the OSD/DFSG, and I personally avoid it. There's a practical problem that AGPL code becomes unusable when embedded in contexts that don't admit an obvious way to offer source through network interactions (e.g., you can't incorporate something into OpenSSL). But it is innovating in a different way from the SSPL.

jimktrains2 8y ago

In what way does the agpl even compare to the sspl? The agpl doesn't extend itself to any other software you're running.

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

geofft 8y ago

The definition is well-accepted; the interpretation of the definition in difficult (and perhaps intentionally-difficult) cases is not. That seems perfectly reasonable and pretty common. The existence of cyan doesn't mean the definition of blue isn't well-accepted. And in any case, I'm not making my decision based on the OSI approving it. I'm making my decision based on my personal consideration that the DFSG expresses principles that are important to me, and the OSD is basically the same thing. (The DFSG, however, does clarify that certain licenses are "a compromise," which seems to have been dropped in the OSD, and I think it's perfectly valid for a definition to have this level of nuance.) I'm making my decision based on my personal belief that "innovating" on these principles isn't great, and the market is the exact opposite of the entity I want deciding on how free/open source software works. For the record, I do actually see the AGPL as "innovating" against the spirit of the DFSG/OSI, although I don't think there's a strong argument that they're non-compliant with the letter of the OSD/DFSG, and I personally avoid it. There's a practical problem that AGPL code becomes unusable when embedded in contexts that don't admit an obvious way to offer source through network interactions (e.g., you can't incorporate something into OpenSSL). But it is innovating in a different way from the SSPL.