Hacker News new | past | comments | ask | show | jobs | submit login

Which part of their explanation for rejecting it do you specifically disagree with?





The entire claim of https://opensource.org/blog/the-sspl-is-not-an-open-source-l... holds down to "the right to make use of the program for any field of endeavor" and the SSPL does not prohibit the use of software in any field of endeavor.

The OSI then strays into a lot of nonsense that demonstrates just how bought and paid for they are, such as "the understanding that their work was going towards the greater good", like apparently... being used by a company which does not open source it's platform and treats its employees so poorly they have to pee in bottles. And of course, they immediately claim that "now... contributions are embedded in a proprietary product" because of course, the OSI believes they own the term and definition of open source, and that everything they don't agree with is inherently "proprietary".

And then of course, they suggest "relicensing is not evidence of any failure of the open source licensing model" even though it is very clear that businesses being unable to survive producing open source is kinda big flaw in the goal of promoting the public software commons. (Taking it a step further, if the FSF argues free software is a moral imperative, not fixing this is outright immoral.)


I think your entire comment can be reduced to you thinking that some limited subset of discrimination based on usage is acceptable, being justified by the market dynamics. That's a fine viewpoint but it simply isn't the accepted definition of "open source". You might not have been aware of that, or you might think that we'd all be better off if that wasn't the case, but those things simply don't change the reality that there is, in fact, a widely understood definition for the term.

The reason people are such sticklers about that particular definition is because the term carries a lot of weight due to the history behind it. Permitting any drift in the ideology enables things that don't match the history to ride on the coattails of the projects that came before.

It's worth noting that if the SSPL is really so beneficial with zero or near zero drawbacks then there's no need to become embroiled in debates over the ideology to begin with. Plainly state that it isn't "open source", make clear what the difference is, and no one will have any room to complain. You can even coin a new term to make room for license variants. If it's a beneficial arrangement then people will naturally use the license.


Still, it's strange to me that the GPL is considered OpenSource while the SSPL is not. When the GPL was first released, its requirement that all linked modules be GPL-licensed wasn't so different from what the SSPL enforces today at the network level. I see the SSPL as analogous to the GPL, and the AGPL as analogous to the LGPL, essentially relaxing the requirements either on linking (in the case of the LGPL versus GPL) or on network interactions (in the case of the AGPL versus SSPL)

> When the GPL was first released, its requirement that all linked modules be GPL-licensed wasn't so different from what the SSPL enforces today at the network level

The “all linked modules” thing does not appear in the text of the GPL as first released or any subsequent version (it is in some versions of the GPL FAQ, but arguably is contradictory to the text of the corresponding license in view of copyright law.)

But that at least was tied to a (even if actually wrong) remotely defensible as good faith interpretation of the boundary of a single work under copyright, and not an attempt to impose licensing terms on unrelated works that merely happened to be used together. And, also, was restricted to a document that purported to interpret the license in th context of the law, even if it arguably did so incorrectly, and not part of the license itself.


Sure, I think your analogy is a reasonable point. There are certainly many different places where the boundary around a functional unit could reasonably be drawn as it pertains to copyright law. There's nothing wrong with having a variety of available choices in that regard when selecting a license.

I think I agree with your analogy. It does sort of seem like SSPL is closing a loophole in the AGPL (which was itself arguably closing a loophole in the GPL). At the same time I don't inherently see an issue with drawing a line about what the ideology does and doesn't include.

One way of interpreting it is that it's a choice that the ideological tenants can include users directly interacting with your program via the network but can't extend to backend network interactions.

Another way of interpreting it is that backend network interactions aren't the issue but rather constraints based around the interpretation of the purpose of a program. The GPL and AGPL arguably regulate based on technical distinctions - is the functional unit constructed using a specific component, is the functional unit what's driving the user interaction. The SSPL on the other hand (specifically the final version that was proposed before being withdrawn [0]) contains the phrases "the primary purpose or features of such Software As A Service" and "the value of the software component of such Software As A Service".

Yet another way of interpreting it is that the current religious leaders just don't want to poke that particular hornets nest right now. That pragmatically speaking the SSPL appears to have a disproportionate impact on an awfully specific business model whereas the existing licenses are much closer to neutral (at least in that regard).

If the boundary is truly being drawn in the wrong place presumably that will be corrected if the error is clearly demonstrated. If the SSPL or something substantially similar becomes widely adopted and ends up facilitating the goals of the ideology in practice then people might be convinced to update their opinions. Even if they don't, as long as user needs are being met I'm not sure it matters what the OSI or FSF or whoever else puts on their list. False negatives (ie omissions) don't seem particularly important here while false positives (ie erroneous inclusions) do.

[0] https://lists.opensource.org/pipermail/license-review_lists....


Thank you and immibis for bringing this issue up. Always thought this was fishy. I don't fully understand this yet and will need to do more research. I bet these comments are unpopular because SSPL hurts GCP/AWS, which hurts YC.

Not saying the mods of HN are conspiring to bury these comments. But the fish rots from the head in upvote-ordered comment trees


I have had my disagreements with dang over the years, but to be clear: I think the HN mods do incredible work. I disagree with some of their choices, but I don't think they moderate with an eye on YC's bottom line.

The OSI and the FSF are still extremely popular organizations despite their very big issues, I fully expect to upset some people when I bring this up. ;)




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: